Re: 28 bit ought to be enough for anyone.
sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes:
Hrvoje> I still don't understand the problem. Even if it is
true
Hrvoje> that the size of the resulting number is unknown (and I am
Hrvoje> not convinced in this!),
Huh? Subtract two very large numbers from each other.
The maximum storage requirements of the result can be predicted with
good precision. Of course, you cannot know *exactly* how many digits
the result will take (in the case of subtraction, it can always be
smaller than the maximum storage), but that's probably not important.
Is exact allocation what you meant by "efficient" bignum arithmetic
implementation?
Hrvoje> you are still quite free to use realloc() and friends to
Hrvoje> adjust the size incrementally.
Not if the bignum is supposed to live in the Emacs Lisp heap.
If you implement bignums as lcrecords (which is the only meaningful
way of implementing them in the current framework), nothing prevents
you from a "bignum" being a C structure that encapsulates the bignum
structure as seen by the multiprecision library.
--
Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Speak softly and carry a +6 two-handed sword.