Codecov Report

Merging #144 into noetic-devel will increase coverage by 0.32%.
The diff coverage is 100.00%.

@@               Coverage Diff                @@
##           noetic-devel     #144      +/-   ##
================================================
+ Coverage         55.54%   55.86%   +0.32%     
================================================
  Files                11       12       +1     
  Lines              1723     1722       -1     
================================================
+ Hits                957      962       +5     
+ Misses              766      760       -6     

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 4538c9b...5172b9d. Read the comment docs.

The rationale for passing the precision and setting it one order "higher" than the precision used for comparison was because I didn't like errors like:

The given transform is not an isometry! It's linear part involves scaling: 1 1 1

But if it seems over-engineered to you, I can make the precision hard-coded which would simplify the code.

But if it seems over-engineered to you, I can make the precision hard-coded which would simplify the code.

I was expecting the 1 1 1 error output as the underlying reason for this change. What about a message like this:
"The linear part involves a scaling, which deviates from identity by %f", max(abs(scaling - ones())

I'm not for introducing other possible rounding/representation errors. I was also thinking about subtracting ones, but in the end I think that showing the raw computed values is more valuable.

Thanks. I'm open to discussion.

I'm not for introducing other possible rounding/representation errors.

I don't think you introduce new rounding errors by the proposed approach. You will just focus on the deviations from the expected values.

I was more concerned about representation errors of IEEE floats. In 32 bits, There are approx 2^30 numbers between 0 and 1, and only 2^23 between 1 and 2. But I don't think that if you take a number from 1-2 range and subtract one, you'd have a guarantee that you'll find a corresponding normal float in the 0-1 range.

However, since these values are anyways computed by SVD, they probably accumulate so many errors during the computation that caring about the representation of the result can be seen as a negligible issue...

So, okay, you convinced me to subtract ones and use the scientific format :)