"indexed properties"...

[David C. Ullrich]

On Sun, 18 May 2008 18:18:34 +0200, pataphor <pataphor at gmail.com>
wrote:

>In article <dtb03495i4isn8oi89i8fpe7p8dif7cct6 at 4ax.com>, 
>dullrich at sprynet.com says...
>
>> Is there some reason that would be better? It would make a lot
>> of the code more complicated. Ok, it would require only one
>> bit of added code, I suppose, but I don't see the plus side.
>
>The plus side is you give up an untenable position :-) 

Maybe you could be more specific? Various "positions" I've
taken in all this may well be untenable, but I can't think
of any that have anything to do with whether the data should
be a single list instead of a list of lists.

(The only way I can parse this to make it relevant is to
assume that the position you're referring to is that a
list of lists is better than a single list. If so: First, I
haven't said that it was. Second, saying "B is untenable"
is not much of an answer when someone asks why you
say A is better than B.)

>And to address an 
>item in a matrix costs two lookups, row and column, while an array needs 
>only one. 

The phrase "premature optimization" springs to mind.

This is _Python_ we're talking about. Supposing you're right that
doing two lookups _in Python_ is faster than doing one lookup
plus the calculuation col + row*width _in Python_, it can't
make enough difference to matter. In the sort of application I
have in mind things already happen "instantaneously".

The point is not to improve on NumPy. Trying to improve on
NumPy in pure Python code would be silly - if I wanted
optimized large matrices I'd _use_ NumPy. The point is just
to give a simple "intuitive" way to manipulate rows and
columns in small matrices. 

So I'm not looking ahead to the future, things are not
scalable? The thing is not _supposed_ to scale up to
large matricies. If a person were dealing with large
matricies then almost all of it would need to be
rewritten (and if a person were dealing with really
large matrices then trying to do the thing in pure
Python would be silly in the first place, and insisting
on being able to write things like "m.row[0] =
m.row[1] + m.row[2]" could very well be a totally
wrong approach to begin with - I'd figure out the
operations I expected to need to do and write functions
to do them.)

Really. In one of the intended applications the matrix
entries are going to be home-made Rationals. Just
adding two of those guys takes a long time. It's
still more than fast enough for the intended application,
but [oh, never mind.

Sorry about the argumentative tone - I _would_ like
to know which "untenable position" you're referring to...

>P.

David C. Ullrich