Nop Head,I disagree with you, 0/0 is not defined, so it is not a number.Undef or Nan are both acceptable. Jean-PaulAC9GH Sent from my Verizon Wireless 4G LTE smartphone -------- Original message -------- From: nop head <nop.head@gmail.com> Date: 2015/10/24 8:08 PM (GMT-05:00) To: OpenSCAD general discussion <discuss@lists.openscad.org> Subject: Re: [OpenSCAD] Software bug I am not sure undef and nan are the same. If I don't define x but use it then it is undefined. x = 0/0 is different because x is defined but mathematically not a number. On 24 October 2015 at 23:37, Andrew Plumb <andrew@plumb.org> wrote: If you were trying to test “2^(1/0)” then the function you want is pow(2,1/0). echo( exp(1/0) );-> infecho( pow(2,1/0) );-> inf Andrew. On Oct 24, 2015, at 5:39 PM, doug moen <doug@moens.org> wrote: exp(x) is a function that takes exactly one argument. It's probably using generic code to return undef if the number of arguments is incorrect. Which is fine. undef and NaN play exactly the same role in the language. Rather than debate when to return undef and when to return nan in a bunch of different cases, I'd rather just unify them into a single value. On 24 October 2015 at 17:29, don bright <hmbright@fastmail.com> wrote: The manual has been updated. https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/Mathematical_Functions#Infinitudes_and_NaNs  Interesting note.... OpenSCAD seems to return 'undef' for exp(2,1/0) but it is probably intended to be returning NaN....   --- hmbright@fastmail.com     On Sat, Oct 24, 2015, at 06:55 AM, nop head wrote: atan(90) is not infinite, it is close to 90 degrees as is the atan of any large number. It approaches 90 asymptotically.   tan(90) is definitely infinite, so inf is correct.   echo(atan(tan(90))); gives 90 as it should. Only 0/0 is undefined and that does give nan.         On 24 October 2015 at 05:13, doug moen <doug@moens.org> wrote: The IEEE floating point standard says that 2/0 is inf, and that's the standard we are following. While your argument for NaN is mathematically correct, at least where real numbers or exact arithmetic is concerned, floating point computation doesn't have the same behaviour as real number arithmetic. For example, it has underflow, where a sufficiently small positive result is represented by 0, and a sufficiently small negative result is represented by -0, which is different from 0 in IEEE floats. So the floating point number 0 sometimes represents a true 0, and it sometimes represents a very small positive real number. So the IEEE float standards committee decided to define 1/0 as inf and -1/0 as -inf, and this results in useful behaviour, making it easier to write floating point code, in a lot of cases. And yes, this is a compromise, since it's not the right behaviour in all cases.     On 23 October 2015 at 23:37, wolf <wv99999@gmail.com> wrote: echo(2/0, atan(2/0), atan(90)); returns ECHO: inf, 90, 89.3634   The proper response for a division by zero should be not-a-number (NaN), since that division may result in any number. Consider sin(0)/0=0, which is a valid expression since the limit for xapproaching zero exists. atan(2/0) should result in undefined, and atan(90) should result in inf, since the respective Taylor series does not converge and no value can be computed.   By the way, is there a means to properly display a formula like binom{limit}{x rightarrow 0} {sin( x)} over {x} = 0 when posting?       -- View this message in context: http://forum.openscad.org/Software-bug-tp14194.html Sent from the OpenSCAD mailing list archive at Nabble.com.   _______________________________________________ OpenSCAD mailing list Discuss@lists.openscad.org http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org         _______________________________________________ OpenSCAD mailing list Discuss@lists.openscad.org http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org   _______________________________________________ OpenSCAD mailing list Discuss@lists.openscad.org http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org   _______________________________________________ OpenSCAD mailing list Discuss@lists.openscad.org http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org _______________________________________________ OpenSCAD mailing list Discuss@lists.openscad.org http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org _______________________________________________ OpenSCAD mailing list Discuss@lists.openscad.org http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

IEEE 754 does lay down rules on how to deal with situations that High-School mathematics does not cover, such as division-by-zero in a context of *finite* calculation accuracy (My training in High-School maths always assumed *infinite* accuracy). To quote <https://www.cs.berkeley.edu/~wkahan/ieee754status/IEEE754.PDF> : "Exception: DIVIDE by ZERO This is a misnomer perpetrated for historical reasons. A better name for this exception is "Infinite result computed Exactly from Finite operands." An example is 3.0/0.0, for which IEEE 754 specifies an Infinity as the default result." Unquote. This 30 page paper discusses what to report in case of an over- or underflow, the range of opinions that (have) exist(ed) on the action to be taken and how unequally this has been implemented historically. Interesting reading. Unequal implementation over different hardware is what I experienced, and reported as a bug. Let's stick to IEEE754. Wolf -- View this message in context: http://forum.openscad.org/Software-bug-tp14194p14211.html Sent from the OpenSCAD mailing list archive at Nabble.com.

On 25 October 2015 at 03:17, louijp <louijp@yahoo.com> wrote: > Nop Head, > I disagree with you, 0/0 is not defined, so it is not a number. > Undef or Nan are both acceptable. > It is defined in the programming sense. It has been given a value that is undefined in the mathematical sense represented by nan. That is different to using a variable that has never been assigned. > > Jean-Paul > AC9GH > > > > Sent from my Verizon Wireless 4G LTE smartphone > > > -------- Original message -------- > From: nop head <nop.head@gmail.com> > Date: 2015/10/24 8:08 PM (GMT-05:00) > To: OpenSCAD general discussion <discuss@lists.openscad.org> > Subject: Re: [OpenSCAD] Software bug > > I am not sure undef and nan are the same. If I don't define x but use it > then it is undefined. x = 0/0 is different because x is defined but > mathematically not a number. > > > > On 24 October 2015 at 23:37, Andrew Plumb <andrew@plumb.org> wrote: > >> If you were trying to test “2^(1/0)” then the function you want is >> pow(2,1/0). >> >> echo( exp(1/0) ); >> -> inf >> echo( pow(2,1/0) ); >> -> inf >> >> Andrew. >> >> On Oct 24, 2015, at 5:39 PM, doug moen <doug@moens.org> wrote: >> >> exp(x) is a function that takes exactly one argument. It's probably using >> generic code to return undef if the number of arguments is incorrect. Which >> is fine. >> >> undef and NaN play exactly the same role in the language. Rather than >> debate when to return undef and when to return nan in a bunch of different >> cases, I'd rather just unify them into a single value. >> >> On 24 October 2015 at 17:29, don bright <hmbright@fastmail.com> wrote: >> >>> The manual has been updated. >>> >>> >>> https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/Mathematical_Functions#Infinitudes_and_NaNs >>> >>> Interesting note.... OpenSCAD seems to return 'undef' for exp(2,1/0) but >>> it is probably intended to be returning NaN.... >>> >>> --- >>> hmbright@fastmail.com >>> >>> >>> On Sat, Oct 24, 2015, at 06:55 AM, nop head wrote: >>> >>> atan(90) is not infinite, it is close to 90 degrees as is the atan of >>> any large number. It approaches 90 asymptotically. >>> >>> tan(90) is definitely infinite, so inf is correct. >>> >>> echo(atan(tan(90))); gives 90 as it should. >>> Only 0/0 is undefined and that does give nan. >>> >>> >>> >>> >>> On 24 October 2015 at 05:13, doug moen <doug@moens.org> wrote: >>> >>> The IEEE floating point standard says that 2/0 is inf, and that's the >>> standard we are following. While your argument for NaN is mathematically >>> correct, at least where real numbers or exact arithmetic is concerned, >>> floating point computation doesn't have the same behaviour as real number >>> arithmetic. For example, it has underflow, where a sufficiently small >>> positive result is represented by 0, and a sufficiently small negative >>> result is represented by -0, which is different from 0 in IEEE floats. So >>> the floating point number 0 sometimes represents a true 0, and it sometimes >>> represents a very small positive real number. So the IEEE float standards >>> committee decided to define 1/0 as inf and -1/0 as -inf, and this results >>> in useful behaviour, making it easier to write floating point code, in a >>> lot of cases. And yes, this is a compromise, since it's not the right >>> behaviour in all cases. >>> >>> >>> On 23 October 2015 at 23:37, wolf <wv99999@gmail.com> wrote: >>> >>> echo(2/0, atan(2/0), atan(90)); >>> returns >>> ECHO: inf, 90, 89.3634 >>> >>> The proper response for a division by zero should be not-a-number (NaN), >>> since that division may result in any number. Consider sin(0)/0=0, which >>> is >>> a valid expression since the limit for xapproaching zero exists. >>> atan(2/0) should result in undefined, and atan(90) should result in inf, >>> since the respective Taylor series does not converge and no value can be >>> computed. >>> >>> By the way, is there a means to properly display a formula like >>> binom{limit}{x rightarrow 0} {sin( x)} over {x} = 0 >>> when posting? >>> >>> >>> >>> -- >>> View this message in context: >>> http://forum.openscad.org/Software-bug-tp14194.html >>> Sent from the OpenSCAD mailing list archive at Nabble.com. >>> >>> _______________________________________________ >>> OpenSCAD mailing list >>> Discuss@lists.openscad.org >>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>> >>> >>> >>> >>> >>> _______________________________________________ >>> OpenSCAD mailing list >>> Discuss@lists.openscad.org >>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>> >>> >>> *_______________________________________________* >>> OpenSCAD mailing list >>> Discuss@lists.openscad.org >>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>> >>> >>> >>> _______________________________________________ >>> OpenSCAD mailing list >>> Discuss@lists.openscad.org >>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>> >>> >> _______________________________________________ >> OpenSCAD mailing list >> Discuss@lists.openscad.org >> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >> >> >> >> _______________________________________________ >> OpenSCAD mailing list >> Discuss@lists.openscad.org >> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >> >> > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org > >

I think the compiler should report a fatal error message if there is a reference to an unassigned variable. Right now, we only report a warning for this. I've seen 4 or 5 forum posts where people can't understand what their program is doing in this situation. The warning is there, but they kind of skim over that and go to the forum for help. There's also a couple pages in the manual about the horribly unintuitive behaviour that results when you include a file and you also have references to unassigned variables. Just make it an error and this source of confusion will go away. On Sunday, 25 October 2015, nop head <nop.head@gmail.com> wrote: > > > On 25 October 2015 at 03:17, louijp <louijp@yahoo.com > <javascript:_e(%7B%7D,'cvml','louijp@yahoo.com');>> wrote: > >> Nop Head, >> I disagree with you, 0/0 is not defined, so it is not a number. >> Undef or Nan are both acceptable. >> > > It is defined in the programming sense. It has been given a value that is > undefined in the mathematical sense represented by nan. That is different > to using a variable that has never been assigned. > > >> >> Jean-Paul >> AC9GH >> >> >> >> Sent from my Verizon Wireless 4G LTE smartphone >> >> >> -------- Original message -------- >> From: nop head <nop.head@gmail.com >> <javascript:_e(%7B%7D,'cvml','nop.head@gmail.com');>> >> Date: 2015/10/24 8:08 PM (GMT-05:00) >> To: OpenSCAD general discussion <discuss@lists.openscad.org >> <javascript:_e(%7B%7D,'cvml','discuss@lists.openscad.org');>> >> Subject: Re: [OpenSCAD] Software bug >> >> I am not sure undef and nan are the same. If I don't define x but use it >> then it is undefined. x = 0/0 is different because x is defined but >> mathematically not a number. >> >> >> >> On 24 October 2015 at 23:37, Andrew Plumb <andrew@plumb.org >> <javascript:_e(%7B%7D,'cvml','andrew@plumb.org');>> wrote: >> >>> If you were trying to test “2^(1/0)” then the function you want is >>> pow(2,1/0). >>> >>> echo( exp(1/0) ); >>> -> inf >>> echo( pow(2,1/0) ); >>> -> inf >>> >>> Andrew. >>> >>> On Oct 24, 2015, at 5:39 PM, doug moen <doug@moens.org >>> <javascript:_e(%7B%7D,'cvml','doug@moens.org');>> wrote: >>> >>> exp(x) is a function that takes exactly one argument. It's probably >>> using generic code to return undef if the number of arguments is incorrect. >>> Which is fine. >>> >>> undef and NaN play exactly the same role in the language. Rather than >>> debate when to return undef and when to return nan in a bunch of different >>> cases, I'd rather just unify them into a single value. >>> >>> On 24 October 2015 at 17:29, don bright <hmbright@fastmail.com >>> <javascript:_e(%7B%7D,'cvml','hmbright@fastmail.com');>> wrote: >>> >>>> The manual has been updated. >>>> >>>> >>>> https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/Mathematical_Functions#Infinitudes_and_NaNs >>>> >>>> Interesting note.... OpenSCAD seems to return 'undef' for exp(2,1/0) >>>> but it is probably intended to be returning NaN.... >>>> >>>> --- >>>> hmbright@fastmail.com >>>> <javascript:_e(%7B%7D,'cvml','hmbright@fastmail.com');> >>>> >>>> >>>> On Sat, Oct 24, 2015, at 06:55 AM, nop head wrote: >>>> >>>> atan(90) is not infinite, it is close to 90 degrees as is the atan of >>>> any large number. It approaches 90 asymptotically. >>>> >>>> tan(90) is definitely infinite, so inf is correct. >>>> >>>> echo(atan(tan(90))); gives 90 as it should. >>>> Only 0/0 is undefined and that does give nan. >>>> >>>> >>>> >>>> >>>> On 24 October 2015 at 05:13, doug moen <doug@moens.org >>>> <javascript:_e(%7B%7D,'cvml','doug@moens.org');>> wrote: >>>> >>>> The IEEE floating point standard says that 2/0 is inf, and that's the >>>> standard we are following. While your argument for NaN is mathematically >>>> correct, at least where real numbers or exact arithmetic is concerned, >>>> floating point computation doesn't have the same behaviour as real number >>>> arithmetic. For example, it has underflow, where a sufficiently small >>>> positive result is represented by 0, and a sufficiently small negative >>>> result is represented by -0, which is different from 0 in IEEE floats. So >>>> the floating point number 0 sometimes represents a true 0, and it sometimes >>>> represents a very small positive real number. So the IEEE float standards >>>> committee decided to define 1/0 as inf and -1/0 as -inf, and this results >>>> in useful behaviour, making it easier to write floating point code, in a >>>> lot of cases. And yes, this is a compromise, since it's not the right >>>> behaviour in all cases. >>>> >>>> >>>> On 23 October 2015 at 23:37, wolf <wv99999@gmail.com >>>> <javascript:_e(%7B%7D,'cvml','wv99999@gmail.com');>> wrote: >>>> >>>> echo(2/0, atan(2/0), atan(90)); >>>> returns >>>> ECHO: inf, 90, 89.3634 >>>> >>>> The proper response for a division by zero should be not-a-number (NaN), >>>> since that division may result in any number. Consider sin(0)/0=0, >>>> which is >>>> a valid expression since the limit for xapproaching zero exists. >>>> atan(2/0) should result in undefined, and atan(90) should result in inf, >>>> since the respective Taylor series does not converge and no value can be >>>> computed. >>>> >>>> By the way, is there a means to properly display a formula like >>>> binom{limit}{x rightarrow 0} {sin( x)} over {x} = 0 >>>> when posting? >>>> >>>> >>>> >>>> -- >>>> View this message in context: >>>> http://forum.openscad.org/Software-bug-tp14194.html >>>> Sent from the OpenSCAD mailing list archive at Nabble.com. >>>> >>>> _______________________________________________ >>>> OpenSCAD mailing list >>>> Discuss@lists.openscad.org >>>> <javascript:_e(%7B%7D,'cvml','Discuss@lists.openscad.org');> >>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> OpenSCAD mailing list >>>> Discuss@lists.openscad.org >>>> <javascript:_e(%7B%7D,'cvml','Discuss@lists.openscad.org');> >>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>>> >>>> >>>> *_______________________________________________* >>>> OpenSCAD mailing list >>>> Discuss@lists.openscad.org >>>> <javascript:_e(%7B%7D,'cvml','Discuss@lists.openscad.org');> >>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>>> >>>> >>>> >>>> _______________________________________________ >>>> OpenSCAD mailing list >>>> Discuss@lists.openscad.org >>>> <javascript:_e(%7B%7D,'cvml','Discuss@lists.openscad.org');> >>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>>> >>>> >>> _______________________________________________ >>> OpenSCAD mailing list >>> Discuss@lists.openscad.org >>> <javascript:_e(%7B%7D,'cvml','Discuss@lists.openscad.org');> >>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>> >>> >>> >>> _______________________________________________ >>> OpenSCAD mailing list >>> Discuss@lists.openscad.org >>> <javascript:_e(%7B%7D,'cvml','Discuss@lists.openscad.org');> >>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>> >>> >> >> _______________________________________________ >> OpenSCAD mailing list >> Discuss@lists.openscad.org >> <javascript:_e(%7B%7D,'cvml','Discuss@lists.openscad.org');> >> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >> >> >

The problem is backwards compatibility. I have things like this at the moment: exploded = $exploded == undef ? 0 : $exploded; // 1 for exploded view On 25 October 2015 at 21:43, doug moen <doug@moens.org> wrote: > I think the compiler should report a fatal error message if there is a > reference to an unassigned variable. > > Right now, we only report a warning for this. I've seen 4 or 5 forum posts > where people can't understand what their program is doing in this > situation. The warning is there, but they kind of skim over that and go to > the forum for help. There's also a couple pages in the manual about the > horribly unintuitive behaviour that results when you include a file and you > also have references to unassigned variables. Just make it an error and > this source of confusion will go away. > > > On Sunday, 25 October 2015, nop head <nop.head@gmail.com> wrote: > >> >> >> On 25 October 2015 at 03:17, louijp <louijp@yahoo.com> wrote: >> >>> Nop Head, >>> I disagree with you, 0/0 is not defined, so it is not a number. >>> Undef or Nan are both acceptable. >>> >> >> It is defined in the programming sense. It has been given a value that is >> undefined in the mathematical sense represented by nan. That is different >> to using a variable that has never been assigned. >> >> >>> >>> Jean-Paul >>> AC9GH >>> >>> >>> >>> Sent from my Verizon Wireless 4G LTE smartphone >>> >>> >>> -------- Original message -------- >>> From: nop head <nop.head@gmail.com> >>> Date: 2015/10/24 8:08 PM (GMT-05:00) >>> To: OpenSCAD general discussion <discuss@lists.openscad.org> >>> Subject: Re: [OpenSCAD] Software bug >>> >>> I am not sure undef and nan are the same. If I don't define x but use it >>> then it is undefined. x = 0/0 is different because x is defined but >>> mathematically not a number. >>> >>> >>> >>> On 24 October 2015 at 23:37, Andrew Plumb <andrew@plumb.org> wrote: >>> >>>> If you were trying to test “2^(1/0)” then the function you want is >>>> pow(2,1/0). >>>> >>>> echo( exp(1/0) ); >>>> -> inf >>>> echo( pow(2,1/0) ); >>>> -> inf >>>> >>>> Andrew. >>>> >>>> On Oct 24, 2015, at 5:39 PM, doug moen <doug@moens.org> wrote: >>>> >>>> exp(x) is a function that takes exactly one argument. It's probably >>>> using generic code to return undef if the number of arguments is incorrect. >>>> Which is fine. >>>> >>>> undef and NaN play exactly the same role in the language. Rather than >>>> debate when to return undef and when to return nan in a bunch of different >>>> cases, I'd rather just unify them into a single value. >>>> >>>> On 24 October 2015 at 17:29, don bright <hmbright@fastmail.com> wrote: >>>> >>>>> The manual has been updated. >>>>> >>>>> >>>>> https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/Mathematical_Functions#Infinitudes_and_NaNs >>>>> >>>>> Interesting note.... OpenSCAD seems to return 'undef' for exp(2,1/0) >>>>> but it is probably intended to be returning NaN.... >>>>> >>>>> --- >>>>> hmbright@fastmail.com >>>>> >>>>> >>>>> On Sat, Oct 24, 2015, at 06:55 AM, nop head wrote: >>>>> >>>>> atan(90) is not infinite, it is close to 90 degrees as is the atan of >>>>> any large number. It approaches 90 asymptotically. >>>>> >>>>> tan(90) is definitely infinite, so inf is correct. >>>>> >>>>> echo(atan(tan(90))); gives 90 as it should. >>>>> Only 0/0 is undefined and that does give nan. >>>>> >>>>> >>>>> >>>>> >>>>> On 24 October 2015 at 05:13, doug moen <doug@moens.org> wrote: >>>>> >>>>> The IEEE floating point standard says that 2/0 is inf, and that's the >>>>> standard we are following. While your argument for NaN is mathematically >>>>> correct, at least where real numbers or exact arithmetic is concerned, >>>>> floating point computation doesn't have the same behaviour as real number >>>>> arithmetic. For example, it has underflow, where a sufficiently small >>>>> positive result is represented by 0, and a sufficiently small negative >>>>> result is represented by -0, which is different from 0 in IEEE floats. So >>>>> the floating point number 0 sometimes represents a true 0, and it sometimes >>>>> represents a very small positive real number. So the IEEE float standards >>>>> committee decided to define 1/0 as inf and -1/0 as -inf, and this results >>>>> in useful behaviour, making it easier to write floating point code, in a >>>>> lot of cases. And yes, this is a compromise, since it's not the right >>>>> behaviour in all cases. >>>>> >>>>> >>>>> On 23 October 2015 at 23:37, wolf <wv99999@gmail.com> wrote: >>>>> >>>>> echo(2/0, atan(2/0), atan(90)); >>>>> returns >>>>> ECHO: inf, 90, 89.3634 >>>>> >>>>> The proper response for a division by zero should be not-a-number >>>>> (NaN), >>>>> since that division may result in any number. Consider sin(0)/0=0, >>>>> which is >>>>> a valid expression since the limit for xapproaching zero exists. >>>>> atan(2/0) should result in undefined, and atan(90) should result in >>>>> inf, >>>>> since the respective Taylor series does not converge and no value can >>>>> be >>>>> computed. >>>>> >>>>> By the way, is there a means to properly display a formula like >>>>> binom{limit}{x rightarrow 0} {sin( x)} over {x} = 0 >>>>> when posting? >>>>> >>>>> >>>>> >>>>> -- >>>>> View this message in context: >>>>> http://forum.openscad.org/Software-bug-tp14194.html >>>>> Sent from the OpenSCAD mailing list archive at Nabble.com. >>>>> >>>>> _______________________________________________ >>>>> OpenSCAD mailing list >>>>> Discuss@lists.openscad.org >>>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> OpenSCAD mailing list >>>>> Discuss@lists.openscad.org >>>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>>>> >>>>> >>>>> *_______________________________________________* >>>>> OpenSCAD mailing list >>>>> Discuss@lists.openscad.org >>>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> OpenSCAD mailing list >>>>> Discuss@lists.openscad.org >>>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>>>> >>>>> >>>> _______________________________________________ >>>> OpenSCAD mailing list >>>> Discuss@lists.openscad.org >>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>>> >>>> >>>> >>>> _______________________________________________ >>>> OpenSCAD mailing list >>>> Discuss@lists.openscad.org >>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>>> >>>> >>> >>> _______________________________________________ >>> OpenSCAD mailing list >>> Discuss@lists.openscad.org >>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>> >>> >> > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org > >