-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sean Carley wrote:
> The thing is, I believe you should never optimize prematurely.
> Without specific data telling me my solution is too slow, I would
> almost never rewrite it to be faster.  I would make changes to 
> make things more clear but not to make them faster.  I wouldn't
> optimize until I knew the speed requirements.

Ah, good approach. :) I keep hearing about this, but it's hard for
me after being ruined by years of C programming.

> For example, if the client came back and said we need to complete
> the pascal triangle of 1000 in under 10 seconds, then I would
> start profiling to find out how to make that happen.

This is more of the situation I was thinking of: "How does this
implementation scale to large triangles?"

In this implementation, nth_row is called n+1 times for a given n.
That's fine if nth_row had a constant access time O(1). However,
nth_row(x) recursively calls itself x-1 times. So the upper bound of
computation for a triangle with n rows is:
	O((n rows) * (x-1 recursions per row)) = O(n**2)

This motivated me to suggest caching in your implementation, so that
you could bring down the execution time to O(n).
- --
BASIC is to computer programming as QWERTY is to typing.
                -- Seymour Papert
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEoZBAmV9O7RYnKMcRAslaAJ42EM31xC9/ZCKR/wblNT+/PgaJpACgr/H8
Zm9068I7/fwBgbI7DPIUCSI=
=tAFw
-----END PGP SIGNATURE-----