On Fri, 10 Sept 2021 at 02:02, Aaron Meurer <asmeu...@gmail.com> wrote: > > On Thu, Sep 9, 2021 at 6:07 PM Oscar Benjamin > <oscar.j.benja...@gmail.com> wrote: > > > > " > > On Thu, 9 Sept 2021 at 23:12, Aaron Meurer <asmeu...@gmail.com> wrote: > > > > > > On Thu, Sep 9, 2021 at 2:25 PM Oscar Benjamin > > > <oscar.j.benja...@gmail.com> wrote: > > > > > > > > Anyone is welcome to have an opinion on the printing of Heaviside > > > > functions: > > > > https://github.com/sympy/sympy/issues/21945 > > > > In the absence of any other opinions I'll just close the issue though. > > > > > > I also commented this on the issue, but why was the default value for > > > Heaviside(0) changed (previously it was unevaluated, but now > > > Heaviside(0) is 1/2)? As I explained in the issue, I think this could > > > negatively impact people's existing code, so we should only make the > > > change if there is a good reason. > > > > There are lots of issues/PRs where this was discussed but probably the > > final discussion was here: > > https://github.com/sympy/sympy/pull/20411 > > I guess I stopped following this PR around when this change was made. > I would have been opposed to it then if I had seen it. > > Making Heaviside default to 1/2 just for lambdify would be an OK > change. I suggested several alternate ways of specifying the value of > Heaviside(0) in that PR. But none of them would be backwards > incompatible because lambdify() didn't support Heaviside at all before > that PR.
I don't think that having a lambdify give different values from the sympy expression is a good choice. I don't know if this is documented anywhere but my basic expectation ot lambdify is that it should give the same values as sympy apart from unavoidable differences due to rounding errors. Having H(0) undefined but with lambdify arbitrarily choosing different values seems like a basic breach of contract to me. > > And the PR that made the change was here: > > https://github.com/sympy/sympy/pull/21452 > > > > A significant part of the motivation was as a prerequisite for this PR > > making it possible to lambdify Heaviside which would fail for H(0) > > unless a decision was made about what value it should have: > > https://github.com/sympy/sympy/pull/21573 > > > > The basic reason why it's a good idea is just because it means that > > the standard 1-arg form of the function is well-defined. > > The previous behavior of Heaviside(0) being unevaluated is also > well-defined. The only way that becomes problematic is if you need a > numeric value for the expression, then neither evalf() nor lambdify() > will produce a value. But I personally always saw this as a feature. > You must explicitly specify your desired value for Heaviside(0). > > My biggest concern here is that this breaks compatibility, and I'm not > sure it's necessary to do so. If we had started with the behavior we > now have in master, that might have been fine, although I personally > think the old behavior with Heaviside(0) unevaluated was better. I don't think that it does really break compatibility in a significant way. I haven't seen any user say that they appreciate the behaviour of H(0) and I think that for most users who notice H(0) is just annoying. A lot of them don't care what value H(0) takes but they don't want it to blow up on them. Those that do care have a clear option: use the second argument to specify the value like H(x, 0) or H(x, nan) or whatever you want. That was the way to handle it before and it's still the way to handle it now. -- Oscar -- 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/CAHVvXxRjSdbTp9O9gBjWE0tOj%3DQa6-UPkn7XZPK6PZG705fNJw%40mail.gmail.com.
