ForthNet@willett.UUCP (ForthNet articles from GEnie) (03/19/90)
Category 10, Topic 17
Message 59 Sat Mar 17, 1990
R.BERKEY [Robert] at 19:32 PST
Re: Definition of mod as a binary operation.
The text below is from _Concrete Mathematics_, Graham, Knuth, Patashnik,
Addison-Wesley: 1989, pp. 81-82.
The notation for the floor (greatest integer) function used in the text isn't
in ASCII, the notation in the text uses left- and right-facing 'L's. So, it's
transliterated as follows, and defined as per p. 67:
floor(x) = the greatest integer less than or equal to x.
---------------------------------------------------------------
3.4 'MOD': THE BINARY OPERATION
The quotient of n divided by m is floor(n/m), when m and n
are positive integers. It's handy to have a simple notation
also for the remainder of this division, and we call it
'n mod m'. The basic formula
n = m * floor(n/m) + n mod m
tells us that we can express n mod m as n - m * floor(n/m).
We can generalize this to negative integers, and in fact to
arbitrary real numbers:
x mod y = x - y * floor(x/y), for y <> 0 (3.21)
This defines 'mod' as a binary operation, just as addition
and subtraction are binary operations. Mathematicians have
used mod this way informally for a long time, taking various
quantities mod 10, mod 2pi, and so on, but only in the last
twenty years has it caught on formally. Old notion, new
notation.
We can easily grasp the intuitive meaning of x mod y,
when x and y are positive real numbers, if we imagine a
circle of circumference y whose points have been assigned
real numbers in the interval [0..y]. If we travel a distance
x around the circle, starting at 0, we end up at x mod y.
(And the number of times we encounter 0 as we go is
floor(x/y).)
When x or y is negative, we need to look at the definition
carefully in order to see exactly what it means. Here are
some integer-valued examples:
5 mod 3 = 5 - 3 * floor(5/3) = 2;
5 mod -3 = 5 - (-3) * floor(5/(-3)) = -1;
-5 mod 3 = -5 - 3 * floor(-5/3) = 1;
-5 mod -3 = -5 - (-3) * floor(-5/(-3)) = -2.
The number after 'mod' is called the _modulus_; nobody has
yet decided what to call the number before 'mod'. In
applications, the modulus is usually positive, but the
definition makes perfect sense when the modulus is negative.
In both cases the value of x mod y is between 0 and the
modulus:
0 <= x mod y < y, for y > 0;
0 >= x mod y > y, for y < 0.
What about y = 0? Definition (3.21) leaves this case
undefined, in order to avoid division by zero, but to be
complete we can define
x mod 0 = x (3.22)
This convention preserves the property that x mod y always
differs from x by a multiple of y. ...
------------------------------------------------------------
and so on--this section continues for three more pages.
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: 'uunet!willett!dwp' or 'willett!dwp@gateway.sei.cmu.edu'ForthNet@willett.UUCP (ForthNet articles from GEnie) (03/19/90)
Category 10, Topic 17
Message 60 Sun Mar 18, 1990
R.BERKEY [Robert] at 07:05 PST
To: Wil Baden
Re: Languages with floored or positive-divisor-floored
remainder operators
I've found some old notes once upon a time posted on the ECFB, and for a while
they were in the GEnie library.
A. P. Chang published a language survey in SIGPLAN Notices, V20 #4, April
1985. He reported that Ada, Modula, Pascal Standard, APL, and PL/1 include a
remainder operator that, like Forth-83:
-29 mod 5 = 1
Ada also requires the functionality of symmetry. Ada and APL are also like
Forth-83 in specifying:
29 mod -5 = -1
which is consistent with the mathematical definition of mod as given by Knuth
(except for division by zero). Tom Almy in ECFB Standard's Conference Msg.
2383 mentions, "Smalltalk, which (has) functions for both rounding methods".
Knuth, p. 38, in Volume 1 of the _Art of Computer Programming_, shows the
definition of mod as follows:
x mod y = x - y(floor(x/y)) if y <> 0; x mod 0 = x
So between 1968 and 1989 (in _Concrete Mathematics_), Knuth has compromised a
bit on the case involving x mod 0.
Some languages (FORTRAN and BASIC) and floating point processors provide the
floor function, perhaps under the name INT, which as shown in Knuth's formula
can be used to generate integer flooring.
Robert
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: 'uunet!willett!dwp' or 'willett!dwp@gateway.sei.cmu.edu'ForthNet@willett.UUCP (ForthNet articles from GEnie) (05/25/90)
Category 10, Topic 17 Message 61 Thu May 24, 1990 R.BERKEY [Robert] at 06:47 PDT Dennis, I hear that the committee has passed a new form of division, with / /MOD and MOD having all stack arguments of +n. I agree that this is preferable to the non-functional division previously in BASIS. However, if a Standard Program cannot use signs in signed division, the only division needed in the standard is unsigned division. Renaming these same functions as unsigned, and changing the dividend and quotient to "u", is superior in many ways to giving new definitions to / /MOD and MOD . ----- This message came from GEnie via willett through a semi-automated process. Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.edu
ForthNet@willett.UUCP (ForthNet articles from GEnie) (05/25/90)
Category 10, Topic 17 Message 62 Thu May 24, 1990 D.RUFFER [Dennis] at 23:09 EDT Thanks Robert! We were concerned that you might still have an objection. I will pass your comments on to the committee tomorrow. I believe the problem with calling arguments unsigned would mean that some would have to fix what they have. By declaring them as positive, signed numbers, everyone's code works. Also, the words FM/MOD and SM/MOD have been added with usage examples so that you can do whatever you need in a standard way. DaR ----- This message came from GEnie via willett through a semi-automated process. Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.edu
ir230@sdcc6.ucsd.edu (john wavrik) (05/26/90)
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 ForthNet@willett.UUCP (ForthNet articles from GEnie) (05/27/90)
Category 10, Topic 17 Message 63 Sat May 26, 1990 R.BERKEY [Robert] at 09:23 PDT Dennis, New definitions for / /MOD and MOD make a third set of incompatible definitions in three editions of the Standard. These definitions remove Standard functionality--this guarantees that there is not a program in existence written to such definitions. ----- This message came from GEnie via willett through a semi-automated process. Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.edu
ForthNet@willett.UUCP (ForthNet articles from GEnie) (05/28/90)
Category 10, Topic 17 Message 64 Sun May 27, 1990 D.RUFFER [Dennis] at 00:54 EDT I disagree Robert. As I read Jack Brown's new definitions, just about everyone complies, because only signed positive numbers are defined. Everything else is either implementation defined or an exception condition (which is also implementation defined). Thus, I can't think of any version of these words that I've seen that don't meet what the standard specifies. IMHO DaR ----- This message came from GEnie via willett through a semi-automated process. Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.edu
ForthNet@willett.UUCP (ForthNet articles from GEnie) (05/28/90)
Date: 05-25-90 (06:17) Number: 399 (Echo)
To: R.BERKEY [ROBERT] Refer#: 397
From: CHARLES WILSON Read: NO
Subj: ANS TC MAGNET FOR DIVISIO Status: PUBLIC MESSAGE
After the committee is done, they should also rename the language, to:
CAMEL
NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530
Date: 05-25-90 (17:58) Number: 400 (Echo)
To: R.BERKEY [ROBERT] Refer#: 397
From: RAY DUNCAN Read: NO
Subj: ANS TC MAGNET FOR DIVISIO Status: PUBLIC MESSAGE
I am amazed that the committee would do something so bizarre as
requiring all positive arguments for / /MOD and MOD. This is not an
acceptable solution as far as LMI is concerned.
NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.eduwmb@MITCH.ENG.SUN.COM (Mitch Bradley) (05/30/90)
RD:> I am amazed that the committee would do something so bizarre as
RD:> requiring all positive arguments for / /MOD and MOD. This is not an
RD:> acceptable solution as far as LMI is concerned.
The committee does not require all positive arguments for / /MOD MOD .
The spec means:
a) If a program uses only positive arguments, then it will work
the same on any system.
b) If a program uses negative arguments, then the results may vary
across systems.
This is a statement of historical fact; currently there are commercially
successful systems on both sides of the division fence. Some important
vendors refused to adopt Forth-83.
This is the best that could be done, considering that there were people on
BOTH (floored and symmetric) sides of the issue who WOULD NOT GIVE IN.
Another angle on this is that ANS Forth does not compel vendor A to
break his customers' code in order to satisfy vendor B, and vice versa.
UM/MOD , FM/MOD , and SM/MOD primitives are provided to allow an
application to explicitly construct any needed division semantics.
The technical problem has been completely solved, in the best possible way
given the extant political constraints. Like it or not, politics is real.
Mitchwmb@pi.Eng.Sun.COM (Mitch Bradley) (05/30/90)
RD:> I am amazed that the committee would do something so bizarre as
RD:> requiring all positive arguments for / /MOD and MOD. This is not an
RD:> acceptable solution as far as LMI is concerned.
The committee does not require all positive arguments for / /MOD MOD .
The spec means:
a) If a program uses only positive arguments, then it will work
the same on any system.
b) If a program uses negative arguments, then the results may vary
across systems.
This is not new; currently there are commercially successful systems
on both sides of the fence. Recall that some important vendors refused
to adopt Forth-83.
This is the best that could be done, considering that there were people on
BOTH (floored and symmetric) sides of the issue who WOULD NOT GIVE IN.
What this compromise means is that ANS Forth does not compel vendor A
to break his customers' code in order to satisfy vendor B, and vice versa.
UM/MOD , FM/MOD , and SM/MOD primitives are provided to allow an
application to explicitly construct any needed division semantics.
The technical problem has been completely solved, in the best possible
way considering the extant political constraints. Politics is reality,
whether one likes it or not.
MitchForthNet@willett.UUCP (ForthNet articles from GEnie) (06/12/90)
Category 10, Topic 17
Message 66 Mon Jun 11, 1990
R.BERKEY [Robert] at 05:03 PDT
Mitch Bradley writes, 900602:
...considering that there were people on BOTH (floored and symmetric)
sides of the issue who WOULD NOT GIVE IN.
Mitch, who are these people to whom you refer? A problem begins here in
accepting that there is a problem. I've not found anyone on the committee
able to represent the sense of the committee. There seems to be little
opinion or knowledge at all there. Certainly they have been unable to write a
rationale for their actions.
Here's the November 1989 TSC discussion on my proposal "Ax Non-Functional
Division".
Berkey: <reads briefly from the abstract and conclusion.>
Committee: silence
Berkey: Is no one going to speak against the proposal?
Rather: I don't think that's necessary.
TSC vote ensues: 1 vote yes, others no
At that time there appeared the so-called "compromise" proposal that received
a favorable straw vote. Let's call that the subset division proposal. I was
there when the subset division proposal was dictated by the TC chair,
Elizabeth Rather. (The same Elizabeth who has been telling us that no other
languages specify the results of signed division!?!) Beyond some comments
from Dean Sanderson, this proposal, too, had no apparent committee
involvement, as well as no paper support. Whatever it was must have been
pretty loose as Jack Brown's write-up just adopted did not follow the
polyFORTH structuring described and voted on then.
Technically, I became aware of the subset division possibility a year ago
November and at that time spent literally a couple of man-weeks writing up
proposals involving it. But I never submitted them. It wasn't until several
months later that I realized the patent pointlessness of the subset division.
You may have already seen this comment several times here on GEnie, starting
last October in DIVREPLY.LST.
If a program cannot use signs in signed division, the only
division needed in the Standard is unsigned division.
As it happens, I submitted an unsigned division proposal in 1982. Back then,
floored signed division was strongly preferred to unsigned division. Now the
committee comes around to leaving those single-length signed-division words as
part of the application's problem. The only problem remaining here, then, is
to call a spade a spade and call unsigned division, unsigned division.
The other problem is to acknowledge uselessness as trash and deprecate Forth-
79 division. Maybe I should say this again: There are no known (portable)
programs in which Forth-79 division is the preferred division algorithm.
There are four specific technical reasons for this, which I don't need to get
into here. The presence of this algorithm in computer hardware is
unfortunate, but irrelevant to BASIS. Something needed from the committee is
a name for the Forth-79 / .
JAX asked me at last Thursday's figgy to clarify my own position on signed
division, and what I think about floored division. What I replied was that I
thought the committee would make it easiest on itself to leave division alone.
I also noted that there was a solid basis for disallowing negative divisors in
portable programs.
As to what I think about floored division, here's the score. There is another
form of signed division, two's complement division, that is simpler, more
complete, and more consistent on two's complement processors--it is truly a
division primitive. Let me be clear here in that this algorithm is consistent
with floored division for positive divisors.
Now then, this division is the easiest (useful) signed division to implement
on common processors such as the 8086. It may also be easier to implement in
hardware as it's the natural result of a signed restoring algorithm. And
unless you've worked with it and seen how it fits things together nicely it
might not give the results you at first expect. On the negative side, and
very much like +LOOP , the best flag may be missing in some processors for
convenient bit-level implementation, so just how easily the RISC computers can
implement it I can't say.
But, nobody needs new definitions for / /MOD and MOD . Those were
specified in 1982, and none of the arguments recently to that effect really
hold water relative to the needs of Forth at large.
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.eduwmb@MITCH.ENG.SUN.COM (Mitch Bradley) (06/12/90)
>> ...considering that there were people on BOTH (floored and symmetric) >> sides of the issue who WOULD NOT GIVE IN. > > Mitch, who are these people to whom you refer? I don't know the specific people. I just know that, for every prior solution that was tried, somebody made division a "burning issue" (i.e. threatened to veto the standard). I just wish that we could get this over with. It has been argued and argued and argued until everybody is bloody sick of it. The current solution makes me happy, because it gives me the tools I need to write whatever programs I want to write. It ought to make vendors happy, because it allows them to leave / just like it is right now, regardless of whether that way is floored or signed. I want to emphasize once again that a very significant fraction of the Forth community is NOT using Forth-83, so saying that "we have know what division is since 1982" depends upon an assumption that is more wishful thinking than reality. I agree with Robert Berkey's technical points, but unfortunately this is not a technical problem. It is a question of trying to get a group of people, representing different constituencies, to come to agreement. As Robert mentioned, the committee is not necessarily consistent in its actions, nor always exactly fair in its proceedings. The committee is made up of people. It is not always the same group of people, and each individual person is not always consistent. People get tired, confused, angry, happy, hungry, impatient, annoyed at each other, form factions, whatever. My own effectiveness on the committee has increased significantly with time, as I have become more aware of these facts. From an idealistic point of view, it is regrettable that politics is involved, but it isn't surprising once you consider the reality of human nature. Sorry, Mitch
ForthNet@willett.UUCP (ForthNet articles from GEnie) (07/11/90)
Date: 07-10-90 (03:44) Number: 3483 (Echo) To: DENNIS RUFFER Refer#: NONE From: GENE LEFAVE Read: NO Subj: DIVISION Status: PUBLIC MESSAGE Dennis, I recently read the transcripts of the Genie RT conference regarding division. I found it incredible that the ANSI committee is spending so much time and energy on what is for the vast majority of programmers a non-issue. I have never run across a programming language that attempts to provide a different division operator than that provided by the hardware. I can't imagine a programmer ever expecting the language to compensate in this way. I checked the manuals of a couple of languages and can't find one that defines the result of MOD over negative numbers. I hope the committee will decide not to decide rather then clutter things up with more words in the dictionary. We are not trying to define ADA here, and if we are then DOD should be paying for it. The idea that a standard program should run on every interpreter is a severe requirement that could sink the entire process. I think that the committe members should lighten up and finish the job before they give up in frustration. I don't think that any one expects perfection at the expense of some type of agreement. Gene --- ~ EZ-Reader 1.13 ~ ----- This message came from GEnie via willett through a semi-automated process. Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.edu
ForthNet@willett.UUCP (ForthNet articles from GEnie) (07/12/90)
Category 10, Topic 17 Message 70 Wed Jul 11, 1990 D.RUFFER [Dennis] at 00:44 EDT Re: GENE LEFAVE You did cheat on +EDIT, but I can understand why. <grin> > division. I found it incredible that the ANSI committee is > spending so much time and energy on what is for the vast majority > of programmers a non-issue. Before the 83 Standard, division WAS a non-issue. However, some of the 83 Std's committee decided to specify what no other language dared to, what happens when you divide with negative operands. They even had the audacity to choose the least common way of doing it! Because they choose to change the world, the ANS TC has no choice but to try to rectify the situation. So, don't blame it on the ANS TC, blame it on the wisdom (?) of those who came before. > I don't think that any one expects perfection at the expense > of some type of agreement. You obviously haven't been to a TC meeting yet. <grin> DaR ----- This message came from GEnie via willett through a semi-automated process. Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.edu
ForthNet@willett.UUCP (ForthNet articles from GEnie) (07/13/90)
Category 10, Topic 17 Message 71 Thu Jul 12, 1990 R.BERKEY [Robert] at 08:19 PDT Gene LeFave writes 900710, GL> I recently read the transcripts of the Genie RT conference GL> regarding division. I found it incredible that the ANSI GL> committee is spending so much time and energy on what is for the GL> vast majority of programmers a non-issue. According to the GEnie messages, the committee spent time on division early on. More recently the time and energy expended in technical analysis on integer division may be primarily mine. This work has been in part a response to a point raised regarding the Forth-83 division: that it came without a rationale. This analysis will remain, independent of what X3.J14 decides. And I agree as to the questionable expenditure of time. Had X3 not exhumed the Forth-79 division, there may well have been more productive use for the time. But I find it interesting, I don't mind standing up for the 1982 committee and the Forth-83 Standard where I think criticism has been misdirected or unfair, and the division effort has not been wasted. The rationale for Forth-83 division is more complete now. One of the results of the analysis is a better understanding of the rounded-to-zero division. If anything, the technical surprise has been just how one-sided are the technical issues. During the 1982 meetings the analysis was simpler: MOD is a mathematically defined operator which Forth-79 had misdefined, the floored division was useful, and the Forth-79 division was both error prone and lacking in demonstration of usefulness. The more recent analysis has further confirmed these points. A point made then from a vendor, which relates to one of Gene's main points, is that most programmers have many concerns other than division that might lead them to call for customer service, i.e., that customer support wasn't seen as a significant issue. I've not assumed that division itself was fundamentally the X3.J14 issue. Thusly the technical analysis effort has verified that the ANS committee involvement with division is not a technical one. And, it's missing the point to say that because division is oft discussed, that the problem is discussing division. There's more to be learned from this than division alone. I'm satisfied that the basic technical issues are now well below any reasonable threshold of doubt, such that any remaining problems with division are political ones. A point I make is that there is a lack of criteria by which X3.J14 makes technical determinations. I sense that cajolery, more than reason, functions as a modus operandi. Is there supposed to be some other rationale for removing the Forth-83 list of tradeoffs? GL> I have never run across a programming language that attempts to GL> provide a different division operator than that provided by the GL> hardware. Remember the tale of the emperor with no clothes? A lot of folks were said to have thought those clothes admirable. GL> I can't imagine a programmer ever expecting the language to GL> compensate in this way. No, I don't accept the innuendo that Forth programmers are to be lacking in imagination. How do we determine expectations of a language? Or, who determines these expectations (for us)? I believe that processors and implementations exist for the needs of users. GL> I checked the manuals of a couple of languages and can't find one GL> that defines the result of MOD over negative numbers. I too have seen that technical writers of language manuals tend not to state how negative operands behave. Yet, Gene, your thesis would seem to be that this is somehow related to Forth Standards. My phone number is (415) 659-1334 x352. Or if you will leave your phone number I'd be willing to give you a call. GL> The idea that a standard program should run on every interpreter GL> is a severe requirement... A standard program runs only on conforming implementations, not "every" interpreter. I think that the implied irrelevance of portability is a challenging question. On the one hand, Forth survives without much in the way of libraries, or secondary markets based on portable code. Is the survival of Forth vendor fiefdoms good enough? It was said in 1982 thereabouts that Forth, Inc., was then marketing some 40 different polyForths--suggesting that if it's been good enough for the flagship vendor it's good enough for standardization. Do we dismiss libraries of portable Forth routines? Do we care? The Forth-83 list of tradeoffs places "portability" second only to "functional correctness". I don't consider that standardized Forth is Forth--rather that Forth-83 should be subtitled "Portable Aspects of Forth". A viewpoint toward giving programs more utility: the lack of committee attention in Forth-83 to the Standard Program, which seems to have resulted in more implementations than programs, is reason to move the balance toward the program. X3.J14 moves the balance farther toward the implementation. Then there is the issue that a Standard System is a commodity product. Since the ability to produce a Forth compiler is something of a given as one of the capabilities of a Forth programmer, perhaps this low market value of standard Forth compilers preconditions Machievellian market motives where prejudicing the careezs!of brde-lance Forth programmers, and locking-in customers, has beeT5isconstrued as a part of the job of marketing/survival. (Why would X3.J14 note that surveys went out to vendors? I know that as a free-lance consultant I wasn't surveyed. Were surveys collected from the customers of various vendor's, and from authors, teachers, and other consumers, such as discerning hobbyists? [Yes, it's not necessarily easy, and I'm not volunteering.] A point of concern is that there is at least an appearance that vendors are accepting preferential treatment.) Do we dismiss the market for interpreters and compilers built on Standard Systems? This last is a personal issue for me as I don't see that the current BASIS will encourage such designs. Nor do I think I will be writing the implementation platforms that would be necessary even just for 680x0, 80x8n, and Harris chips. I doubt the committee themselves presently understand how to fit the pieces of BASIS together. Things like the recent text that removes the specification of a bit pattern for zero. This has weird implications like FALSE is no longer defineable as 0 CONSTANT FALSE but would be maybe 0 0< CONSTANT FALSE . GL> The idea that a standard program should run on every interpreter GL> is a severe requirement that could sink the entire process. Counter to the viewpoint that portability is irrelevant, why would Forth be the only language whose X3 standard exists more for the implementation than the program? I don't know, but perhaps an attempt to propose a non-portable language to X3, a language that is not seriously expected to be used by programmers, would be a self-eliminating problem. One of those committee members, Robert ----- This message came from GEnie via willett through a semi-automated process. Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.edu
ForthNet@willett.UUCP (ForthNet articles from GEnie) (07/18/90)
Category 10, Topic 17
Message 72 Tue Jul 17, 1990
R.BERKEY [Robert] at 08:52 PDT
I'll run through some rationale concerning signed integer division,
especially as it concerns standardization in 1982 of floored division.
(rationale, 1: an explanation of controlling principles of opinion, belief,
practice, or phenomena 2: an underlying reason : BASIS). I'll also list here
what I mentioned last month as "specific technical problems" with rounded-to-
zero division.
-----
1) MOD is a mathematically defined symbol. Forth-83 follows that
definition.
2) Rounded-to-zero division is ignored in mathematical textbooks. Five
technical problems with rounded-to-zero division:
a) Rounded-to-zero division needs a negative zero such as is found
on a sign-magnitude machine, and in this regard, it cannot be
implemented properly on two's complement processors. The effect
on two's complement machines is that quotients between -1 and 0
are represented as if they were between 0 and 1. Thereby,
testing a quotient with 0< is a trap when using rounded-to-zero
division. Information is lost, as 0 represents two sets of
quotients, both those between -1 and 0, and those between 0 and 1.
As a result of the lost information, a rounded-to-zero quotient
exhibits a discontinuity at zero--in such applications as machine
control and graphics. The often noted example from Brodie and
Sanderson (see references below) is that of a robot arm that
stalls momentarily during its movement.
b) Rounded-to-zero division rounds quotients in two directions.
This duality leads to reverse engineering programming to remove
the extra direction, and if allowed to propogate, complexity in
higher levels of the program. A common example is in coding a
rounded-to-nearest result: a Forth-79 version requires an
IF statement.
c) A corollary to the bi-directional rounding of Forth-79 quotients
is that the rounded-to-zero division has a cyclical remainder that
reverses direction at zero. There has been no evidence or opinion
that this remainder is useful. Charles Moore hasn't provided a
rounded-to-zero remainder in his systems (his remainders are
unsigned). A modulus, on the other hand, is a recurring
application need.
d) The rounding of the quotient of rounded-to-zero division is
considered to be statistically inferior. The effect with analog
signals is distortion. In the absence of the remainder, rounding
to nearest or even "provides the most accurate and statistically
unbiased estimate of the true results," (Intel, _8087 Numeric Data
Processor, p. S-17). The rounding of flooring consistently biases
the quotient, thus is more useful, such as in implementing a
rounded-to-nearest result, and in limits-of-error analysis.
e) Bit-fields, given that the high bit might be set, cannot be
shifted with rounded-to-zero division.
3) As a result of the technical problems, rounded-to-zero division is bug
prone, and this is demonstrated by published bugs in examples by Forth experts
who are also division specialists.
4) With floored division, 2 / , is the same as 2/ .
5) Compared with using rounded-to-zero division, applications involving
real numbers are in general handled better with either extra bits of
precision, unsigned division, or rounded-to-nearest using floored division.
6) There has been no demonstration of a portable application in which
rounded-to-zero division is the preferred division algorithm.
References:
Leo Brodie and Dean Sanderson, "Division, Relationals, and Loops",
_1981 Rochester FORTH Standards Conference_, p. 117-121.
Notes that the Forth-79 division is mathematically impure and
produces undesirable side effects in ordinary applications.
Robert Berkey, "Integer Division Rounding and Remainders", _1982
FORML Conference Proceedings_, p. 14-23.
Includes timing comparisons for common division algorithms. Lists
16 division algorithms.
Robert L. Smith, "Signed Integer Division", Dr. Dobbs, September 1983,
also available in the GEnie library as FLOORED.DIV.
"If we require that the remainder be cyclical, then the quotient no
longer has any unusual discontinuities."
...
"Floored division is simply more useful in the majority of
applications programs."
-----
Robert
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.eduForthNet@willett.UUCP (ForthNet articles from GEnie) (07/25/90)
Date: 07-22-90 (06:07) Number: 445 (Echo) To: R.BERKEY [ROBERT] Refer#: 441 From: ZAFAR ESSAK Read: NO Subj: ANS TC MAGNET FOR DIVISIO Status: PUBLIC MESSAGE All this discussion regarding the handling of division in Forth is important even if at times it wears out one's interest. The Forth language is a tremendous tool for developing applications as well as exploring the intricacies of hardware structure. To maintain the "public" interest in using Forth for application development the ANSI Standards effort is going to have to make some hard decisions between trying to compromise between what has been done in past implementations of Forth and answering what is correct. I have followed discussions of division in Forth for years and have longed for resolution based on mathematically correct criteria. Having already learnt a language doesn't make me scared of learning a little more. But I am quite scared of a language based on the need to please individuals at the expense of pursuing knowledge and understanding. One can even justify the cost of changes to an application based on CORRECTNESS but not based on appeasing others. I do appreciate the amount of effort individuals are expending on the ANSI Standard and some of the ideas and discussions on-line have demonstrated some nice approaches to simplification of programming. However, if the prime motivation of the committee is to find the areas of compromise then maybe a more appropriate name for the resulting language would be COMPOST, and it might possibly provide fertile ground for future development. Unfortunately such an approach may cause application developers to look elsewhere for required transportability or convince them to support a single like-minded vendor. Zafar. --- * Via Qwikmail 2.01 NET/Mail : British Columbia Forth Board - Burnaby BC - (604)434-5886 ----- This message came from GEnie via willett through a semi-automated process. Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.edu
UNBCIC@BRFAPESP.BITNET (07/29/90)
From: DCS@CIC.UNB.ANDF.BR
To: FIGI-L@SCFVM.BITNET
Subj: ANS TC Magnet for Division
I think ANS TC Magnet for Division is an excelent Subject
Description for the messages that came with it. I remember reading
about someone saying that having both SM/MOD and FM/MOD makes the ANS
Forth Standard weaker than having only one... I didn't understand
why.
BUT many others complain about the fact that the Standard
says that when / receives negative arguments the result is
unpredictable. HOWEVER, in my view, this is not true for *any*
Forth ever written. / with negative arguments will give SM/MOD
DROP or FM/MOD DROP , right? And this is not what is said by
BASIS 12. BASIS 12 says that 20 -10 / can give me 7! Or 130, or 0
et cetera.
Well, when I write a program, I am not usually interested in
whether / is symmetric or floored, but I certainly expect that 20
-10 / will give me -2. And that 25 -10 / will give me -2 or -3.
And I think that TC members expect that too. If I am right, it was
only bad writting of the Standard (although bad writting of a
Standard cannot be considered as "ONLY"). And, if this is the case,
what is needed is just a rewrite of this section (and more care in
the future). *BUT*, if this is not the case, then I really condemn
the way things were done.
Also, if the people who are complaining about division are not
complaining about this, I would like to hear (read) more specific
arguments. I just cannot understand why SM/MOD and FM/MOD cannot
exist, and why / cannot be implementation defined (if we are sure
that it will be symmetric or floored, but not unpredictable).
As I said above, I am not usually interested in the kind of
division I have. But sometimes I need to know what kind of division
it is. That is why I approve of things like SM/MOD, FM/MOD and
predictable result for ... 0 /MOD . They give me a solid ground.
And I don't need to worry about rewritting code if the Forth I use
becomes unavaible for the Computer Enviroment I *MUST* to use.
Trying to be clear,
(8-DCS)
----------------------------------------------------------------------
DCS@CIC.UNB.ANDF.BR Daniel C. Sobral
UNBCIC@BRFAPESP.BITNET (8-DCS)
"Ah, but there are always rules to break..."
- The Vampire Lestat
in The Queen of the Damned
by Anne Rice
----------------------------------------------------------------------koopman@a.gp.cs.cmu.edu (Philip Koopman) (07/30/90)
In article <9007292127.AA24336@ucbvax.Berkeley.EDU>, UNBCIC@BRFAPESP.BITNET writes: > BUT many others complain about the fact that the Standard > says that when / receives negative arguments the result is > unpredictable. HOWEVER, in my view, this is not true for *any* > Forth ever written. / with negative arguments will give SM/MOD > DROP or FM/MOD DROP , right? And this is not what is said by > BASIS 12. BASIS 12 says that 20 -10 / can give me 7! Or 130, or 0 > et cetera. >... In a "reasonable" implementation, this probably would not happen. However, this is the thrust of my current problem with division in the BASIS. If we are going to go to all the trouble to specify N kinds of division, at least we should fully specify how to make / work in a generally useful (if implementation dependent) manner. Phil Koopman koopman@greyhound.ece.cmu.edu Arpanet 2525A Wexford Run Rd. Wexford, PA 15090 Senior scientist at Harris Semiconductor, and adjunct professor at CMU. I don't speak for them, and they don't speak for me.
ir230@sdcc6.ucsd.edu (john wavrik) (08/01/90)
Daniel Sobral writes: > I think ANS TC Magnet for Division is an excelent Subject > Description for the messages that came with it. I remember reading > about someone saying that having both SM/MOD and FM/MOD makes the ANS > Forth Standard weaker than having only one... I didn't understand > why. I think the main objection to what ANSI has done to division is not so much this one particular thing but rather what it says about the approach that the ANSI team is taking. The real issue is how the ANSI team is going about creating standards. This newsgroup is interesting reading. Some of the articles are written by two people who I will call J and M. J, a user of Forth, is very concerned about how the standards are shaping up -- it seems to him that the ANSI team is doing things that are destined to result in a weak standard. He expresses his worries in the form of analogies: I am concerned because what the ANSI team seems to be doing looks like this...". M, a member of the ANSI team, immediately posts a reply ostensibly to deny the analogy -- but he then goes on to provide ample evidence to confirm J's worst fears. This has been repeated several times. As a result, it seems quite likely that users (rather than vendors) of Forth have just cause to worry. Let's look at division. Here is the way in which the ordinary signed division operation is obtained from UM/MOD (copied from F83): >R S>D R> ?DUP IF DUP >R 2DUP XOR >R >R DABS R@ ABS UM/MOD SWAP R> ?NEGATE SWAP R> 0< IF NEGATE OVER IF 1- R@ ROT - SWAP THEN THEN R> DROP THEN SWAP DROP If everyone would use this sequence whenever division is required in their application, all would be well. We could glance at it and tell immediately what kind of division is being used. But this will not happen. Instead programmers will define / somewhere (probably in a file which is automatically loaded into their system). They will use the symbol / for division -- but it now will be a programmer-dependent word. Apparently the ANSI team, insofar as they have any interest in portability at all, seems to be thinking in terms of entire applications. What is more likely to be beneficial for the future of Forth is the ability of programmers to exchange individual words or application fragments. Currently, when looking at a fragment in Forth Dimensions, JFAR, etc., one must know if the code is in Forth-79 or Forth-83. Once this is known, the meaning of a collection of basic words (like /, ', PICK, ROLL, etc) are known. A compromise which makes basic words programmer dependent increases the difficulty of understanding application fragments. It is a very bad idea to let the meaning of fundamental words float. There should be absolute agreement on the meaning of the 100-150 words needed to generate the Forth language. Vendor eccentricity and "value added" features should be at a higher level. These statements are really not revolutionary. Both Shakespeare and Hemmingway agree on the meaning of "the", "is", "be", etc. Their contribution to writing does not consist in changing the meaning of fundamental English words. Allowing everyone to choose their own meaning for basic words can only have one effect: it will make it harder to communicate. John J Wavrik jjwavrik@ucsd.edu Dept of Math C-012 Univ of Calif - San Diego La Jolla, CA 92093
ZMLEB@SCFVM.GSFC.NASA.GOV (Lee Brotzman) (08/01/90)
John J Wavrik <jjwavrik@ucsd.edu>, writes: >Let's look at division. Here is the way in which the ordinary signed >division operation is obtained from UM/MOD (copied from F83): > > >R S>D R> ?DUP > IF DUP >R 2DUP XOR >R >R DABS R@ ABS UM/MOD > SWAP R> ?NEGATE > SWAP R> 0< IF NEGATE OVER IF 1- R@ ROT - SWAP THEN THEN > R> DROP > THEN SWAP DROP > >If everyone would use this sequence whenever division is required in >their application, all would be well. Reality check: the fact that not everyone will use this sequence is precisely the problem. There is no consensus on this particular issue. The standards process demands consensus. Therefore, this issue must be resolved through compromise (which, simply stated, is a means of "redistibuting unhappiness" so that it becomes bearable to all involved). The compromise reached on this issue was an artful one, and very simple to understand, unlike the problem it fixed. The arguments pro and con on floored division have been flying around for eight years and still there is controversy. Isn't that evidence enough that some kind of compromise was needed? >... We could glance at it and tell >immediately what kind of division is being used. But this will not >happen. Instead programmers will define / somewhere (probably in a >file which is automatically loaded into their system). They will use >the symbol / for division -- but it now will be a programmer-dependent >word. So what else is new? Before, one had to know that the code was Forth-79 or Forth-83 in order to correctly interpret / . I take that back: one could know the base standard being used and STILL not know how to interpret division because it was, and is, implemented differently in systems that otherwise comply with their standard. This is a product of the aforementioned ongoing controversy. Do you honestly believe that I would be unable to understand an algorithm because I couldn't be sure of whether floored or truncated division was used? It's simple, "the division operator, /, will work the way I define it in *my* system, not the original implementer's." And if that interpretation proves to be wrong, I preface the code with: : / FM/MOD NIP ; or : / SM/MOD NIP ; (if I got the stack right) whichever is the antonym of the way my system is implemented. This is a hell of a lot simpler than the mess we have now, to which there is no easy answer. If the implementer really cares about portability, he should use the explicit division routine of his choice rather than using / . I believe this is mentioned in Basis. If it isn't, it should be. The ANSI team did us a favor by making a complicated pain in the ass into a simple pain in the ass. I agree that it would be better to remove the pain altogether, but it just ain't gonna happen. > ... A compromise which makes >basic words programmer dependent increases the difficulty of >understanding application fragments. Just what other basic words are programmer dependant? And were they programmer/standard dependant before? And is the number of dependencies decreasing or increasing? Would any ANSI committee members care to give a quick synopsis? >It is a very bad idea to let the meaning of fundamental words float. >There should be absolute agreement on the meaning of the 100-150 words >needed to generate the Forth language. Agreed. Now if the standard were written by one person or one company that could happen. Tell you what, John, write a standards document that you feel is the best it can be -- take the Basis and fix what you perceive to be the flaws, for instance -- then try to get everyone to use it. Suppose you received several negative comments from people who would refuse to use Wavrik-90 Forth until the contentious parts of the Standard were modified. Would you seek a compromise? Remember that if you don't, then the standard will be crippled by the lack of universal acceptance. Think hard about this. Can there ever be a perfect standards document? >These statements are really not revolutionary. Both Shakespeare and >Hemmingway agree on the meaning of "the", "is", "be", etc. Their >contribution to writing does not consist in changing the meaning of >fundamental English words. Allowing everyone to choose their own >meaning for basic words can only have one effect: it will make it >harder to communicate. Another misguided analogy. Look in a dictionary. My copy of Webster's Collegiate lists four definitions for "the"; the first with 11 qualifications, the second with two qualifications, and the third with two, and the fourth with one. None of the definitions vary greatly, but they are slightly different and depend on the context that "the" is being used in. Seems to me that having only two precisely-defined alternatives for / isn't so bad, after all. Let's see, how about the word "then" as long as I have the dictionary open... "Then" can mean "at that time", "soon after that" <walked to the door, _then_ turned>, or "in that case" <take it, _then_, if you want it>. Again, each meaning depends on the context in which the word is used. I wonder how we ever learned to communicate with such variation in meaning? > John J Wavrik > jjwavrik@ucsd.edu Dept of Math C-012 > Univ of Calif - San Diego > La Jolla, CA 92093 -- Lee Brotzman (FIGI-L Moderator) -- BITNET: ZMLEB@SCFVM Internet: zmleb@scfvm.gsfc.nasa.gov -- I'm only a contractor, don't blame me for the tax rates and don't blame -- the government for my statements.
ForthNet@willett.UUCP (ForthNet articles from GEnie) (08/06/90)
Category 10, Topic 17 Message 74 Fri Aug 03, 1990 R.BERKEY [Robert] at 00:41 PDT I have talked with some dozen people in the last couple of weeks concerning division in particular. Some groups of opinion include: A favoring of change to the semantics of / relative to Forth-83 independent of technical issues. Objection to the new semantics of / as defined in BASIS. I am also not hearing the same pattern of issues regarding /MOD and MOD as concerns / . Support for increasing the role of unsigned division with single precision operators is generally favorable. There is, however, at least some objection to adding "new" division operators, and whether a single precision U/ is in widespread use has been questioned. The naming issue is unclear. I can go into more detail on each of these issues. If you have interest or opinion, my phone number is (415) 659-1334 x352. ----- This message came from GEnie via willett through a semi-automated process. Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.edu
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (09/03/90)
Category 10, Topic 17 Message 75 Fri Aug 31, 1990 D.RUFFER [Dennis] at 13:32 EDT From Elizabeth Rather, Chair, ANS X3J14 Technical Committee: This is addressed to those who have been commenting extensively on our work on UseNet and related boards. Although Mitch Bradley has been doing a great job of answering your specific comments (thanks, Mitch!), I do have a couple of personal (unofficial) remarks on recently popular topics. 1. Division: Somehow, all other high-level languages, even ADA, seem to get along without specifying how division works. Why do Forth programmers require a level of specification unique in the industry? There was a firestorm of discussion over the recent revisions to ANS Fortran, and no one ever complained that Fortran makes no specification as to the rounding of integer division with negative arguments! The fact that ANS Forth will support both of the two most popular algorithms (symmetric flooring is more attractive to the mathematically sophisticated, and truncation is the way most hardware DIV instructions work) provides options you can't get any other way than writing your own in assembler. People who know the difference should be overjoyed, and people who don't shouldn't care. I don't understand why everyone's mad. ----- This message came from GEnie via willett through a semi-automated process. Report problems to: uunet!willett!dwp or dwp@willett.pgh.pa.us
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (04/18/91)
Category 10, Topic 17 Message 82 Wed Apr 17, 1991 R.BERKEY at 01:57 PDT Zarko Berberski writes, 91-04-09, > ..."the mathematical use of" MOD is not as an operator but as a > qualifier of equivalence statemant... From Graham, Knuth, Patashnik, _Concrete Mathametics_, Addison-Wesley Publishing Co.: 1989, p. 82, Chapter 3.4, 'MOD': THE BINARY OPERATION: x mod y = x - (y * floor(x/y)), for y <> 0. (3.21) This defines 'mod' as a binary operation, just as addition and subtraction are binary operations. Mathematicians have used mod this way informally for a long time, taking various quantities mod 10, mod 2*pi, and so on, but only in the last twenty years has it caught on formally. Old notion, new notation. > ...so there is no popular computer language that implements the MOD > the way we are using it in mathematics. This statement allows that there are some "unpopular" languages that implement the MOD. Languages implementing the MOD function on at least the positive integer domain of y include PASCAL, Modula-2, Smalltalk, APL, Ada, FORTRAN and Forth. (FORTRAN's syntax of "MOD" is something different: the name used there for the MOD operator is "MODULUS".) Robert Berkey ----- This message came from GEnie via willett. You *cannot* reply to the author using e-mail. Please post a follow-up article, or use any instructions the author may have included (USMail addresses, telephone #, etc.). Report problems to: dwp@willett.pgh.pa.us _or_ uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (05/20/91)
Date: 05-17-91 (08:26) Number: 2196 of 2196 (Echo)
To: R.BERKEY [ROBERT] Refer#: 2194
From: JACK WOEHR Read: NO
Subj: DIVISION Status: PUBLIC MESSAGE
Conf: FORTH (58) Read Type: GENERAL (+)
-> Intel with their 8088/8086 and Motorola with their 68000 have each
-> demonstrated the complexities. Intel's difficulties in implementing
-> -32768 as a dividend have been reported in Forth dimensions as well
-> as are recorded in the Intel 80286 Programmer's Reference Manual.
-> Motorola's signed opcode is sufficiently inefficient that an ordinary
-> implementation of floored division based on unsigned division will
-> divide positive numbers such as 8 by 3 more efficiently than will the
-> Motorola signed opcode (1 to 2% difference).
Bob, for years you and I have been talking about division, by
phone, telecom and face-to-face. I agree with your research and in
general with your conclusions. As a matter of fact, though I have used
floored division for years (indexing round and round through short
arrays is a good example of the benefits of neg-infinity floored
division), I never really *understood* integer division until you
explained it to me.
I just wish with 20/20 hindsight that you had confined your
agenda to this critical point rather than widened the front to an
all-out assault on X3J14. If you and I had kept focussed, we might have
been able to change more things in BASIS.
As it is, by keeping focussed on what is important to me and to
Vesta Technology, I have had the satisfaction of seeing many very
progressive adaptations of the BASIS as regards small-memory, mixed
RAM/ROM systems.
=jax=
NET/Mail : RCFB Golden, CO (303) 278-0364 VESTA & Denver FIG for Forth!
<<<>>>
-----
This message came from GEnie via willett. You *cannot* reply to the author
using e-mail. Please post a follow-up article, or use any instructions
the author may have included (USMail addresses, telephone #, etc.).
Report problems to: dwp@willett.pgh.pa.us _or_ uunet!willett!dwp