Gory details (including code) follow:
Right, so I made a Python version of the polite shrub by tweaking the Pymel polite worm, and tested it against the MEL version. It’s slow, as I suspected. Real slow.

I’m learning things, also slowly. In Pymel, variable1 = variable2 doesn’t just set values; it turns variable1 into an auto-updating pointer to variable2. Why you’d want this, when you could just use variable2, I’m not sure, but knowing this has eliminated at least one embarrassing structural flaw in the code.

On the other hand, the MEL eats memory, and I smell a leak somewhere — Maya’s usage climbs steadily through the running, far more than I would have guessed necessary to store 500 strings, and if you set the number of iterations too high, it runs out of ram and bails. The Python is better-behaved, though my fears of long running times were well-founded: for 500 pyramids, the MEL took a minute 10 seconds; the Pymel took 36 minutes, finished, and crashed.

It’s not so bad for shorter runs, but the time increases exponentially: it can do 50 in 1 minute, 100 in 3, 200 in 9… etc. Toward the end of a 500-run, it can take upwards of 15 seconds to place a new cone, if it’s in a dense area.

So, yeah. It might just be the Pymel, but I suspect something’s still not quite on. Suspiciously, the Pymel also makes a more tightly-packed structure, resulting in more lithop-type near-intersections, as though the MEL’s collision detection is comparatively over-sensitive. This may be related to the longer running time of the Python: for higher iteration values, if everything’s more tightly-packed there are more pyramids to check for every growth.

Anyway. Possibly-broken code follows, set at 100 iterations, which takes about 3 minutes on my machine.

This entry was posted
on Friday, April 24th, 2009 at 6:44 pm and is filed under Code, Python.
You can follow any responses to this entry through the RSS 2.0 feed.
You can leave a response, or trackback from your own site.

2 Responses to “Polite Python shrub”

variable1 = variable2 doesn’t just set values; it turns variable1 into an auto-updating pointer to variable2.

In Python this is usually the difference between a mutable type and an immutable type. Python doesn’t have variables so much as it has labels for values. Literals are often implemented as singletons. So, if you have two variables which are the letter ‘a’ for example, you may not worry about if they are the same ‘a’ – why would you?

>>> one = 'a'
>>> two = 'a'
>>> one is two
True

This can vary depending on how you get the value.

>>> one = 'definitely'
>>> two = 'definitely not'
>>> three = two.split()[0]
>>> one
'definitely'
>>> two
'definitely not'
>>> three
'definitely'
>>> one is three
False

Ontologically the difference is between A is B and A == B. The first tests identity and the second tests equivalence.

The primary gotcha for most people with this is lists – they are mutable.

Thanks for the breakdown; my gotcha was indeed with a list. I was trying to make a copy of it, for to branch therefrom. I’m still not sure what the benefit is of essentially allowing multiple names for the same variable, but I’m sure I’ll come around.