# Software bug

15 messages
Open this post in threaded view
|

## Software bug

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

## Re: Software bug

 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 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 [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Open this post in threaded view
|

## Re: Software bug

Open this post in threaded view
|

## Re: Software bug

Open this post in threaded view
|

## Re: Software bug

Open this post in threaded view
|

## Re: Software bug

Open this post in threaded view
|

## Re: Software bug

Open this post in threaded view
|

## General thank you

 In reply to this post by clothbot 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 XP to XUbuntu - The journey, join me! 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 <[hidden email]> 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 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....       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 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 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         _______________________________________________ OpenSCAD mailing list   _______________________________________________ OpenSCAD mailing list   _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org ```_______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org ``` _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org Rob W Lake Tyers Beach, Victoria, Australia
Open this post in threaded view
|

## Re: Software bug

Open this post in threaded view
|

## Re: Software bug

Open this post in threaded view
|

## Re: Software bug

Open this post in threaded view
|

## Re: Software bug

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