> This is a great example of code that ends up being dependent on automatic evaluation behavior which makes that behavior harder to remove.
If that is removed then the test will be changed to whatever mechanism will allow the sign of `self - i` to be determined. And for an arbitrary function I don't know how you can do that without evaluation (even if that evaluation does something like ball/interval arithmetic to determine that the range of possible values allows the inequality to be determined). Computing with `n(2)` is much faster than trying to infer the value of a complicated expression. Do you have ideas about how we can tell if `sqrt(log(100)+log(log(100))) > 2` that is faster than evaluation? I don't really appreciate the preference for using `is_gt(a,b)` instead of `(a > b) is S.true` or else I may have used the former. (I forgot until writing this that we had that function.) I can change that in the code if that would make something clearer. /c On Tuesday, September 19, 2023 at 12:26:31 PM UTC-5 Aaron Meurer wrote: > 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/3da5eaa6-2299-4d24-bfd1-fbe0e899d678n%40googlegroups.com.
