On 08/ 6/10 06:59 AM, Robert Dodier wrote:
On 8/5/10, Dr. David Kirkby<david.kir...@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[23]:= Log[10,2^53] //N

Out[23]= 15.9546

decimal digits.

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.

FWIW

Robert Dodier


Anyway, that's my best attempt to convince you!


Dave

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Reply via email to