This is somewhat off-topic, but perhaps related to what you are trying to figure out, and anyway I see that this code is part of a PR https://github.com/sympy/sympy/pull/25699. I don't like how this code depends on the fact that self < i automatically evaluates to true or false. This is a great example of code that ends up being dependent on automatic evaluation behavior which makes that behavior harder to remove. Whether a < b can be computed and whether it should evaluate automatically are separate considerations. It would be better if there were an explicit method, like say (a > b).doit(), to tell an inequality to try to evaluate to true or false.
Things like this are one of the main reasons the core is slower than it needs to be. It's the reason why, for instance, the expression from https://github.com/sympy/sympy/issues/24565 takes over 20 seconds just to construct. There are three types of automatic evaluation that are bad, in terms of performance: 1. Creating expressions that are larger than the original 2. Using assumptions. 3. Using evalf (this is often implicitly done as part of using assumptions) Using evalf is by far the worst of these. It's the thing that causes SymPy to hang on very simple things that should return instantly (see https://github.com/sympy/sympy/issues/10800 for another example of this). We need to move to a model where evalf is never called automatically, except for cases where it is known that it will be very cheap. Aaron Meurer On Tue, Sep 19, 2023 at 8:48 AM Chris Smith <[email protected]> wrote: > > `eq=(cos(2)**2+sin(2)**2-1/S(10**120))` rounds to 1 but neither `eq<1` nor > `eq>1` evaluates but the correct value for `int(eq)` is 0. > > /c > > On Tuesday, September 19, 2023 at 8:14:35 AM UTC-5 Chris Smith wrote: >> >> Given >> ``` >> def f(self): >> from sympy.core.numbers import int_valued >> r = self.round(2) >> i = int(r) >> if int_valued(r): >> # non-integer self should pass one of these tests >> if (self > i) is S.true: >> return i >> if (self < i) is S.true: >> return i - 1 >> # is it safe to assume that self == i? >> return i ``` Can anyone think of a real numerical expression which will >> round up and then not compare with self and cause f to return an integer >> that is 1 too large? > > -- > 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 view this discussion on the web visit > https://groups.google.com/d/msgid/sympy/e58a36bd-af3d-43ae-97fd-c9fb06d4f4afn%40googlegroups.com. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6KN8ZW%2BUE9hkmuqh7zw_ENX%3DPJzsSZ5UiCG1uZf3OVOZg%40mail.gmail.com.
