Subject Re: [IB-Architect] Re: [Firebird-admin] Draft: FB v1.0 Status Update
Author Ali
select cast (-70000 as numeric (18,5)) / cast (1.95583 as numeric (18,5))
from rdb$database;

(FB RC2, copy-paste-execute from your mail)

another windows calculator:
- 70000.
/ 1.95583

are you sure about that bug?

----- Original Message -----
From: "Ann W. Harrison" <aharrison@...>
To: <Firebird-devel@...>
Cc: <>
Sent: Friday, February 15, 2002 11:21 AM
Subject: [IB-Architect] Re: [Firebird-admin] Draft: FB v1.0 Status Update

> I've just stepped through the Klapperich bug - for those of you
> who are not aware of it, the new algorithms in Dialect 3 that
> check for numeric overflow are questionable, and an overflow on
> division with the divisor less than zero is not caught. The
> precise Klapperich bug is this:
> SQL> select cast (-70000 as numeric (18,5)) / cast (1.95583 as numeric
> CON> from rdb$database;
> =====================
> 1936.2502338333
> SQL>
> Note the improbability of dividing a negative number by a positive
> number and achieving a positive result.
> The cause is an undetected and unreported truncation. That is,
> for me, a priority 1 bug. I'd rather see the server crash than
> return the wrong answer.
> This must be fixed (my opinion) - the question is how.
> The problem can be solved in one of two ways - improving the
> algorithm so it correctly detects and reports overflow or
> "promoting" all calculations that might overflow to double
> precision. The InterBase group chose to report an overflow
> unless one of the operands were cast to double precision.
> Prior to V6, all suspect computations were done in double
> precision and converted back to the original datatype if
> possible. For Dialect 3, the InterBase group chose to report
> an overflow if both operands are int64 and the operation
> could create an internal overflow if performed in int64.
> We can fix this particular test so the computation returns an
> error or we can go back to performing computations in double
> precision. One problem with fixing this particular test is
> that the same guy who blew this computation wrote all the rest
> of the boundary tests. Another is that we will return errors
> for computations that can be done in double precision and return
> correct results. The major problem with "promoting" the
> computation to double precision is that it is a couple of
> bits less precise than int64 - if the computation works in
> int64.
> Being tired, cranky and in the wrong time zone, I don't have
> an answer and would like to hear opinions.
> Ann
> To unsubscribe from this group, send an email to:
> Your use of Yahoo! Groups is subject to