Alternative bernoulli(const numeric &)
Markus Nullmeier
markus.nullmeier at urz.uni-heidelberg.de
Fri Feb 1 18:44:54 CET 2002
Now the point I was going to make is simply to update the CLN
documentation. As for the debatable optimization I made in the
posted patches, I totally agree to use cl_value_len there.
> > weird (hypothetical?) system with alignment = 8 and sizeof(long) =
> > "32 bits" will break the documented behaviour :-/
well, that would mean cl_value_len = 29 insted of the normal
cl_value_len = 30 for 32 bit architectures and
cl_value_len = 32 for 64 bit architectures,
if my interpretation of CLN's header didn't fail (but such failure is
quite likely anyway...): 4-byte alignment eats 2 bits, 8-byte alignment
eats 3 bits off cl_value_len, at least for 32 bit architectures. And,
the headers get the architecture idea from something like sizeof(long)
in intparam.h: e.g. #define long_bitsize 32 (made by autoconf, I guess).
> Pointer size and alignment==8, but sizeof(long)==4, hmmm, dunno what would
I don't know if (Pointer size) != sizeof(long) will work for CLN's
headers. I was thinking of Pointer size = 4 and alignment = 8. Maybe I'm
a fool and anybody will prove that there were never such systems and
never will be...
> have to be changed... What do you say is gonna break there? (BTW, the
The only thing that would break on these non-existing (?) system is the
"quick conversion" from C++'s int to CLN's cl_I, for values of e. g. 2^28,
contrary to the documentation. Therefore IMHO CLN's documetation
could be updated to speak of 2^(cl_value_len-1) instead of 2^29.
Anybody still reading? Markus
More information about the GiNaC-devel
mailing list