Le vendredi 13 mai 2011 à 10:47 -0700, Vinzent Steinberg a écrit : > On 13 Mai, 03:23, Ronan Lamy <[email protected]> wrote: > > > Hello everyone, > > > > > I took ideas from mattpap's thesis at [1], specifically the idea of > > > multi level structure. > > > > > The hierarchy I have in mind is > > > > > Level 0 : A collection of functions that operate on groundtypes(GMPY, > > > Python, Sympy). > > > Functions of this layer will receive the Matrix data as arguments. > > > Function names will be prefixed with identifiers as to which data > > > structure it works on. > > > This layer is unaware of Matrix classes. > > > Functions of this level can only call functions of the same level. > > > All the algorithms for factorization, etc. will be implemented in this > > > level. > > > > > Level 1 : A collection of classes like DOKMatrix, COOMatrix, > > > DenseMatrix, etc. > > > The data structure is defined in this class. > > > This class will have user functions which use the functions of level > > > 0. > > > > > Level 2 : The Matrix class > > > These class which will return one of the class of level 1 using the > > > __new__ function. > > > > > This idea is still unformed. I invite comments to help me evolve this > > > idea. > > > Ask if you feel something is not clear. > > > > Frankly, that's a bad idea. Object-oriented design was invented to be > > able to write M.do_stuff() instead of COOMatrix_do_stuff(M). Choosing to > > use the latter in Python is absurd and inefficient - in a word, > > unpythonic - because you'll waste a lot of time and brain power doing > > stuff the interpreter could do for you while missing out on optimisation > > opportunities since your code is less readable and less modular. > > Well, the low-level interface can be cumbersome for performance's > sake. (At least this is what I read in a presentation by Alex Martelli > you recently posted, so it must be true! ;)
The lowest level is the implementation, not the interface. The interface, even if it's low-level, should be designed independently. > And procedural code is faster in Python than OO. If you're into micro-optimisation and everything else being equal, yes, dot-lookups are expensive. But everything else is never equal. By turning naturally OO code into procedural, you lose a lot in readability and developer productivity. If that wasn't the case, we'd all be using only C - after all, it can do everything Python does, can't it? Making high-level decisions based on micro-optimisation concerns is very much "premature optimisation", I think. > I don't see why it has to be less modular. It always turns out that way, because nobody is perfect. It's already hard to maintain proper encapsulation when you have strong syntax support for that, so when you don't have it, it becomes nearly impossible. > There are people how don't believe in OO at all (Linus for example). I don't think lessons learned from writing kernel code in C apply directly to high-level Python code. > > The user will get a nice higher level OO interface. > > > At the other end, having Matrix.__new__ do weird and wonderful things > > turns it into a magic black box that can't be picked apart. > > > > The Pythonic version of your idea is to define a common interface for > > your classes in an abstract base class (= your level 2), then make your > > classes subclasses of that (= your level 1) and implement the interface > > with efficient algorithms adapted to each data structure and as many > > private helpers and specialised manipulation methods as you see fit (= > > your level 0). > > This is a valid OO approach, however I expect it to be slower. If you use a JIT (pypy) or static compilation (Cython), it shouldn't make any difference. If you factor in better code quality and productivity, OO code will actually be faster. -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
