[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#51276: Problems with format and scaling floats
From: |
Bengt Richter |
Subject: |
bug#51276: Problems with format and scaling floats |
Date: |
Tue, 19 Oct 2021 10:42:49 +0200 |
User-agent: |
Mutt/1.10.1 (2018-07-13) |
Nice catch :)
On +2021-10-18 17:22:49 -0400, Timothy Sample wrote:
> Hi Guilers,
>
> It turns out there’s a little blunder in ‘format’ (from ‘ice-9’). Look
> at what happens when using the SCALE argument to format a fixed-point
> float (this is Guile from the Git repo at the time of writing):
>
> GNU Guile 3.0.7.6-22120
> Copyright (C) 1995-2021 Free Software Foundation, Inc.
>
> Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
> This program is free software, and you are welcome to redistribute it
> under certain conditions; type `,show c' for details.
>
> Enter `,help' for help.
> scheme@(guile-user)> (format #t "~,,3f~%" 0.00123)
> 0.23
> $3 = #t
> scheme@(guile-user)> (format #t "~,,1f~%" 0.00123)
> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> Value out of range 0 to 400: -1
>
> Entering a new prompt. Type `,bt' for a backtrace or `,q' to continue.
>
> The first example gives the wrong result. Scaling 0.00123 by 3 should
> yield 1.23, not 0.23. For the second example, instead of 0.0123, we get
> an error! What’s going on here?
>
> Well, our ‘format’ code comes from SLIB and was written in 1998, so it’s
> not easy to explain. There’s so much mutation even a C programmer would
> blush! ;) The issue happens in the ‘format:parse-float’ procedure
> (which is defined inside of ‘format’). It normalizes the string
> representation of a number, and applies the scale argument when needed.
> It does this by keeping a string of digits and the location of the
> decimal point. Another thing it keeps track of the leading zeros in a
> variable called ‘left-zeros’. Here’s the code that does the final
> shifting and places the decimal point:
>
> (if (> left-zeros 0)
> (if (<= left-zeros shift) ; shift always > 0 here
> (format:fn-shiftleft shift) ; shift out 0s
> (begin
> (format:fn-shiftleft left-zeros)
> (set! format:fn-dot (- shift left-zeros))))
> (set! format:fn-dot (+ format:fn-dot shift)))
>
> The issue is that the cases in the inner ‘if’ form are reversed. That
> is, if there are MORE leading zeros than we need to shift, we can just
> shift. Otherwise (if there are FEWER leading zeros), we need to shift
> out the zeros and then move the decimal point (‘format:fn-dot’).
>
> AFAICS, this bug was in the original SLIB implementation (1998) and has
> not been fixed since then. It’s been in Guile since 1999.
>
> Anyway, that’s more than anyone cares to know.... Here’s a patch with
> tests! :)
>
1999 until now (2021), /and/ reliably reproduced all that time! :)
--
Regards,
Bengt Richter