The bug reproduces in Gauche as well. I think the fix is along this line:

============

*** format.orig.scm Thu Oct 12 10:37:42 2017

--- format.scm Thu Oct 12 10:38:23 2017

***************

*** 80,86 ****

(string-append "0." frac-str)))

0)))

(new-frac

! (substring temp-str 0 digits))

)

(string-append

(if carry? (number->string (+ 1 (string->number pre-str))) pre-str)

--- 80,88 ----

(string-append "0." frac-str)))

0)))

(new-frac

! (if (> dot-pos digits)

! (substring temp-str (- dot-pos digits) dot-pos)

! (substring temp-str 0 digits)))

)

(string-append

(if carry? (number->string (+ 1 (string->number pre-str))) pre-str)

============

On Thu, Oct 12, 2017 at 9:42 AM, Donald Allen <xxxxxx@gmail.com> wrote:

On 12 October 2017 at 15:07, Arthur A. Gleckler <xxxxxx@speechcode.com> wrote:
On Thu, Oct 12, 2017 at 6:04 AM, Donald Allen <xxxxxx@gmail.com> wrote:

Thanks for the quick response. From your description of the patch, it
sounds like you addressed the error that occurs using Gambit. But did
you also have a look at the odd rounding behavior I reported in my
first message?

earlier:

3> (/ (round (* 1.997554209949891 100)) 100)
2.

I get the same result with MIT Scheme. I must be missing something. Why do you consider it wrong? According to R7RS (and probably earlier versions of the standard),"round returns the closest integer to x, rounding to even when x is halfway between two integers."

Sorry, I wasn't clear. I was talking about this:

2> (format "~a & ~7,2F\\%\\\\\n" "Framingham Mass Muni Purpose Loan" 1.997554209949891)
"Framingham Mass Muni Purpose Loan & 2.10\\%\\\\\n"

Why does a ~7,2 formatting of something just under 2 result in 2.1? When, as you say,

3> (/ (round (* 1.997554209949891 100)) 100)
2.