ANSI, =, hash, Integer, Float

Stephan Rudlof sr at evolgo.de
Thu Dec 19 14:53:06 UTC 2002


I wrote:
<...>

> Richard A. O'Keefe wrote:
<...>

>>>From a _user's_ perspective, The Simplest Thing That Could Possibly Work
>>is simply to fix #hash.  I not only know that it can be done, I know how
>>to do it.  With the proviso that the code is for specification purposes
>>only (I do NOT propose actually allocating a fresh Float each time):
>>
>>    LargePositiveInteger>>hash   ^self asFloat hash
>>    LargeNegativeInteger>>hash   ^self asFloat hash
>>    Fraction>>hash               ^self asFloat hash
>>    Float hash
>>      ^((self between: SmallIntger minVal and: SmallInteger maxval)
>>        and: self fractionPart = 0.0)
>>        ifTrue: [self truncated hash]
>>        ifFalse: ["the current basicAt: bitAnd: ... stuff goes here"]
>>
>>This ensures consistency by
>> - forcing Float to use SmallInteger hash whenever the float
>>   could be equal to a SmallInteger
>> - forcing rationals other than SmallInteger to use Float hash
>>
>>The change would be hidden entirely inside the Number classes.
>>

<...>

> But independently of your suggestion I don't like mixed mode arithmetics and
> comparisons between rationals (Integers and Fractions) and Floats and would
> like to forbid it.

In the light of ANSI and
  'It's hard to make things fool-proof because fools are so ingenious.'
I have to *cancel* this suggestion! (the horses have been too wild ;-) )

But how to avoid mixed mode arithmetics errors? Seems to remain necessary to
*think* for programmers...


Greetings,

Stephan

> 
> 
> Greetings,
> 
> Stephan


-- 
Stephan Rudlof (sr at evolgo.de)
   "Genius doesn't work on an assembly line basis.
    You can't simply say, 'Today I will be brilliant.'"
    -- Kirk, "The Ultimate Computer", stardate 4731.3




More information about the Squeak-dev mailing list