Ann,
IBConsole:
select cast (-70000 as numeric (18,5)) / cast (1.95583 as numeric (18,5))
from rdb$database;
-35790,4316837353

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

another windows calculator:
- 70000.
/ 1.95583
---------------
-35790.4316837353

are you sure about that bug?

Ali

----- Original Message -----
From: "Ann W. Harrison" <aharrison@...>
To: <Firebird-devel@...>
Cc: <ib-architect@yahoogroups.com>
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
(18,5))
> 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:
> IB-Architect-unsubscribe@onelist.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>