QCAD Bugtracker

  • Status Assigned
  • Percent Complete
    0%
  • Task Type Refactoring
  • Category QCAD (main)
  • Assigned To
    Andrew
  • Operating System All
  • Severity Low
  • Priority Very Low
  • Reported Version Development
  • Due in Version Post 3.0
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: QCAD Bugtracker
Opened by Peter - 08.07.2011
Last edited by Andrew - 14.07.2011

FS#137 - SVG Export precision

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.

Peter commented on 10.07.2011 18:46

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.

Peter commented on 12.09.2011 18:31

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

Admin
Andrew commented on 12.09.2011 18:54

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).

Peter commented on 13.09.2011 12:42

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?"

Peter commented on 01.10.2011 13:00

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.

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing