Inkscape precision not as high as promised?
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Inkscape |
New
|
Undecided
|
Unassigned |
Bug Description
the following is the bit shortened version of discussion:
http://
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.00000026238
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?
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)