translate([90, 190, 0])
    cylinder(r = 2, h = 100, center = true);

After updating openscad I noticed some of my generated DXF sheet drawings have very small numbers like 3.02425e-14 at the corners where they had 0 before. I tracked it down to a sequence of rotates by 90 degrees corrupting the (0,y) vertices. It probably corrupts all of them but 3.02425e-14 + x where x is an integer isn't representable in a float so they get rounded to whole numbers. I distilled it down to a simple example like this: - projection(cut = true) rotate([0, 0, 90]) difference() { translate([0, 0, -1.5]) cube([100, 200, 3], center = false); translate([90, 190, 0]) cylinder(r = 2, h = 100, center = true); } Removing the cylindrical hole gives accurate zeros, so it looks like rotate is like translate in that it has different precision operating on CGAL objects. Looking at the source code it looks like all transformations will have this problem. So I added a derivative of Giles' user space rotate and that fixes it. module rotate(a) { cx = cos(a[0]); cy = cos(a[1]); cz = cos(a[2]); sx = sin(a[0]); sy = sin(a[1]); sz = sin(a[2]); multmatrix([ [cy * cz, cz * sx * sy - cx * sz, cx * cz * sy + sx * sz, 0], [cy * sz, cx * cz + sx * sy * sz,-cz * sx + cx * sy * sz, 0], [-sy, cy * sx, cx * cy, 0], [0, 0, 0, 1] ]) children(); } Giles used accurate at 90 versions of sin and cos but I think the sin and cos functions in OpenScad got fixed to be accurate for 90, 45, 30 and 60. The problem is they aren't used in rotate, they only seem to be used in user code. So now we have not only multiple vertex representations but also two versions of the trig functions. Nothing is going to line up exactly. If I replace rotate globally then obviously all my files change a little bit. Are there any down sides to this? Are user space expressions stored as floats or doubles?

nophead wrote > Giles used accurate at 90 versions of sin and cos but I think the sin and > cos functions in OpenScad got fixed to be accurate for 90, 45, 30 and 60. > The problem is they aren't used in rotate, they only seem to be used in > user code. So now we have not only multiple vertex representations but > also > two versions of the trig functions. Nothing is going to line up exactly. > > If I replace rotate globally then obviously all my files change a little > bit. Are there any down sides to this? Are user space expressions stored > as > floats or doubles? Perhaps OpenSCAD should use them everywhere? ----- Newly minted Admin - PM me if you need anything, or if I've done something stupid... Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above. The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out! -- View this message in context: http://forum.openscad.org/Inaccurate-rotates-tp15537p15693.html Sent from the OpenSCAD mailing list archive at Nabble.com.

Yes everywhere it uses trig to generate vertices. Looking at the code it seems to be rotate, rotate_extrude, generating circles, cylinders and spheres, clipper offsetting and dxf import and dxf dims. On 15 January 2016 at 03:04, MichaelAtOz <oz.at.michael@gmail.com> wrote: > nophead wrote > > Giles used accurate at 90 versions of sin and cos but I think the sin and > > cos functions in OpenScad got fixed to be accurate for 90, 45, 30 and 60. > > The problem is they aren't used in rotate, they only seem to be used in > > user code. So now we have not only multiple vertex representations but > > also > > two versions of the trig functions. Nothing is going to line up exactly. > > > > If I replace rotate globally then obviously all my files change a little > > bit. Are there any down sides to this? Are user space expressions stored > > as > > floats or doubles? > > Perhaps OpenSCAD should use them everywhere? > > > > ----- > Newly minted Admin - PM me if you need anything, or if I've done something > stupid... > > Unless specifically shown otherwise above, my contribution is in the > Public Domain; to the extent possible under law, I have waived all > copyright and related or neighbouring rights to this work. Obviously > inclusion of works of previous authors is not included in the above. > > The TPP is no simple “trade agreement.” Fight it! > http://www.ourfairdeal.org/ time is running out! > -- > View this message in context: > http://forum.openscad.org/Inaccurate-rotates-tp15537p15693.html > Sent from the OpenSCAD mailing list archive at Nabble.com. > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >