Maxima/ECL combination not printing a leading zero

  On 8/6/2010 8:16 AM, Dr. David Kirkby wrote:
>
> It's worth noting however that the failure to print the leading zero 
> is seen on a common CPU (Intel Xeon), albient with a less common 
> operating system (Solaris).
The behavior of Common Lisp and its format function is specified by an 
ANSI standard.
That standard apparently specifies the result without the leading 0,
though if you expand the format field by one , it includes it.

This standard is adhered to by apparently all the correctly compliant 
common lisps.

Which apparently does not include ECL/Sparc.
So it is a bug in ECL/Sparc.  So you can go fix it since it is open source.

If you want to change the behavior of Maxima,  it too is an open source 
system.
>
>
> Small differences are to be expected when computing these things, 
> especially on SPARC processors, so I'm not concerned about the exact 
> value of the last digit - that's pretty irrelevant.
Actually, the point of the IEEE standard is that small differences 
should not appear. You should get the same numbers for the
same calculations.

There are some points of difference that have emerged though, since 
Intel floating point registers have "extended"
64 bit fractions so roundings happen in a different place from registers 
with 53 bits, and (so far as I know) the Sparc
systems have 53 fraction registers. There are also some differences with 
a fused multiply-add, which does one rounding
instead of two.  These are supposed to provide "better" results, which 
is disconcerting when you don't want better, you
want "the same".  So some compilers have options to make these better 
results "the same" while typically also making them slower.

Here's a way to solve this problem and so many other problems regarding 
Sage and Sparc that affect you.

Take your Sparc systems to the recycling depot.

RJF