Re: unsafe floats
От | Dennis Bjorklund |
---|---|
Тема | Re: unsafe floats |
Дата | |
Msg-id | Pine.LNX.4.44.0403102323430.13979-100000@zigo.dhs.org обсуждение исходный текст |
Ответ на | Re: unsafe floats (Neil Conway <neilc@samurai.com>) |
Ответы |
Re: unsafe floats
|
Список | pgsql-hackers |
On Wed, 10 Mar 2004, Neil Conway wrote: > No, 'NaN' is legal float4/float8/numeric input whether UNSAFE_FLOATS > is defined or not. Yes, the tests are: if (fabs(val) > FLOAT8_MAX) if (val != 0.0 && fabs(val) < FLOAT8_MIN) and only infinity and not NaN will trigger the overflow. I read it wrong first. > Well, CheckFloat4Val() is needed to ensure that the input fits in a > 'float' (rather than just a 'double'). Sure, for Float4 (maybe working with float in C instead of double and this check would make a difference, but I havn't really thought about that). > What number would you like 'Infinity'::float4 and 'Infinity'::float8 > to produce? Is this actually useful functionality? I would like them to produce the IEEE 754 number 'infinity' (usually writte 'Inf' in other languages). > As for it being in the SQL standard, using Acrobat's "text search" > feature finds zero instances of "infinity" (case insensitive) in the > 200x draft spec. I haven't checked any more thoroughly than that, > though. If they say that it should use IEEE 754 math, then they do say that Infinity is a number, just like it is in C and lots of other languages with IEEE 754 math. Being as old as it is, I would guess that the standard doesn't really say much at all about floats. Why should pg not do the same as most (all?) other language that use IEEE 754 math? -- /Dennis Björklund
В списке pgsql-hackers по дате отправления: