Re: What is 0.01 here not 0.01 here 0.009999999999999?

[John Yates <john@yates-sheets.org>]

> I did not find the word "significand", but I think you mean that above
> definition.

https://en.wikipedia.org/wiki/Significand

> Yes, I need arithmetic on imprecise representations... to deliver what
> I want, and it is doing what I want. `calc-eval' is doing it, and my
> function is delivering me string that is increased for 0.01 -- well
> that is what I wanted, and is happening... several times per hour
> those numbers are increasing, function is working ;-p

This will probably work because each time you increment by an
approximation of 0.01 you convert back to a decimal representation
via a path that applies a number of heuristics to guess what value
you want to see.  Having rendered your incremented value as a
decimal string, when you read it back in you _do not_ recreate
a bit for bit copy of the earlier sum, but rather a floating point
number that is the closest approximation possible to the decimal
number being presented.  Put another way, each output / input
iteration prevents you from accumulating errors.

If you wanted to support more general arithmetic on your version
numbers I would advise using scaled integer arithmetic.  Assuming
that you can guarantee the granularity of your version numbers will
always be 0.01 then you can represent 0.01 as 1 and 11.07 as
1107.  Then to recover the major version you just divide by 100 and
to recover the minor version you mod by 100.

Using 100 is necessary if you want 10.99 + 0.01 to return 11.00.
If you never expect to handle a carry from your minor version field
into your major version field then you could scale by a power of
two (e.g. 128).  Then division reduces to right shifting and mod
to masking (e.g. for 128 that means anding with 127).

/john