458,044 Members | 1,213 Online Need help? Post your question and get tips & solutions from a community of 458,044 IT Pros & Developers. It's quick & easy.

# "indexed properties"...

17 Replies

 P: n/a En Wed, 14 May 2008 18:15:41 -0300, David C. Ullrich

 P: n/a En Wed, 14 May 2008 18:15:41 -0300, David C. Ullrich

 P: n/a In article , du******@sprynet.com says... window.pos = (x,y) seems more natural than window.SetPos(x,y); Yes, and to assign a row in a matrix I'd also like to use either tuples or lists on the right side. def __add__(self, other): return Row([x + y for x, y in zip(self, other)]) worked as hoped if self is a Row and other is a Row _or_ a list.) Anyway, my m.rows[j] can't be a list, because I want to be able to say things like m.rows += c*m.rows. Allowing m.rows[j] = [1,2,3] seems convenient, while requiring m.rows[j] = Row([1,2,3]) fixes this problem. Hmm. I'm not sure how far you'd go along with Gabriel's idea of decoupling views from data but I think there isn't even a need for using a matrix as the underlying data type. Why not use a flat list and compute matrix positions according to a row or column adressing scheme on the fly? P. Jun 27 '08 #7

 P: n/a On Sun, 18 May 2008 08:50:23 +0200, pataphor wrote: >In article ,du******@sprynet.com says... > window.pos = (x,y)seems more natural than window.SetPos(x,y); Yes, and to assign a row in a matrix I'd also like to use either tuplesor lists on the right side. Heh - in the current (flawed) implementation you can say m.row = 'Hello'; m.row= 'World!' .Not that I see why you'd want to, but that happened in the test code just to check that things were as general as I wanted - sure enough m.row + m.row comes out to ['HW', 'eo', 'lr', ''ld', 'o!']. > def __add__(self, other): return Row([x + y for x, y in zip(self, other)])worked as hoped if self is a Row and other is aRow _or_ a list.)Anyway, my m.rows[j] can't be a list, becauseI want to be able to say things likem.rows += c*m.rows. Allowingm.rows[j] = [1,2,3] seems convenient, whilerequiring m.rows[j] = Row([1,2,3]) fixesthis problem. Hmm. I'm not sure how far you'd go along with Gabriel's idea of decouplingviews from data but I think there isn't even a need for using a matrixas the underlying data type. Why not use a flat list and compute matrixpositions according to a row or column adressing scheme on the fly? 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. Hmm. It might actually _reduce_ the total amount of code, since the code to access columns has to exist anyway and rows could use the same code as columns with different "start" and "skip". And come to think of it rows and columns could be obtained just with a slice of the data. So column access might even be more efficient. But I expect that row access will happen a lot more often than column access. >P. David C. Ullrich Jun 27 '08 #8

 P: n/a In article , du******@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 :-) And to address an item in a matrix costs two lookups, row and column, while an array needs only one. P. Jun 27 '08 #9

 P: n/a On Mon, 19 May 2008 06:29:18 -0500 David C. Ullrich

 P: n/a On Tue, 20 May 2008 06:12:01 -0500 David C. Ullrich

 P: n/a In article <20080520154802.4b5df647@hyperspace>, pataphor

 P: n/a On May 20, 10:40*am, "David C. Ullrich" , *pataphor >a= {}a[0,1]= 2a[2,3]= 7a[0,1] 2 Jun 27 '08 #15

 P: n/a On Tue, 20 May 2008 10:40:17 -0500 "David C. Ullrich"

 P: n/a On Wed, 21 May 2008 12:47:44 +0200, pataphor wrote: >On Tue, 20 May 2008 10:40:17 -0500"David C. Ullrich" There is a little notational gotcha, instead of writingrow = [1,2,3] one now must write row[:] = [1,2,3] or elsesynchronicity is lost.I found a nice ListMixin class athttp://aspn.activestate.com/ASPN/Coo.../Recipe/440656Using that I wrote the following proof of concept:class Storage(ListMixin): def __init__(self, seq=[]): self.L = [[x] for x in seq] def _constructor(self, iterable): return Storage(iterable) Probably I'm just being dense. Why does _constructor exist? (Oh - looking at things below, I imagine it's something to do with ListMixin.) def __len__(self): return len(self.L) def _get_element(self, i): assert 0 <= i < len(self) return self.L[i] def _set_element(self, i, x): assert 0 <= i < len(self) self.L[i] = x def _resize_region(self, start, end, new_size): assert 0 <= start <= len(self) assert 0 <= end <= len(self) assert start <= end self.L[start:end] = [[None] for i in range(new_size)]def test(): n = 3 R = range(n) it = iter(range(n*n)) MR = [Storage(it.next() for i in R) for i in R] MC = [Storage() for i in R] T = zip(*[x.L for x in MR]) for x,y in zip(MC,T): x.L = y print MR print MC MC[:] = 'abc' print print MR print MCif __name__=='__main__': test()Output:[Storage([0, 1, 2]), Storage([3, 4, 5]), Storage([6, 7, 8])][Storage([0, 3, 6]), Storage([1, 4, 7]), Storage([2, 5, 8])][Storage([0, 1, 'a']), Storage([3, 4, 'b']), Storage([6, 7, 'c'])][Storage([0, 3, 6]), Storage([1, 4, 7]), Storage(['a', 'b', 'c'])]P. David C. Ullrich Jun 27 '08 #17

 P: n/a On Thu, 22 May 2008 06:26:41 -0500 David C. Ullrich wrote: Using the trick of encapsulating the values inside single-element lists one can make a transposition of the matrix and get synchronicity for the little price of doubling the number of instances. Since the views share the data this is a lot less expensive than one would think. One can use the row view or the column view to alter data and the changes will automatically be visible in the other view, since the views update the same lists. Oh - that's different. This is not what I thought you had in mind (it's not what I had in mind in the thing I called a joke.) The idea has two parts, the first part is to create two views and the second part is to somehow synchronize the data. To make both views update the same data is just not a very lazy synchronization procedure. Does it even have to be a list? Let's see ... No, this works as well: class Shared(object): def __init__(self,value=None): self.value = value class Storage(ListMixin): def __init__(self, seq=[]): self.L = map(Shared,seq) def _constructor(self, iterable): return Storage(iterable) def __len__(self): return len(self.L) def _get_element(self, i): assert 0 <= i < len(self) return self.L[i].value def _set_element(self, i, x): assert 0 <= i < len(self) self.L[i].value = x def _resize_region(self, start, end, new_size): assert 0 <= start <= len(self) assert 0 <= end <= len(self) assert start <= end self.L[start:end] = [Shared() for i in range(new_size)] def _constructor(self, iterable): return Storage(iterable) Probably I'm just being dense. Why does _constructor exist? (Oh - looking at things below, I imagine it's something to do with ListMixin.) I just filled in the example class. It was very handy, one can make changes very quickly because all the functionality is in a few lines of code. P. Jun 27 '08 #18

### This discussion thread is closed

Replies have been disabled for this discussion. 