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.
>
>> 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.
