|
Bill Allombert on Fri, 15 Dec 2023 23:43: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: Fri, 15 Dec 2023 23:43:00 +0100
- Delivery-date: Fri, 15 Dec 2023 23:43:30 +0100
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=math.u-bordeaux.fr; s=2022; t=1702680182; bh=2iOqyJoUC3bYI/mtAaNXF1r2SsV4qM3lDqBv5aj/g0s=; h=Date:From:To:Subject:References:In-Reply-To:From; b=mct/A7SeuL3+EZhHl40wAC2kEsTFgpOssGIE1VxM7kwOqc2f+PgQPdzY/Voj7ZPhs CsR5NNxrgkjsGL1zpwNbOhV7AQpQrFRQNnU8jSrAH8yD2fZQ9c1XbF4GLUOBbdKEIK 6aHM0wGgDnABan2qy22GRz6U/68oDGao9VUKrrfWIcJ1/2lAgVdBI1dqfDmQJHUi/F Pm/+AN0MmnKoGzrmueA8wy5Q8Stlsw+gVNVYSR+fjwG/gAOo365UCMGm4Wsb8aB01k pAK0R1+pj0+Y3jHD3L0qWuTOLQtSkOInyHun2Lw9/Tb9J+H3UMHg89zWME1qdB6eEA UvlJ4kJ4A0gfEUMTlT8jhAMyJ/OOCiDw5srvwgBks2mLIkwHT15qdcN/QngKeDWuVq mJOgpBZqrBm6KB7C+VtvAggz2+xrABkzZvGjUJiP4ScRRRCYcxI2gohIzq7RvjTi1K MCPf4PNmScFItwG3TGYRz8fCbqvrtZWylkzOMnd5NBdVtTKRHbjYXAS3v4dE2BWo8T aspWqICF40yrL0ImAr5+Gn72y/wupTF6Fx4hermy20vqbKJphghubSChDG0enDlP5g MPeczeK42YUi71Qswc17sZcsw05sVusolaKsd8jqKB9mb3YQPdo6tdhyvKMlyaRwYR 57oPxW8hzTKAGZhDjYOtdnLA=
- In-reply-to: <ZXuwiTdvUFVzsaAy@login.math.berkeley.edu>
- Mail-followup-to: pari-dev@pari.math.u-bordeaux.fr
- References: <ZWzqp8+Qz9wvZ2jU@seventeen> <ZXuwiTdvUFVzsaAy@login.math.berkeley.edu>
On Thu, Dec 14, 2023 at 05:48:57PM -0800, Ilya Zakharevich wrote:
> On Sun, Dec 03, 2023 at 09:52:55PM +0100, Bill Allombert wrote:
> > Dear PARI developers,
> >
> > 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.
Cheers,
Bill