[Ecls-list] [Maxima] Maxima/ECL combination not printing a leading zero
Dr. David Kirkby
david.kirkby at onetel.net
Fri Aug 6 14:56:48 UTC 2010
On 08/ 6/10 06:59 AM, Robert Dodier wrote:
> On 8/5/10, Dr. David Kirkby<david.kirkby at onetel.net> wrote:
>> (%i1) asinh(1.0);
>> (%o1) .8813735870195429
> Appears to be a consequence of the way ECL formats
> floating point numbers. I can produce an example on Linux
> so it's not specific to Solaris. e.g.
> (format nil "~vf" 17 (/ 1d0 1.39239992382181823812d0))
> => ".7181844690534236"
> By default Maxima calls (format nil "~vf" 17 x) where x
> is the number to be formatted. It appears that sometimes
> the leading 0 is omitted in order to squeeze x into 17 characters.
> I think ECL's behavior is reasonable. It seems likely that the
> we could make the 0 reappear by giving at least one more
> character in the field width (circa line 339 in EXPLODEN in
> maxima/src/commac.lisp) ... be that as it may, I'm not
> inclined to do it; the number formatting stuff has been thrashed
> a lot over the years and I'm not convinced this is a change
> of lasting importance. Maybe someone wants to talk me into it.
Well to me at least, it is not normal behaviour for software to print a number
as .8813735870195429, but rather more usual to print it as 0.8813735870195429. I
would personally consider printing .8813735870195429 irrespective if was
Maxima, Mathematica or on a pocket calculator.
Since similar behavior can be produced with CMUCL and clisp on Linux (see
examples Raymond Toy posted) and you concede ECL's behavior is reasonable, I
would have thought changing it in Maxima would have been sensible.
I can't see why this fix would not be of lasting importance.
> A work-around might be to set the Maxima global variable
> maxfpprintprec to something greater than 16 (the default).
> Does that help?
I'm not keen on that. A double-precision number in IEE-754 format has 53-bits in
the significand, so the precision is
In:= Log[10,2^53] //N
In that case, printing 16 digits (Maxima's default) seems reasonable, but
printing 17 digits does not.
Printing a leading zero makes sense to me - printing digits unlikely to be
correct does not.
As a second point, failing to print the leading zero is an inconstancy, as
sometimes it's printed.
> Robert Dodier
Anyway, that's my best attempt to convince you!
More information about the ecl-devel