That makes sense -- it would be nice to have Parakeet be fast for iterative
applications.

Let's go ahead and merge the example changes separately and we can work on
the optimization stuff.


On Wed, May 7, 2014 at 2:53 PM, MaggieQi <notifications@github.com> wrote:

> In spartan/expr/local.py:
>
> > @@ -164,13 +166,27 @@ def pretty_str(self):
> >      return 'parakeet_op'
> >
> >    def evaluate(self, ctx):
> > +    if len(self.op_map) == 0:
>
> Hi, Russell, I find that when we do optimization on iterative
> applications, parakeet will compile the code in each iteration since the
> key_id in the code changes in each iteration. I have tried to fix this bug
> when we construct the parakeet operation. However, since the position of
> each child in the children list may change in different iteration, we can
> hardly give the right parameters for the parakeet function call. Ok, I will
> move the local.py and optimize.py into a separate pull request so that we
> can think it more clearly. 2014-05-07 13:51 GMT-04:00 Russell Power <
> notifications@github.com>:
> … <#145d8ad34455fb74_>
>  In spartan/expr/local.py: > @@ -164,13 +166,27 @@ def pretty_str(self): >
> return 'parakeet_op' > > def evaluate(self, ctx): > + if len(self.op_map)
> == 0: What's going on with op_map? It looks like we build it up by search
> for the key_* variables in the source code string; then we don't need it to
> be an instance variable, right? Should we instead build it when we
> construct the parakeet operation? — Reply to this email directly or view it
> on GitHub<
> https://github.com/spartan-array/spartan/pull/150/files#r12391375> .
>  -- Chen Qi Department of Computer Science School of EECS Peking
> University
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/spartan-array/spartan/pull/150/files#r12405182>
> .
>