[Matrix-SIG] Numeric Nits

David Ascher da@ski.org
Mon, 21 Jun 1999 22:21:25 -0700 (Pacific Daylight Time)


On Mon, 21 Jun 1999, Perry Greenfield wrote:

> The question is, is there a way for Numeric to determine that one of
> operands is a temporary?  It looks to us as if the reference count for
> a temporary result (which will be discarded after the operation) is
> smaller than for a variable operand.  If so, it should be possible for
> Numeric to reuse the temporary for the output in cases where the
> temporary is the same type and shape as the output.  Maybe there is
> something tricky here that we don't understand, but if not it seems like
> a fairly simple change would make Numeric a lot less memory-hungry.

This is an issue I've thought about a little, but alas I believe the
solution requires experience in fields I'm got a provably bad record in,
such as parsing, code tree manipulations, etc. so thinking is all I'll do
on the topic.

The problem is that there is no way to have NumPy do the detection you
mention above because the assignment process is one that Python does not
give any 'hooks' into (yet).  An alternative idea I did have is that one
could do analysis of the bytecode of specific functions and automatically
detect the patterns involved based on the lexical analysis, as long as one
limited oneself to the simple patterns.  I think that would be worthwhile,
and doable, if somewhat hackish.  One would then write things like:

def foo(x,y):
  x = x + 1
  y = y * 3
  x = x + y
  return x

foo = optimize(foo)

and the new foo would contain bytecode which would be equivalent to that
generated by an equivalent (but faster & smaller):

def foo(x,y):
  add(x, 1, x)
  multiply(y, 3, y)
  add(x, y, x)
  return x

Doing this completely is very hard.  Doing it partially (with problems of
the kind determined above) is just hard.  Someone with the right kind of
bent might find it an interesting problem, though.  Resources worth
investigating for this are bytecodehacks, Skip's pipeline optimizer, the
parser module, etc.

--david ascher