On Friday, April 4, 2014 7:44:11 AM UTC-7, Sergey Kirpichev wrote: > > On Mon, Mar 31, 2014 at 02:17:56PM -0700, Richard Fateman wrote: > > I think the answer from a practical perspective is that you can't > exclude > > floats. > > But why we need them as a class, derived from Number and Basic? >
It is perfectly possible for floating point numbers like 0.1 (which is not equal to 1/10) to be subtracted from other floating point numbers and get 0.0, or not, even if the numbers you might (incorrectly) believe they exactly represent should come out 0, or not. It is not a proof of associativity, as I assume you realize :) Any example in which you display floating point numbers in decimal is immediately suspect unless you are using decimal floating point. (for the purposes here of exactness etc.) *I have no idea what evaluate=False means. I am guessing what Add( ) means.* > > An example of real issue: > In [1]: n1=Float(0.001) > In [2]: n2=Float(1.1) > In [3]: n3=Float(1.0) > In [4]: x1=n1*x > In [5]: x2=n2*x > In [6]: x3=n3*x > In [10]: f1=Add(Add(x1, x2, evaluate=False), -x3, evaluate=False) > In [11]: f1 > Out[11]: -1.0*x + 0.001*x + 1.1*x > In [13]: f2=Add(x1, Add(x2, -x3, evaluate=False), evaluate=False) > In [14]: f1 > Out[14]: -1.0*x + 0.001*x + 1.1*x > In [20]: f1-f2 # Hey, sympy thinks associativity holds > Out[20]: 0 > > But: > In [21]: f1e=Add(Add(x1, x2), -x3); f1e > Out[21]: 0.101*x > In [22]: f2e=Add(x1, Add(x2, -x3)); f2e > Out[22]: 0.101*x > In [23]: f1e-f2e > Out[23]: -1.11022302462516e-16*x > > > So are you taking the view, now, that 0.5 is rational? > > Yes, for the provided example (x**0.5) > > > End of story. It seems, people want to introduce not floats but a > fancy > > notation for rationals. > > > > You can't predict the future. > > I'm not attempting to do so. > > If this is only the reason why we keep Float > > object - we should drop Float's and fix sympify to map python's > floats > > to Rational's instead (for example: sympify(0.2) -> > Rational(str(0.2))). > > > > Sometimes floats can be very handy. Finding approximations to roots > > of a polynomial. Compared to rational arithmetic, where different, > > usually much slower methods, might be used. > > But I don't suggest to forbid using float at all (python has builtin > float type, we also have mpf from mpmath; we can convert SymPy's numbers > to these > types in some use cases). > > > Is there a real need for floats in symbolic mathematics package? > > > > Just because you might not need them now, doesn't really answer the > > question. > > Good point. But if we don't need them now - it's a good idea to > introduce such an object only on demand... > In my opinion, truly a bad idea, not a good idea. You must think about many different aspect of computation even if you don't implement them yet. I think that Mathematica, not necessarily my favorite system, nevertheless was vastly improved by writing most of the documentation before coding. But in any case leaving out floats seems particularly hazardous because: Floats are already around. You should aim sympy to be conceptually like a traditional multi-tiered wedding cake, with layers built sturdily upon other layers, and nice to look at. http://www.weddingcakeforbreakfast.com/ Not like a giant cranberry-orange scone with odd shaped pieces sticking out at random angles. http://sweetpeaskitchen.com/2010/08/cranberry-orange-scones/ That's how most computer algebra systems end up, despite efforts to the contrary. Having looked at sympy but only in small pieces, I think it is already looking scone-ish.. RJF -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/220f81f0-1bf9-42e5-847a-5668abf91905%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
