Constrained noisemodels cannot be serialized if they contain precisions with inf

Issue #23 resolved
Alex Cunningham created an issue

When running unit tests with serialization enabled, the tests for constrained noisemodels fail that use text or XML archives fail due to the presence of any inf/NaN float values appearing in the data structure. When the precisions are included for the constrained noisemodel, they will always be inf, so deserializing them will result in an "input stream error" from boost serialization. It's a known boost serialization problem that inf/NaN cannot be reconstructed from text, though binary serialization works.

One option is to have the constrained model change the values of the precisions that would get set to inf using a mask over the constrained dimensions.

Comments (7)

  1. Frank Dellaert

    I like your solution: the "mask" is just the zero sigma values, I presume. The constructors

          /** protected constructor takes sigmas */
          Constrained(const Vector& sigmas = zero(1)) :
            Diagonal(sigmas), mu_(repeat(sigmas.size(), 1000.0)) {}
    
          // allows for specifying mu
          Constrained(const Vector& mu, const Vector& sigmas) :
            Diagonal(sigmas), mu_(mu) {}
    

    Don't have to call that Diagonal constructor: they can fill in invsigmas_ and precisions_ with 0 where sigma is 0.

    BTW, I did not test serialization, but I am assuming that all other uses of Constrained were unit-tested?

  2. Alex Cunningham reporter

    I didn't have any other problems with Constrained, so it should just be the unit test.

    I'm implementing the fix right now for noisemodel. One question: is there a reason to for the default constructor for Diagonal to actually fill in those vectors with dummy values? Right now, it sets the sigmas/invsigmas/precisions to ones(1), which does some allocation that will be largely useless, and it's already protected from direct use by users.

  3. Alex Cunningham reporter

    All tests now pass properly, though there is some room for optimization in the checks for values of sigmas_

  4. Frank Dellaert

    Great! yes, I noticed that you check for 1/sigma. Why not simply check that sigma(i) is zero?

  5. Alex Cunningham reporter

    I wasn't quite sure whether there was a range of sigmas for which 1/sigma is inf and checking 1/sigma didn't require choosing a threshold.

  6. Log in to comment