Maxima/ECL combination not printing a leading zero

 On 8/6/10 12:44 PM, Robert Dodier wrote:
> On Fri, Aug 6, 2010 at 3:04 AM, Raymond Toy <toy.raymond at gmail.com> wrote:
>
>>> (format nil "~vf" 17 (/ 1d0 1.39239992382181823812d0))
>>>  => ".7181844690534236"
>> Nice example.  It's not even specific to ecl.  CMUCL and clisp print the
>> same thing.
>>
>> The difference between ecl on Solaris/sparc and Solaris/x86 could very
>> well be the floating-point units or the routines used to compute cl:asinh.
>>
>> (format nil "~vf" 17 (asinh 1d0))
>>
>> produces a leading 0 on Solaris with cmucl, but there's no leading zero
>> on Solaris clisp.  The number value of (asinh 1d0) is slightly different
>> too.
> I suspect the presence or absence of leading 0 is due to
> differing significant digits, not a difference in the printing algorithm.
I don't know the algorithm used in clisp, but I do know CMUCL uses an
algorithm that is guaranteed to produce the correctly rounded result. 
That algorithm, however, has to fit in with what the CLHS says about ~F
and friends.
> I don't really care about the leading 0, but on looking at this
> again I'm inclined to try (again) to make the printed digits
> conform to fpprintprec. (The number of printed digits is approximately
> fpprintprec, but not exactly.)
What are you saying here?  Are we going to print trailing zeroes too for
exactly 0.5?  I think it's much easier to change the documentation to
say fpprintprec is the maximum number of significant digits to print.
:-) Hence we can drop the non-significant leading zero, and we don't
have to print any trailing zeroes.

Ray