```At 09:46 -0400 3/27/08, Mark J. Reed wrote:
>Is it just me, or is all this talk about precedence and functions vs operators
>vs methods creating a niggling sensation in anyone else's head? It feels like
>we're in the vicinity of another one of them Big Simplifying Idea things.
>Unfortunately, I don't have the actual Big Idea, so it could just be a false
>alarm.```
```
At 16:24 +0100 3/26/08, TSa wrote:
>I agree. But let me explain how I arrive at that. To me there is no binary
>minus! -f(x) - g(x) = -f(x) + -g(x) = -g(x) + -f(x). I.e. plus is commutative.
>Or even better is to deeply overload unary plus to do the Ring role.
>Additionally implementing unary / or 1/ or so would yield the Field role.

At 17:06 +0100 3/20/08, TSa wrote:
>BTW, do we have a unary multiplikative inversion operator? That is 1/ as
>prefix or **-1 as postfix? Perhaps .inv as method? Do we have .neg for

This is becoming a night time habit. I really need to spend a whole lot of time
learning the new operator syntax and "Perl 6 Essentials" 1st edition isn't
going to cut it. Following Mark's line of thought, that bothers me.

Thomas' idea that there is no such thing as a binary minus operator and his
question about inversion operators intrigue me. Perhaps there is a way to a
breakthrough that would be acceptable to long-time users of the chalkboard and
still be mathematically pure and and easily parsed.

A while back there was a flurry of "new math" being taught in US elementary
schools. The idea was to introduce set theory early and avoid the re-learning
necessary when groups and fields are introduced later. It was a failure mostly
because the teachers couldn't understand it.

A "group" is a set with a single binary operator defined, the result of that
operator is a member of the group, there is a null member of the group that
returns the value of the other operand, and every member of the group has an
inverse for which the operation returns the null. Note that those axioms say
nothing about an inversion operator. For numbers the operator is either
addition, +, or multiplication, *. Subtraction and division are notably missing.

A "field" is a set which looks like two kinds of group with two operators. One
operator has higher precedence than the other and the existence of the inverse
for one operator requires some modification for the null of the other operator.

Matrices and vectors are reasonably comfortable in fields. Note that
commutativity is not a group requirement. The vector cross product is a bit
strange but some folks claim that a cross product is really an antisymmetric
tensor that isn't really a vector because it doesn't transform, under
reflection, as the coordinate differentials. That kind of thinking would fit
right in and might be beneficial. Overloading code would be required for * and
+ only but inversions would replace that bit of simplification. Note that the
term "class" acquires a close relationship with the term "field".

I think it is possible to insist that users of perl 6 for math think in terms
of fields while writing expressions. Just remove the "/" and "-" operators from
the language. They're not present in the field axioms so why have them? Just
announce that perl 6 will be different. The rest of the world now listens when
we say a "perl regular expression". Why not the same for "perl math expression
"?.

NIST now likes people to avoid the term "per" when writing about dimensions of
physical quantities. A watt is a kg*m**2*s**-2 when translated to perl 5 but it
looks a lot better in print with superscripts and no explicit * operator.
Calling it a kilogram meter squared per second per second has been deprecated
for years. Engineers and physicists known to me have no problem with it.

There was once a mnemonic, PEMDAS, that was taught in algebra classes.
Parentheses, exponentiation, multiplication, division, addition, subtraction
was the order to use when working with algebraic expressions. Restricting that
to fields would change it to PFMA by which I mean parentheses, functions,
multiplication, addition. Functions would include exponentiation along with
other things like inversion and more complicated library functions.. Users
would have to learn that division and subtraction would be called out by an
inversion followed by a multiply or add operation.

Terms on the right side of the replacement operator would be separated by +
signs only.

Needed would be a really simple syntax for the two types of inversion.
Something like a distinct sigl would be nice from a user's point of view.
\$xxx[\$n] is closely associated with @xxx and it seems possible to come up with
something like Nxxx for the additive inversion of \$xxx and Dxxx for its
multiplicative equivalent. Variables starting with I through N was not a bad
way to indicate an integer.

I haven't any idea how one would request that a function return an inverted
result even though such a provision may be necessary at least for simple
functions like squaring followed by additive inversion which is where all of
this started, at least for me. The result of evaluation of a parenthesized
block might need to be inverted and I don't know what that syntax would look
like. Using the - and / as prefixed operators would be fraught with confusion
of the new with the old syntax.

Chalkboard algebra has the vinculum operator which is simultaneously a pair of
parentheses and a division that just won't work in a linear line of text. It's
also part of a square root symbol.

I do see a temporary problem with conversion to actual machine language
instructions. Floating point inversion followed by a floating multiply may not
be the best thing to do. Floating division is a bottleneck that is getting some
attention in chip design with the loop that is the long division operation
going from 2 to 4, and more, bits at a time at the expense of more transistors
in the arithmetic unit. Leave it to the optimizing parrot, I guess. For speed
it's better to multiply all of the components of the numerator and of the
denominator and then make one final division. That may not be true next week.

And while I'm here that ! operator for factorial leaves me cold. It applies to
integers only unless someone is going to treat it as a gamma function. Is it
really necessary? Even for such things as a Taylor series expansion it is more
efficient to retain the n! from the previous term and multiply it once by the
new n than to recompute the new n! from scratch. Terms like (-1)**\$n/\$n! for an
alternating series need to look simple and unambiguous in the new syntax.

</rant> Perhaps I'll sleep tonight.
--

Applescript syntax is like English spelling:
Roughly, though not thoroughly, thought through.
```