Le jeudi 12 mai 2011 à 18:41 -0700, SherjilOzair a écrit : > > 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(...) ?
Yes, if the user wants a DOKMatrix, he should get one. > 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 ? If one class needs to use a method of another, then either the method should be public or the classes should both inherit the method from a common ancestor. > > What is the purpose of the abstract base class in your structure ? To define the interface common to all classes. > Will it contain any code ? If yes, what ? It can contain default implementations that work for all subclasses but could be overridden more efficiently in some. > 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. Object-oriented design is the way to go whenever you think of something in terms of objects. And your design is actually quite object-oriented anyway - name-mangling with a class name is one way of doing OOD in C. > > > > > > > [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.
