Applied.
---
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > OK, are you saying that there is a signal we are ignoring for
> > > overflow/underflow, or that we should just silently
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > OK, are you saying that there is a signal we are ignoring for
> > overflow/underflow, or that we should just silently overflow/underflow
> > and not throw an error?
>
> Silent underflow is fine with me; it's the norm in most all float
On 12/29/2006 11:27 AM, Tom Lane wrote:
Doesn't even compile here (no ).
Where do you compile?
Roman
---(end of broadcast)---
TIP 6: explain analyze is your friend
Roman Kononov <[EMAIL PROTECTED]> writes:
> Think about this idea please. This has no INF, NaN or range
> checks and detects all "bad" cases with any floating point
> math.
Doesn't even compile here (no ).
regards, tom lane
---(end of broadcast)---
On 12/29/2006 12:23 AM, Bruce Momjian wrote:
Well, then show me what direction you think is better.
Think about this idea please. This has no INF, NaN or range
checks and detects all "bad" cases with any floating point
math.
The only issue is that a bad case is detected only once.
You need to
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
OK, are you saying that there is a signal we are ignoring for
overflow/underflow, or that we should just silently overflow/underflow
and not throw an error?
Silent underflow is fine with me; it's the norm in most all float
implementatio
Bruce Momjian <[EMAIL PROTECTED]> writes:
> OK, are you saying that there is a signal we are ignoring for
> overflow/underflow, or that we should just silently overflow/underflow
> and not throw an error?
Silent underflow is fine with me; it's the norm in most all float
implementations and won't s
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> This is *not* going in the right direction :-(
>
> > Well, then show me what direction you think is better.
>
> Fewer restrictions, not more. The thrust of what I've been saying
> (and I think Roman too) is to t
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> This is *not* going in the right direction :-(
> Well, then show me what direction you think is better.
Fewer restrictions, not more. The thrust of what I've been saying
(and I think Roman too) is to trust in the hardware float-arith
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > 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
10 matches
Mail list logo
