Bignums and stuff (was: [21.5] Tweak etc/NEWS)

[Stephen J. Turnbull]

>>>>> "Hrvoje" == Hrvoje Niksic <hniksic at xemacs.org> writes:

    Hrvoje> "Stephen J. Turnbull" <stephen at xemacs.org> writes:

    Hrvoje> 2. If bignums are to become required in the above sense,
    Hrvoje> we should ship a simple bignum implementation with XEmacs,

    >> What does that mean?

    Hrvoje> It means having bignum code that doesn't rely on an
    Hrvoje> external library.  Again, think Python.

First, think "replace the Lisp engine".  The current one can't run
footraces with a snake.  :-(

    >> Is +, -, *, /, mod, everything else coerces to float good
    >> enough?

    Hrvoje> Coercing to float is not the same as having bignums.

Then Python doesn't have bignums, or in general doesn't do integer
arithmetic CLTL2-correctly.  10**-2 => 0.01, there's no built-in sqrt
function, the math library returns 5.0 for sqrt(25), etc.

I don't have a problem with this, it just makes me unclear on what you
mean by comparing to Python.  AFAICS Python provides the 4 basic
arithmetic operations (counting mod as part of division, and
non-negative integral exponentiation as multiplication) on integers,
including bignums, and everything else is done by coerce-to-float.
No?

Basic multiple precision integer arithmetic in C is fairly easy:
loopy-loopy-loop and you're done; should be fast enough for anybody
not using bignums often enough to be willing to deal with the library.
The hard parts Jerry has already done: when do you coerce from fixnum
representation to bignum representation?  Am I missing something?

That is, you're welcome to veto a release without benchmarks and a
built-in simple implementation, I'll be lined up right behind to
second it.  But it's quite clear what we need to do, isn't it?
(That's a real question; I think you agree, but I'm not sure.)  Does
committing to CVS still worry you?  (Again, a real question.)

    >> If so, doesn't calc already provide that much, at least?

    Hrvoje> calc's bignum implementation is way too slow, and it
    Hrvoje> doesn't affect builtins such as `+' and `*'.  Also, calc
    Hrvoje> is not (necessarily) shipped with XEmacs either.

OK, we'll do it in C.

    Hrvoje> Maybe you're right, maybe checking for overflow will get
    Hrvoje> lost in the proverbial forest of other checks.  I'd still
    Hrvoje> be happier if that were proven with benchmarks.

Me too, before the release of 22.0 if we plan to default it on, which
I'm sure you would support if no known bugs and reasonable
performance.  But for committing Jerry's work as experimental, it's
not necessary IMO.

    Hrvoje> For the purposes of gaining the one extra bit, it might be
    Hrvoje> best to introduce this:

    static EMACS_INT some_variable;  /* intentionally not Fixnum */
    DEFVAR_FULLINT ("some-variable", &some_variable /*
    This variable can hold all 32-bit (or 64-bit) values.
    */ );
    some_variable = 0;

Yuck.  The compiler won't catch mistakes in a non-union build, and
it's just generally confusing, for one bit?  It shouldn't be _that_
much harder to implement multiple-precision array indicies; add,
subtract, multiply.  Only division is "hard" and that we can limit to
"by size_t", right?

But I appreciate you laying out the possibilities, it's very
educational.

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.