27 messages
12
Open this post in threaded view
|

 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
Open this post in threaded view
|

 sclaes wrote 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? 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
Open this post in threaded view
|

Open this post in threaded view
|

Open this post in threaded view
|

Open this post in threaded view
|

Open this post in threaded view
|

Open this post in threaded view
|

Open this post in threaded view
|

Open this post in threaded view
|

 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*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] ]) for(i = [0:$children-1]) child(i);} On 20 March 2014 08:31, Johannes Reinhardt wrote: -----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 language-core 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/Degrees-instead-of-radians-tp7398.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 _______________________________________________ OpenSCAD mailing list [hidden email] http://rocklinux.net/mailman/listinfo/openscadhttp://openscad.org - https://flattr.com/thing/121566 Reply | Threaded Open this post in threaded view | ## Re: Degrees instead of radians  In reply to this post by doug.moen Clearly sin(x*RAD). This reads pretty much as usual units; if one definesRAD = 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 assin(π∕₄ 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 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 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 language-core bloat? On Wed, Mar 19, 2014 at 3:35 PM, sclaes 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/Degrees-instead-of-radians-tp7398.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 _______________________________________________ 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/openscadhttp://openscad.org - https://flattr.com/thing/121566 Reply | Threaded Open this post in threaded view | ## Re: Degrees instead of radians  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 short-circuit 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 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. 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 _______________________________________________ OpenSCAD mailing list [hidden email] http://rocklinux.net/mailman/listinfo/openscadhttp://openscad.org - https://flattr.com/thing/121566 Reply | Threaded Open this post in threaded view | ## Re: Degrees instead of radians In reply to this post by nophead Good, that answers my question: it is not fixed in core. Really, core trig functions should really short-circuit 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! Function sin cos tan cot sec csc (I know, the roots themselves are not exact in floating point, but better than the result from an already inexact pi/6?) Szelp, André Szabolcs +43 (650) 79 22 400 On Thu, Mar 20, 2014 at 9:33 AM, nop head wrote: 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*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] ]) for(i = [0:$children-1])
child(i);
}

On 20 March 2014 08:31, Johannes Reinhardt wrote:
-----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?
>
>
>
>
> 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 language-core 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?
> >>
> >>
> >> TIA
> >>
> >> Stefaan
> >>
> >>
> >>
> >>
> >> --
> >> View this message in context:
> >> Sent from the OpenSCAD mailing list archive at Nabble.com.
> >> _______________________________________________
> >> [hidden email]
> >>
> >
> >
> > _______________________________________________
> > [hidden email]
> >

- --

-----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-----
_______________________________________________
[hidden email]

_______________________________________________
[hidden email]

_______________________________________________
[hidden email]
Open this post in threaded view
|

Open this post in threaded view
|

 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
Open this post in threaded view
|

 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/openscadhttp://openscad.org - https://flattr.com/thing/121566
Open this post in threaded view
|

Open this post in threaded view
|

 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
Open this post in threaded view
|