I have always liked the high minus of APL and using the underscore in J to represent negative numbers. Not because it allowed lists of numbers to include negative numbers, but because it made a true representative of negative numbers, not the negation of a positive number. Using the minus sign to represent negative numbers implies an action on a positive number. Not just a negative number as a constant. Similarly using the forward slash to represent the reciprocal of an integer (gosh! we don't even have a name for that) also implies an action. -And -/2 to represent negative-one-half is getting awkward.
It seems to me that if he intends to extend the notation of a number that using / and - like this would only lead to confusion. It makes it seem that non-negative integers are special which they are not. On Sat, Apr 30, 2016 at 8:24 AM, Skip Cave <[email protected]> wrote: > Gustafson re-invents APL/J's reciprocal notation... Slide 17 of Gustafson's > Unums 2.0 Powerpoint presentation: > > <<<>>> > > *A new notation: Unary “/”* > > Just as unary “–” can be put before *x* to mean 0 – *x*, > unary “/” can be put before *x* to mean 1/*x*. > > Just as we can write –*x* for 0 – *x*, we can write /*x* for 1/*x*. > Pronounce it “over x” > > Parsing is just like parsing unary minus signs. > > – (–*x*) = *x*, just as / (/*x*) = *x*. > > *x* – *y* = *x* + (–*y*), just as *x* ÷ *y = x *× (/*y*) > > These unum systems are lossless (no rounding error) under negation *and* > reciprocation. > Arithmetic ops + – × ÷ are on *equal footing*. > ------------------------------------------------------------------------ > > OK, this is a big one. Other than the SORN slide, this may be the most > disruptive idea in this slide deck. I’m proposing a fundamental change to > the way we commonly write and read numbers, one that conceivably could be > taught in grade school from now on. > > The term “unary minus” means a minus sign that negates the value that > follows, as opposed to the kind of minus we mean when we write x – y. We > can abbreviate zero minus x as just, minus x. Leave out the zero. We could > do the same thing for 1/x, and leave off the 1. Instead of saying “one over > x” we would just say “over x”. > > We know that compilers can parse unary minus signs; they’ve been doing it > for sixty years. It should not be at all difficult for them to parse the > “over” sign, unary “/”. > > Notice that two unary minus signs cancel out. The negative of the negative > of a number gives us back the positive. Similarly, the reciprocal of the > reciprocal of a number gives us back the number. Usually you have to make > an exception for dividing by zero, but we don’t with this system. The > reciprocal of zero is ±∞, and the reciprocal of ±∞ is zero. > > As anyone who has ever used a pocket calculator knows, dividing x by y is > not the same as multiplying x by 1/y. Like, if you divide 6 by 3 you will > get exactly 2 on a calculator or a computer. But if you multiply 6 by the > calculator version of 1/3, you will get a number close to 2, but not quite! > Which can be pretty disastrous in even the simplest of computer programs, > like when you are trying to use these small integers or fractions to decide > how many times to execute a loop of code. > > We’ve long had the ability to negate numbers without any loss of accuracy > or information. But reciprocation has always been sloppy, and you cannot > take 1/x with floats and land exactly on another float unless you’re very > lucky, so you experience rounding errors just with the simple act of asking > for a reciprocal. Suppose going from 3 to 1/3 was as simple as writing “–3” > for the negation of 3? You write “/3” and that is the answer. That is the > way the computer stores it internally, and that is the way it displays the > result for humans to read and understand. As I said, this probably has to > be taught starting at the elementary school level at the time they > introduce negative numbers, fractions, and decimals. They are just as hard > to understand at first as fractions and decimals, and just as easy to > understand after you get used to that notation. > > I sometimes say that “division is the ‘bad boy’ of arithmetic.” It’s the > hardest one to learn in school and the slowest to execute on a computer. > Remember the notorious Intel Pentium Divide Bug? That was the result of > aggressive attempts to raise the speed of divides on a microprocessor, > since divides are quite a bit slower than multiplies the way we do things > now. But the system described here makes all four arithmetic operations > equally simple, equally symmetric, equally fast. > <<<>>> > > Skip > > Skip Cave > Cave Consulting LLC > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
