On Sun, May 15, 2011 at 12:26 AM, Ronan Lamy <[email protected]> wrote:
> Le samedi 14 mai 2011 à 08:43 -0700, Vinzent Steinberg a écrit : > > On 13 Mai, 01:54, SherjilOzair <[email protected]> wrote: > > > Did I leave anything Vinzent ? > > > > I think we should also talk about the future of the matrix module (and > > a possible refactoring), so that we have a clear vision of the design > > when the official coding starts. For example, I'm not really happy > > with the current code (everything in one file in one class) and the > > current interface (A.LUsolve(b) for example). > > Yes, having everything in one file is inconvenient. > > For A.LUsolve(b), here's an idea. I think that it should be something > like linear_solve(A, b) instead. It should be up to sympy to figure out > what the best solving method is. If users want more control, they could > use: > >>> A_LU = A.Ludecomposition() > >>> linear_solve(A_LU, b) > I don't understand the logic behind this. Is A_LU user-usable ? For example what would print A_LU give ? How does it relate to the current class structure of Sympy ? Does it subclass Basic ? The answer is probably 'no'. Why give the user something of which he has no use ? Why not a kwarg ? I think the check `if method="LU":` is as fast as `if isinstance(A_LU, LUDecomposition):`. What advantage does a special wrapper class just for this have ? > > Note that I am NOT suggesting adding a method='LU' kwarg, using the LU > algorithm is implicitly specified by the fact that A_LU is some kind of > LUDecomposition object (probably just a wrapper around a (L, U, p) > tuple). If users type 'linear_solve', they're only interested about the > result. If they care about the LU decomposition, then they should get it > explicitly > > > > > Ronan wrote: > > > By turning naturally OO code into procedural, you lose a lot in > readability > > > and developer productivity. > > > > Well, under the hood (on the lowest level) you have some (specialized) > > algorithm that operates on some data structure. I fail to see how this > > is naturally OO. About abstracting between the different types of data > > representation I agree, you have a point. But isn't this compatible > > with such a model? You can have your OO approach on a higher level, on > > the lowest level you have specialized routines (you called it "private > > helpers and specialised manipulation methods") that cannot be > > abstract, thus defeating the advantage of OO IMHO. Do you think it > > would be better to have them inside the class rather than separated? > > If you're thinking in terms of data structures and operations on them, > then you're considering them as objects, with clear boundaries. The > natural way of representing them in Python is to write a class and > implement the operations as methods of that class. > > I'm not sure what you mean about "routines that cannot be abstract", but > if you're saying that it doesn't really make sense for a subclass of > Matrix to have, for instance, dict manipulation methods, I tend to > agree. The data structures should probably be attributes of the matrix > class, rather than be the matrix class itself. So we should have: > > class DOKMatrix(...): > def __init__(self, key_dict, ...): > self.dok = DOK(key_dict) > ... > > def __iadd__(self, other): > ... > self.dok.update(other.dok) > ... > > but not this: > > def _update(self, dic): > self.dok.update(dic) > > > > > > > > If that wasn't the case, we'd all be using > > > only C - after all, it can do everything Python does, can't it? > > > > You could as well say that BF does everything that Python does. > > > > > Making high-level decisions based on micro-optimisation concerns is > very > > > much "premature optimisation", I think. > > > > I think it is not only about micro-optimization, but also about a > > clear code separation. But let's hear more opinions about this. > > > > > The lowest level is the implementation, not the interface. The > > > interface, even if it's low-level, should be designed independently. > > > > What do you mean? The different parts of the implementation obviously > > have to interact with each other. > > If it's only for internal use, then it's not an interface. And if it's > meant to be used from the outside, then it should be designed as such. > The purpose of a low-level interface is to abstract away details that > happen at a lower level. So if you have an operation that combines data > structures in some specified ways, you should be able to call a single > function or method to do it, and it will take care of whatever tedious > bookkeeping is required. > > > > I don't think lessons learned from writing kernel code in C apply > > > directly to high-level Python code. > > > > (IIRC his point was more general than only about kernel development.) > > > > > 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 assume that OO code is always better than procedural code. I don't > > think everyone agrees. > > > > 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. > > -- 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.
