bug-gmp
[Top][All Lists]
Advanced

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

Re: Suggestion For mpz_sizeinbase() Function


From: Kevin Ryde
Subject: Re: Suggestion For mpz_sizeinbase() Function
Date: 17 Jul 2001 09:16:50 +1000
User-agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.5

"David T. Ashley" <address@hidden> writes:
> 
> I do not know how quick floating-point instructions are on most machines, or
> if they typically have hardware support.  I know that the 80x87 (the
> floating-point chip) exists, but I don't know how fast this is.

Builtin on 486dx and up, latest chips like athlon are quite good.

> Most of my
> experience is with microcontrollers, which do not have hardware support for
> floating point (and of course doing it in software is somewhat expensive).
> 
> With this in mind, looking at the mpz_sizeinbase() function, it seems that
> floating point arithmetic isn't necessary.

Yep.

> I'm assuming that the entries in the table __mp_bases[] are of the form:
>    ln(2)/ln(base)

Yep.

> chars_required = (12655 * bits_required)/42039 + 1
> 
> Most machines will do this blindingly fast:  one integer multiply as a
> processor instruction followed by one integer divide as a processor
> instruction.

A fixed point binary approximation might be better, so it could be one
mul and a shift, if that gave enough precision.

> The other issue to cover is in general if this method is used, whether the
> claim that the value returned will be exact or one greater will be met.

That chars_per_bit_exactly is used in a few different places, it'd be
good to convert all of them.  I'm not sure if a rounded-up or
rounded-down value would best suit.

> So, what does everyone think of using rational approximations instead of
> floating-point arithmetic?  Do most machines provide floating point support,
> and is there any speed or code savings here?

On the x86s (other than athlon) there's a penalty for switching
between MMX and float code, so avoiding unnecessary float is a good
thing.  On some of the RISCs, on the other hand, float can be faster
than integer, though it doesn't always give enough precision (see the
tasks entry about mpf exponents >2^53).

But speed in this radix conversion stuff isn't all that important,
since no sensible program should be dominated by such things.
Correctness is very important though, and getting away from the
vagueries of floating point rounding modes would be good from that
point of view.



reply via email to

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