[comp.lang.forth] Division... Is both types of division in BASIS arithmatically

S47852EF@ETSUACAD.BITNET ("Frank C. Earl") (02/28/91)

To the net:

This is an emprical proof of the fact that the forms of division used in
most of the current computer languages (Including the two used in the
BASIS...) are incorrect in the results given for the remainder for
operations in the third quadrant (both divisor and dividend are
negative).   This is in response to a comment made to me by Mitch
Bradley over a statement that I made about this being a problem in both
types of division.


Passed to /MOD is the values minus four and minus three-

Results:

F-PC         1 -1
MVP          1 -1
TaskForth    1 -1

So, you might ask, what is wrong with this?

The remainder is NEGATIVE.
This is incorrect, as you will soon see...


Consider,
                             -4
-4 -3 /MOD is equivalent to  -- in fractional expression terms.
                             -3

            -4   -1   4          -1
Given this, -- = -- * - .    The -- = 1 because the signs cancel.
            -3   -1   3          -1

                                          4                1
Therefore, our calculation is really with - , which is 1 + - .
                                          3                3

This is what /MOD passes back as a result - the whole number resulting
from the division and the dividend of the fraction that's left over.
                                                                   -1
But, every Forth dialect that I have asked, tells me that it's 1 + -- ,
                                                                    3
which, from what I just said is *quite* wrong...   (Not only is Forth off
here, but every language dialect I've tried does the same thing (ADA's the
only one I know of that does the right calculation for the remainder
portion)).   If you think that this doesn't matter- think again...

    1   4            -1   3   1   2       4                2
1 + - = -  and,  1 + -- = - - - = -  and, - does not equal - .
    3   3             3   3   3   3       3                3


That's sufficient enough an error to justify re-working it (What if you
don't check to see that this throws off your calculations- it could
prove catastrophic- might cause a horrible accident of some sort if it
was used in a critical application that only very rarely drifted off
into the third quadrant??) and looking at ways of doing it better...

The next posting from me (time permitting) will be a description of the
algorithm I propose should be considered for standardization (I know it's
too late- but we could start considering it for the next standard...) and
some sample Forth-83 (F-PC) code that does the desired operation...

Frank