Alternative bernoulli(const numeric &)

Richard B. Kreckel kreckel at thep.physik.uni-mainz.de
Wed Jan 23 11:56:13 CET 2002


On Tue, 22 Jan 2002, Markus Nullmeier wrote:
> > I suspect the condition should really be `(p < (1UL<<cl_value_len/2))', in
> > order to be portable across platforms...
> > 
> 
> Well, I just followed the documentation which made me believe that
> int -> cl_I conversion should work at least up to values of 2^29-1.

Hmm, from CLN's docu:

: Small integers (typically in the range `-2^29'...`2^29-1', for 32-bit
: machines) are especially efficient, because they consume no heap
: allocation. Otherwise the distinction between these immediate integers
: (called "fixnums") and heap allocated integers (called "bignums") is
: completely transparent.

> So maybe cl_value_len should be documented, as it indeed makes one
> feel somewhat more secure. Now reading the headers it looks like a
> weird (hypothetical?) system with alignment = 8 and sizeof(long) =
> "32 bits" will break the documented behaviour :-/

???  On any machine where an address is 64 Bit (Alpha, ia64,...) and
matching alignment we store a full 32-Bit word and tag it as not being an
address (as immediate).  That gives the range `-2^31'...`2^31-1'.  
Pointer size and alignment==8, but sizeof(long)==4, hmmm, dunno what would
have to be changed...  What do you say is gonna break there?  (BTW, the
`-2^29'...`2^29-1' range should even hold for m68k, where alignment==2.  
There we just have one tag bit less.)

>                                                   Anyhow, I'm just
> too lazy to incorporate this version of p^2/2 < 2^(cl_value_len-1)
> into my sources and waiting for the next release...

I have already put it into CVS with the (p<(1UL<<cl_value_len/2))
condition.  It looks correct, at least to me.  And it's fast.  Thanks!

Regards
    -richy.
-- 
Richard B. Kreckel
<Richard.Kreckel at Uni-Mainz.DE>
<http://wwwthep.physik.uni-mainz.de/~kreckel/>



More information about the GiNaC-devel mailing list