Re: account on an ARM server (and the usual floating point troubles)

[Dima Pasechnik]

On 31 January 2014 16:55, Dima Pasechnik <dim...@gmail.com> wrote:
> On 31 January 2014 15:54, Volker Braun <vbrau...@gmail.com> wrote:

>> If the tests don't pass then its not really useful. I certainly don't
>> want to manually comb through the log to see whether its an
>> already-known failure...

a new twist seems to be that Maxima outputs different number of digits on ARM
and on x86_64, this being the cause at least two test failures.
Although I don't know whether this is due to extra space between the prompt
and the output inserted by Maxima on ARM:
(%i1) elliptic_e(0.5, 0.1);
(%o1) .4980113944988315
as compared to x86_64:
(%i1) elliptic_e(0.5, 0.1);
(%o1) .49801139449883153


Dima

PS : we're getting an ARM buildbot, finally, it seems...
Write to me if you want an account on the corresponding ARM machine.

[Volker Braun]

if its just a matter of the last digit then I'd be satisfied with just

adding a # rel tol 1e-16 or so to the doctest...

[Dima Pasechnik]

On 2014-01-31, Dima Pasechnik <dim...@gmail.com> wrote:
> On 31 January 2014 16:55, Dima Pasechnik <dim...@gmail.com> wrote:
>> On 31 January 2014 15:54, Volker Braun <vbrau...@gmail.com> wrote:
>
>>> If the tests don't pass then its not really useful. I certainly don't
>>> want to manually comb through the log to see whether its an
>>> already-known failure...
>
> a new twist seems to be that Maxima outputs different number of digits on ARM
> and on x86_64, this being the cause at least two test failures.
> Although I don't know whether this is due to extra space between the prompt
> and the output inserted by Maxima on ARM:
> (%i1) elliptic_e(0.5, 0.1);
> (%o1) .4980113944988315
> as compared to x86_64:
> (%i1) elliptic_e(0.5, 0.1);
> (%o1) .49801139449883153
>

in fact, the x86_64 output has 17 digits, whereas Maxima manual
seems to say that there should be 16 digits:
http://maxima.sourceforge.net/docs/manual/en/backup/maxima_10.html#Item_003a-fpprintprec

For ordinary floating point numbers, when fpprintprec has a value
between 2 and 16 (inclusive), the number of digits printed is equal to
fpprintprec. Otherwise, fpprintprec is 0, or greater than 16, and the
number of digits printed is 16.

setting fpprintprec to 16 still produces 17 digits;
setting it to 15 produces 16 digits.

On ARM setting fpprintprec to 16 or 15 produces 16 digits,
and setting it to 14 produces 15 digits...

Strange...
Dima

[Dima Pasechnik]

On 2014-01-31, Volker Braun <vbrau...@gmail.com> wrote:
> if its just a matter of the last digit then I'd be satisfied with just
> adding a # rel tol 1e-16 or so to the doctest...

this is trickier, if I interpret the events right:
the numbers spit out by Maxima get rounded by Sage,
and .49801139449883153 is rounded as .498011394498832, whereas
.4980113944988315 is rounded as .498011394498831

sage: .4980113944988315
0.498011394498831
sage: .49801139449883153
0.498011394498832


So you need to increase tolerance more, and one would naturally object
that this is defeating the purpose of doctests...

[cl...@jhcloos.com]

Dima Pasechnik <dim...@gmail.com> writes:

> and the output inserted by Maxima on ARM:
> (%i1) elliptic_e(0.5, 0.1);
> (%o1) .4980113944988315
> as compared to x86_64:
> (%i1) elliptic_e(0.5, 0.1);
> (%o1) .49801139449883153

FWIW, maxima compiled with sbcl on amd64 agrees with the arm output
above. Ie, exactly 16 digits.

Perhaps the issue is with ecls?

-JimC
--
James Cloos <cl...@jhcloos.com> OpenPGP: 1024D/ED7DAEA6

[Dima Pasechnik]

On 2014-02-01, cl...@jhcloos.com <cl...@jhcloos.com> wrote:
> Dima Pasechnik <dim...@gmail.com> writes:
>
>> and the output inserted by Maxima on ARM:
>> (%i1) elliptic_e(0.5, 0.1);
>> (%o1) .4980113944988315
>> as compared to x86_64:
>> (%i1) elliptic_e(0.5, 0.1);
>> (%o1) .49801139449883153
>
> FWIW, maxima compiled with sbcl on amd64 agrees with the arm output
> above. Ie, exactly 16 digits.
>
> Perhaps the issue is with ecls?

I tried the latest maxima built with GCL on ARM, and the output is
again different:
0.49801139449883

I asked on the maxima mailing list if they have an idea why this is
so wildly different accross platforms and compilers...

Dima

[Robert Dodier]

Yeah. That's a bug in Maxima, caused by a misunderstanding (mine) of the
Common Lisp function FORMAT. I'm trying to fix that at the moment, to
make the behavior of fpprintprec match its description. I think I
understand how to accomplish that now. Wish me luck.

best

Robert Dodier

[Robert Dodier]

On 2014-02-01, Dima Pasechnik <dim...@gmail.com> wrote:

> I asked on the maxima mailing list if they have an idea why this is
> so wildly different accross platforms and compilers...

It's a combination of implementation-specific behavior (probably stuff
not specified by the Common Lisp spec & therefore not an implementation
bug) and misunderstanding of the spec. I'm trying to regularize the
behavior of fpprintprec now.

FYI the Maxima mailing list is down at the moment. Stay tuned, and
sorry for the bother.

best

Robert Dodier