Re: Musings on operator overloading
HaloO, Larry Wall wrote: As it stands the .() forms are a great way to stack ops after a term. Together with knowing about the ops on the symbolic unary level you can easily read expressions from the terms outwards. I'm not actually parsing expressions. Or as you point out below with respect to look-ahead I'm bad at it as a human. But as a human I've got a 2D vision and mathematical expressions are inherently 2D on paper. So they are more like a drawing than a writing. The poor equivalent in a programming language is whitespace markup. Consider the triangle inequality: |$x+$y| = |$x| + |$y| This nicely breaks apart into five clusters of characters. I recognize the two infix ops = and + and bring my precedence knowledge to bear or look it up. After that I analyze the remaining three clusters. I see all of them having | as first and last character. So I know that three absolute values are linked by two operators. And only then do I start to analyze the things inside the | |s which gives me the sum of $x and $y and the same values separately. The version with more spaces is different |$x + $y| = |$x| + |$y| because now I tend to perceive the two +s on equal footing and converge visually on |$x using prefix | and $y| postfix. To avoid that an ASCII equivalent of a typesetting system gives | $x + $y | = | $x | + | $y | to guide my visual distance parsing or however that might be called. Good practice would then be to join these extended terms by an obvious set of infix ops---usually one. The only twists to learn in this scheme would be ++, -- and **. I don't follow that. Example? The twist of ++, -- and ** is that they lay between method and symbolic unary precedence and that ** is the only binary operator with tighter precedence then the symbolic unarys. By operator stacking I mean something like !+-~?|+^~^$x.a.b.c + [EMAIL PROTECTED] which splits into two blobs left and right of + each of which has a sigiled term as nucleus. From there I would work outwards in operator precedence. In other words, writing the former example as $x ** $y! visually attaches ! to $y and deters from the precedence issue. So it should be something like $x**$y\ ! to highlight it. But parens aren't that bad here either ($x ** $y)! But the tight precedence of infix ** should be made obvious by not surrounding it with whitespace. Which gives ($x**$y)! as the best option. I would make more infix ops list like. We already have , associative, non-commutative | ^ associative, commutative and could add ~ into the first group and *, +, +, +|, ~, ~, +^ and ~^ into the second one. The code generator and the optimizer would use these features and give erroneous results when overloads don't respect them. Regards, TSa. -- The Angel of Geometry and the Devil of Algebra fight for the soul of any mathematical being. -- Attributed to Hermann Weyl
[svn:perl6-synopsis] r14528 - doc/trunk/design/syn
Author: larry Date: Fri Mar 28 10:42:39 2008 New Revision: 14528 Modified: doc/trunk/design/syn/S04.pod Log: typo from cognominal++ Modified: doc/trunk/design/syn/S04.pod == --- doc/trunk/design/syn/S04.pod(original) +++ doc/trunk/design/syn/S04.podFri Mar 28 10:42:39 2008 @@ -269,7 +269,7 @@ ?BLOCK.next($retval); -[Conjecuture: a bare Cnext($retval) function could be taught to do +[Conjecture: a bare Cnext($retval) function could be taught to do the same, as long as C$retval isn't a loop label. Presumably multiple dispatch could sort this out.]
Integerizing a rat involves truncating its tail
HaloO, just re-reading S03 I saw that it defines the Rat to Int conversion as truncation. Why not floor semantics like in %? Actually I would recommend floor semantics whenever an integer is coerced. With the sole exception of Num propably using rounding. Regards, TSa. -- The Angel of Geometry and the Devil of Algebra fight for the soul of any mathematical being. -- Attributed to Hermann Weyl
Re: Musings on operator overloading
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
Re: Integerizing a rat involves truncating its tail
I think nearest makes more sense. People will be really surprised when /1 turns into 0. -- Mark Biggar [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] -- Original message -- From: TSa [EMAIL PROTECTED] HaloO, just re-reading S03 I saw that it defines the Rat to Int conversion as truncation. Why not floor semantics like in %? Actually I would recommend floor semantics whenever an integer is coerced. With the sole exception of Num propably using rounding. Regards, TSa. -- The Angel of Geometry and the Devil of Algebra fight for the soul of any mathematical being. -- Attributed to Hermann Weyl
Re: Integerizing a rat involves truncating its tail
TSa wrote: just re-reading S03 I saw that it defines the Rat to Int conversion as truncation. Why not floor semantics like in %? Actually I would recommend floor semantics whenever an integer is coerced. With the sole exception of Num propably using rounding. If the difference matters to people, I suggest just having available a range of explicit rounding methods to choose from, though not necessarily as separate operators, but rather as an enumerated type you can supply as an additional argument (or trait?) to a routine that would do rounding, to coerce the desired semantics. In my Muldis D language, I have so far these 7 rounding methods as values of a particular enumerated type: half_down|half_up|half_even|to_floor|to_ceiling|to_zero|to_inf, for use as an extra argument. To give you an idea of what I refer to. These can also apply to any situation of simply rounding to lesser precision, not necessarily just to integers. Or maybe your question is more about what method to use by default if users don't explicitly choose one? -- Darren Duncan
Re: Integerizing a rat involves truncating its tail
The choice of floor vs ceiling is essentially arbitrary, as long as its consistent; using truncation or rounding is mathematically unsound. Most implementations use floor, though. So in general I would expect these to hold: x div y = floor(x/y) x mod y = x - y * floor(x/y) Most importantly, this means that -3 mod 5 should yield 2, not -3. Perl5, Python, and Ruby get this right; Java, JavaScript, and PHP do not. (C's behavior in this regard is theoretically implementation-dependent but most implementations return the negative value.) I would also expect the modulus operator to be generalized to non-integers, since there is nothing in the above formulae that requires integral inputs. f mod 1 would then return the fractional part of a number, for instance. -- Mark J. Reed [EMAIL PROTECTED]
Re: Integerizing a rat involves truncating its tail
On Fri, Mar 28, 2008 at 3:47 PM, [EMAIL PROTECTED] wrote: I think nearest makes more sense. People will be really surprised when /1 turns into 0. They shouldn't be, if they're asking for an integer specifically. That's what happens now in Perl 5... If you have a rational number and need to turn it into an integer, best be explicit about how you want the conversion done. I'd almost be tempted to have no default coercion there, but that'd break too much ported code. -- Mark J. Reed [EMAIL PROTECTED]
