axiom-developer
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Axiom-developer] i-output and decimal width


From: Stephen Wilson
Subject: Re: [Axiom-developer] i-output and decimal width
Date: 06 Aug 2007 18:25:55 -0400
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4

Hi Waldek,

Waldek Hebisch <address@hidden> writes:

> Stephen Wilson wrote:
> > Stephen Wilson <address@hidden> writes:
> > > Could I suggest the following to replace these two cases:
> > > 
> > >     (+ 1 |negative| (round (log n 10)))
> > 
> > 
> > This should _not_ be used to replace both cases, but only the first.
> > I believe the second case might be OK unless the `over estimation'
> > is not enough account for the width in the negative case.
> > 
> > However, these messages are now adrift a bit premature, so perhaps
> > someone may know of a better solution?
> > 
> 
> I looked at this code and I belive that I have written a better
> version (commited to wh-sandbox).  Some remarks:
> 
> - Ansi says that for exact arguments results are either exact or
>   single precision.  I feel that single precision give us no
>   help so I use double precision arguments (as type gcl does not
>   distingiush between single and double, but it stil gave only
>   single precision result).
> - for moderate lengths if numerical result is suspect I use
>   extra verification.
> - for large arguments I use over-estimate. 

I think a log10 function like the one you implemented would certainly
be useful.  A few questions:

  - Has the code been tested on various lisps?  I see the following
    under gcl-2.7.0 for example:

       (|axiom_log_10| 10) ==> 0

  - Would you be willing to submit a patch with pamphlet
    documentation?

We could use your log10 function to optimize the base 10 case.  I
would also like to look into using mpz_sizeinbase as a more general
solution. Currently, exact calculation becomes slow when there are
more than 100000 decimal digits -- this is a fairly practical range
for the pretty printing of expressions, so there is not urgent need to
optimize IMHO.


Take care,
Steve





reply via email to

[Prev in Thread] Current Thread [Next in Thread]