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
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
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
On Wed, 3 Sep 2003, Uri Guttman wrote:
> IMO the simplest solution is a global
> mutex when doing any scans through the pmcs.
For the lock to be useful any and all mutators would have to aquire it, as
well as anyone reading the shared variables, since we need to keep anyone
from changi
Uri Guttman <[EMAIL PROTECTED]> wrote:
> so i don't see any major downside to a global mutex vs the nastiness of
> deadlocks and handling them. the mutex means no difficult coding issues
> and it can handle all the different (i agree with dan and vote for one
> common scan iterator) possible scan
ng is imperative and they live with deadlocks including detecting
and clearing them. but how often will we be doing
cloning/serializing/DOD scans? i feel they would only be a small
fraction of total cpu usage so IMO the simplest solution is a global
mutex when doing any scans through the pmcs. this allow
28 matches
Mail list logo
