By the way, I watched this presentation about the ast module from PyCon 2011. It's pretty interesting. Based on that, doing something like this would be really easy to do.
http://pycon.blip.tv/file/4880291/ Aaron Meurer On Thu, May 12, 2011 at 6:28 PM, Ronan Lamy <[email protected]> wrote: > Le jeudi 12 mai 2011 à 16:06 -0700, Ondrej Certik a écrit : >> On Thu, May 12, 2011 at 3:49 PM, Aaron Meurer <[email protected]> wrote: >> > Hi. >> > >> > There was a discussion over at >> > http://code.google.com/p/sympy/issues/detail?id=1721 to rename the >> > Real class to Float, because the name fits the class better. The >> > reasoning is that Real represents floating point numbers, not any real >> > number like sin(1) or 2*pi, and it is confusing to have the subtle >> > difference between Real and real in the docs. See the discussion over >> > at that issue page for more info. >> > >> > How do people feel about this? If it were to happen, it would happen >> > in the next release, which also breaks some other things in terms of >> > backwards compatibly. >> >> It seems that most code uses some variation of Real already: >> >> Sage: uses RealField and RealLiteral: >> >> sage: a = 1.345 >> sage: type(a) >> <type 'sage.rings.real_mpfr.RealLiteral'> >> >> >> Mathematica uses "Real": >> http://reference.wolfram.com/mathematica/ref/Real.html > > And their "Possible issues" section can be summed up with "Reals aren't > reals, reals aren't Reals". Do we need to repeat others' mistakes? > > Anyway, both Python and numpy call floats "float" which, I think, trumps > compatibility with Sage and Mathematica. Maple and Maxima use "float" as > well. > >> And given that it would break compatibility, it seems to me that it's >> not worthy to make the change. > > If you look at the tree for 0.6.7, it seems to be used less often than > the syntax symbols('xyz') which will be forbidden in 0.7.0, apparently. > Not to mention the Basic/Expr split that is bound to break a lot of code > in ways that won't always be easily fixed. > > For me, this is a big flaw that confuses users and devs on a crucial > matter for sympy: the difference between symbolic and numeric > computation. I certainly think it's worth the small increase in > compatibility breaking. > > -- > 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.
