Rounding errors when moving a path

I agree that seeing numerical error like this is extremely annoying. However, I don't think that it is completely clear that switching from absolute coordinates to relative coordinates will actually solve the problem. For example if that were the case then in the example you gave:

m 60.000004,-28.571429 99.999996,0 0,-100.000001 -99.999996,0 z

one would expect that the first number should be 60, not 60.000004. The roundoff error in all the other numbers can be blamed on relative/absolute conversions, but the first number is not affected by such conversions, so there may be some other roundoff problem that is to blame.

Yes, the 60.000004 is actually strange - especially since I moved the path around freely with the mouse (without any snapping or the like). So it should be highly unlikely to move it exactly to x=60 anyway. Therefore I won't give too much thought on that. ;-)

Do I understand you correctly that Inkscape's current behavior is to convert all nodes to absolute coordinates before translating the path, then doing the translation, then converting back to relative coordinates? Since this would perfectly explain the numerical error in the nodes (that is obviously correlated).

I agree with you that exclusively relying on relative coordinates won't solve rounding errors of the first node. However if all following nodes keep untouched, the shape of a path is always maintained and it's impossible to accumulate rounding errors by repeatedly translating the path. Little errors of the first node will only lead to negligible errors in the paths absolute position (and it doesn't harm if these errors accumulate since one always can move the path to the wanted coordinates again).

>> Do I understand you correctly that Inkscape's current behavior is to convert all nodes to absolute coordinates before translating the path, then doing the translation, then converting back to relative coordinates?

Actually I don't know. I did not mean to imply that this was the case. All I know is that the roundoff problem is more complex than just the issue of absolute vs. relative.

Same thing happens with the stroke width on some items (Bug #1093742).