ma.chris.m at gmail.com
Wed Dec 17 21:22:17 UTC 2014
> On Wed, Dec 17, 2014 at 11:23 AM, Chris Muller <asqueaker at gmail.com> wrote:
>> On Wed, Dec 17, 2014 at 12:55 PM, Eliot Miranda <eliot.miranda at gmail.com>
>> > Hi Chris,
>> > On Dec 17, 2014, at 9:17 AM, Chris Muller <asqueaker at gmail.com> wrote:
>> >> On Wed, Dec 17, 2014 at 12:20 AM, Eliot Miranda
>> >> <eliot.miranda at gmail.com> wrote:
>> >>> Hi Chris,
>> >>> On Dec 16, 2014, at 7:24 PM, Chris Muller <asqueaker at gmail.com> wrote:
>> >>>> I wish to access some of the Float constants without a message send.
>> >>> I'm curious. Why?
>> >> Speed. I need a fast map of the 32-bit Float range to unsigned 32-bit
>> >> integer range such that comparisons within the integer range are
>> >> consistent with comparisons of their floats.
>> Ah, I can see how my wording created an ambiguous meaning..
>> > So am I right in thunking that you want that if the Float has an integer
>> > equivalent the float and integer have the same hashKey32 and if they don't,
>> > you don't care as long as the hash is well-distributed?
>> No I meant that I need to pickle Floats as an 32-bit Integer,
> Now I'm really confused. How come you can get away with 32-bits when Floats
> are 64-bits?
Because I need speed and efficiency more than precision. I'll be
loading _billions_ of 64-bit Squeak Floats into a indexing system that
operates on 32-bit integers (it can operate at any size even 256-bit
but it operates much faster in a 32-bit range due to a lot smaller and
fewer LargeIntegers and performance takes precedence).
>> while in their pickled Integer state, I need to run #> and #<
>> comparisons against other pickled Floats (e.g., as their Integer
>> representation) and need those comparisons to produce the same results
>> as if they were still in their Float state.
>> For example, the reason I cannot simply use asIEEE32Bit is because
>> negative floats have a high-order bit set, and so the pickled
>> represetnations don't compare correctly:
>> -4.321 asIEEE32Bit < 1.2345 asIEEE32Bit "false" <--- I need true
> So you need an sign-insensitive absolute comparison? Easy to synthesize:
> (self at: 1) bitAnd: 16r7FFFFFFF) << 32 + (self at: 2)
No, I need it to be sign-sensitive. That does not pass the example I
gave. Here are the two number lines again from my original email. I
need to map Floats from:
to Integers in the range:
-Infinity needs to map to 0 and +Infinity to (2^32)-1.
> This will put Infinity beyond the finite values.
>> 32-bit unsigned so I made -Infinity to be 0, +Infinity to be (2^32)-1.
>> But since NaN needs representation too, I decided to put it at the
>> top, so I bumped +Infinity down to (2^32)-2..
> Again floats are 64-bit not 32-bit so I don't see how this can work.
Squeak Floats are 64-bit, but they can be easily converted to 32-bit
floats for a loss in precision.
> If you
> want something that orders things absolutely then something like this, which
> is close to my immediate float representation will work. It effectively
> rotates, putting the sign in the lsb:
> | mostSignificantWord |
> mostSignificantWord := self at: 1.
> ^(mostSignificantWord bitAnd: 16r7FFFFFFF) << 33 + ((self at: 2) << 1)
> + (mostSignificantWord >> 31)
> This doesn't work for +/-0.0 since they have a zero exponent, but that's the
> only exception
It benches to 18% faster than my range-checking but fails the example.
-4.321 eliotHashKey32 < 1.2345 eliotHashKey32 "false" <--- I need true
+/- 0.0 doesn't matter, I only need one 0.0.
More information about the Squeak-dev