Fix 32-bit unit test failures

[jlblancoc]

Closes #308
Closes #306

Don't merge until these PPA builds end, to confirm that the test errors have been fixed.

Update: It can be merged now, PPA builds pass!

---

This change is 

[dellaert]

Seems to say

buildsPackage build summary
A total of 92 builds have been created for this PPA.

Completed builds
23 successful
69 failed

[jlblancoc]

Yes... it still fails, but now because of #306, will try to fix it too in this pr.

[jlblancoc]

PS: you have to click on a package version on the bottom, the click on one of the platform that fails, then buildlog to see all the details.

[dellaert]

Nice!!

[dellaert]

@jlblancoc please delete the branch when you’re done with it. I just realized maybe you were using it to push more changes.

SymmetricBlockMatrkx is pretty core: wondering what other bugs were caused by this. Although, now that I think more about it, I’m wondering whether I pushed merge too fast: is the semantics of the constructor to deliver a zero matrix, or just an allocated one? Perhaps the bug was caused by code that incorrectly assumed it would get zeros...

[jlblancoc]

Branch deleted, no problem.

I guess the "problem" here is that SymmetricBlockMatrix expects to get all its entries correctly initialized by its caller, and this QP code was NOT filling in some of the entries... (it was filled to zeros, apparently only by accidents that depends on the architecture and Eigen implementation).
Now, what to do at the API level:

• If you prefer to DETECT non-filled entries, maybe the hessian could be initialized to quietNAN instead of zeros?
• Or, to keep it as is, with zeros to be "benevolent" with "user" errors, or even document that behavior so zeroes in information matrices don't need to be filled it and save some time.

Not sure what's better.

[dellaert]

I think we actually have a flag that enables the Nan behavior. I think perhaps in debug the flag should be on by default, and we fill everything with Nan, while in Release we just allocated. Comments?

[jlblancoc]

I'll think about this. There may be another way to fix the bug that doesn't mask possible future bugs due to uninitialized values...

[jlblancoc]

Definitively, I think you are right, Frank: it might be better NOT to initialize to zeros, since it has a cost (vs. leave uninitialized) that may be relevant when building very large graphs. And all just to "fix" apparently buggy code... Will come back with another PR.