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