foo(1: 2: 3: 4:) ?
So I'm finally starting to implement multi-level invocants in MMDs. I'd like to sanity check some cases first, though. Are these two assumed to be identical? multi sub foo ($x, $y) multi sub foo ($x, $y : ) But these two are _not_ identical? multi sub foo ($x : $y : $z) multi sub foo ($x : $y : $z : ) Is multiple colons usable in invocation? If yes, is these two assumed to be identical? $a.foo($b : $c); foo($a : $b : $c); S12 says all the following cases come out to the same thing: $handle.close # 1 close($handle) # 2 close $handle: # 3 close $handle # 4 Does it mean that during invocation, when there is no colons and no dots, an implicit colon is added at the end, making all arguments same-level invocants and subject to MMD? That is, these are identical: foo($a, $b) foo($a, $b : ) But these two are _not_: foo($a : $b : $c) foo($a : $b : $c : ) Thanks, /Autrijus/ pgpUwHCY5QDg9.pgp Description: PGP signature
Re: hyperoperators and multi-dimensional datastructures
Uri Guttman wrote:
i can't spit out the syntax but here is the conceptual way i would do
it. we do have multidimensional slices so we could grab each slice
(maybe with zip?) and pass that to [+] and then grab the list of results
back into a array/matrix with one less dimension than the original.
Yup. I wonder though if that formulation is made simpler by
the notion of iterating a data structure at a given
depth. It might even be useful for $data{$x}{$y}{$z}[$i] or
similar, where e.g. map() could make a deep copy down to a
certain depth where it then operates elementwise.
so it would be something like this: (very wacko pseudo code):
@in[ * ; 2 ; * ] ==
map [+] ==
@out
One limiting thing about this is that the data being 3-dimensional
and the focus on the second dimension are explicit in the syntax:
presumably not possible to reduce a $j dimensional array over
dimension $i in the same way. Equivalently, the autoindexing described
in Synopsis 9 looks like it enables
do - $i, $j, $k { @sum[$i, $k] = @data[$i, $j, $k] }
which is very elegant. But if I was wanting to write a library
which handles arbitrary data cubes, it would be nice to specify
the dimensions using variables.
LP I think we're beginning to re-invent PDL. Poorly.
but is there a p6 pdl yet? they may not need much with multi-dim ops,
slices, hyper and reduce all built in! also with type int (patform
ints), they can get the dense storage needed (but losing any dimensional
flexibility).
Yes. I don't quite understand that point. I rather see PDL as a limited
version of MATLAB, and MATLAB as a limited version of APL. The right
set of vector primitives can be combined powerfully in some very
non-obvious ways (c.f. in fact the recent post by Edward Cherlin), and
APL and successors have worked this out over 30+ years. To hold PDL as
a design benchmark instead doesn't seem quite right.
Rgds
Anthony
Re: How do I... create a new meta operator?
HaloO Luke,
you wrote:
I wonder how we specify meta
operators that only work on comparators, or only on assignment forms,
or etc. etc. etc.
Well, Perl6 has got first class Code types, hasn't it?
So it's a matter of defining a type hierarchy among the
operators and then you can dispatch on them with MMD or
restrict applicable types for non-invocant params.
Ingo's infix_circumfix_meta_operator:{'-', '-'}:(Code,Any,Any:)
could then easily be specialized like
infix_circumfix_meta_operator:{'-', '-'}
:(Comparator of ::T, T does Compare[T], T does Compare[T] :)
or less specific, of course.
The above said, I hope that the degree to which meta ops are
macro/compiler supported versus how much they lean onto the
type system is favoring the type system. The typical Perl 6
programmer seems for historical reasons more inclined to think
about this language feature more in terms of combinations of
eval, join and split. E.g. could the macro assistence for »« and []
be restricted to parse their inside as an operator name so that
the programmer doesn't have to use their long name? Or is something
more complicated needed? And if yes, then why?
Regards,
--
TSa (Thomas Sandlaß)
Re: reduce metaoperator on an empty list
Mark == Mark A Biggar [EMAIL PROTECTED] writes:
Mark The usual definition of reduce in most languages that support it, is
Mark that reduce over the empty list produces the Identity value for the
Mark operation.
In Smalltalk, the equivalent of reduce is inject:into:, so a
sum reduce looks like:
sum := aList inject: 0 into: [:previous :this | previous + this]
Now the advantage here is that if aList is empty, we get back the inject
value. Thus, the behavior is always well-defined.
The Perl reduce operator treats the first element of the list as the
inject value above. However, if the first element is missing,
the most Perlish thing I can think of is having it return undef,
because it's like you've specified an undef inject value.
I'd also argue that we could provide .inject_into, to make Smalltalkers
happy to always spell out the initial value and codeblock, instead
of relying on the first element of the list for the initial value.
For example, if I wanted the identity hash (where all values are 1,
but keys are original list elements), I could do:
my %hash = @somelist.inject({}, { $^a{$^b} = 1; $^a });
That'd be Way Cool. Once you get your head around inject, you never
want to go back to reduce. :)
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
merlyn@stonehenge.com URL:http://www.stonehenge.com/merlyn/
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: reduce metaoperator on an empty list
John Macdonald wrote:
... (and there may be additional
operator attributes that make sense there too, although none
come immediately to mind).
Well, I wonder why people neglect the fact that the neutral/identity
element is not a property of the operator alone?! Besides the
associativity and commutativity of the operator the inverse
element---or the left and right one---with respect to the
underlying representation come at least to my mind :)
This would give an axiomatic type system:
class Num does Group[Num,+,0] {...}
class Num does Field[Num,+,0,*,1] {...}
class Str does Monoid[Str,~,''] {...}
class Complex does Field[Array[2] of Num,+,[0,0],*,[1,0]] {...}
class 3DVector does VectorSpace[Array[3] of Num,+,[0,0,0]] {...}
And it provides valuable information to the optimizer.
--
TSa (Thomas Sandlaß)
Re: reduce metaoperator on an empty list
John Macdonald wrote: Is there a built-in operator that doesn't have a meaningful identity value? I first thought of exponentiation, but it has an identity value of 1 - you just have to realize that since it is a right associative operator, the identity has to be applied from the right. Well the identity of % is +inf (also right side only). The identities for ~| and ~^ are infinitely long bitstrings of 0's, while that for ~ is a similarly long bitstring of 1's. The chained comparison ops are weird as depending of which why you define the associativity (and thus which side's value you return when true) you get either a left side only or right side only Identity. E.g. if XY is left associative and returns Y when true then it has a left side identity of -inf, etc. But as I'm not sure if the chained ops are actually going to be defined defined in terms of the associativity of the binary op (the way false results propagates through messes things up), so that argument may not work. -- [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: reduce metaoperator on an empty list
Mark A. Biggar wrote: Well the identity of % is +inf (also right side only). I read $n % any( $n..Inf ) == $n. The point is there's no unique right identity and thus (Num,%) disqualifies for a Monoid. BTW, the above is a nice example where a junction needn't be preserved :) E.g. if XY is left associative and returns Y when true then ... Sorry, is it the case that $x = $y $z might put something else but 0 or 1 into $x depending on the order relation between $y and $z? -- TSa (Thomas Sandlaß)
lazy context
Hola,
Some of us on #perl6 bitched once more about how lazy will make our
IO brain hurt a lot.
The concensus is that a lazy context has not been discussed yet.
Here is a proposal for lazyness defined with coroutines.
we have a lazy modifier:
my $a = lazy { get_value(5, 10) };
my @array = lazy gather { ... take ... };
What it returns is a proxy object that vivifies to a true value, or
in the case of list context lazy, a proxy object array that
implements a generator.
The rvalue of the lazy context modifier is turned into a coro
closure, and is invoked only when the value is accessed.
Moreover, in lazy context, if the coro yields instead of finishing,
then it is not finalized into a real value. Here's how the range
operator would be implemented:
sub infix:.. ($from, $to where { $to $from }){ reverse $to ..
$from }
sub infix:.. ($from, $to) { lazy gather {
while ($from = $to) {
take($from++);
}
}}
In this case, take in lazy context gather would yield.
The only builtin feature that needs to be added is that coroutines
can masquerade as their return value, and not a code reference, but
AFAIK proxy objects will give us that anyway, right?
--
() Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker
/\ kung foo master: /me wields bonsai kittens: neeyah
pgpiaSDtG8T6t.pgp
Description: PGP signature
Re: How do I... invoke a method reference
C. Scott Ananian wrote:
I think Ingo was trying to explicitly specify the normally-implicit
invocant; ie, invoke the method via the reference *without* using a '.'.
If this is possible (and I think it is), it's not (yet) clear what the
syntax would be. Maybe
$ref(Foo.new():)
I think for MMD calls no : is needed. The dispatcher should find the best
match for the complete set of args anyway. The problem is to hit the
intended recipient when there's no argument other than $_ which was just
recently re-instated as the default invocant. Even though a simple $ref.()
might know from the type of $ref which is 'Ref of Method of Foo', to
invoke a method on $_, I would expect a type error unless $_ happens to
refer to a subtype of Foo.
Since Ingo's simple example doesn't need an invocant at all the following
might work
class Foo
{
method bar(Any:) { 42 }
method baz() { bar }
}
But I think it's better to make bar a sub.
--
TSa (Thomas Sandlaß)
Re: Complex Arithmetic
On Thursday 19 May 2005 09:39, Luke Palmer wrote: On 5/19/05, Edward Cherlin [EMAIL PROTECTED] wrote: It turns out that the domain and range and the location of the cut lines have to be worked out separately for different functions. Mathematical practice is not entirely consistent in making these decisions, but in programming, there seems to be widespread agreement that the shared definitions used in the APL, Common LISP, and Ada standards are the best available. Do we want to get into all of this in Perl6? I'm not really sure I know what you mean by do we want to get into all of this?. If we're going to have a Complex class, we have to. But getting into it might involve saying that APL, CL, and Ada are the best, so we use those. This is the kind of problem where, if someone wants to get more precise, they turn to CPAN. Luke Math::Complex - complex numbers and associated mathematical functions http://cpan.uwinnipeg.ca/htdocs/perl/Math/Complex.html lists the complex functions, but with no information given there on domain, range (principal values), and branch cuts. The APL standard costs $350 from ANSI or 260 Swiss Francs from ISO, but the Common Lisp Hyperspec is available online for free. http://www.lispworks.com/documentation/HyperSpec/ as is the Ada Reference Manual. The CL and Ada definitions are incomplete. I'll have to find a copy of the APL standard. log(z) CL Hyperspec: The branch cut for the logarithm function of one argument (natural logarithm) lies along the negative real axis, continuous with quadrant II. The domain excludes the origin. Thus the range would be defined as -pi Im(log(z)) = pi sin(z) CL Hyperspec: Not defined for complex arguments. Ada RF says: The functions have their usual mathematical meanings. However, the arbitrariness inherent in the placement of branch cuts, across which some of the complex elementary functions exhibit discontinuities, is eliminated by the following conventions: (13) * The imaginary component of the result of the Sqrt and Log functions is discontinuous as the parameter X crosses the negative real axis. (14) * The result of the exponentiation operator when the left operand is of complex type is discontinuous as that operand crosses the negative real axis. (15) * The real (resp., imaginary) component of the result of the Arcsin and Arccos (resp., Arctanh) functions is discontinuous as the parameter X crosses the real axis to the left of -1.0 or the right of 1.0. (16) * The real (resp., imaginary) component of the result of the Arctan (resp., Arcsinh) function is discontinuous as the parameter X crosses the imaginary axis below -i or above i. (17) * The real component of the result of the Arccot function is discontinuous as the parameter X crosses the imaginary axis between -i and i. (18) * The imaginary component of the Arccosh function is discontinuous as the parameter X crosses the real axis to the left of 1.0. (19) * The imaginary component of the result of the Arccoth function is discontinuous as the parameter X crosses the real axis between -1.0 and 1.0. (20) The computed results of the mathematically multivalued functions are rendered single-valued by the following conventions, which are meant to imply the principal branch: (21) * The real component of the result of the Sqrt and Arccosh functions is nonnegative. (22) * The same convention applies to the imaginary component of the result of the Log function as applies to the result of the natural-cycle version of the Argument function of Numerics.Generic_Complex_Types (see G.1.1). (23) * The range of the real (resp., imaginary) component of the result of the Arcsin and Arctan (resp., Arcsinh and Arctanh) functions is approximately -Pi/2.0 to Pi/2.0. (24) * The real (resp., imaginary) component of the result of the Arccos and Arccot (resp., Arccoth) functions ranges from 0.0 to approximately Pi. (25) * The range of the imaginary component of the result of the Arccosh function is approximately -Pi to Pi. -- Edward Cherlin Generalist activist--Linux, languages, literacy and more A knot! Oh, do let me help to undo it! --Alice in Wonderland http://cherlin.blogspot.com
Re: hyperoperators and multi-dimensional datastructures
On Thursday 19 May 2005 12:48, Uri Guttman wrote: LP == Luke Palmer [EMAIL PROTECTED] writes: LP On 5/18/05, Anthony Heading [EMAIL PROTECTED] wrote: Is there a way to target hyperoperators at different axes of a multi-dimensional array? This is an attractive feature of various APL-like languages, viz. e.g. in J: a =. 2 5 $ i. 7 - a simple 2-by-5 array a 0 1 2 3 4 - like this 5 6 0 1 2 +/1 a - sum reduce over axis 1 10 14 That is, break the array into rows, and reduce each row. LP [+] @a +/2 a - sum reduce over axis 2 5 7 2 4 6 Actually, that's sum reduce over planes, which gives the default behavior when applied to a single plane, of breaking the plane into rows, and adding the rows to each other. The result is the same as from +/a . The rank conjunction () is tersely explained at http://www.jsoftware.com/books/help/dictionary/intro20.htm and more fully in The J Primer, J for C Programmers, and other online publications at http://www.jsoftware.com/publications_books.htm LP Can't think of any for this one. Or maybe it's this one that I can LP think of it for, and the other one which I can't. i can't spit out the syntax but here is the conceptual way i would do it. we do have multidimensional slices so we could grab each slice (maybe with zip?) and pass that to [+] and then grab the list of results back into a array/matrix with one less dimension than the original. Exactly how Iverson conceived rank for reduction. so it would be something like this: (very wacko pseudo code): @in[ * ; 2 ; * ] == map [+] == @out that was an (bad) attempt to slice the third entry in the second dimension to be summed. You might find it useful to examine this published source code for an early version of J http://www.math.uwaterloo.ca/apl_archives/j/early_j/src/j7/ to see how Iverson's crew implemented rank. The numbering is confusing, because they restarted at some point, so J5.0.4 is current. LP I think we're beginning to re-invent PDL. APL and J, too. Poorly. Amen. but is there a p6 pdl yet? they may not need much with multi-dim ops, slices, hyper and reduce all built in! also with type int (patform ints), they can get the dense storage needed (but losing any dimensional flexibility). uri -- Edward Cherlin Generalist activist--Linux, languages, literacy and more A knot! Oh, do let me help to undo it! --Alice in Wonderland http://cherlin.blogspot.com
Re: [unclassified] Re: reduce metaoperator on an empty list
On Thursday 19 May 2005 19:51, Sam Vilain wrote: Edward Cherlin wrote: Here is the last answer from Ken Iverson, who invented reduce in the 1950s, and died recently. file:///usr/share/j504/system/extras/help/dictionary/intro28 .htm http://www.jsoftware.com/books/help/dictionary/intro28.htm Sorry. It's exactly the same material the provide with their software, so I got confused. [snip] Thanks for bringing in a little history to the discussion. Those links are all local to your system; do you have internet reachable versions of them? Cheers, Sam. -- Edward Cherlin Generalist activist--Linux, languages, literacy and more A knot! Oh, do let me help to undo it! --Alice in Wonderland http://cherlin.blogspot.com
Re: lazy context
On Fri, 20 May 2005, Yuval Kogman wrote:
then it is not finalized into a real value. Here's how the range
operator would be implemented:
sub infix:.. ($from, $to where { $to $from }){ reverse $to ..
$from }
sub infix:.. ($from, $to) { lazy gather {
while ($from = $to) {
take($from++);
}
}}
This is very elegant. It might be worthwhile for someone to attempt to
define a 'core perl' set of operators, etc, so that the 'rest of perl' can
be defined in perl proper...
--scott
Pakistan FBI assassination Israel AVBUSY BATF ODEARL [Hello to all my fans in domestic surveillance]
interception domestic disruption KMFLUSH ODENVY IDEA DES MI5 arrangements
( http://cscott.net/ )
Re: lazy context
On Fri, May 20, 2005 at 05:15:24PM -0400, C. Scott Ananian wrote:
On Fri, 20 May 2005, Yuval Kogman wrote:
then it is not finalized into a real value. Here's how the range
operator would be implemented:
sub infix:.. ($from, $to where { $to $from }){ reverse $to ..
$from }
sub infix:.. ($from, $to) { lazy gather {
while ($from = $to) {
take($from++);
}
}}
This is very elegant. It might be worthwhile for someone to attempt to
define a 'core perl' set of operators, etc, so that the 'rest of perl' can
be defined in perl proper...
It may be fairly tough to identify what's core and what isn't.
But in general I'd propose that if something can be easily and
efficiently defined as a perl 6 sub or method, then let's at least
document it that way (if not actually implement it that way) and
later we'll optimize the things that need optimizing.
Pm
Re: lazy context
On Fri, May 20, 2005 at 17:15:24 -0400, C. Scott Ananian wrote: This is very elegant. It might be worthwhile for someone to attempt to define a 'core perl' set of operators, etc, so that the 'rest of perl' can be defined in perl proper... Have a look at synopsis 29... For documentation purposes it implements lots of perl 6's non-core core. -- () Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker /\ kung foo master: /me groks YAML like the grasshopper: neeyah!! pgpXAWRMFPEnt.pgp Description: PGP signature
Re: reduce metaoperator on an empty list
Mark A. Biggar wrote: Well the identity of % is +inf (also right side only). I read $n % any( $n..Inf ) == $n. The point is there's no unique right identity and thus (Num,%) disqualifies for a Monoid. BTW, the above is a nice example where a junction needn't be preserved :) If as usual the definition of a right identity value e is that a op e = a for all a, then only +inf works. Besdies you example should have been; $n % any (($n+1)..Inf), $n % $n = 0. E.g. if XY is left associative and returns Y when true then ... Sorry, is it the case that $x = $y $z might put something else but 0 or 1 into $x depending on the order relation between $y and $z? Which is one reason why I siad that it might not make sense to define the chaining ops in terms of the associtivity of the binary ops, But as we are interested in what [] over the empty list shoud return , the identity (left or right) of '' is unimportant as I think that should return false as there is nothing to be less then anything else. Note that defaulting to undef therefore works in that case. -- Mark Biggar [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
