[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <so2o9n6n-2955-p5o0-9r79-nr113snsnqp5@syhkavp.arg>
Date: Mon, 8 Jul 2024 08:41:51 -0400 (EDT)
From: Nicolas Pitre <nico@...xnic.net>
To: Uwe Kleine-König <u.kleine-koenig@...libre.com>
cc: Andrew Morton <akpm@...ux-foundation.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 1/2] mul_u64_u64_div_u64: make it precise always
On Mon, 8 Jul 2024, Uwe Kleine-König wrote:
> On Sun, Jul 07, 2024 at 03:05:19PM -0400, Nicolas Pitre wrote:
> > From: Nicolas Pitre <npitre@...libre.com>
> >
> > Library facilities must always return exact results. If the caller may
> > be contented with approximations then it should do the approximation on
> > its own.
> >
> > In this particular case the comment in the code says "the algorithm
> > ... below might lose some precision". Well, if you try it with e.g.:
> >
> > a = 18446462598732840960
> > b = 18446462598732840960
> > c = 18446462598732840961
> >
> > then the produced answer is 0 whereas the exact answer should be
> > 18446462598732840959. This is _some_ precision lost indeed!
> >
> > Let's reimplement this function so it always produces the exact result
> > regardless of its inputs while preserving existing fast paths
> > when possible.
> >
> > Signed-off-by: Nicolas Pitre <npitre@...libre.com>
> > Tested-by: Uwe Kleine-König <u.kleine-koenig@...libre.com>
> > Tested-by: Biju Das <biju.das.jz@...renesas.com>
>
> I would have wished that parts of the conversation about v2 made it into
> code comments. Anyhow, *I* have understood the code, so:
More comments coming soon in a follow-up patch. I still don't know
exactly how to convey
them though. Suggestions welcome from someone! ;-)
Nicolas
Powered by blists - more mailing lists