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

[Andy Moreton]

On Mon 20 Aug 2018, Pip Cet wrote:

> On Mon, Aug 20, 2018 at 4:43 PM Andy Moreton <address@hidden> 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.

Agreed, Apologies for misunderstanding your original message.

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

A good point.

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

Perhaps these implementation details should also be added to bug reports ?

    AndyM