Re: [Pharo-project] Extending #< to compare all numbers
"Schwab,Wilhelm K" <bschwab@anest.ufl.edu>
Floating point is not always what it seems. Â
Hence my comment that IEEE floats get "the wrong answer fast". I have used interval math, continued fractions, and linear fractional transforms (a.k.a. exact reals). I agree that each representation has its challenges. Let's talk for a second about integers. 0 = (0+0i) --> true 1 = (1+0i) --> true 0 < 1 --> true (0+0i) < (1+0i) --> ?? which answer here gives me the least surprise ?? To put it another way (A = a) --> true (B = b) --> true (A < B) --> true (a < b) --> ?? what do you expect to see here ??
By extension, I argue that computer-represented complex numbers are not always what they seem, only more so. Â
Agreements: computers don't do math well. Computers approximate math. We would prefer to get the best approximations possible and be told when we are in deep waters. There are math systems (e.g. using interval arithmetic) which either complain that they can't come up with a sensible answer (all the bits are roundoff error) or go back and recompute with higher precision numeric representations in order to get X digits of correct precision. I am _not_ proposing to make Pharo into such a system.
Intuition resulting from lots of exposure to mathematicians suggests that they consider this non-trivial but well-known.
I don't consider "What Every Computer Scientist Should Know About Floating-Point Arithmetic" trivial -- especially for us non-mathematician users of numbers. [ http://docs.sun.com/source/806-3568/ncg_goldberg.html ]
If I am reading this correctly, defining $< is making a promise we can't keep, or perhaps we simply should not try.
Again, I am using unit tests as a fixed point. I want "if A=a and B=b and A<B then a<b" to work as I expect. I consider anything else to be deeply broken.
If you can find something that claims to produce a sensible ordering of complex numbers, please post a reference. Â For now, my sense is that such a thing cannot exist.
I posted what I consider a sensible ordering which unit tests the property I care about. It happens to be a total ordering (not that I really care). I can certainly remove Complex>>< from the code, but I deeply dislike breaking basic logic on integers. I would prefer to have something more meaningful than "mathematicians can't agree on a theoretical ordering of complex numbers, so practical logic must fail". Do you really not believe that (0+0i) = 0 ?? Why, such numbers must be imaginary!! ;^) -KenD
Ken, My concerns are not with the (representable) numbers in your tests; it is with the many numbers that do not have exact representations, and with those that will contain roundoff error. Please note that I never called "What Every Computer Scientist Should Know About Floating-Point Arithmetic" trivial - in fact, I used the word non-trivial in connection with such things. I gather that $< is very important to you. What is so critical about it? There is probably a way to solve any problem you have without creating problems in the process, such as using a keyword message to do the comparison and keeping complex numbers separate from magnitudes. "Do you really not believe that (0+0i) = 0 ?? Why, such numbers must be imaginary!! ;^)" Try 0+(0.1+0.1+0.1-0.3)i = 0. Is it so clear now? The zero imaginary part is simple for us, but not nearly so clear to a machine. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Ken.Dickey Sent: Wednesday, August 12, 2009 4:00 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Extending #< to compare all numbers "Schwab,Wilhelm K" <bschwab@anest.ufl.edu>
Floating point is not always what it seems.
Hence my comment that IEEE floats get "the wrong answer fast". I have used interval math, continued fractions, and linear fractional transforms (a.k.a. exact reals). I agree that each representation has its challenges. Let's talk for a second about integers. 0 = (0+0i) --> true 1 = (1+0i) --> true 0 < 1 --> true (0+0i) < (1+0i) --> ?? which answer here gives me the least surprise ?? To put it another way (A = a) --> true (B = b) --> true (A < B) --> true (a < b) --> ?? what do you expect to see here ??
By extension, I argue that computer-represented complex numbers are not always what they seem, only more so.
Agreements: computers don't do math well. Computers approximate math. We would prefer to get the best approximations possible and be told when we are in deep waters. There are math systems (e.g. using interval arithmetic) which either complain that they can't come up with a sensible answer (all the bits are roundoff error) or go back and recompute with higher precision numeric representations in order to get X digits of correct precision. I am _not_ proposing to make Pharo into such a system.
Intuition resulting from lots of exposure to mathematicians suggests that they consider this non-trivial but well-known.
I don't consider "What Every Computer Scientist Should Know About Floating-Point Arithmetic" trivial -- especially for us non-mathematician users of numbers. [ http://docs.sun.com/source/806-3568/ncg_goldberg.html ]
If I am reading this correctly, defining $< is making a promise we can't keep, or perhaps we simply should not try.
Again, I am using unit tests as a fixed point. I want "if A=a and B=b and A<B then a<b" to work as I expect. I consider anything else to be deeply broken.
If you can find something that claims to produce a sensible ordering of complex numbers, please post a reference. Â For now, my sense is that such a thing cannot exist.
I posted what I consider a sensible ordering which unit tests the property I care about. It happens to be a total ordering (not that I really care). I can certainly remove Complex>>< from the code, but I deeply dislike breaking basic logic on integers. I would prefer to have something more meaningful than "mathematicians can't agree on a theoretical ordering of complex numbers, so practical logic must fail". Do you really not believe that (0+0i) = 0 ?? Why, such numbers must be imaginary!! ;^) -KenD _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2009/8/12 Ken.Dickey <Ken.Dickey@whidbey.com>:
"Schwab,Wilhelm K" <bschwab@anest.ufl.edu>
Floating point is not always what it seems.
Hence my comment that IEEE floats get "the wrong answer fast". Â I have used interval math, continued fractions, and linear fractional transforms (a.k.a. exact reals). Â I agree that each representation has its challenges.
Let's talk for a second about integers.
 0 = (0+0i)  --> true  1 = (1+0i)  --> true  0 < 1      --> true  (0+0i) < (1+0i)  --> ?? which answer here gives me the least surprise ??
To put it another way
(A = a) Â --> true (B = b) Â --> true (A < B) --> true (a < b) Â --> ?? what do you expect to see here ??
Let me extend your test a little i do expect that, if : a < b and 0 < x then a*x < b*x now lets pick a = 1i, b = 2i , x = 1i. a <b -> returns true, good! 0 < x -> also returns true, good! now what about: a*x < b*x ? 1i*1i < 2i*1i ==> -1 < -2 -- what is a _least_ surprising answer of this expression?
By extension, I argue that computer-represented complex numbers are not always what they seem, only more so.
Agreements: computers don't do math well. Â Computers approximate math. Â We would prefer to get the best approximations possible and be told when we are in deep waters.
There are math systems (e.g. using interval arithmetic) which either complain that they can't come up with a sensible answer (all the bits are roundoff error) or go back and recompute with higher precision numeric representations in order to get X digits of correct precision.
I am _not_ proposing to make Pharo into such a system.
Intuition resulting from lots of exposure to mathematicians suggests that they consider this non-trivial but well-known.
I don't consider "What Every Computer Scientist Should Know About Floating-Point Arithmetic" trivial -- especially for us non-mathematician users of numbers. [ http://docs.sun.com/source/806-3568/ncg_goldberg.html ]
If I am reading this correctly, defining $< is making a promise we can't keep, or perhaps we simply should not try.
Again, I am using unit tests as a fixed point.
I want "if A=a and B=b and A<B then a<b" to work as I expect. Â I consider anything else to be deeply broken.
If you can find something that claims to produce a sensible ordering of complex numbers, please post a reference. Â For now, my sense is that such a thing cannot exist.
I posted what I consider a sensible ordering which unit tests the property I care about. Â It happens to be a total ordering (not that I really care).
I can certainly remove Complex>>< from the code, but I deeply dislike breaking basic logic on integers. Â I would prefer to have something more meaningful than "mathematicians can't agree on a theoretical ordering of complex numbers, so practical logic must fail".
Do you really not believe that (0+0i) = 0 ?? Â Why, such numbers must be imaginary!! Â Â ;^)
-KenD
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
Em 12/08/2009 19:30, Igor Stasenko < siguctua@gmail.com > escreveu:
2009/8/12 Ken.Dickey :
"Schwab,Wilhelm K"
Floating point is not always what it seems.
Hence my comment that IEEE floats get "the wrong answer fast". I have used interval math, continued fractions, and linear fractional transforms (a.k.a. exact reals). I agree that each representation has its challenges.
Let's talk for a second about integers.
0 = (0+0i) --> true 1 = (1+0i) --> true 0 < 1 --> true (0+0i) < (1+0i) --> ?? which answer here gives me the least surprise ??
To put it another way
(A = a) --> true (B = b) --> true (A < B) --> true (a < b) --> ?? what do you expect to see here ??
Let me extend your test a little
i do expect that, if :
a < b
and
0 < x
then
a*x < b*x
Your "counter example" is mathematically flawed even in Real (non imaginary): let a = 1; b = 2 and x = -1: a < b and a*x > b*x So there isn't this kind of transitivity for inequality operators at all. [snipped]
2009/8/13 <csrabak@bol.com.br>:
Em 12/08/2009 19:30, Igor Stasenko < siguctua@gmail.com > escreveu:
2009/8/12 Ken.Dickey :
"Schwab,Wilhelm K"
Floating point is not always what it seems.
Hence my comment that IEEE floats get "the wrong answer fast". Â I have used interval math, continued fractions, and linear fractional transforms (a.k.a. exact reals). Â I agree that each representation has its challenges.
Let's talk for a second about integers.
 0 = (0+0i)  --> true  1 = (1+0i)  --> true  0 < 1      --> true  (0+0i) < (1+0i)  --> ?? which answer here gives me the least surprise ??
To put it another way
(A = a) Â --> true (B = b) Â --> true (A < B) --> true (a < b) Â --> ?? what do you expect to see here ??
Let me extend your test a little
i do expect that, if :
a < b
and
0 < x
then
a*x < b*x
Your "counter example" is mathematically flawed even in Real (non imaginary):
let a = 1; b = 2 and x = -1:
do you intentionally missed the condition 0 < x?
a < b and a*x > b*x
So there isn't this kind of transitivity for inequality operators at all.
[snipped]
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
Just briefly... I'd keep the base numbers simple while leaving the door open for optional, loadable packages to extend comparisons as necessary. IMO, matching the capabilities of C (integers, floating point) plus fractions should be sufficient for a base system. If not, there is the risk of creeping featurism. Not long ago, Ralph Johnson pointed out to a 1998 presentation by Guy L Steele regarding the design of the Java language, and GLS makes good points regarding the need to prevent the definition of a "language" or its "default shipping offer" from offering more than necessary. My 2 cents... Andres. Igor Stasenko wrote:
2009/8/13 <csrabak@bol.com.br>:
Em 12/08/2009 19:30, Igor Stasenko < siguctua@gmail.com > escreveu:
2009/8/12 Ken.Dickey :
"Schwab,Wilhelm K"
Floating point is not always what it seems.
Hence my comment that IEEE floats get "the wrong answer fast". I have used interval math, continued fractions, and linear fractional transforms (a.k.a. exact reals). I agree that each representation has its challenges.
Let's talk for a second about integers.
0 = (0+0i) --> true 1 = (1+0i) --> true 0 < 1 --> true (0+0i) < (1+0i) --> ?? which answer here gives me the least surprise ??
To put it another way
(A = a) --> true (B = b) --> true (A < B) --> true (a < b) --> ?? what do you expect to see here ??
Let me extend your test a little
i do expect that, if :
a < b
and
0 < x
then
a*x < b*x
Your "counter example" is mathematically flawed even in Real (non imaginary):
let a = 1; b = 2 and x = -1:
do you intentionally missed the condition 0 < x?
a < b and a*x > b*x
So there isn't this kind of transitivity for inequality operators at all.
[snipped]
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (5)
-
Andres Valloud -
csrabak＠bol.com.br -
Igor Stasenko -
Ken.Dickey -
Schwab,Wilhelm K