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! ;) And procedural code is faster in Python than OO. I don't see why it has to be less modular. There are people how don't believe in OO at all (Linus for example). 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. Vinzent -- 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.
