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