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. > > 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. > > > More generally, for release notes entries for backwards compatible > > changes, I think we should explain not just what changed but why it > > was changed, and why it was considered important enough to break > > compatibility. None of the entries listed in the 1.9 backwards > > compatible breaks section really do that, except for the one about > > sample() returning to pre-1.7 behavior. > > Yes, they should be improved. That's the part of the release notes > that I intend to focus on. > > Some of the release notes listed under the backwards compatibility > section are actually not incompatible changes at all e.g. "Moment no > more has None in args" is just a bug fix that doesn't need to be > listed. I don't even think that particular example needs an ordinary > release note. > > Others like the changes to rewrite and Predicate are unlikely to be > noticed by anyone. They are listed as compatibility breaks when they > are really just internal changes. Unfortunately the SymPy > documentation does not make it clear what is internal and what is not > so it is hard to judge whether any particular change needs to be > listed as a compatibility break or not. > > You can see another example in the release notes where I wrote: > > - The (internal) PolyMatrix class has been changed and now requires > generators to be provided on construction. (#21441 by @oscarbenjamin) > > Here I need to clarify that the class is internal. I have definitely > seen people trying to use this class though so even though it is > internal someone is using it for something. There have been changes to > it that are not at all compatible. The SymPy docs don't make clear > what's internal or not though and regardless people will just go into > the code and use whatever they find if they think it is the right > thing: > https://stackoverflow.com/a/58124273/9450991 To be fair, I think there is some expectation that if you dig up some random undocumented class from a codebase that it is probably not really public API. People still use private APIs even when they know they are private if it's the only thing that can solve their problem. I'm not saying we shouldn't be clear about this, especially given the discussions around backwards compatibility breaks, but the main signal I would take from this is that something like this would be useful to have in the public API, even if it isn't this specific class. Aaron Meurer > > I decided that the changes made to PolyMatrix did not need to be > listed as a compatibility break because no one should have been using > that class. I know however that some people are using it though so I > at least added a release note explaining that there was a change to an > internal class. I think some of the other "compatibility breaks" could > also be listed in the same way. > > The question is how cautious do you want to be about describing > something as an incompatible change. In a formal sense no change is > entirely compatible so there needs to be some judgement about what is > worth mentioning or what is worth adding a DeprecationWarning for > (rather than simply making the change). > > -- > 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/CAHVvXxS%3DW2QzD-HsePuR9B6QARUpUoTcKq7tdqcPuUU8rPto4Q%40mail.gmail.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 sympy+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6%2BgVdyZ1njLZ9siQsY36DY%2BPFuYiQ6ZJjgGxOJyHWYzAQ%40mail.gmail.com.
