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.
