On May 13, 5:23 am, Ronan Lamy <ronan.l...@gmail.com> wrote: > Le vendredi 13 mai 2011 à 03:51 +0400, Sherjil Ozair a écrit : > > > > > > > > > > > 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. > > 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).
I think you're right if we're constrained to follow OO design. Polys is more like the structure I presented. Yours is the OO structure. But in your structure, how do you plan to encapsulate everything into one user level class ? Since (in your structure), the Data structure classes are at the bottommost level in the inheritance tree, do you expect the user to call A = DOKMatrix(...) ? Private functions should be inside the Data Structure classes (DOKMatrix, COOMatrix, etc.) ? What if one DS class needs to use a function of another DS class ? What is the purpose of the abstract base class in your structure ? Will it contain any code ? If yes, what ? I agree that my design isn't 100% OO, but I feel that OO isn't the way to go about this, similar to Polys. > > > > > > > > > [1]http://mattpap.github.com/masters-thesis/html/src/internals.html > > > -- > > You received this message because you are subscribed to the Google > > Groups "sympy" group. > > To post to this group, send email to sympy@googlegroups.com. > > To unsubscribe from this group, send email to sympy > > +unsubscr...@googlegroups.com. > > For more options, visit this group at > >http://groups.google.com/group/sympy?hl=en. -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
