Re: Incorrect rounding of double values at max precision

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Incorrect rounding of double values at max precision
Дата
Msg-id 698043.1603248090@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Incorrect rounding of double values at max precision  (Andres Freund <andres@anarazel.de>)
Список pgsql-bugs
Andres Freund <andres@anarazel.de> writes:
> On 2020-10-20 21:48:52 -0400, Tom Lane wrote:
>> Meh.  Yeah, we could improve the observed results for float4 values
>> that are integers between 1M and 16M, and some similarly-sized band
>> for float8; but to what end?

> I'm not actually arguing that we should improve it by relying on range
> based heuristics. Just that throwing away precision that can't just
> argued to have been conjured by float representation issues is an
> indicator of our current approach to be quite wrong.

I think your argument is founded on the unprovable assumption that
the original input value was an integer.  If we see 12345678::float4,
the "true" value could have been anything between 12345677.5 and
12345678.5.  Printing it as an exact integer isn't going to seem
too exact to a person who knows they put in a fraction.

Or for a person who does know a little bit about float arithmetic, they
might reasonably wonder why 12345.678::float4 is "exactly" converted to
numeric but 1234.5678::float4, with the same number of digits, is not.
(Ryu renders the latter as 1234.5677.)

>> The most likely practical result is just to postpone the user's
>> discovery that they're Doing It Wrong.

> I don't buy this, not even for a second. Why is FLT_DIG = 6 the right
> way to hint at that? Why not a precision of 5, 4, 3? Sure 6 digits is
> guaranteed to roundtrip the same way, but that's an *extremely* coarse
> filter.

It's also the *highest* precision that is guaranteed to round-trip,
which 5,4,3 are not, so that argument is unconvincing too.

> And if we like exposing people to floating point imprecision, why is
> select (502.15::float8 / 10)::numeric resulting in 50.214999999999996
> bad?

The point there was that that's "worse" (seemingly less precise)
than what happens now.

Please notice that I did not say that that one example means we
shouldn't change; any more than I think that isolated other examples
mean we should.  The question I was trying to get at is how
we could decide whether using Ryu for this is an overall win when
some examples will get better and others worse.  No one's stepped
up to that plate yet.

            regards, tom lane



В списке pgsql-bugs по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Incorrect rounding of double values at max precision
Следующее
От: PG Bug reporting form
Дата:
Сообщение: BUG #16680: Crash database with sefault 11