The `is_rational` flag can be used by the assumption system to make inferences about properties. Currently it is failing to allow `Eq(i/2, 0.5)` to be true (for integer `i`) because the rational lhs has a non-rational rhs. Yet, `Eq(S.Half, 0.5)` evaluates to True. So either we should make the latter fail or make modifications so the former passes. In https://github.com/sympy/sympy/pull/25865 I restore the `Float.is_rational == True` behavior.
Allowing something to report itself as `rational` in SymPy has no implication for how that object will behave in computation since that property must be defined and understood by those using SymPy. If some routine makes decisions based on the `is_rational` or `is_integer` property it will have to consider how Float should be included. An example is the `ceiling(x + 2)` vs `ceiing(x + 2.0)`: the first simplifies to `ceiling(x) + 2` while the latter does not. Both should be treated the same (and both should consider what the simplification is intended to convey: the exact value or the calculated value, for if `x` is a small Float then the result matters): >>> ceiling(S(2) + 1e-16) 2 >>> ceiling(x + y).subs({x:1e-6,y:2}) 3 The user must understand why this is correct -- the argument in the first case truncated to 2 and in the second, the evaluation machinery handled the calcuation so it was symbolically correct. I think there is a case, however, to keep `rational` reserved for things that mathematically behave as rationals. Floats do not, e.g. >>> a, b = Float(.1, 1), Float(.3, 1) >>> s = a + b >>> s - a - b -0.004 >>> s - s 0 So there might be a better case made for modifying routines to handle Float (as I did in https://github.com/sympy/sympy/pull/25864) instead of limiting `is_rational` to the form of the number and invalidating other common mathematical assumptions about the behavior or rationals. /c On Monday, April 14, 2014 at 6:14:36 PM UTC-5 skirp...@gmail.com wrote: > On Sat, Apr 12, 2014 at 03:11:28PM -0700, Richard Fateman wrote: > > This example was actually for other sympy developers. Think about > > Add(2, 2, evaluate=False) as a poor-man's analog of the Mathematica > > Hold[2+2]. > > > > That's awful. > > Lisp would use the syntax (+ 2 2). > > That's fine, by my example was not about the syntax. > > > You totally miss the point. I'm against using these "inexact" numbers > > in symbolic context, especially if we assume that some algebraic > > properties are valid for any expression (associativity for the provided > > above example). > > > > I think you are missing my point, which is that these numbers are not > > inexact > > at all. They are precise numbers on the real line. > > Rational numbers, real numbers, > integer numbers - not just about the notation. These notions include > also available operations, i.e. addition and multiplication. "Inexact" > in this context means that some well known algebraic properties for such > "numbers" - broken. > > In the SymPy, we can't use such objects reliably. Well, until our "+" > and "*" are associative (see Expr and AssocOp classes). > > > However, there is > > nothing wrong with using them as input values > > I'm not against python's float literals or using floats > as output values. > -- 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 sympy+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/05144fd0-ff57-4465-85b9-285b4d5aa4d7n%40googlegroups.com.