Extending #< to compare all numbers

Greetings,

Since there is some discussion around comparing using#< let me try to explain
the context of my thinking.


I am approaching this as a programmer and a user of mathematics, not as a
mathematician.

I prefer the Principle of Least Surprise.

I prefer simple, easy to explain rules and simple implementations.


I expect the following expressions all to answer true.

  1/2 = 0.5.
  1 = 1 asComplex.
  1 = (1 + 0i).  "same as the previous line"
  0 < 1.
  0 < 1 asComplex.

Every number is-equivalent-to a complex number because 1 = (1 + 0i).

[In the Scheme language every number _is_ a complex number, BTW].

So to me, saying that 0 and (1 asComplex) are not comparable is saying that 0
and 1 are also not comparable, because I consider them numerically the same
as (0+0i) and (1+0i).


My observation is that I don't want to lose properties.  If A and B are
numbers, I want them to be comparable on the real number line -- no matter
how many other dimensions I add.

If B is to the right on the real number line from A, then I expect (A < B) to
answer true.   I expect this to be true NO MATTER HOW MANY DIMENSIONS I ADD.

To put this in context, say that I have an object which is a "basket of
measurements" at a place and time (say position, density, temperature,
pressure).  Now if I add a new dimension, say electrical conductivity, I do
not expect temperature comparisons to stop working.  I can still compare
temperatures between objects which lack the conductivity slot/measurement and
those which have them.

OK.  Now to the extension.  I suspect this is the root of the (potential)
controversy.

I chose to say that if the real/x component of a 2d number is equal, then one  
number may be considered less than another if the imaginary/y value is less.

This means that (0+0i) < (0+1i) holds.

These are the properties (and test cases) I care about.

Currently, the definition for Complex>>< is just this (see below).  This
implies that (3+0i) < (3+1i) holds, even though the x/real components are
equal.

I think that this is OK.  What do you think?  


Are there simpler, least surprising definitions for Complex>>< ?  

What useful properties/invariants/tests would you add?  [As unit tests]


Thanks for your thoughtful input.

-KenD
--------------------------------Complex
< other
        "self < other if other's real-part is to the right or the real-parts are
equal and the oher's imaginary part is larger"
        | otherCpx |
        otherCpx := other asComplex.
        ^self real < otherCpx real
                        or: [self real = otherCpx real  and: [self imag < otherCpx imag]]
---------------------------------

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Ken,

1/2 = 0.5 comes close to making an important point, but it doesn't quite get there.  However, inspect

  0.1+0.1+0.1-0.3

Floating point is not always what it seems.  By extension, I argue that computer-represented complex numbers are not always what they seem, only more so.  Not only do they have the representation/precision quirks of floats, they are sometimes appropriate and sometimes indicative of nonsense.  The line between those two cases is best left to the application programmer who will happily signal their desire to use complex numbers by inserting #asComplex.


"Every number is-equivalent-to a complex number because 1 = (1 + 0i).
[In the Scheme language every number _is_ a complex number, BTW]."

The same is (AFAIK) true in matlab, but that does not make the machine number problems go away, at least not if one wants to use floating point coprocessors.  Treating the real line as a subspace of complex plane is fine in a purely mathematical setting, but things get interesting once real-world data, and the occaisional non-representable number, start flying through an algorithm running on hardware.  Also, matlab is not the first thing people think of when they want blazing speed, in part because of the way it treats numbers and because of its interpreted execution[*].

Intuition resulting from lots of exposure to mathematicians suggests that they consider this non-trivial but well-known.  As a result, there are fleeting insights in exercises and other forums intended for teaching.  That can make it difficult to get a clear answer.  However, their official reading appears to be that while one can create total orders on the complex numbers, something will always suffer.  That is probably because arbitrary decisions have to be made (what is greater than what, does the real or imaginary part get to break the tie?) and result in arbitrary behavior.  A couple of IEEE sources state that orders on complex numbers are "meaningless."  That means those most likely to take notice of the work will fault us for defining such an order.

If I am reading this correctly, defining $< is making a promise we can't keep, or perhaps we simply should not try.  You will be doing a great service if you can simply get all the arithmetic and transcendental functions to work properly on complex arguments.  However, I think there are compelling reasons to *not* try to make the existing magnitudes coerce into complex numbers.

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.

Bill


[*] Interpreters can be fast, as Object Arts showed in nice paper some time back, but, matlab's is apparently not terribly quick.  I base that on cautions I received from various sources in a recent exploration of Octave as a possible vehicle to solving a problem.



-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Ken.Dickey
Sent: Wednesday, August 12, 2009 1:34 PM
To: [hidden email]
Subject: [Pharo-project] Extending #< to compare all numbers

Greetings,

Since there is some discussion around comparing using#< let me try to explain the context of my thinking.


I am approaching this as a programmer and a user of mathematics, not as a
mathematician.

I prefer the Principle of Least Surprise.

I prefer simple, easy to explain rules and simple implementations.


I expect the following expressions all to answer true.

  1/2 = 0.5.
  1 = 1 asComplex.
  1 = (1 + 0i).  "same as the previous line"
  0 < 1.
  0 < 1 asComplex.

Every number is-equivalent-to a complex number because 1 = (1 + 0i).

[In the Scheme language every number _is_ a complex number, BTW].

So to me, saying that 0 and (1 asComplex) are not comparable is saying that 0
and 1 are also not comparable, because I consider them numerically the same
as (0+0i) and (1+0i).


My observation is that I don't want to lose properties.  If A and B are
numbers, I want them to be comparable on the real number line -- no matter
how many other dimensions I add.

If B is to the right on the real number line from A, then I expect (A < B) to
answer true.   I expect this to be true NO MATTER HOW MANY DIMENSIONS I ADD.

To put this in context, say that I have an object which is a "basket of
measurements" at a place and time (say position, density, temperature,
pressure).  Now if I add a new dimension, say electrical conductivity, I do
not expect temperature comparisons to stop working.  I can still compare
temperatures between objects which lack the conductivity slot/measurement and
those which have them.

OK.  Now to the extension.  I suspect this is the root of the (potential)
controversy.

I chose to say that if the real/x component of a 2d number is equal, then one  
number may be considered less than another if the imaginary/y value is less.

This means that (0+0i) < (0+1i) holds.

These are the properties (and test cases) I care about.

Currently, the definition for Complex>>< is just this (see below).  This
implies that (3+0i) < (3+1i) holds, even though the x/real components are
equal.

I think that this is OK.  What do you think?  


Are there simpler, least surprising definitions for Complex>>< ?  

What useful properties/invariants/tests would you add?  [As unit tests]


Thanks for your thoughtful input.

-KenD
--------------------------------Complex
< other
        "self < other if other's real-part is to the right or the real-parts are
equal and the oher's imaginary part is larger"
        | otherCpx |
        otherCpx := other asComplex.
        ^self real < otherCpx real
                        or: [self real = otherCpx real  and: [self imag < otherCpx imag]]
---------------------------------

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

"Schwab,Wilhelm K" <[hidden email]>
> 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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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: [hidden email] [mailto:[hidden email]] On Behalf Of Ken.Dickey
Sent: Wednesday, August 12, 2009 4:00 PM
To: [hidden email]
Subject: Re: [Pharo-project] Extending #< to compare all numbers

"Schwab,Wilhelm K" <[hidden email]>
> 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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2009/8/12 Ken.Dickey <[hidden email]>:
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?




--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Em 12/08/2009 19:30, Igor Stasenko < [hidden email] > escreveu:

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]


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2009/8/13  <[hidden email]>: do you intentionally missed the condition 0 < x?



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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:
_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project