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 по дате отправления: