Ondrej Certik wrote: > On Wed, Jul 1, 2009 at 6:33 PM, William Stein<wst...@gmail.com> wrote: >> 2009/7/2 Stéfan van der Walt <ste...@sun.ac.za>: >>> 2009/7/1 William Stein <wst...@gmail.com>: >>>> Perhaps I'm missing the point, but I'm taking this as a message to >>>> focus in Sage more on the algebraic/symbolic side of mathematics >>>> (e.g., Magma, Maple, Mathematica) rather than the numerical side, at >>>> least for the time being. I don't have a problem with that >>>> personally, since that is what I do best, and where most of my >>>> personal interests are. >>> I'm joining this conversation late, so I am glad to see the >>> conclusions reached so far (not to give up on numerics!). >>> >>> If I may highlight a distinction (maybe obvious to some) between SAGE >>> and NumPy-based experiments: >>> >>> Sage provides a "language" for eloquently expressing >>> algebraic/symbolical problems. On the other hand, NumPy is mainly a >>> library (that provides a data structure with accompanying operations). >>> >>> This means that users of that library expect to run their code >>> unmodified on any Python platform where it is available (Sage >>> included). Whether this expectation is reasonable or not is up for >>> debate, but I certainly found it surprising that I had to modify my >>> code in order to compute things in Sage. >> Either that, or you click on the "python" switch at the top of the >> notebook or type "sage -ipython", or from within Sage you type >> "preparser(False)". >> >>> On a more practical level, it frightens me that Maxima spawns so >>> easily without my even knowing, simply by refering to a certain >>> variable or by using the wrong "exp". >> FYI, that is no longer the case. In Sage-4.0, we replaced Maxima by >> the C++ library Ginac (http://www.ginac.de/) for all basic symbolic >> manipulation. >> >>> That's the kind of thing that kills numerics performance! >> There is often a tension between numerics performance and correct >> answers. The following is in MATLAB: >> >>>> format rat; >>>> a = [-101, 208, 105; 76, -187, 76] >>>> rref(a) >> ans = >> 1 0 -2567/223 >> 0 1 -3839/755 >> >> The same echelon form in Sage: >> >> a = matrix(QQ, 2, [-101, 208, 105, 76, -187, 76]) >> a.echelon_form() >> [ 1 0 -35443/3079] >> [ 0 1 -15656/3079] >> >> Trying the same computation on larger matrices, and one sees that >> matlab is way faster than Sage. But of course the answers are >> nonsense... to anybody not doing numerics. To a numerical person they >> mean something, because matlab is really just doing everything with >> floats, and "format rat" just makes them print as rational >> approximations to those floats. >> >> So indeed, mixing numerics with mathematics is a very difficult >> problem, and nobody really seems to have solved it to everybody's >> satisfaction. > > I think people need both approaches, but I why you cannot just pass an > option to echelon_form() to use fast floating point numbers (besides > nobody yet implementing it)? Then we can have both.
Because it is pretty easy to do: A.change_ring(RR).echelon_form() which also allows things like A.change_ring(RealField(200)).echelon_form() for extended precision. Is this not sufficient? Jason --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
