[Openmcl-devel] Error in rational -> float conversion

[Ron Garret]

Oh never mind, I’m an idiot.

? 4110710000054/100000000000
2055355000027/50000000000
? 4110710000055/100000000000
822142000011/20000000000
? 4110710000056/100000000000
513838750007/12500000000

On Sep 20, 2021, at 9:53 AM, Ron Garret <ron at flownet.com> wrote:

> All this is true, but it does not account for the anomaly.  This appears to be a legitimate bug:
> 
> ? (let ((a 4110710000054) (b 100000000000))
>      (list (float (/ a b)) (float (/ (+ a 1) b)) (float (/ (+ a 2) b))))
> (41.1071 41.107098 41.1071)
> ? (mapcar 'decode-float *)
> (0.64229846 0.6422984 0.64229846)
> 
> It is very data dependent, only manifesting itself for very particular values of A.  I have not yet been able to discern any pattern, but here are a few interesting edge cases:
> 
> ? (let ((a 7110710000054) (b 100000000000))
>      (list (float (/ a b)) (float (/ (+ a 1) b)) (float (/ (+ a 2) b))))
> (71.1071 71.10709 71.1071)
> 
> ? (let ((a 7110720000054) (b 100000000000))
>      (list (float (/ a b)) (float (/ (+ a 1) b)) (float (/ (+ a 2) b))))
> (71.1072 71.1072 71.1072)
> 
> ? (let ((a 4110709000054) (b 100000000000))
>      (list (float (/ a b)) (float (/ (+ a 1) b)) (float (/ (+ a 2) b))))
> (41.10709 41.10709 41.10709)
> 
> AFAICT the bug is in ccl::%short-float-ratio.  I’ll track it down when I have time, but with the above test cases it should not be too hard to figure it out.
> 
> rg
> 
> On Sep 19, 2021, at 10:56 PM, Raymond Wiker <rwiker at gmail.com> wrote:
> 
>> For IEEE-754 single-precision floating-point, the mantissa is held in 23 bits. log10 of 2^23 is about 6.9237, so you should expect less than 7 decimal digits of accuracy. 411071.0 is 7 digits, so anything after that can (and should) be ignored. The difference between 411071.0 and 411071.03 expressed as a float32 is a single bit: the least significant bit of the mantissa.
>> 
>> The reason that coerce gives a slightly worse result is that you compute the value as float32, then convert to float64, and when you print the number, more digits will be printed.
>> 
>> 
>>> On 19 Sep 2021, at 15:05, Steven Nunez <steve_nunez at yahoo.com> wrote:
>>> 
>>> Hi folks,
>>> 
>>> I just posted an issue regarding what looks like a bug in rational->float conversion, and I'm hoping someone here can try this on 1.12 (preferably on MS Windows), or perhaps provide some insight as to what might be going on here for a quick fix.
>>> 
>>> CL-USER> (lisp-implementation-version)
>>> "Version 1.11.8 (v1.11.8-2-gd411e378) WindowsX8664"
>>> CL-USER> (float 41107100000541273/100000000000)
>>> 411071.03
>>> 
>>> Hmm. If you work out the decimal points, the float is: 411071.00000541273, that's a long way from .03. Maybe coerce? Nope, that's even worse:
>>> 
>>> CL-USER> (coerce 41107100000541273/100000000000 'double-float)
>>> 411071.03125D0
>>> 
>>> Any ideas? That's not a small rounding error.
>>> 
>>> Regards,
>>>     Steve
>>> _______________________________________________
>>> Openmcl-devel mailing list
>>> Openmcl-devel at clozure.com
>>> https://lists.clozure.com/mailman/listinfo/openmcl-devel
>> 
>> _______________________________________________
>> Openmcl-devel mailing list
>> Openmcl-devel at clozure.com
>> https://lists.clozure.com/mailman/listinfo/openmcl-devel
> 
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> https://lists.clozure.com/mailman/listinfo/openmcl-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20210920/843c4056/attachment.htm>