Software bug

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

Software bug

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

Re: Software bug

doug.moen
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));
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
Reply | Threaded
Open this post in threaded view
|

Re: Software bug

nophead
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 <[hidden email]> 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 <[hidden email]> 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



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Software bug

donbright
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 <[hidden email]> 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 <[hidden email]> 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?
 
 
 
--
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
Reply | Threaded
Open this post in threaded view
|

Re: Software bug

doug.moen
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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?
 
 
 
--
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
Reply | Threaded
Open this post in threaded view
|

Re: Software bug

clothbot
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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?
 
 
 
--
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

signature.asc (506 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Software bug

nophead
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:
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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?
 
 
 
--
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
Reply | Threaded
Open this post in threaded view
|

General thank you

RobWLakes
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).

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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?
 
 
 
--
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
Reply | Threaded
Open this post in threaded view
|

Re: Software bug

doug.moen
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:
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:
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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?
 
 
 
--
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



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Software bug

donbright
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:
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 <[hidden email]> wrote:

The manual has been updated.
 
 
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 <[hidden email]> 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 <[hidden email]> 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?
 
 
 
--
Sent from the OpenSCAD mailing list archive at Nabble.com.
 
_______________________________________________
OpenSCAD mailing list
 
 
 
 
_______________________________________________
OpenSCAD mailing list
 
_______________________________________________
OpenSCAD mailing list
 
 
_______________________________________________
OpenSCAD mailing list
 
_______________________________________________
OpenSCAD mailing list
 

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Software bug

louijp
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:
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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?
 
 
 
--
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
Reply | Threaded
Open this post in threaded view
|

Re: Software bug

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

Re: Software bug

nophead
In reply to this post by louijp


On 25 October 2015 at 03:17, louijp <[hidden email]> 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 <[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:
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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?
 
 
 
--
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



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Software bug

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


On 25 October 2015 at 03:17, louijp <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;louijp@yahoo.com&#39;);" target="_blank">louijp@...> 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 <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;nop.head@gmail.com&#39;);" target="_blank">nop.head@...>
Date: 2015/10/24 8:08 PM (GMT-05:00)
To: OpenSCAD general discussion <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;discuss@lists.openscad.org&#39;);" target="_blank">discuss@...>
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 <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;andrew@plumb.org&#39;);" target="_blank">andrew@...> 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 <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;doug@moens.org&#39;);" target="_blank">doug@...> 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 <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;hmbright@fastmail.com&#39;);" target="_blank">hmbright@...> 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....
 
---
<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;hmbright@fastmail.com&#39;);" target="_blank">hmbright@...
 
 
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 <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;doug@moens.org&#39;);" target="_blank">doug@...> 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 <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;wv99999@gmail.com&#39;);" target="_blank">wv99999@...> 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?
 
 
 
--
Sent from the OpenSCAD mailing list archive at Nabble.com.
 
_______________________________________________
OpenSCAD mailing list
<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;Discuss@lists.openscad.org&#39;);" target="_blank">Discuss@...
 
 
 
 
_______________________________________________
OpenSCAD mailing list
<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;Discuss@lists.openscad.org&#39;);" target="_blank">Discuss@...
 
_______________________________________________
OpenSCAD mailing list
<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;Discuss@lists.openscad.org&#39;);" target="_blank">Discuss@...
 

_______________________________________________
OpenSCAD mailing list
<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;Discuss@lists.openscad.org&#39;);" target="_blank">Discuss@...
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;Discuss@lists.openscad.org&#39;);" target="_blank">Discuss@...
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;Discuss@lists.openscad.org&#39;);" target="_blank">Discuss@...
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



_______________________________________________
OpenSCAD mailing list
<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;Discuss@lists.openscad.org&#39;);" target="_blank">Discuss@...
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
Reply | Threaded
Open this post in threaded view
|

Re: Software bug

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

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:


On 25 October 2015 at 03:17, louijp <[hidden email]> 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 <[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:
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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?
 
 
 
--
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



_______________________________________________
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