On Thu, Jun 20, 2013 at 11:48:09PM +0200, Johan Engelen wrote:
On 18-6-2013 4:06, Matthew Petroff wrote:
Over the past two weeks, I have looked at Inkscape's code, outlined existing unit support, and planned my approach to refactoring it.
http://www.mpetroff.net/archives/2013/06/17/current-state-of-units/
Something to add to the list is "lossless" storing of dimensions and units. I.e., if working with mm as document unit, 10mm should stay 10mm without rounding errors sneaking in and turning it into 10.00001mm.
This brings up an interesting/important point: what is the correct interpretation of 10mm. Is it more precise or less precise than 10.000mm, 10.001mm? [1]
To the mathematician me, 10 == 10.000, 10 != 10.001 To the engineering me, 10 == 10.000 == 10.001; but 10.000 != 10.001
This is one reason why scientific notation is so elegant - the precision is encoded in the number of digits in the mantisa. 1e1 is less precise than 1.0e1, the first is expected to only be right to the first digit, the second to 2 digits.
We could have a numeric class which keeps track of both the value and the precision and correctly propagates these. Better still would be to use something like affine arithmetic which gives fairly tight bounds on the true precision, all the time maintaining a conservative bound on the error. This would tie in nicely to better boolean ops and the various clipping operations which we have talked about for the last decade or so :) Furthermore, the same machinery for affine arithmetic can also be used to implement some of the logic for 'px' vs '%' vs 'mm' units - we can treat these three as having separate variables (in the statistics sense) and the calculation will work out correctly.
njh [1] We can't do much about accuracy :)