This page is part of the web mail archives of SRFI 54 from before July 7th, 2015. The new archives for SRFI 54 contain all messages, not just those from before July 7th, 2015.
On Thu, 25 Mar 2004, soo wrote: >R5RS says: If the written representation of a number has no exactness prefix, >the constant may be either inexact or exact. It is inexact if it contains a >decimal point, an exponent, or a "#" character in the place of a digit, >otherwise it is exact. This is true, but a number such as #e1.234 is still an exact number. It could also have been written 1234/10000. In general, if you rely on implementations to do the "Right thing" with exact vs. inexact numbers, you will be disappointed or wind up with a nonportable library. Some of them throw syntax errors on exactness prefixes, some ignore exactness prefixes, some disallow decimal points in exact numbers, some silently coerce to inexact even after reading an exactness prefix if they encounter a decimal, etc. The behavior described in R5RS is fully implemented, alas, only by a very few. > > (fmt 1/2 5 0) > | " 1." ; Huh? > > > (fmt -1 10 0) > | " -1." ; Is this on purpose? > >Yes, it expresses that -1. is inexact number. The problem here is that in both cases you should have an exact number. You were given exact parameters, you had no need for inexact computations. Why aren't the results exact? What display ought to give you here would be simply "1" and "-1". >(fmt 1/2 5 2 #\space (fmt 10)) " 0.5010" >(fmt 1/2 5 2) " 0.50" >The default value of padding character is #\space. In these cases people have given you exact numbers and asked for decimal format. The correct responses would be exact prefixes followed by a decimal fractions, but I don't think the write procedure of any known scheme will produce them. I'd need to pass my own write procedure into FMT in order to get them, and FMT as specified doesn't allow it. Bear