QCAD - 2D CAD System.

Click here for a documentation of the DokuWiki formatting syntax that can be used in reports

Please search for existing tasks (also closed ones) before opening a new task.

Please make sure that you are using the latest Version of QCAD before posting a bug (menu Help > Check for Updates)


FS#137 - SVG Export precision

Attached to Project: QCAD
Opened by Peter (hungerburg) - Friday, 08 July 2011, 16:50 GMT+2
Last edited by Andrew (andrew) - Thursday, 14 July 2011, 16:10 GMT+2
Task Type Refactoring
Category QCAD (main)
Status Assigned
Assigned To Andrew (andrew)
Operating System All
Severity Low
Priority Normal
Reported Version Development
Due in Version Post 3.0
Due Date Undecided
Percent Complete 0%
Votes 0
Private No


In files exported with the (even PG) exporter I sometimes see values like these: 334.99999999999994 or 570.0000000000001 and very often 12 digits of precision.

To safe on file size, I suggest, that QCAD rounds values on SVG export to eg. three places. When viewed in an ordinary web browser, that will result in a precision of 1 inch / 96dpi / 1000 = 0.00026mm, not? Ends should still meet.

This task depends upon

Comment by Peter (hungerburg) - Sunday, 10 July 2011, 20:46 GMT+2

This one is very similar to #138 - as said there, filesize is not an issue. But it might point at some floating point misbehaviour somewhere - so I do not request closure now.

Comment by Peter (hungerburg) - Monday, 12 September 2011, 20:31 GMT+2

Such floating point issues also appear in dxf files. While in the GUI numbers appear as entered, they are serialized wrongly to file.

Comment by Andrew (andrew) - Monday, 12 September 2011, 20:54 GMT+2

The GUI rounds numbers for convenience.

Internally (inside the QCAD software and in DXF/DWG files), there will always be rounding errors.

It's a broad topic, but briefly it has to do with the way how computers store numeric values (binary floating-point). Surprisingly, computers cannot even represent 0.1 accurately but only as an approximation of 0.1000000000000000055511151231257827021181583404541015625. This is not a bug in QCAD but a limitation of computer hardware floating-point arithmetic.

Once you start doing arithmetic with such a value, the error may increase (e.g. through scaling).

Comment by Peter (hungerburg) - Tuesday, 13 September 2011, 14:42 GMT+2

I would expect a calulator to print 1, when I do " 1 / 10 * 10" instead of 1.000000000000001 or such. I now skimmed http://docs.python.org/tutorial/floatingpoint.html which gives a thorough overview. The python developers seem to have a solution for cases like these: "In current versions, Python displays a value based on the shortest decimal fraction that rounds correctly back to the true binary value […]" Maybe current hardware supports that, and gcc / the gnu C-library?

Am I wrong, when I consider the dxf or svg serialization of the QCAD state not as internal, but external? Am I "päpstlicher als der Papst?"

Comment by Peter (hungerburg) - Saturday, 01 October 2011, 15:00 GMT+2

Hmm, does not look too well for me: also the javascript interpreter has the problem of fake precision, eg. in the qt debugger:

qsdb> .eval 0.15/0.05 gives 2.9999999999999996 instead of just 3. (While 0.05/0.05 will corretly yield 1.)

The state of the art javascript way of presenting users with nice floats could be prototyped like this:

Number.prototype.toNice = function(prec) { return parseFloat(this.toFixed(prec)); }

which is not nice at all, because sadly, the intrinsic number to string conversion done when writing cant be overridden (it is not Number.toString(), which of course could be overridden). After all, this may just an aesthetical problem, not worth the effort.