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.

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

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

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

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

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 <mailto:hmbright@fastmail.com>> wrote: > The manual has been updated. > > https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/Mathematical_Functions#Infinitudes_and_NaNs <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 <mailto: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 <mailto: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 <mailto: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 <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 <mailto:Discuss@lists.openscad.org> >> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org <http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org> >> >> >> >> >> _______________________________________________ >> OpenSCAD mailing list >> Discuss@lists.openscad.org <mailto:Discuss@lists.openscad.org> >> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org <http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org> >> >> _______________________________________________ >> OpenSCAD mailing list >> Discuss@lists.openscad.org <mailto:Discuss@lists.openscad.org> >> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org <http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org> > > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org <mailto:Discuss@lists.openscad.org> > http://lists.openscad.org/mailman/listinfo/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 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 > >

 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 <mailto: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
 <mailto: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
     <mailto: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 <http://Nabble.com>.
         _______________________________________________
         OpenSCAD mailing list
         Discuss@lists.openscad.org
         <mailto:Discuss@lists.openscad.org>
         http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

     _______________________________________________
     OpenSCAD mailing list
     Discuss@lists.openscad.org <mailto:Discuss@lists.openscad.org>
     http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

 _________________________________________________
 OpenSCAD mailing list
 Discuss@lists.openscad.org <mailto:Discuss@lists.openscad.org>
 http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

 _______________________________________________
 OpenSCAD mailing list
 Discuss@lists.openscad.org <mailto:Discuss@lists.openscad.org>
 http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

Just to throw in a philosophical angle to another thread discussing how to deal with the limits of trigonometric and arithmetic functions: Mathematics (IMHO) in its purest form is values free, but as soon as it is applied to the real world, there has to be some judgments applied, as to when and how it is applied. Consequently any transition from the theoretical (eg infinity) to get to a 3-D printed model that I can hold in my hand (and not just in my head) is going to require many judgments and compromises. OpenSCAD is a perfect example when applying pure mathematical concepts to practically rendering 3-D objects on the screen, and later into machinable shapes. I am a retired Maths/Science/Technology teacher, and now I would just HAVE to have openSCAD and a 3-D printer in my classroom (s). The conversations in this forum are very helpful to my understanding of the scope of openSCAD. The convergence of theoretical maths being applied so directly to real world challenges, and at a level that people can access relatively easily, is just a fantastic teaching learning opportunity. The positive and constructive critique in this discussion list of the openSCAD system encourages me to look forward to more improvements in operation and documentation. I no longer feel condemned to the daily paper's crossword or Sudoku puzzle to keep my brain in trim. OpenSCAD is the perfect reply to the often asked question in Mathematics classes "When are we ever going to use this again Sir??" Thank you folks! *Rob Ward* Lake Tyers Beach, 3909 Lake Tyers Beach Website <http://www.laketyersbeach.net.au> XP to XUbuntu - The journey, join me! <http://www.laketyersbeach.net.au/XP2XU.html> On 25/10/15 09:37, Andrew Plumb 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 >> <mailto: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 >> <mailto: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 <mailto: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 >>> <mailto: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 >>> <mailto: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 <http://Nabble.com>. >>> _______________________________________________ >>> OpenSCAD mailing list >>> Discuss@lists.openscad.org >>> <mailto:Discuss@lists.openscad.org> >>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>> >>> _______________________________________________ >>> OpenSCAD mailing list >>> Discuss@lists.openscad.org <mailto:Discuss@lists.openscad.org> >>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>> >>> _________________________________________________ >>> OpenSCAD mailing list >>> Discuss@lists.openscad.org <mailto:Discuss@lists.openscad.org> >>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >> >> _______________________________________________ >> OpenSCAD mailing list >> Discuss@lists.openscad.org <mailto:Discuss@lists.openscad.org> >> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >> >> >> _______________________________________________ >> OpenSCAD mailing list >> Discuss@lists.openscad.org <mailto: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

nan and undef are both used as the return value from a function, when an argument is passed that is outside the domain of the function. In this context, they have the same meaning, but we aren't consistent about whether we return nan or undef. len(x) is only defined if x is a string or list, so len(42) == undef. asin(x) is only defined if x is a number in the range [-1...+1]. asin(2) is nan, but asin("foo") is undef. foo[i] is only defined if foo is a string or list, and i is an integer in the range [0...len(foo)-1]. "abc"[0] == "a" "abc"[42] == undef On 24 October 2015 at 20:08, nop head <nop.head@gmail.com> wrote: > 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 > >

the test suite had a bug , was passing two variables to exp() i updated the test suite --- hmbright@fastmail.com On Sat, Oct 24, 2015, at 04:39 PM, doug moen 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