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. >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.
