I've been trying to understand how a library from thingiverse worked (& how to fix it ) and I didn't understand where this magic variable PI came from or where it's value was set. It would have saved me a lot of time if it was listed in the cheatsheet. Which section should it go in? Is it a special variable, or a function, or something else ? regards Richard. -- View this message in context: http://forum.openscad.org/why-isn-t-PI-listed-on-the-cheat-sheet-tp20390.html Sent from the OpenSCAD mailing list archive at Nabble.com.

PI is a trigonometric constant. I would put it in Math, together with the trig functions. On Saturday, 11 February 2017, richardk <rskennedy307@gmail.com> wrote: > I've been trying to understand how a library from thingiverse worked (& how > to fix it ) and I didn't understand where this magic variable PI came from > or where it's value was set. > > It would have saved me a lot of time if it was listed in the cheatsheet. > > Which section should it go in? Is it a special variable, or a function, or > something else ? > > regards > > Richard. > > > > > -- > View this message in context: http://forum.openscad.org/why- > isn-t-PI-listed-on-the-cheat-sheet-tp20390.html > Sent from the OpenSCAD mailing list archive at Nabble.com. > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org <javascript:;> > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org > > >

I seem to recall kintel is trying to discourage PI's use as it (as the only 'constant') may be deprecated in the future. ----- 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/why-isn-t-PI-listed-on-the-cheat-sheet-tp20390p20393.html Sent from the OpenSCAD mailing list archive at Nabble.com.

I doubt it will be deprecated if it is being used on Thingiverse. On 11 February 2017 at 16:48, MichaelAtOz <oz.at.michael@gmail.com> wrote: > I seem to recall kintel is trying to discourage PI's use as it (as the only > 'constant') may be deprecated in the future. > > > > ----- > 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/why- > isn-t-PI-listed-on-the-cheat-sheet-tp20390p20393.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 >

"PI is a trigonometric constant. I would put it in Math, together with the trig functions." Those trig functions surely are based on the sum of series' that use radians to keep things as error free as possible. That means that some binary approximation of Pi is used to convert degrees to radians. I would prefer to see radians used by the compiler to avoid possible error when the programmer uses a value of Pi that isn't identical to that used by the subroutines. But then degrees, breaking up a circle into an integer number of parts, are nice for pictures. perl recommends using: Pi = 4 * atan(1,1); as an early definition to get closer to the whatever your library uses.

On Ubuntu Linux, MacOS and Windows, 4*atan2(1,1) returns PI. That is, it returns the closest approximation of pi that fits in a 64 bit float. On Ubuntu, I'm testing the C library directly, on the other two platforms I used Python, which uses the C library. So I think our PI constant is okay. It's too late to change OpenSCAD to use radians. This would break backwards compatibility. It was designed for engineering/CAD applications, so degrees still seem like the right choice. I ran some tests, and I can't find any examples where there is loss of precision caused by built-in degree to radian conversion, that wouldn't caused anyway by manual degree to radian conversion, if we used radians in the API. Maybe this could happen if the # of degrees is a transcendental number, like the dihedral of a regular tetrahedron (acos(1/3))? Even here, I don't see a loss of precision when I test this in Python: >>> acos(1.0/3.0) 1.2309594173407747 >>> radians(degrees(acos(1.0/3.0))) 1.2309594173407747 In summary, I can't find any evidence that there is a problem here that needs to be solved. On 5 March 2017 at 14:59, doug <dmcnutt@macnauchtan.com> wrote: > "PI is a trigonometric constant. I would put it in Math, together with the > trig functions." > > Those trig functions surely are based on the sum of series' that use > radians to keep things as error free as possible. That means that some > binary approximation of Pi is used to convert degrees to radians. > > I would prefer to see radians used by the compiler to avoid possible error > when the programmer uses a value of Pi that isn't identical to that used by > the subroutines. But then degrees, breaking up a circle into an integer > number of parts, are nice for pictures. > > perl recommends using: > > Pi = 4 * atan(1,1); > > as an early definition to get closer to the whatever your library uses. > > > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org > > >