Inkscape precision not as high as promised?

[theozh]

the following is the bit shortened version of discussion:
http://www.inkscapeforum.com/viewtopic.php?f=22&t=32160

It seems that Inkscape generates some "arbitrary random numbers" when it comes to high precision.

Three example cases:
a) Assuming you type in a rectangle width 40 mm, you will see a width 40 in the XML-editor. Fine!

b) Although the "Tools control bar" displays only 3 digits after the decimal point you can enter more digits there.
If you enter 10.0005 you will get for example 10.0004997253418 in the XML-editor. Unexpected!

c) Create a guide, double click on it and enter 100, 200 for the origin.
What you will get in the XML-Editor: 100.0000002623867,200.0000005247733 which is unexpected. I never got 100,200 for the guide.

Well, yes, you can tell me that this is academic or this and that precision is enough for practical purposes.
However, if a program tells me that it has a certain precision but in reality it creates some arbitrary random numbers I would like to know the reason why it does so.
This looks to me that Inkscape claims to allow for a precision of 16 digits but in reality it handles maybe just only 8 digits. Is it maybe some internal LongInt, ShortInt, Extended, ... or whatever back and forth number conversions?
If Inkscape calculates internally with 8 digits, then an output of 16 digits is just nonsense.

Maybe somebody can explain to me?

[Mc (mc...)]

see https://www.w3.org/TR/SVG/types.html#Precision

"
Unless stated otherwise for a particular attribute or property, a <number> has the capacity for at least a single-precision floating point number and has a range (at a minimum) of -3.4e+38F to +3.4e+38F.

It is recommended that higher precision floating point storage and computation be performed on operations such as coordinate system transformations to provide the best possible precision and to prevent round-off errors.

Conforming High-Quality SVG Viewers are required to use at least double-precision floating point for intermediate calculations on certain numerical operations.
"

I think even if most codepaths uses single precision floats, some might use double precision (for paths, probably), and that lib2geom is templatable for precision. (see also the IEEE 754-2008 standard for conversions)

[theozh (theozh)]

Thanks, @Mc for that info.
Maybe another example which might help to identify the detailed origin:

When rescaling objects and let them snap to existing fixed and unchanged nodes you also will get "arbitrary random numbers".
More info:
http://www.inkscapeforum.com/viewtopic.php?f=5&t=32113

...looks like there is a quantisation of the "arbitrary" numbers of 1.907348e-6 which is 2^-19. Whatever that means... and wherever it comes from...