
12

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


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


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.
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscadhttp://openscad.org  https://flattr.com/thing/121566


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?
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscadhttp://openscad.org  https://flattr.com/thing/121566


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/openscadhttp://openscad.org  https://flattr.com/thing/121566


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/openscadhttp://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); }
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscadhttp://openscad.org  https://flattr.com/thing/121566


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.
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscadhttp://openscad.org  https://flattr.com/thing/121566


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


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


Those were my exact thoughts, actually...
On 3/21/2014 3:15 PM, Brad Pitcher
wrote:
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
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscadhttp://openscad.org  https://flattr.com/thing/121566


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/openscadhttp://openscad.org  https://flattr.com/thing/121566

12
