Re: Bignum speedup patch causes crash at startup

[Paul Eggert]

Eli Zaretskii wrote:
> > First, converting a fixnum to a double can lose info.
> Whether that is a possibility could be established by a simple
> magnitude test.

Yes, that could be done, though a simple test like that would not be perfect as 
it would mistakenly reject some valid integers. It would still suffer from 
double-rounding, though.

> > Second, the double
> > division could round, which would mean the result would be double-rounded. We're
> > already suffering from double-rounding when either argument is floating-point,
> > and we don't want that bug to also infect integer division.
> I don't understand what bug you are alluding to.  Can you elaborate?

Double rounding occurs when you are attempting to compute (say) the floor of 
A/B, and do that by first computing A/B as a double (which rounds to the nearest 
double), and then taking the floor of the result. The rounding can cause you to 
lose information, and when you take the floor of the rounded result you get the 
wrong answer. For example, on a 64-bit Emacs, (floor (1+ most-negative-fixnum) 
(1- most-positive-fixnum)) should yield -2 because the the numerator is negative 
and has absolute value slightly greater than that of the positive denominator, 
but with the method you're suggesting the expression would yield -1 (assuming 
IEEE double) because double-precision floating-point division rounds the 
mathematically exact quotient to -1.0.

> don't you agree that calling libgmp, when the second
> argument is 1 and the 1st is a fixnum, is a little bit ridiculous?

Although I wouldn't go that far, we can improve the runtime performance in the 
special case of fixnum / fixnum, at the cost of some complexity in the code and 
very minor slowdown elsewhere. I installed the attached to do that.

0001-Improve-round-FIXNUM-FIXNUM-performance.patch
Description: Text Data