Re: [BUGS] BUG #2846: inconsistent and confusing
От | Bruce Momjian |
---|---|
Тема | Re: [BUGS] BUG #2846: inconsistent and confusing |
Дата | |
Msg-id | 200612280141.kBS1fN216423@momjian.us обсуждение исходный текст |
Ответ на | Re: [BUGS] BUG #2846: inconsistent and confusing handling of underflows, (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-patches |
Tom Lane wrote: > Roman Kononov <kononov195-pgsql@yahoo.com> writes: > > In float4mul() and float4div(), the computation should be double precision. > > Why? It's going to have to fit in a float4 eventually anyway. One issue is in the patch comment: ! * Computations that slightly exceed FLOAT8_MAX are non-Infinity, ! * but those that greatly exceed FLOAT8_MAX become Infinity. Therefore ! * it is difficult to tell if a value is really infinity or the result ! * of an overflow. The solution is to use a boolean indicating if ! * the input arguments were infiity, meaning an infinite result is ! * probably not the result of an overflow. This allows various ! * computations like SELECT 'Inf'::float8 + 5. + * Underflow has similar issues to overflow, i.e. if a computation is + * slighly smaller than FLOAT8_MIN, the result is non-zero, but if it is + * much smaller than FLOAT8_MIN, the value becomes zero. However, + * unlike overflow, zero is not a special value and can be the result + * of a computation, so there is no easy way to pass a boolean + * indicating whether a zero result is reasonable or not. It might + * be possible for multiplication and division, but because of rounding, + * such tests would probably not be reliable. For overflow, it doesn't matter, but by using float8, you have a much larger range until you underflow to zero. I will make adjustments to the patch to use this, and add comments explaining its purpose. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
В списке pgsql-patches по дате отправления: