On 11-Sep-2014 10:23, Nathan Hurst wrote:
Ok, that's another vote for using double precision everywhere. That gets us 14-15 digits, which should be enough for anybody.
Adding more digits to the numerical representation does not in itself provide numerical stability, it just makes it easier to sweep the problem under the carpet of "looking at a smallish number of digits".
Conversely, at least with respect to this units question, numerical stability, which for the purposes of this conversation means when a diff of two SVG's shows no changes, can be achieved if the lengths and coordinates inside the document are never changed, instead only one transform (or its equivalent) at the top level is. Then an end user could flip endlessly between different document units and never corrupt the numerical representations in the drawing. The only change that would show up, if no other changes were made, would be the values for that one transform.
This assumes that the code did this:
"we are currently using mm, user wants inches, REPLACE document unit transform with the pixels to inch transform"
If instead it did:
"we are currently using mm, user wants inches, MULTIPLY document transform by mm to inches conversion"
then the single unit transform itself might not be numerically stable. (It could be if all of the units scaling factors have terminating binary representations with precision to spare, and the same is true for all combinations of their products.)
Regards,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
Actually, with enough extra bits of precision you do indeed get the right behaviour. And it's not sweeping anything under the rug, it's simply accepting that every calculation has a loss of precision. Conversion between units will cost about 0.5 sp every time, which seems pretty reasonable.
At the cost of appeal to authority, I've actually implemented quite a lot of arbitrary precision numerics, so I know what I'm talking about :)
njh
On Thu, Sep 11, 2014 at 01:01:17PM -0700, mathog wrote:
On 11-Sep-2014 10:23, Nathan Hurst wrote:
Ok, that's another vote for using double precision everywhere. That gets us 14-15 digits, which should be enough for anybody.
Adding more digits to the numerical representation does not in itself provide numerical stability, it just makes it easier to sweep the problem under the carpet of "looking at a smallish number of digits".
Conversely, at least with respect to this units question, numerical stability, which for the purposes of this conversation means when a diff of two SVG's shows no changes, can be achieved if the lengths and coordinates inside the document are never changed, instead only one transform (or its equivalent) at the top level is. Then an end user could flip endlessly between different document units and never corrupt the numerical representations in the drawing. The only change that would show up, if no other changes were made, would be the values for that one transform.
This assumes that the code did this:
"we are currently using mm, user wants inches, REPLACE document unit transform with the pixels to inch transform"
If instead it did:
"we are currently using mm, user wants inches, MULTIPLY document transform by mm to inches conversion"
then the single unit transform itself might not be numerically stable. (It could be if all of the units scaling factors have terminating binary representations with precision to spare, and the same is true for all combinations of their products.)
Regards,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.cl... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
mathog wrote
"we are currently using mm, user wants inches, MULTIPLY document transform by mm to inches conversion"
then the single unit transform itself might not be numerically stable.
Personally I expect this behavior. I see changing the document unit (not the GUI input and visualization unit) as a deep operation that means that all internal numbers should be recalculated with respect to this new selected unit, if this is really what the user wants. I see the "document unit" as the user selection about how the numbers should be internally represented. Of course if you change the document unit having existing objects already created in a different unit, rounding errors could happen in the conversion. I assume that one usually first selects the document unit and then starts drawing. The document unit is not supposed to change at all during a document lifetime, unless a real need arises and then you should know what you are doing. If this is the case, Tav's description perfectly fits; unless I misinterpreted it and what he meant was that only the root viewbox was going to change and so 1 mm would become 1 inch (this sound so crazy that I feel it can only be a wrong interpretation).
Luca
-- View this message in context: http://inkscape.13.x6.nabble.com/Units-in-Inkscape-tp4971507p4971528.html Sent from the Inkscape - Dev mailing list archive at Nabble.com.
participants (3)
-
LucaDC -
mathog -
Nathan Hurst