Float Objects

Why does,


| x y |

x := 1.0*1.0.
y := 1.0.

x == y. true

evaluate to true, whereas


#(0.0 1.0 2.0 3.0) select: [:i | i == (i*i)] ()

returns an empty set ?

Thanks in Advance,
Pranab Mehta

Pranab Mehta wrote(-ish):

> Why does,
> | x y |
>
> x := 1.0*1.0.
> y := 1.0.
> x == y.
> evaluate to true, whereas [...]

Which Smalltalk are you using ?  That expression comes out false on all the
implementations I've tried.

-- chris

"Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> wrote in
news:tNadna5z8c9q8c_cRVn-gw@nildram.net:

> Pranab Mehta wrote(-ish):
> 
>
> Which Smalltalk are you using ?  That expression comes out false on
> all the implementations I've tried.
>
>     -- chris
>
>

IBM VisualAge SmallTalk.

Also, I noticed something different from what my reference book
suggested, the following also evaluates to true -

| x y |

x := 'hello'.
y := 'hello'.

x == y. true

Any clue, why ?

Pranab Mehta wrote:
 

> IBM VisualAge SmallTalk.

Funny ?  It comes out false for me.  This is pasted from a workspace in IBM
Smalltalk 6.0.1

| x y |

x := 1.0*1.0.
y := 1.0.

x == y.  false

I'm afraid that I have no idea at all why you are getting a different answer
.


> Also, I noticed something different from what my reference book
> suggested, the following also evaluates to true -
>
> | x y |
>
> x := 'hello'.
> y := 'hello'.
>
> x == y. true

Now that I can tell you.  (And the answer may even be correct ;-)  IBM St
merges String literal objects that are found in one compilation.  So if you
evaluate the above in one go, the two occurrences of 'hello' will be compile
d
into references to the /same/ instance of String.  This optimisation is, I
think, misguided since it saves very little and causes unnecessary confusion
.
Under "normal" circumstances the String(s) wouldn't have come from the same
compilation, and so they would only be =, not ==.  (At least, I /think/ it's
done on a per-compilation basis, rather than globally (as in Java).  That's 
how
Dolphin St implements the same idea anyway.)

Perhaps your version of IBM St is doing something similar with Float literal
s
and constant-valued expressions ??

-- chris

On Thu, 23 Sep 2004 08:21:21 +0100, Chris Uppal wrote:

FWIW: it does evaluate to true in VA 5.5.2

> Pranab Mehta wrote:
> 
> 
>
> Funny ?  It comes out false for me.  This is pasted from a workspace in IB
M
> Smalltalk 6.0.1
>
> | x y |
>
> x := 1.0*1.0.
> y := 1.0.
>
> x == y.  false
>
<...>

Bob Nemec wrote:
> On Thu, 23 Sep 2004 08:21:21 +0100, Chris Uppal wrote:
>
> FWIW: it does evaluate to true in VA 5.5.2

I remember that at some stage VAST parser/compiler was converting equal
literals to references to the same single instance.
I am not sure whether it was intentional or just a side effect of some
equality based lookup somewhere deep in the guts.



Regards, Jaroslaw.
 
>
> <...>

Pranab,

> Why does,
>
>
> | x y |
>
> x := 1.0*1.0.
> y := 1.0.
>
> x == y. true
>
> evaluate to true, whereas
>
>
> #(0.0 1.0 2.0 3.0) select: [:i | i == (i*i)] ()
>
> returns an empty set ?

The basic problem here is one of representing floating-point numbers on the
computer.  The computer uses some number of significant digits with an
exponent.  Multiplying (and performing other arithmetic operations on)
floating-point numbers can lead to rounding errors in some circumstances,
for example 1.0 is expressed as 0.999999999999999999 * 10^0.  The exponent
is 10^0.  Naturally, 1.0 is not equal to 0.999999999999999999 * 10^0, but it
should be because it is within the precision of the computer to distinguish
between one floating-point number and another.

Because of this, and no matter whether there is a bug in the particular
Smalltalk environment you are using, you should not use an "=" or "=="
message to compare floating-point numbers.  You should write some code to
find out what that resolution is on your computer and then use that
precision to check to see if you can distinguish between the floating-point
numbers.  If they can not be distinguished, they are equal as far as the
computer is concerned.

Hope that makes sense.

Regards,

Randy

The == operator compares the object addresses (handles.)

The result will return true if the addresses are the same regardless
of what its an address of (or to.)

It depends on whether your parser evaluates two literal strings in the
parsing process to one instance (in which case the answer to == will
be true,) or to two instances (in which case the answer to == will be
false.)

-Charles-A.

"Randy A. Ynchausti" <randy.ynchausti@oocl.com> wrote in message news:<415824df@news.totall
yobjects.com>...
> Pranab,
> 
>
> The basic problem here is one of representing floating-point numbers on th
e
> computer.  The computer uses some number of significant digits with an
> exponent.  Multiplying (and performing other arithmetic operations on)
> floating-point numbers can lead to rounding errors in some circumstances,
> for example 1.0 is expressed as 0.999999999999999999 * 10^0.  The exponent
> is 10^0.  Naturally, 1.0 is not equal to 0.999999999999999999 * 10^0, but 
it
> should be because it is within the precision of the computer to distinguis
h
> between one floating-point number and another.
>
> Because of this, and no matter whether there is a bug in the particular
> Smalltalk environment you are using, you should not use an "=" or "=="
> message to compare floating-point numbers.  You should write some code to
> find out what that resolution is on your computer and then use that
> precision to check to see if you can distinguish between the floating-poin
t
> numbers.  If they can not be distinguished, they are equal as far as the
> computer is concerned.
>
> Hope that makes sense.
>
> Regards,
>
> Randy