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 

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. 
>In other words overloading unary minus gives you the binary version for free. 
>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 
>additive inversion?

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.

Reply via email to