And here I mis-read < as <=.
Perhaps I should stop "fixing", as I'm making too many errors here...
On 5/10/06, Markus Laire <[EMAIL PROTECTED]> wrote:
> > filter (list [<] @array) @array ==>
> > first monotonically increasing run in @array
> >
> This seems false. @array = (1 2 2
On 5/9/06, Jonathan Scott Duff <[EMAIL PROTECTED]> wrote:
On Tue, May 09, 2006 at 06:07:26PM +0300, Markus Laire wrote:
> ps. Should first element of scan be 0-argument or 1-argument case.
> i.e. should list([+] 1) return (0, 1) or (1)
I noticed this in earlier posts and thought it odd that anyo
In the previous mail I accidentally read [<=] as [>=]
On 5/10/06, Markus Laire <[EMAIL PROTECTED]> wrote:
> > 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?
On 5/10/06, Austin Hastings <[EMAIL PROTECTED]> wrote:
Mark A. Biggar wrote:
> 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 increasi
l you found one that differed.
I think the one thing that is redeeming scans in this case is the (my?)
assumption that they are automatically lazy.
The downside is that they aren't random-access, at least not in 6.0. I
expect that
@scan ::= list [==] @array;
say @scan[12];
will have
Austin Hastings wrote:
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, th
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
Mark A. Biggar writes:
> Austin Hastings wrote:
>
> > Gaal Yahas wrote:
> >
> > > list [==] 0, 0, 1, 2, 2;
> > > # bool::false?
> > > # (bool::true, bool::true, bool::false, bool::false, bool::false)
> >
> >(And I'm with Smylers on this one: show me a useful example, please.)
>
Gaal Yahas writes:
> On Tue, May 09, 2006 at 11:23:48AM +0100, Smylers wrote:
>
> > So I have the list generated by the scan. And? What do I do with
> > it? I can't think of any situation in my life where I've been
> > wanting such a list.
>
> Scans
On Tue, May 09, 2006 at 06:07:26PM +0300, Markus Laire wrote:
> ps. Should first element of scan be 0-argument or 1-argument case.
> i.e. should list([+] 1) return (0, 1) or (1)
I noticed this in earlier posts and thought it odd that anyone
would want to get an extra zero arg that they didn't spec
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 reduc
Markus Laire wrote:
ps. Should first element of scan be 0-argument or 1-argument case.
i.e. should list([+] 1) return (0, 1) or (1)
APL defines it as the later (1).
--
[EMAIL PROTECTED]
[EMAIL PROTECTED]
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 reduc
On 5/9/06, Austin Hastings <[EMAIL PROTECTED]> wrote:
Gaal Yahas wrote:
> 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::f
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 c
On Tue, May 09, 2006 at 11:23:48AM +0100, Smylers wrote:
> So I have the list generated by the scan. And? What do I do with it?
> I can't think of any situation in my life where I've been wanting such a
> list.
Scans are useful when the intermediate results are interesting,
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 lov
Markus Laire writes:
> On 5/9/06, Smylers <[EMAIL PROTECTED]> wrote:
>
> > But this could just be because I don't (yet) grok scans.
>
> Here's a simple example:
>[+] 1,2,3,4,5
> would return scalar 1+2+3+4+5 as a reduction and list (0, 1, 1+2,
>
On 5/9/06, Smylers <[EMAIL PROTECTED]> wrote:
But this could just be because I don't (yet) grok scans.
Here's a simple example:
[+] 1,2,3,4,5
would return scalar 1+2+3+4+5 as a reduction and list (0, 1, 1+2,
1+2+3, 1+2+3+4, 1+2+3+4+5) as a scan. (0 comes from [+](),
Larry Wall writes:
> On Mon, May 08, 2006 at 05:30:23PM +0300, Gaal Yahas wrote:
>
> : We have a very nifty reduce metaoperator. Scans are a counterpart of
> : reduce that are very useful -- they are the (preferably lazy) list
> : of consecutive accumulated reductions up to t
On Mon, May 08, 2006 at 05:30:23PM +0300, Gaal Yahas wrote:
: We have a very nifty reduce metaoperator. Scans are a counterpart of
: reduce that are very useful -- they are the (preferably lazy) list of
: consecutive accumulated reductions up to the final result. But I can't
: think
Gaal Yahas skribis 2006-05-08 17:58 (+0300):
> (Is there special sugar to make @input be the last index when used in a
> range, or did you mean ..^ ?)
I meant @input.last, or probably @input.indices (or .keys?) instead of
the entire range, and @input.first instead of the first 0.
Juerd
--
http:
On Mon, May 08, 2006 at 04:44:51PM +0200, Juerd wrote:
> To make sure I understand what you mean, not as a proposed
> implementation:
>
> my @input = (...);
> my @scan = map { [op] @input[0..$_] } [EMAIL PROTECTED];
>
> Is this what you mean?
>
> Hm, could that be written as:
>
> my
Gaal Yahas skribis 2006-05-08 17:30 (+0300):
> We have a very nifty reduce metaoperator. Scans are a counterpart of
> reduce that are very useful -- they are the (preferably lazy) list of
> consecutive accumulated reductions up to the final result. But I can't
> think of a
We have a very nifty reduce metaoperator. Scans are a counterpart of
reduce that are very useful -- they are the (preferably lazy) list of
consecutive accumulated reductions up to the final result. But I can't
think of a convenient way of expressing scans in Perl 6.
I'm probably not thi
25 matches
Mail list logo
