Degrees instead of radians

classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Degrees instead of radians

sclaes
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
tp3
Reply | Threaded
Open this post in threaded view
|

Re: Degrees instead of radians

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

Re: Degrees instead of radians

Kevin Crowley
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
> 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
--
View this message in context: http://forum.openscad.org/Degrees-instead-of-radians-tp7398p7399.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
Reply | Threaded
Open this post in threaded view
|

Re: Degrees instead of radians

doug.moen
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 built-in 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
> 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
--
View this message in context: http://forum.openscad.org/Degrees-instead-of-radians-tp7398p7399.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
RGH
Reply | Threaded
Open this post in threaded view
|

Re: Degrees instead of radians

RGH
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:
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 built-in 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
> 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
--
View this message in context: http://forum.openscad.org/Degrees-instead-of-radians-tp7398p7399.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
Reply | Threaded
Open this post in threaded view
|

Re: Degrees instead of radians

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

Re: Degrees instead of radians

doug.moen
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


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: Degrees instead of radians

Doug Mcnutt
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
Reply | Threaded
Open this post in threaded view
|

Re: Degrees instead of radians

Johannes Reinhardt
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 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
Reply | Threaded
Open this post in threaded view
|

Re: Degrees instead of radians

nophead
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 <[hidden email]> 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/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: Degrees instead of radians

szabi
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:
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


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

Re: Degrees instead of radians

szabi
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 <[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.

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

Re: Degrees instead of radians

szabi
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 0 \ (0^\circ) \frac{\pi}{12} \ (15^\circ) \frac{\pi}{8} \ (22.5^\circ) \frac{\pi}{6} \ (30^\circ) \frac{\pi}{4} \ (45^\circ) \frac{\pi}{3} \ (60^\circ) \frac{5\pi}{12} \ (75^\circ) \frac{\pi}{2} \ (90^\circ)
sin 0 \frac{ \sqrt{6} - \sqrt{2} } {4} \frac{ \sqrt{2 - \sqrt{2}} } {2} \frac{1}{2} \frac{\sqrt{2}}{2} \frac{\sqrt{3}}{2} \frac{ \sqrt{6} + \sqrt{2} } {4} 1
cos 1 \frac{\sqrt{6}+\sqrt{2}}{4} \frac{ \sqrt{2 + \sqrt{2}} } {2} \frac{\sqrt{3}}{2} \frac{\sqrt{2}}{2} \frac{1}{2} \frac{ \sqrt{6} - \sqrt{2}} {4} 0
tan 0 2-\sqrt{3} \sqrt{2} - 1 \frac{1}{\sqrt{3}} 1 \sqrt{3} 2+\sqrt{3} \infty
cot \infty 2+\sqrt{3} \sqrt{2} + 1 \sqrt{3} 1 \frac{\sqrt{3}}{3} 2-\sqrt{3} 0
sec 1 \sqrt{6} - \sqrt{2} \sqrt{2} \sqrt{ 2 - \sqrt{2} } \frac{2}{\sqrt{3}} \sqrt{2} 2 \sqrt{6}+\sqrt{2} \infty
csc \infty \sqrt{6}+\sqrt{2} \sqrt{2} \sqrt{ 2 + \sqrt{2} } 2 \sqrt{2} \frac{2\sqrt{3}}{3} \sqrt{6} - \sqrt{2} 1
(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 <[hidden email]> 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 <[hidden email]> 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/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
Reply | Threaded
Open this post in threaded view
|

Re: Degrees instead of radians

doug.moen
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 domain-specific 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:

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

<a href="tel:%2B43%20%28650%29%2079%2022%20400" value="+436507922400" target="_blank">+43 (650) 79 22 400


On Thu, Mar 20, 2014 at 3:59 AM, 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


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

Re: Degrees instead of radians

sclaes
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
RGH
Reply | Threaded
Open this post in threaded view
|

Re: Degrees instead of radians

RGH

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

Re: Degrees instead of radians

Brad Pitcher
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:

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


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
tp3
Reply | Threaded
Open this post in threaded view
|

Re: Degrees instead of radians

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

Re: Degrees instead of radians

jon_bondy
In reply to this post by Brad Pitcher
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

---------
Brad Pitcher


On Fri, Mar 21, 2014 at 12:08 PM, Robert Harris <[hidden email]> wrote:

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

Re: Degrees instead of radians

Johannes Reinhardt
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/Degrees-instead-of-radians-tp7398p7458.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
12