Decimal values rounded on save

[Linus Torvalds]

On Mon, Sep 3, 2012 at 10:00 AM, Linus Torvalds
<torvalds at linux-foundation.org> wrote:
>
> Interesting. Trying it on Linux, I did see *one* rounding issue (depth
> of "0.019 m" was somehow saved as "0.018 m" - I'll look into it)

Oops. I should have looked closer. The depth value was actually
*negative* at that point (61:16 minutes into the dive). So you were 19
mm *above* the water according to your divelog. Funny ;)

And that does explain the '-0.019 -> -0.018' rounding. What is going
on is  that we round to the nearest mm by doing:

  depth->mm = val.fp * 1000 + 0.5;

and if "val.fp" is -0.019, we get "-19" mm, but then when we assume
that the float-to-int rounding rounds *down*, so the "+0.5" is about
fixing that. However, it actually rounds-to-zero, which shouldn't
matter, but since you have a negative depth, you'll get -18 mm.

So every time you load an xml file with negative depth values, those
depth values will be one mm less. That said, if the value had actually
been much *more* negative (-1.019, for example), we wouldn't have
parsed it as a number at all because we have some legacy "look at it
as an integer first" code that refuses negative integers (but "-0"
will pass as zero).

Ho humm. I guess we should use "rint()", or just avoid floating point
entirely. We do the "+ 0.5" a *lot*, just because we always expect
these things to be positive.

Where the heck did you get those original values from?

Anyway, none of this explains the crazy windows "truncate to integer"
problem. The above obviously *does* create an integer depth, but it's
an integer depth in *mm*, not in meters.

               Linus