Le samedi 14 mai 2011 à 08:43 -0700, Vinzent Steinberg a écrit :
> On 13 Mai, 01:54, SherjilOzair <sherjiloz...@gmail.com> 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)

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 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.

Reply via email to