Alternative bernoulli(const numeric &)

[Richard B. Kreckel]

Hi, Markus!

On Fri, 1 Feb 2002, Markus Nullmeier wrote:
> Now the point I was going to make is simply to update the CLN
> documentation.

Maybe.  I'll try to think up a formulation.

>                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.

No, your interpretation did not fail, at least as long as you refer to the
value of cl_word_alignment.  See below...

>                                                                  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).

Yes, intparam.h is generated by compiling and running intparam.cc while
running configure.

> > 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.

Okay, just for the record: I have never heard of any 64-bit machine which
does not adhere to the LP64-model.  Has anybody else?

>          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...

Well, we should see if anybody really comes up with something thus pervert
and just fix the header <cln/object.h> then...

...by dropping the macro cl_word_alignment into <cln/object.h> as usual.
I am talking about lying, here.  We can simply tell CLN the alignment is
actually 4.  Nothing is spoiled if the system never sets this additional
bit in the malloc'ed address.  They can even make it 12, 16, 20 or 128 if
they think this is a bright idea, as long as the last two bits are not
set.   ;-)

Sounds reasonable?

> > 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.

OTOH, if you compute with int variables you need to be careful in C,
anyways:
  int x = 1000000;
  int y = x*x;
is not a mistake but anybody who expects y to be equal to 1000000000000
then is naive, at best.  This limit just happens to be pushed down from
2^32 to 2^29.

> Anybody still reading? Markus

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