[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Making 'eq' == 'eql' in bignum branch
From: |
Andy Moreton |
Subject: |
Re: Making 'eq' == 'eql' in bignum branch |
Date: |
Mon, 20 Aug 2018 22:54:09 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.1.50 (windows-nt) |
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
- Re: Making 'eq' == 'eql' in bignum branch, (continued)
- Re: Making 'eq' == 'eql' in bignum branch, Pip Cet, 2018/08/20
- Re: Making 'eq' == 'eql' in bignum branch, Paul Eggert, 2018/08/20
- Re: Making 'eq' == 'eql' in bignum branch, Pip Cet, 2018/08/20
- Re: Making 'eq' == 'eql' in bignum branch, Paul Eggert, 2018/08/20
- Re: Making 'eq' == 'eql' in bignum branch, Andy Moreton, 2018/08/20
- Re: Making 'eq' == 'eql' in bignum branch, Paul Eggert, 2018/08/20
- Re: Making 'eq' == 'eql' in bignum branch, Andy Moreton, 2018/08/20
- Re: Making 'eq' == 'eql' in bignum branch, Paul Eggert, 2018/08/20
- Re: Making 'eq' == 'eql' in bignum branch, Andy Moreton, 2018/08/20
- Re: Making 'eq' == 'eql' in bignum branch, Pip Cet, 2018/08/20
- Re: Making 'eq' == 'eql' in bignum branch,
Andy Moreton <=
- Re: Making 'eq' == 'eql' in bignum branch, Richard Stallman, 2018/08/20
- Re: Making 'eq' == 'eql' in bignum branch, Eli Zaretskii, 2018/08/20
- Re: Making 'eq' == 'eql' in bignum branch, Paul Eggert, 2018/08/20
- Re: Making 'eq' == 'eql' in bignum branch, Eli Zaretskii, 2018/08/20
- Re: Making 'eq' == 'eql' in bignum branch, Stefan Monnier, 2018/08/20
- Re: Making 'eq' == 'eql' in bignum branch, Eli Zaretskii, 2018/08/20
- Re: Making 'eq' == 'eql' in bignum branch, Robert Pluim, 2018/08/21
- Re: Making 'eq' == 'eql' in bignum branch, Robert Pluim, 2018/08/21
- Re: Making 'eq' == 'eql' in bignum branch, Paul Eggert, 2018/08/21
- Re: Making 'eq' == 'eql' in bignum branch, Lars Ingebrigtsen, 2018/08/22