|
Bill Allombert on Sat, 16 Dec 2023 11:42:30 +0100
|
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
|
Re: libpari precision handling changes
|
- To: pari-dev@pari.math.u-bordeaux.fr
- Subject: Re: libpari precision handling changes
- From: Bill Allombert <Bill.Allombert@math.u-bordeaux.fr>
- Date: Sat, 16 Dec 2023 11:42:14 +0100
- Delivery-date: Sat, 16 Dec 2023 11:42:30 +0100
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=math.u-bordeaux.fr; s=2022; t=1702723335; bh=uHEV2ti4X+BfRbLcOnjvm9CGyJWc0s5E4mByDGjfGSQ=; h=Date:From:To:Subject:References:In-Reply-To:From; b=n8plZY+7IC7ftSTZU2+Kw0PEXpoUVQvq2bTbAKfAmZW8YtZb3GjVc9zlr00lQPTpX O9lWJtQ7RAzLGETxrPTGvAMOkiPbqefRmI+UNCLqpyRik0tUpdHbTJiD4j3rHqBfNe FCye2fzaT/SzWqHRU1cducBi3J/uTQFhAAUCd2+NzH6WjQ22OZz9hx8UJs6wCGHGY5 gqPbMIZv9VAdOzEExqhRiffSfXSLHGWVMIJJAw5PcCvzJ1q7G+blmsNGZG4FE4O9SN VQ5jvr+2tNOTLcm4GCIYiErw1TzVTHytlF+Ikr864w70DVnNfM3g96n26AkYiRc1jv BpBh4jmON+I65rGqMfWbjA2Ca3wQC2RTfprr/ZpFCLgkUrYI8d8srrz9GZ0x7cCpwT DJ+yUUvLjD88iIsf0Fxlhht4dpPSm8l6x0YjU3ZsXC1DLIcGIN21kPjAq20T8cQEIG kvoUGZRTGnpsVpNY1DPiYiPRKIPY/2txGfs8caiNMQNGwZhT9b8k2hu5jVcMW77eqz mkjRDtEUM3u4UQAgJo8Z7K490jqBlqQFwz1yZ5ikxFrWeTAKRbX7GLHpNW8bf2ejp5 D371arIRca8kitINlugX12i7u9eRqkbntRofnHVOXRTmKq2kT0b3kazJnEuMVhI8yH 7kmAtJPpe5cu2MzIGAncFEKA=
- In-reply-to: <ZX0APnZEEHzv3Nse@login.math.berkeley.edu>
- Mail-followup-to: pari-dev@pari.math.u-bordeaux.fr
- References: <ZWzqp8+Qz9wvZ2jU@seventeen> <ZXuwiTdvUFVzsaAy@login.math.berkeley.edu> <ZXzWdHrFDrlH6mP2@seventeen> <ZX0APnZEEHzv3Nse@login.math.berkeley.edu>
On Fri, Dec 15, 2023 at 05:41:18PM -0800, Ilya Zakharevich wrote:
> On Fri, Dec 15, 2023 at 11:43:00PM +0100, Bill Allombert wrote:
> > > > I committed a change to the way the precision is manipulated in the
> > > > C library.
> > > >
> > > > Now the precision is a multiple of BITS_IN_LONG.
> > >
> > > This is a major backwards-incompatible change. Should not it better
> > > be handled by introducing new names for macros and functions?
>
> > It has been documented since 2013 than one should not assume that
> > realprec==lg.
>
> > Anyway, I am available to fix any code that is affected.
> > It is just a matter of using realprec, prec2nbits and nbits2prec properly.
>
> It seems that I was not clear enough. THE reason for changing the
> names of macros and functions is not to make it easier to “fix any
> code that is affected”.
The change does not change the documented API, so no properly written code
should be affected. Changing the macro and function names would force everybody
to rewrite the code to use the new names.
The new stable releases 2.17 will have a new ABI anyway.
Cheers,
Bill