Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!ucsd!sdcc6!ir230
From: ir230@sdcc6.ucsd.edu (john wavrik)
Newsgroups: comp.lang.forth
Subject: Re: ANS TC Magnet for Division
Summary: unstandard division?
Message-ID: <10834@sdcc6.ucsd.edu>
Date: 25 May 90 19:14:01 GMT
References: <1006.UUL1.3#5129@willett.UUCP>
Organization: University of California, San Diego
Lines: 99



Dennis Ruffer posts an urgent plea for any last minute comments for the
ANSI Committee -- which is followed (as received at this site) by an 
exchange between himself and Robert Berkey" 


RB:> I hear that the committee has passed a new form of division, with  
RB:> / /MOD  and MOD  having all stack arguments of +n.  I agree that 
RB:> this is preferable to the non-functional division previously in 
RB:> BASIS. 

RB:> However, if a Standard Program cannot use signs in signed 
RB:> division, the only division needed in the standard is unsigned 
RB:> division. 

 
DR:> Thanks Robert!  We were concerned that you might still have an 
DR:> objection.  I will pass your comments on to the committee 
DR:> tomorrow. I believe the problem with calling arguments unsigned 
DR:> would mean that some would have to fix what they have.  By 
DR:> declaring them as positive, signed numbers, everyone's code 
DR:> works.                                      ^^^^^^^^^^^^^^^
     ^^^^^

Everyone's except mathematicians who sometimes use negative numbers in 
division.

DR:> Also, the words FM/MOD and SM/MOD have been added with usage 
DR:> examples so that you can do whatever you need in a standard way. 

And, of course, we all know what FM/MOD and SM/MOD are.

                                ------

Dennis Ruffer asks for last minute comments. I wonder if there is any 
possibility that the ANSI Committee has put users of the language in a 
position where they really can't comment? 

When I observed the ANSI Committee (at their last meeting) arithmetic 
operations were apparently still to be discussed. Someone on the 
Committee was working on a proposal which, among other things, 
undertook to define what numbers are -- he asked me privately for 
input which is: 

     1.  Numbers and their operations are defined in mathematics,
         external to computers and their languages -- computer 
         language committees don't get to do this. 

     2.  It is important that numbers and their operations as 
         represented in a computer match as closely as possible the 
         behavior defined in mathematics. It is important for those 
         who use computers to understand how numbers and operations 
         are represented and how they behave. [Example: How will 
         addition behave under overflow?] 

     3.  Forth has come upon some useful properties: Since integers 
         are usually building blocks for bigger numerical data types,
         the fact that arithmetic operations "wrap around" rather than
         abort on overflow simplifies programming. Similarly floored
         division has more useful properties than rounded to zero.
                           HOWEVER
     4.  The bottom line is that it is unacceptable that algorithms 
         which use just basic arithmetic  would have to be coded in 
         different ways to run on different vendor's systems. If the 
         matter is controversial, it would be far better to flip a 
         coin, if it comes to that, to produce a division operation 
         called / which works on ALL integers in the same way on ALL 
         Forth systems. There are some times where the fact that 
         something is universally agreed upon is more important than 
         what it is (the side of the street on which automobiles 
         drive is one example -- the behavior of arithmetic operations 
         is another). 


The current state of affairs is this:  If I want to write an 
application which will run on other Forth systems. I must take into 
account the fact that arithmetic is slightly different on Forth-79 
systems than on Forth-83 systems. If I want to accomodate users of the 
older standard by writing the application to be backward compatible, I 
can use a variety of strategies. This is possible because I know 
exactly how Forth-79 differs from Forth-83. 

The proposed state of affairs: If I want to write an application which 
will run on other Forth systems I must know exactly how each of the 
many current and possible INDIVIDUAL Forth IMPLEMENTATIONS treat the 
arithmetic operations -- because these will not be adequately defined 
in the Standard. 

I am willing to assume that all of this has been carefully thought 
through and that the strange impression I am getting just comes from 
learning of this through bits and pieces -- so please correct my 
misunderstanding (if any). 


                                                  John J Wavrik 
             jjwavrik@ucsd.edu                    Dept of Math  C-012 
                                                  Univ of Calif - San Diego 
                                                  La Jolla, CA  92093