Le jeudi 12 mai 2011 à 19:22 -0700, Ondrej Certik a écrit : > On Thu, May 12, 2011 at 5:28 PM, Ronan Lamy <ronan.l...@gmail.com> wrote: > > Le jeudi 12 mai 2011 à 16:06 -0700, Ondrej Certik a écrit : > >> On Thu, May 12, 2011 at 3:49 PM, Aaron Meurer <asmeu...@gmail.com> 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. > > If Maple + Maxima both use float, I am ok with that. Do you have some > reference for that? I didn't manage to find one for Maple.
For Maple: http://www.maplesoft.com/support/help/Maple/view.aspx?path=float For Maxima: http://maxima.sourceforge.net/docs/manual/en/maxima_10.html > >> 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. > > Yes, the Expr thing broke pydy for example. It was easy to fix, but it > is backwards incompatible. > > > > > 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. > > Ondrej > -- 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.
