"indexed properties"...

pataphor pataphor at gmail.com
Tue May 20 09:48:02 EDT 2008


On Tue, 20 May 2008 06:12:01 -0500
David C. Ullrich <dullrich at sprynet.com> wrote:

> Well, ok. Like I said, I never _took_ the position that it _should_
> be a list of lists, I just said I didn't see the advantage to using
> a single list.

I'm now thinking about a list of lists containing single element lists.

def test():
    n = 3
    R = range(n)
    M = [[[i+j*n] for i in R] for j in R]
    for L in M:
        print L
    row2 = M[1]
    print
    print row2
    col3 = [L[2] for L in M]
    print col3
    col3[1][0]=9

print col3
    print row2
    print
    for L in M:
        print L
        
if __name__=='__main__':
        test()

The idea is to use a single element list as kind of storage facility.
That enables me to copy a column, then change something in that column
and make the change turn up in the matrix and even in a previously made
copy of a row that shared the specific element.
 
> Today's little joke: Long ago I would have solved
> this by storing the data as a list of rows and _also_
> a list of columns, updating each one any time the
> other changed. Just goes to show you things
> could always be worse...

Well have I ever ... I only thought about this last week and I
actually thought it was a *good* idea.  I only gave up on it because
now I would have to keep  track of how far the two views are out of
sync, because some operation could use data that was modified by an
other view. Zipstar transposition is very handy for syncing, but it is
also very expensive. But probably not for you.

> Expressing interest is a big mistake...

How so? ;-)
 
> Sometime soon a thread will appear titled something
> like "indexed attributes" with a stripped-down but
> functional example of what I have in mind for Matrix

I can't wait! Keep up the good work.

P.




More information about the Python-list mailing list