On 14 Mai, 20:56, Ronan Lamy <ronan.l...@gmail.com> wrote: > 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
This is an interesting idea, however it is more verbose than "method='LU'" and less flexible. There are solver algorithms which don't explicitly calculate the factorization to solve the system. But thinking about it, this could be abstracted away by Decomposition(), so that it only calculates the factorization when explicitly asked and only stores the necessary information to solve the system. 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.
