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