Re: Making 'eq' == 'eql' in bignum branch

[Pip Cet <pipcet@gmail.com>]

On Mon, Aug 20, 2018 at 4:43 PM Andy Moreton <andrewjmoreton@gmail.com> wrote:
> On Mon 20 Aug 2018, Paul Eggert wrote:
>
> > Andy Moreton wrote:
> >
> >> There will always be a performance diffrence between fixnum and bignum
> >> values, and it may be useful for performance tuning to have a simple way
> >> to discover where that boundary lies.
> >
> > Performance nerds can use 'most-positive-fixnum' and 'most-negative-fixnum'
> > for that sort of thing. These constants have been there for some time and are
> > not going away. My objection is to 'bignump' and 'fixnump', which are no more
> > necessary as primitives than 'negativep' would be.
>
> Pip Cet was advocating removal of most-positive-fixnum, and that is what
> I was objecting to as being too severe. We do not need negativep as we
> already have other prmitives for testing that property.

I'm sorry for the sloppy wording. `most-positive-fixnum' should stay:
it's an important implementation detail. All the references to it in
lisp/, though, look to me like they should be removed.

The references in test/ should stay, for example, and I think a good
case can be made that the fixnum range should be included in Emacs bug
reports, which would be a legitimate use in the lisp/ directory.

> >> These are used in the tests to ensure that implementation is correct,
> >> and that values in fixnum range are always represented as fixnums, not
> >> bignums. How do you propose to test that without these predicates ?
> >
> > Tests can use 'most-positive-fixnum' and 'most-negative-fixnum', constants
> > that tests need to use anyway in order to generate values like (1+
> > most-positive-fixnum). So they can survive quite well without 'bignump' and
> > 'fixnump' as primitives.
>
> You have avoided the question.
>
> The current codebase assumes that lisp bignum objects only exist for
> values outside fixnum range. Without fixnump how can tests check that
> values within fixnum range actually have a fixnum representation ? How
> can test check that no bignum object is created for a fixnum value ?

I think keeping a Lisp function around for the sole purpose of testing
C code from Lisp is wrong. The right thing to do in this case is to
test the C code from C; I believe GCC does so extensively, and it
would be easy enough to add a test function that eassert()s that
FIXNUMP(Fsub1(Fadd1(MOST_POSITIVE_FIXNUM))), for example.

Again, I think important implementation details, like what a good
range for fast integer arithmetic is ([most-negative-fixnum,
most-positive-fixnum]) and how floats are encoded and whether IEEE
rules are being followed (IEEE_FLOATING_POINT), should be exposed to
Lisp. (For example, I'm playing around with big rational numbers, and
one possible implementation is for them to replace floats, but that
almost naturally requires a ratio-to-nearby-simple-ratio function to
avoid building up huge representations; whether to use such a function
and what it does would be an implementation detail, but one that code
might want to optimize for...)

Does bignump serve a purpose other than testing C code? My impression
is that it doesn't in the current implementation, and the symbol
should be left unbound, but considered reserved. While there is
hypothetical code that wants to know whether a number is currently
encoded as a bignum (I'm thinking of benchmarking code that's run in a
future Emacs with contrarily bignum-encoded fixnum-range integers), I
think it's exotic enough that it can just test (if (fboundp 'fixnump)
(fixnump x) (<= most-negative-fixnum x most-positive-fixnum)). Leaving
bignump in will lead to people thinking it's synonymous to "is this
number outside the fixnum range", and such code will then break if
it's suddenly possible for (bignump 0) to be false.

Perhaps a good analogy is that (bignump x) is on a level with "what C
address is x stored at": it's a question only very curious Lisp
programs would ask, and the answer is subject to change and dangerous
to rely on.