On Sun, 18 May 2008 18:18:34 +0200, pataphor <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>, >[EMAIL PROTECTED] 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 -- http://mail.python.org/mailman/listinfo/python-list
