caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Bill Wood <william.wood3@comcast.net>
To: Erik de Castro Lopo <mle+ocaml@mega-nerd.com>
Cc: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] Generators/iterators and lazy evaluation?
Date: Wed, 04 Apr 2007 17:55:20 -0500	[thread overview]
Message-ID: <1175727321.21360.9.camel@localhost> (raw)
In-Reply-To: <20070405071652.bcb9be46.mle+ocaml@mega-nerd.com>

On Thu, 2007-04-05 at 07:16 +1000, Erik de Castro Lopo wrote:
> Alain Frisch wrote:
> 
> > I think you cannot implement this notion of iterator without some kind
> > of control flow operator (at runtime) or some code rearrangement (at
> > compile time). The point is that you must mainting several active
> > "threads" of computations, including their own stack.
> 
> Alain, I think you may have misunderstood Python's yeild operator.
> Typically the original poster's pow2 generators would be used like:
> 
>     for p = pow2 (10):
>         print p
> 
> but I really don't see how laziness Python's generators actually
> provide any benefit for this problem over the more obvious Python 
> solution to this which is:
> 
>     for i = range (10):
>         p = 2 ^ i
>         print p
> 

I think the motivation was to treat the memory issues with the "range"
function, which is most often used to implement "for" loops (range(N)
returns the list [0, ..., N-1]).  People complained about a control
structure allocating memory linear in the depth of the loop, so "xrange"
was created; it generates the items of the list one at a time rather
than all at once.  Further releases of Python generalized to iterators
and generators.  It does make a difference too.  Somebody wrote a Sieve
of Eratosthenes using Python's high-level list operators; it blew up on
fairly small arguments.  I wrote a straight-forward Sieve using indexing
into a static array, with reasonable time performance.  I then rewrote
it using an iterator and got analogous time performance (roughly a
factor of 2 penalty), without statically allocating the entire sieve
first.


  parent reply	other threads:[~2007-04-04 22:55 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-04 16:33 Raj B
2007-04-04 20:10 ` [Caml-list] " Mathias Kende
2007-04-04 20:46 ` Alain Frisch
2007-04-04 21:16   ` Erik de Castro Lopo
2007-04-04 21:37     ` Erik de Castro Lopo
2007-04-04 22:55     ` Bill Wood [this message]
2007-04-05  2:49     ` skaller
2007-04-05 16:41     ` Richard Jones
2007-04-04 23:53 ` Jon Harrop
2007-04-05  3:13   ` Erik de Castro Lopo
2007-04-05  5:58   ` Alain Frisch
2007-04-05 20:35     ` Jon Harrop

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1175727321.21360.9.camel@localhost \
    --to=william.wood3@comcast.net \
    --cc=caml-list@yquem.inria.fr \
    --cc=mle+ocaml@mega-nerd.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).