Tom Lane wrote:
> No, because you are still comparing against FLOAT4_MAX. I'm suggesting
> that only an actual infinity should be rejected. Even that is contrary
> to IEEE spec, though.
>
> The other problem with this coding technique is that it must invoke
> isinf three times when the typical case really only requires one (if the
> output isn't inf there is no need to perform isinf on the inputs).
> If we're going to check for overflow at all, I think we should lose the
> subroutine and just do
>
> if (isinf(result) &&
> !(isinf(arg1) || isinf(arg2)))
> ereport(...OVERFLOW...);

I wasn't excited about doing one isinf() call to avoid three, so I just
made a fast isinf() macro:

/* We call isinf() a lot, so we use a fast version in this file */
#define fast_isinf(val) (((val) < DBL_MIN || (val) > DBL_MAX) && isinf(val))

and used that instead of the direct isinf() call. (We do call fabs() in
the Check* routines. Should we be using our own Abs()?) The new patch
also uses float8 for float4 computations, and adds a comment about why
(avoid underflow in some cases).

In looking at the idea of checking for zero as an underflow, I found
most transcendental functions already had such a check, so I moved the check
into the Check*() routines, and added checks for multiplication/division
underflow to zero. The only outstanding uncaught underflow is from
addition/subtraction.

--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +


---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match