On Tue, Dec 28, 2010 at 12:47:05PM -0500, Raymond Toy wrote:
> On 12/28/10 10:42 AM, Oliver Kullmann wrote:
> > On the other hand, the difference of
> >
> > 4.830986538632788-4.83098653863282 ~ -3.197442310920451e-14
> >
> > is gigantic (so well, at least to me ;-)) ?
> Yes, that is a bit larger than we want. One solution would be to ask
> your lisp vendor to have it signal an error on log(<really big
> integer>). Then the loss of accuracy only happens when there is a big
> integer.
>
> But I can also change the code to do an explicit check for the range
> when using gcl and ecl. That might be ok.
> >
> > Aha, thus it got slower. So well, it seems we need to lower our
> > expectations for some time ...
> Not according to your results. 5.22 was 10 sec faster when running
> testf1 than 5.21.
>
sorry, I meant "expectations" w.r.t. the allowed floating-point error in
our tests (and "for some time" relating to the hope that after a certain
low accurracy-tide we will get a high accurrary-tide in the Maxima life-cycle).
> But if you look at $float, there is a huge amount of processing before
> we get to part that computes the actual log. I suspect there isn't
> much extra caused by the extra computations.
>
yes, looks like that. (We have problems with Maxima running-times, but they
relate to different computations, typical list-set processing at large scale.
But (in principle) that's okay for us, since we use Maxima as the "set-theoretical level"
of our library/platform, where we get the basic definitions and algorithms right,
and then go for the full implementations to the "C++ level".)
Oliver