Mark A. Biggar wrote:
Austin Hastings wrote:
Gaal Yahas wrote:
On Mon, May 08, 2006 at 04:02:35PM -0700, Larry Wall wrote:
: I'm probably not thinking hard enough, so if anyone can come up
with an
: implementation please give it :) Otherwise, how about we add
this to
: the language?
Maybe that's just what reduce operators do in list context.
I love this idea and have implemented it in r10246. One question
though,
what should a scan for chained ops do?
list [==] 0, 0, 1, 2, 2;
# bool::false?
# (bool::true, bool::true, bool::false, bool::false, bool::false)
Keeping in mind that the scan will contain the boolean results of the
comparisons, you'd be comparing 2 with "true" in the later stages of
the scan. Is that what you intended, or would ~~ be more appropriate?
(And I'm with Smylers on this one: show me a useful example, please.)
Well the above example does tell you where the leading prefix of equal
values stops, assuming the second answer.
That's a long way to go...
Combined with reduce it gives some interesting results:
[+] list [?&] @bits ==> index of first zero in bit vector
Likely to win the obfuscated Perl contest, but ...?
There are other APLish operators that could be very useful in
combination with reduce and scan:
the bit vector form of grep (maybe called filter);
filter (1 0 0 1 0 1 1) (1 2 3 4 5 6 7 8) ==> (1 4 6 7)
This is really useful if your selecting out of multiple parallel arrays.
Okay, this begins to approach the land of useful. If there's a
faster/better/stronger way to do array or hash slices, I'm interested.
But the approach above doesn't seem to be it.
Use hyper compare ops to select what you want followed by using filter
to prune out the unwanted.
filter gives you with scan:
filter (list [<] @array) @array ==>
first monotonically increasing run in @array
This seems false. @array = (1 2 2 1 2 3), if I understand you correctly,
yields (1 2 2 3).
filter (list [<=] @array) @array ==>
first monotonically non-decreasing run in @array
So @array = (1 0 -1 -2 -1 -3) ==> (1, -1) is monotonically non-decreasing?
That was 5 minutes of thinking.
I'm thinking that APL is dead for a reason. And that every language
designer in the world has had a chance to pick over its dessicated
bones: all the good stuff has been stolen already. So while "scans" may
fall out as a potential side-effect of reduce, the real question should
be "are 'scans' useful enough to justify introducing context sensitivity
to the reduce operation?"
=Austin
