Re: [BUGS] BUG #4660: float functions return -0

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [BUGS] BUG #4660: float functions return -0
Дата
Msg-id 3354.1234886278@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [BUGS] BUG #4660: float functions return -0  (Gregory Stark <stark@enterprisedb.com>)
Ответы Re: [BUGS] BUG #4660: float functions return -0
Список pgsql-hackers
Gregory Stark <stark@enterprisedb.com> writes:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>> I'm of the opinion that minus zero was put into the IEEE floating point
>> standard by people who know a great deal more about the topic than
>> anyone on this list does, and that we do not have the expertise to be
>> second-guessing how it should work.  Not long ago we took out code that
>> was interfering with spec-compliant treatment of IEEE infinity; I think
>> we should take out this code too.

> If the original complaint was that it looked ugly in query results then the
> right way to fix it would surely in float4out and float8out. Interfering with
> IEEE floating points may be a bad idea but surely it's up to us how we want to
> represent those values in text.

> But without a convenient and widely used binary format that kind of restricts
> our options. If we squash -0 on float[48]out then dumps will lose information.

The point I'm trying to make is that we should deliver IEEE-compliant
results if we are on a platform that complies with the spec.  Right down
to the minus sign.  If that surprises people who are unfamiliar with the
spec, well, there are a lot of things about floating point arithmetic
that surprise people who aren't familiar with it.
        regards, tom lane


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

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: pg_migrator and handling dropped columns
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: PL/Perl translation, croak