December 22, 2024
Floats
If you evaluate the following code in LearningWorks.
| myFloat yourFloat |
myFloat := 3.1.
yourFloat := 3.1.
myFloat == yourFloat
You will find that it answers false.
| myFloat yourFloat |
myFloat := 3.1.
yourFloat := myFloat copy.
myFloat == yourFloat
Also answers false.
This clearly establishes that floats are not unique. But this
is an implementation issue, because in some Smalltalk systems I believe
that
3.1 == 3.1
will answer true. In LW this is not the case
and each time a float is evaluated, and hence needed, a new one is generated.
The versions that answer true keep a list of
literals and reuse as and when needed. Don't ask me which versions do
this because I don't know, but I have read that this is the case.
In LB21 discussion 13 it states:
"In the expression 3.1 == 3.1 there are two 3.1 objects and each object 3.1 is an instance of Float and is not immutable. Hence the expression returns false as there are two different objects. Evaluating 3.1 = 3.1 will return true."
Well I reckon that this is wrong and that floats are immutable, even if you can copy them. Copies of floats are not the same object, but I think that M206 gives a misleading view of immutability and one of the reasons for this is that it appears to be linked to uniqueness.
I have spoken with a colleague who has this take on Smalltalk. He stresses, and I agree, that it takes a very cooperative approach. By that I mean that programmers should act within a certain spirit and if something is proclaimed as immutable then we should respect that. It's certainly possible to subvert this and with floats he claims that you could undermine the system. He gave me the code to do this, but I am not about to divulge (maybe another time). But he started with:
x := 3.0
"code omitted"
"...you'll find that x
is now 2.76563. My
guess (I ain't no guru) is that this is just hacking away at the binary
representation of the number. But, using the (cooperative) public protocol
of Float, I think
its instances are immutable."
In Block 4 you will look at symbols. For me M206's claim that symbols
are immutable is a thorny issue, as I could go on to show by use of the
basicAt:put: message selector (see the Word
doc Smalltalk Traps and Bugs). A simple word of
warning though, don't!
M206 when discussing symbols states that:
"once created they cannot be changed."
That is simply not true. But again you could say that the spirit is, "Look, we need to treat them this way because if we don't then all hell will break loose". The Course Team could have told the truth and said that symbols appear to be immutable, before giving a brief outline of Smalltalk's cooperative nature and illustrating how a programmer, who doesn't play ball, can destroy the system.
⇑ Up to top of page