Fun with Number readFrom: What should we do ?

Andreas Raab andreas.raab at gmx.de
Mon May 1 19:31:55 UTC 2006


Hi Nicolas,

The first step is to publish what you have in any place you have access 
to (or even via email) so we can test these changes and see if they work 
as advertised ;-) I'm looking forward to throw a few of my test cases at 
the parser and see if they come out correctly.

Cheers,
   - Andreas

nicolas cellier wrote:
> Le Vendredi 28 Avril 2006 20:08, nicolas cellier a écrit :
>> However i still have the bellerophon algorithm (from tony's reference)
>> failing with last bit incorrect in a few cases (i can check that with
>> asTrueFraction for number greater than 1.0 timestwoPower: 53). So i do not
>> release it yet.
>>
>> Nicolas
> 
> Subjects developped in this (too) long email are:
>  - A) Float readFrom: now round exactly :)
>  - B) my solution use a new ArbitraryPrecisionFloat class :(
>  - C) this class can solve other asFloat problems :)
>  - D) shouldn't the readFrom: fix better be moved to asFloat fix ?
> 
> A)----------------------------------------------------------------------------
> 
> OK, now i have the Float reading working, also for gradual underflow !
> 
> This of course solve Andreas' Numerics question: reading floating point 
> constants,
> i now have
> (SqNumberParser on: '6.07710050630396597660e-11') nextNumber hex = 
> '3DD0B4611A600000'.
> 
> B)----------------------------------------------------------------------------
> 
> The solution is not as light as i wanted, because i finally added an 
> ArbitraryPrecisionFloat class to handle 64bits arithmetic involved in 
> Bellerophon.
> So i do not know if i should publish my solution at 
> http://bugs.impara.de/view.php?id=3512, or rather in SM.
> Unfortunately my SM account is blocked inactive...
> 
> It's funny how easy creating a new Number class was.
> Of course, ArbitraryPrecisionFloat lacks a short literal form syntax, it does 
> not implement usual mathematical functions (default is to convert to Float).
> And it's not optimized at all (please don't compare to hardwired Float 
> arithmetic...).
> But it's more general than just reading Float. This is why i wanted to publish 
> on SM.
> 
> C)----------------------------------------------------------------------------
> 
> This can potentially solve other asFloat incorrect rounding behaviour:
> 
> C.1) current implementation of LargeInteger>>asFloat.
> will not round to nearest even Float when highBit > 53.
> 
> example:
>  16r1FFFFFFFFFFFF081 asFloat hex
> 
> The ArbitraryPrecisionFloat implements IEEE rounding mode, so it can cure this 
> one easily.
> 
> C.2) it is more difficult with Fraction>>asFloat
> which does neither round to nearest even Float...
> 
> Bellerophon and ArbitraryPrecisionFloat together can fix the Fraction problem 
> (conversion from decimal to binary representation is just a special case of 
> these Large fractions).
> 
> I now know why i never succedeed in implementing my own Smalltalk Float 
> reading in VW, despite of Integer infinite precision... I was over-trusting 
> asFloat implementation that suffer the same problem...
> 
> D)----------------------------------------------------------------------------
> 
> So, maybe we should better move the fixes i wrote from Number>>readFrom: to 
> LargeInteger and Fraction>>asFloat,
> Then exactly rounded Float>>readFrom: will be a side effect...
> 
> Nicolas
> 
> 
> 
> 




More information about the Squeak-dev mailing list