I know the difference between the two is only a factor pi/180 but I wonder why degrees are being used instead of radians (for me specifying an angle of pi/2 radians is as easy as 90 degrees).
How hard is it to change the sources to use radians? I quickly tried to grep the sources but I didn't find any place where I could make the change. Do I have to edit more than one source file? Any suggestions/comments? TIA Stefaan 
I guess that's pretty easy to do (all the builtin functions are in func.cc, so that might be the only file to change) but what then? That would be incompatible with almost every script you can find on the net. Another option is to define "function sinr(x) = sin(180 * x / PI);" and use sinr(PI/2).
 Torsten

Most people seldom think in term of radians. For those that do the conversion is easy. On Wed, Mar 19, 2014 at 3:45 PM, tp3 <[hidden email]> wrote: sclaes wrote _______________________________________________ OpenSCAD mailing list [hidden email] http://rocklinux.net/mailman/listinfo/openscad http://openscad.org  https://flattr.com/thing/121566 
In reply to this post by tp3
Backward compatibility, plus the fact that degrees are far more popular than radians, are good reasons for maintaining the status quo. It would be reasonable to define a new builtin constant called RAD:
RAD = 180 / PI; // 1 radian, measured in degrees To convert r radians to degrees, use r*RAD. To convert d degrees to radians, use d/RAD. Instead of writing sinr(x), you could write sin(x*RAD), which I think is fairly readable, and avoids defining extra copies of all the trig functions.
On 19 March 2014 16:45, tp3 <[hidden email]> wrote: sclaes wrote _______________________________________________ OpenSCAD mailing list [hidden email] http://rocklinux.net/mailman/listinfo/openscad http://openscad.org  https://flattr.com/thing/121566 
The only problem I'd have with this is that RAD is a bit too close (wordwise) to radius. I occasionally use rad as my radius variable.
(I realise one is capitalised and the other not, but ...) On Wed, Mar 19, 2014 at 10:16 PM, doug moen <[hidden email]> wrote:


_______________________________________________ OpenSCAD mailing list [hidden email] http://rocklinux.net/mailman/listinfo/openscad http://openscad.org  https://flattr.com/thing/121566 
In reply to this post by sclaes
As noted it's not going to happen, but if you wanted to, for future reference, all .scad code is lexed and parsed in lexer.l and parser.y. The numbers, in particular, are put into Value (value.h value.cc) as C++ doubles. The math functions, sin, cos, etc, are in func.cc, and you will notice there all input passes through a 'deg2rad' function. (And all the inverse functions, like Arc Cosine, pass through a rad2deg function). I guess it would be interesting to know how many people would want 'deg2rad' and 'rad2deg' to become a 'builtin function' like sin and cos are? or does it tend towards languagecore bloat?On Wed, Mar 19, 2014 at 3:35 PM, sclaes <[hidden email]> wrote: I know the difference between the two is only a factor pi/180 but I wonder _______________________________________________ OpenSCAD mailing list [hidden email] http://rocklinux.net/mailman/listinfo/openscad http://openscad.org  https://flattr.com/thing/121566 
Okay then, what is better? sin(rad2deg(x)) sin(x*RADIAN) deg2rad(asin(x)) asin(x)/RADIAN
On 19 March 2014 22:32, Don Bright <[hidden email]> wrote:
_______________________________________________ OpenSCAD mailing list [hidden email] http://rocklinux.net/mailman/listinfo/openscad http://openscad.org  https://flattr.com/thing/121566 
In reply to this post by RGH
Openscad has problems with precision, especially the part that comes with IEEE floating point definitions that support 52 bits of accuracy in a value always between 0.5 (10) and 1 (10) and a 12 bit power of 2 which the value is to be multiplied by.
It is impossible to represent 180 degrees as an integer multiple of pi because pi itself can never be exactly represented as an IEEE float. It's all a bit like expressing 1/3 in decimal which cannot be done without the ... sequence that indicates that 0.3333333...(10) goes on forever. Pi is worse though because it is a transcendental number that is not rational. It cannot be represented as a ratio of two integers and it cannot even be represented exactly as the solution of an algebraic polynomial. Folks long ago, and long before Newton's calculus, decided on 360 which is 2 * 2 * 2 * 3 * 3 * 5. The first integer that is not a divisor is 7 and it's pretty extreme to try to include 7 but nobody is supposed to try dividing a circle  2 pi  by 7 or any prime number other than 2,3,or 5. The use of radians facilitates the calculus of trigonometry. It makes the derivative of the sine into the cosine without a multiplier. That's nice for solving Schrodinger's equation in spherical coordinates. Openscad is not doing much of that. There are advantages though and the function cos(90) in degrees is zero while cos(pi/2) is off in the 17th decimal place just because pi/2 is not the same as 180 degrees using IEEE 64 bit floats. I am thinking seriously that something I did for the study of rocket motion after the V2 but well before anything was orbital and one was lucky to have 24 bit computers that spoke octal with their vacuum tubes. All angles were represented in circle fractions which made anything the computer could represent could be an exact 24 bit fraction. It's just like the mariner's compass. N,E,S,W became N, NE, E, SE, S, SW, W, NW, N and after a while we had NNE by E a half S and the like until the best of sailors could not box the compass to more bits. The 24 bit computer had no problems with it and if you added to angles for which the sum was 1 or more you could ignore the overflow and keep going. Angles were much like the division of an inch into binary fractions as displayed in a grade school ruler. 3 and 5/16 inches could be added to another 3 + 5/16 and the result was always exact but one could use binary denominators without worrying about loss of accuracy when the increment was repeated over and over again. Worse, in the likes of openscad, it is most important that sin^2(x) plus cos^2(x) be exactly unity even when x is one of those impossible to represent angles. As of now, using multiples of pi/2, when one creates a rotation matrix the top row of which is (sin(x), cos(x), 0) you have a row vector that isn't normal in that the dot product with itself is not exactly 1. In three dimensions and rotations of more than a circle I suspect the matrices can differ from orthonormality enough to produce those silky surfaces that are not real.. Perhaps what is needed is a subroutine  er method  that returns the sine and cosine of an angle with a guarantee that sin^2 + cos ^2 is exactly unity. Using circle fractions that could evaluate only the sine function up to 45 degrees. Everything else would be derived from the octant identified by the first 3 bits of the circle fraction and a square root of (1  sin^2). I have been dreaming about it. Rational numbers as a replacement for floating point does not address the problem.  Fe++ // \ Fe++ Fe++   Fe++ Fe++ \\ / Fe++ _______________________________________________ OpenSCAD mailing list [hidden email] http://rocklinux.net/mailman/listinfo/openscad http://openscad.org  https://flattr.com/thing/121566 
In reply to this post by doug.moen
BEGIN PGP SIGNED MESSAGE
Hash: SHA1 Using functions, one could at least try to take care of the apparently problematic special cases like pi/2 <> 180. On Wed, 19 Mar 2014 22:59:54 0400 doug moen <[hidden email]> wrote: > Okay then, what is better? > > sin(rad2deg(x)) > sin(x*RADIAN) > > deg2rad(asin(x)) > asin(x)/RADIAN > > > On 19 March 2014 22:32, Don Bright <[hidden email]> wrote: > > > As noted it's not going to happen, but if you wanted to, for future > > reference, all .scad code is lexed and parsed in lexer.l and > > parser.y. The numbers, in particular, are put into Value (value.h > > value.cc) as C++ doubles. The math functions, sin, cos, etc, are in > > func.cc, and you will notice there all input passes through a > > 'deg2rad' function. (And all the inverse functions, like Arc > > Cosine, pass through a rad2deg function). > > > > I guess it would be interesting to know how many people would want > > 'deg2rad' and 'rad2deg' to become a 'builtin function' like sin and > > cos are? or does it tend towards languagecore bloat? > > > > > > On Wed, Mar 19, 2014 at 3:35 PM, sclaes <[hidden email]> wrote: > > > >> I know the difference between the two is only a factor pi/180 but > >> I wonder why degrees are being used instead of radians (for me > >> specifying an angle of > >> pi/2 radians is as easy as 90 degrees). > >> > >> How hard is it to change the sources to use radians? I quickly > >> tried to grep > >> the sources but I didn't find any place where I could make the > >> change. Do I > >> have to edit more than one source file? > >> > >> Any suggestions/comments? > >> > >> TIA > >> > >> Stefaan > >> > >> > >> > >> > >>  > >> View this message in context: > >> http://forum.openscad.org/Degreesinsteadofradianstp7398.html > >> Sent from the OpenSCAD mailing list archive at Nabble.com. > >> _______________________________________________ > >> OpenSCAD mailing list > >> [hidden email] > >> http://rocklinux.net/mailman/listinfo/openscad > >> http://openscad.org  https://flattr.com/thing/121566 > >> > > > > > > _______________________________________________ > > OpenSCAD mailing list > > [hidden email] > > http://rocklinux.net/mailman/listinfo/openscad > > http://openscad.org  https://flattr.com/thing/121566 > >   BEGIN PGP SIGNATURE Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJTKqdIAAoJED3c2393ksVELXAQAJPaVpWy1WIYYlG6WQYAsfeX HYwPwpaA/eWelrNFC/rNaLK6ypDPFgzSRCd7W3W6CE9riRJFo9KE5LUZs+H3KWXR LL0EpqBhReVbDdPPeJ06EwyVl0+7qCYNI1N5hizP/aUe4OIsqp2fLmePfw1cqE8Z abdfwr6MT6jb9k9TMgmW0v8eFHWh+9Gd06ffahH6pT26URVpPkVTXtho2/Qk/EWb OMRXL9Xx1rHnTWw+vQxAZwULreCeZx+x6bOl1ri05t4gJb+rvsMOi41+wu8k+fjv tfdwk0LkoK8DDH+KyUqzDnsHR79n7nC41r93scTK8FM0SHLHFqlHITCIkwz4+bFc 9ghPp5ndE5gdJiYb6Idv3zNdrJCdwga+ZM8dnVeIIN3a/qb6yLvKbq/AArY9s5L4 6pAY002iilW38rRr2QuzACDsOyjRgcnaNvgYQP2nxdtVUaiMTKx2wLbX8eWMxdhp kPLqO5ha9JtI0cmRnVCVFZNiLHZJXMledxf+J4i1+WxBkharXM7AXPpYBq0shhoU 406Zk2rQXGi9HFNiIB8WSgfCMMndBlG/0tzN/SelOf4+NlZt3JV8kV30nIaguE9p VUm/nWm1Pdg1lxEyR/Tl7mzfxXnr/moMB0mlMpr6iGabpGNar3ZtsCesPYi/szvc DkxxyAmYhpA4d43JTDYF =aUqZ END PGP SIGNATURE _______________________________________________ OpenSCAD mailing list [hidden email] http://rocklinux.net/mailman/listinfo/openscad http://openscad.org  https://flattr.com/thing/121566 
I use Giles' fix: function cos_n(a) = a%90?cos(a):round(cos(a)); function sin_n(a) = a%90?sin(a):round(sin(a)); module rotate(a) {
cx = cos_n(a[0]); cy = cos_n(a[1]); cz = cos_n(a[2]); sx = sin_n(a[0]); sy = sin_n(a[1]); sz = sin_n(a[2]); multmatrix([ [cy*cz,cz*sx*sycx*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] ]) for(i = [0:$children1]) child(i); } On 20 March 2014 08:31, Johannes Reinhardt <[hidden email]> wrote: BEGIN PGP SIGNED MESSAGE _______________________________________________ OpenSCAD mailing list [hidden email] http://rocklinux.net/mailman/listinfo/openscad http://openscad.org  https://flattr.com/thing/121566 
In reply to this post by doug.moen
Clearly sin(x*RAD). This reads pretty much as usual units; if one defines RAD = 180 / PI; DEG = 1; The latter, while redundant, can make thinks more explicit, and such more readable if the author chooses so. One can explicily write sin(PI/4 *RAD) or sin(120 *DEG), which reads pretty much as sin(π∕₄ rad) resp. sin(120°) So it reads pretty natural, I think. Szelp, André Szabolcs
+43 (650) 79 22 400 On Thu, Mar 20, 2014 at 3:59 AM, doug moen <[hidden email]> wrote:
_______________________________________________ OpenSCAD mailing list [hidden email] http://rocklinux.net/mailman/listinfo/openscad http://openscad.org  https://flattr.com/thing/121566 
In reply to this post by RGH
Hm, actually, at a certain point sin(90) was not 1 in OpenSCAD exactly because 90 was first converted to π∕2, which was fed to the C++ math "sin" function. There was a suggestion to shortcircuit the values (from tables?) for common fractions of the circle. Was that implemented? Szelp, André Szabolcs
+43 (650) 79 22 400 On Thu, Mar 20, 2014 at 4:19 AM, Doug Mcnutt <[hidden email]> wrote: Openscad has problems with precision, especially the part that comes with IEEE floating point definitions that support 52 bits of accuracy in a value always between 0.5 (10) and 1 (10) and a 12 bit power of 2 which the value is to be multiplied by. _______________________________________________ OpenSCAD mailing list [hidden email] http://rocklinux.net/mailman/listinfo/openscad http://openscad.org  https://flattr.com/thing/121566 
In reply to this post by nophead
Good, that answers my question: it is not fixed in core. Really, core trig functions should really shortcircuit special values for special circle segments, rather than returning the C++ sin on the converted (due to float and pi's transcendental nature) inexact rad value!
Szelp, André Szabolcs
+43 (650) 79 22 400 On Thu, Mar 20, 2014 at 9:33 AM, nop head <[hidden email]> wrote:
_______________________________________________ OpenSCAD mailing list [hidden email] http://rocklinux.net/mailman/listinfo/openscad http://openscad.org  https://flattr.com/thing/121566 
In reply to this post by szabi
I agree with André: sin(x*RAD) is clearer, and works better as mathematical notation. I'm working on a compiler for a domainspecific language in my day job. Our strategy is to use an optimizing compiler to decouple the syntax from the generated code. Notation is a tool of thought, so pick the syntax that best expresses the problem domain. Then figure out how to compile that syntax into code that executes most quickly or computes the most accurate result.
For example, in OpenSCAD right now, sin(x*RAD) executes the following C++ code: sin(deg2rad(x*RAD)) // in C++ So x is being converted from radians, to degrees, and back to radians, and both computations are imprecise. We could make the compiler recognize this pattern (the argument to sin is multiplied by RAD), and generate different code that avoids the double conversion:
sin(x) // in C++ This kind of math is not my area of expertise, so I won't claim that we should add this specific optimization. An expert could figure out a better set of compile time and run time optimizations for getting the best results from the trancendental functions. What I am saying is: don't forget to consider compile time optimizations. My experience is that you can get quite a lot of benefit from a small set of simple compile time optimizations, if they are well chosen.
On 20 March 2014 06:06, Szelp, A. Sz. <[hidden email]> wrote:
_______________________________________________ OpenSCAD mailing list [hidden email] http://rocklinux.net/mailman/listinfo/openscad http://openscad.org  https://flattr.com/thing/121566 
In reply to this post by doug.moen
If you know the length of an arc, it's easy to compute the corresponding angle by dividing it by the radius. But... the angle is in radians. So it has to be converted to degrees if you want to use one of the goniometric functions. But the compiler has to convert those degrees back to radians again because the C++ function requires radians.
I'm tempted to alter openscad and remove the conversions. I know it will make it incompatible with most existing openscad scripts, but I can live with that. Regards, Stefaan 
A lot of the engineering textbooks I use have their equations using degrees (I have just been doing some calculations on four bar linkages for example). I would prefer not to have to remember or figure out that everything is in radians. On the other hand if you're just talking about your personal copy of OpenSCAD, then have at it! _______________________________________________ OpenSCAD mailing list [hidden email] http://rocklinux.net/mailman/listinfo/openscad http://openscad.org  https://flattr.com/thing/121566 
Would it be insane to have it be configurable via preferences?
Or it could even be a variable that is specified in the script, eg: use_degrees = false; // defaults to true Another similar possibility would be to use a keyword argument to functions that take angles as arguments, eg: sin(pi, use_degrees = false); // use_degrees defaults to true  Brad Pitcher On Fri, Mar 21, 2014 at 12:08 PM, Robert Harris <[hidden email]> wrote:
_______________________________________________ OpenSCAD mailing list [hidden email] http://rocklinux.net/mailman/listinfo/openscad http://openscad.org  https://flattr.com/thing/121566 
Actually yes ;). That would randomly break existing libraries. I think that type of setting should not be installation dependent. That could work if it's scoped correctly for exactly only the script where it's set. It would probably still break scripts imported by include<>. It might be possible to get use<> behavior correct. It still feels a bit risky to do. That's of cause possible, I can't see any risk breaking existing scripts with that. Hard to say if that's much better than angle * RAD or something similar. It might be a bit clearer (but I'd vote for radians=true with default false instead).
 Torsten

In reply to this post by Brad Pitcher
Those were my exact thoughts, actually...
On 3/21/2014 3:15 PM, Brad Pitcher
wrote:
_______________________________________________ OpenSCAD mailing list [hidden email] http://rocklinux.net/mailman/listinfo/openscad http://openscad.org  https://flattr.com/thing/121566 
In reply to this post by tp3
BEGIN PGP SIGNED MESSAGE
Hash: SHA1 I like the sin(pi, use_radians=false). It also avoids name space pollution by leaving RAD free. This seems to be the cleanest of all proposals. On Fri, 21 Mar 2014 12:29:44 0700 (PDT) tp3 <[hidden email]> wrote: > Brad Pitcher wrote > > Would it be insane to have it be configurable via preferences? > > Actually yes ;). That would randomly break existing libraries. I > think that type of setting should not be installation dependent. > > > Brad Pitcher wrote > > Or it could even be a variable that is specified in the script, eg: > > > > use_degrees = false; // defaults to true > > That could work if it's scoped correctly for exactly only the script > where it's set. It would probably still break scripts imported by > include<>. It might > be possible to get use<> behavior correct. It still feels a bit risky > to do. > > > Brad Pitcher wrote > > Another similar possibility would be to use a keyword argument to > > functions > > that take angles as arguments, eg: > > > > sin(pi, use_degrees = false); // use_degrees defaults to true > > That's of cause possible, I can't see any risk breaking existing > scripts with that. > Hard to say if that's much better than angle * RAD or something > similar. It might be a bit clearer (but I'd vote for radians=true > with default false instead). > > > > > > >  >  Torsten >  > View this message in context: > http://forum.openscad.org/Degreesinsteadofradianstp7398p7458.html > Sent from the OpenSCAD mailing list archive at Nabble.com. > _______________________________________________ OpenSCAD mailing list > [hidden email] > http://rocklinux.net/mailman/listinfo/openscad > http://openscad.org  https://flattr.com/thing/121566   BEGIN PGP SIGNATURE Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJTLKbmAAoJED3c2393ksVEg1UP/0OxDwZ7REX/L01+uzFLtxxr RfbI27BDSu4mNJ/SVLPtsHz2mwuFe/6GF13RqI4GxefQse8npu10ujiXH7KlMqqN rIi/jwmRUh0fRnlgvsQ0dWAZ+YTrU2RPifiTUNQGLt5EVWt02K8t6ksf0/Gtxke2 WXkOKu02LNqygzpMfBXxEaqz7UgMY+zVIWwMsxskyX9UrdR2AR8uj/744KCxR/Es zaimLjACp7F2O2Xr06aQotQxnuMeruhj+FtkWDL/IEqTU/8ViKMN2FZsxHdwuBWN 4FOkXj9Rgk06yyjfjutyWoUco0XBLKgVYURHzYClrubX1W0wObu3sR5Fe3Vc7Zq2 buQUJ7oYLRmsK9rppAa+/DnHXT1BKM+C7BJgXnR3pkTE6K7zzTvZ2U21/mqHr5a1 EQiGjgpE3vrvKhdeD+Jt1aLAZgtD/uv34HjPTiavqqt1gobzJYWALFky5hid5sXk +zoe0aXtxPsezo0on1KwXzKF4kTQFfg/Qc/exJN7CoDt6JlbQEQVzUqs3mpqBKw3 /37YO3EmgYA31jDi25rErW2Lhaji411iQqXmZdepJZ0jm9/ggklefDrNBJJzkdDJ kWeim9MoHrQ8CJ0RDukVVhw5O3lV4Gh5ctRDNizOyJ/7y+VGO9mNtww13bpletcq bICGbYolnva5x82nTW/T =G2gx END PGP SIGNATURE _______________________________________________ OpenSCAD mailing list [hidden email] http://rocklinux.net/mailman/listinfo/openscad http://openscad.org  https://flattr.com/thing/121566 
Free forum by Nabble  Edit this page 