Let's discuss it here on the mailing list. Probably Mateusz will have better input about it than I will. He will be better to answer questions about implementation. I could answer questions about my potential use case.
Aaron Meurer On Sat, Jun 11, 2011 at 2:49 AM, SherjilOzair <[email protected]> wrote: > I meant the Frac class. > > On Jun 11, 1:48 pm, SherjilOzair <[email protected]> wrote: >> Aaron, it would be wonderful if we could discuss the implementation of >> the Frac function. >> >> On Jun 2, 10:37 pm, Aaron Meurer <[email protected]> wrote: >> >> >> >> >> >> >> >> > I use Matrices in the Risch algorithm. >> > Seehttps://github.com/asmeurer/sympy/blob/integration3/sympy/integrals/p.... >> > The function in the test >> > athttps://github.com/asmeurer/sympy/blob/integration3/sympy/integrals/t... >> > should give you an idea of a typical usage. >> >> > The matrices are rational functions, with possible symbolic >> > coefficients, though the computability problems for symbolic >> > coefficients is something we know we will have to deal with (see the >> > comment at the top of constant_system()). At the moment, it doesn't >> > get very large with what is implemented, but it could when more things >> > are implemented. The main things that I need to do are rref(), with >> > correctness assured with rational functions, and the ability to >> > compute null spaces (mainly with rational entries, but I suppose they >> > could be any symbolic entries). This is the only part of the Risch >> > algorithm code that uses Expr instead of Poly, since Matrix doesn't >> > work with Poly (we would need a Frac class for that). I don't like >> > how I have to manually make sure rref calls cancel to assure >> > correctness (actually, if we had Frac, I could remove a ton of calls >> > to Poly.cancel in my code). >> >> > Like Mateusz pointed out, heurisch() solves a huge linear system. The >> > sizes he gives are a little misleading, since those are only for the >> > integrals that run fast enough to be in the tests. If you try to run >> > an integral like the one from issue 1441, it hangs because of a sparse >> > system of about 600 equations in about 450 variables (put a print >> > statement in the code). >> >> > Aaron Meurer >> >> > On Tue, May 31, 2011 at 9:51 PM, Brian Granger <[email protected]> wrote: >> > > Hi, >> >> > > In sympy.physics.quantum we use sympy Matrix instances all over the >> > > place. These can be quite large (100x100 up to many 1000x1000. In >> > > the future we could get even bigger) and always have symbolic entries. >> > > At times we do like to convert them to numerical numpy arrays, but in >> > > many cases we really want the symbolic forms. >> >> > > On Sat, May 28, 2011 at 6:56 AM, SherjilOzair <[email protected]> >> > > wrote: >> > >> I would like to know how and where Sympy's matrices are used. >> > >> Is Sympy matrices used for numeric computing anywhere ? >> > >> Are Sympy Matrices expected to offer any advantage that matrices in >> > >> numpy/scipy or other libraries cannot offer ? >> >> > >> Is its use limited to symbolic ? What size of Matrices with symbolic >> > >> content is used ? >> > >> Operations on Expr are way costlier than operations on numerics. So, >> > >> knowing the size of the symbolic matrices that are required would help >> > >> me in optimization when writing algorithms for sparse matrices, and >> > >> also when refactoring Matrix. >> >> > >> I expect that one cannot use too large symbolic matrices, as solving/ >> > >> inversing/etc. would result in expression blowup. >> >> > >> I would be glad if you could also tell what running time you would >> > >> expect from the matrices that you use. >> >> > > instant ;) >> >> > > When we are dealing with large symbolic matrices, we are typically >> > > just doing matrix/vector multplies. But for small matrices we do >> > > other things like linear solves, decompositions and eigenvalue >> > > problems. symbolic eigenvalues are great, but expressions quickly get >> > > out of hand as the matrix size increases. >> >> > > Cheers, >> >> > > Brian >> >> > >> -- >> > >> 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 >> > >> athttp://groups.google.com/group/sympy?hl=en. >> >> > > -- >> > > Brian E. Granger >> > > Cal Poly State University, San Luis Obispo >> > > [email protected] and [email protected] >> >> > > -- >> > > 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 >> > > athttp://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. > > -- 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.
