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
|