On Fri, Nov 18, 2005 at 10:43:48AM +1100, Kinsley Turner wrote:
- somewhere in between allows a user to specify how many digits to round off eg. .750 >> .75, 143.23123576 >> 143.231
...
It might be more useful to let a user specify the number of significant digits. This should give much more consistent results.
How about to within an error margin...
You lose alot more detail rounding 1.4444 -> 1 rather than rounding 1.9999 -> 2
Maybe what is needed is a kind of 'normalise'.
Think of a particularly bad case for rounding, say a rectangle with the left side with an X of 1.5 and the other at 3.0 Say you rounded to 0dp, then the left side moves 30%, but the right side moves 0. I wonder if you could not massage the points a bit so they both move around the same sort of amount.
Would this preserve the 'image' better?! (*shrug*)
There's some code I wrote a long time ago that does these sorts of number formatting mechanisms. It's in the 'experimental' cvs module under bryce/ftos/ if anyone would like to play with hooking it up for Inkscape.
It does the basic "drop trailing 0's" stuff, plus has options for doing sigfigs and controlled precision. Usage:
// string ftos(double val[, char mode[, int sigfig[, int precision[, int options]]]])
// sigfig - the number of significant figures. These are the digits // that are "retained". For example, the following numbers // all have four sigfigs: // 1234 12.34 0.0001234 1.234e-10 // the last digit shown will be rounded in the standard // manner (down if the next digit is less than 5, up otherwise.) // // precision - the number of digits to show to the right of the decimal. // For example, all of the following numbers have precisions // of 2: // 1234.00 12.34 0.00 1.23e-10 123.40e-12 //
(It's got some other formatting features like engineering style, or with 42x10^12 instead of 42E12, although obviously we wouldn't need those styles.)
Anyway, I think the work of hooking this up would involve adding a user preference variable somewhere for keeping track of the preferred sigfigs and then inserting this ftos() routine at the point where numbers get exported, and of course some GUI stuff for the user to type in their desired sig fig value. Maybe there's more to it beyond that... I think pjrm looked at it at one point so he'd be a good one to ask.
It'd be interesting to see how badly the rounding would affect things. I'd done some analysis to see how the rounding propagated (for an engineering program I was developing), and found that even small errors would tend to propagate pretty quickly, but if it's only used during document save, as it would be in Inkscape, then the impact may be minimal.
Personally, it was only the excessive .00000's that bugged me, and I was happy to see Peter fixed that; I don't mind so much that there are extra digits in other numbers, but certainly for numbers like 1.999999 or 0.7500001 it would be nice to see those rounded off. If anyone's bugged enough to want to fix it, feel free to play with ftos() and if it'd work ok.
Bryce