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? |
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 <[hidden email]> wrote: echo(2/0, atan(2/0), atan(90)); _______________________________________________ OpenSCAD mailing list [hidden email] 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. Only 0/0 is undefined and that does give nan.tan(90) is definitely infinite, so inf is correct. echo(atan(tan(90))); gives 90 as it should. On 24 October 2015 at 05:13, doug moen <[hidden email]> wrote:
_______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
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:
_______________________________________________ OpenSCAD mailing list [hidden email] 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. On 24 October 2015 at 17:29, don bright <[hidden email]> wrote:
_______________________________________________ OpenSCAD mailing list [hidden email] 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.
_______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org signature.asc (506 bytes) Download Attachment |
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 <[hidden email]> wrote:
_______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
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! 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). _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Rob W
Lake Tyers Beach, Victoria, Australia |
In reply to this post by nophead
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 <[hidden email]> wrote:
_______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
In reply to this post by doug.moen
the test suite had a bug , was passing two variables to exp()
i updated the test suite
---
On Sat, Oct 24, 2015, at 04:39 PM, doug moen wrote:
_______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
In reply to this post by wolf
Nop Head, I disagree with you, 0/0 is not defined, so it is not a number. Undef or Nan are both acceptable. Jean-Paul AC9GH Sent from my Verizon Wireless 4G LTE smartphone -------- Original message -------- From: nop head <[hidden email]> Date: 2015/10/24 8:08 PM (GMT-05:00) To: OpenSCAD general discussion <[hidden email]> 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 <[hidden email]> wrote:
_______________________________________________ OpenSCAD mailing list [hidden email] 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:
"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 |
In reply to this post by louijp
On 25 October 2015 at 03:17, louijp <[hidden email]> wrote:
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.
_______________________________________________ OpenSCAD mailing list [hidden email] 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 <[hidden email]> wrote:
_______________________________________________ OpenSCAD mailing list [hidden email] 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 <[hidden email]> wrote: I think the compiler should report a fatal error message if there is a reference to an unassigned variable. _______________________________________________ OpenSCAD mailing list [hidden email] http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org |
Free forum by Nabble | Edit this page |