Sympy generating broken `Piecewise` conditions when simplifying












2















My Code



I effectively have the following reduced code snippet within a larger program:



import sympy as sp
print('sympy version:', sp.__version__)

n = sp.symbols('n', integer=True)
expr = sp.Piecewise((0, sp.Ne(n, 3)), (-1/2, True))*sp.Piecewise((2, sp.Ne(n, 0)), (1, True))

print('raw expression:', expr)
print('simplified expression:', sp.simplify(expr))


For the simplified expression, I expect something equivalent to:




simplified expression: Piecewise((0, Eq(n, 0)), (-1.0, Eq(n, 3)), (0, True))




(This potentially could be simplified further to just two branches, but something like that.)



However, my actual output is:




sympy version: 1.3



raw expression: Piecewise((0, Ne(n, 3)), (-0.5, True))*Piecewise((2, Ne(n, 0)), (1, True))



simplified expression: Piecewise((0, Ne(n, 3)), (-1.0, Ne(n, 0)), (-0.5, True))




My Problem



The obvious issue is that I did not get what I expected. But more than that, there are blatant logical issues in the simplified resulting piecewise expression; more specifically, in the conditions therein.



The first condition is Ne(n, 3), meaning "the first value will be used when n is not equal to 3". That's fine on it's own.



However, the second condition is Ne(n, 0), which in light of the first condition is completely nonsensical. If n were 0, the first condition would be true and the first branch value would be used, thus it's logically guaranteed that n is not 0 if the second condition is being evaluated.



Worse yet, the last condition is True (i.e., "otherwise"), which is the default condition should those of the earlier branches not be met. However, it is logically impossible to reach this branch, since the prior two conditions partition the full space of integers (and n is defined as an integer; however, the same problem occurs when n's number type is left unspecified).



(I want to also note that this problem does not exist in either of the original Piecewise expressions before simplifying. While they do use Ne for their first branch condition, the second condition is the default True, which is perfectly valid.)



My Question



Can anyone explain this as an intended behavior?



If not, I plan to submit this as a bug to SymPy. I did briefly search the SymPy issue tracker for my problem before posting, but I didn't see anything that matched it. I just wanted to double-check here that I'm not overlooking anything first.










share|improve this question




















  • 1





    Have never used Symply, but a well written question!

    – narendra-choudhary
    Nov 13 '18 at 18:29








  • 1





    @narendra-choudhary aside from technical support, emotional support is also appreciated :) thanks!

    – CrepeGoat
    Nov 13 '18 at 18:34
















2















My Code



I effectively have the following reduced code snippet within a larger program:



import sympy as sp
print('sympy version:', sp.__version__)

n = sp.symbols('n', integer=True)
expr = sp.Piecewise((0, sp.Ne(n, 3)), (-1/2, True))*sp.Piecewise((2, sp.Ne(n, 0)), (1, True))

print('raw expression:', expr)
print('simplified expression:', sp.simplify(expr))


For the simplified expression, I expect something equivalent to:




simplified expression: Piecewise((0, Eq(n, 0)), (-1.0, Eq(n, 3)), (0, True))




(This potentially could be simplified further to just two branches, but something like that.)



However, my actual output is:




sympy version: 1.3



raw expression: Piecewise((0, Ne(n, 3)), (-0.5, True))*Piecewise((2, Ne(n, 0)), (1, True))



simplified expression: Piecewise((0, Ne(n, 3)), (-1.0, Ne(n, 0)), (-0.5, True))




My Problem



The obvious issue is that I did not get what I expected. But more than that, there are blatant logical issues in the simplified resulting piecewise expression; more specifically, in the conditions therein.



The first condition is Ne(n, 3), meaning "the first value will be used when n is not equal to 3". That's fine on it's own.



However, the second condition is Ne(n, 0), which in light of the first condition is completely nonsensical. If n were 0, the first condition would be true and the first branch value would be used, thus it's logically guaranteed that n is not 0 if the second condition is being evaluated.



Worse yet, the last condition is True (i.e., "otherwise"), which is the default condition should those of the earlier branches not be met. However, it is logically impossible to reach this branch, since the prior two conditions partition the full space of integers (and n is defined as an integer; however, the same problem occurs when n's number type is left unspecified).



(I want to also note that this problem does not exist in either of the original Piecewise expressions before simplifying. While they do use Ne for their first branch condition, the second condition is the default True, which is perfectly valid.)



My Question



Can anyone explain this as an intended behavior?



If not, I plan to submit this as a bug to SymPy. I did briefly search the SymPy issue tracker for my problem before posting, but I didn't see anything that matched it. I just wanted to double-check here that I'm not overlooking anything first.










share|improve this question




















  • 1





    Have never used Symply, but a well written question!

    – narendra-choudhary
    Nov 13 '18 at 18:29








  • 1





    @narendra-choudhary aside from technical support, emotional support is also appreciated :) thanks!

    – CrepeGoat
    Nov 13 '18 at 18:34














2












2








2








My Code



I effectively have the following reduced code snippet within a larger program:



import sympy as sp
print('sympy version:', sp.__version__)

n = sp.symbols('n', integer=True)
expr = sp.Piecewise((0, sp.Ne(n, 3)), (-1/2, True))*sp.Piecewise((2, sp.Ne(n, 0)), (1, True))

print('raw expression:', expr)
print('simplified expression:', sp.simplify(expr))


For the simplified expression, I expect something equivalent to:




simplified expression: Piecewise((0, Eq(n, 0)), (-1.0, Eq(n, 3)), (0, True))




(This potentially could be simplified further to just two branches, but something like that.)



However, my actual output is:




sympy version: 1.3



raw expression: Piecewise((0, Ne(n, 3)), (-0.5, True))*Piecewise((2, Ne(n, 0)), (1, True))



simplified expression: Piecewise((0, Ne(n, 3)), (-1.0, Ne(n, 0)), (-0.5, True))




My Problem



The obvious issue is that I did not get what I expected. But more than that, there are blatant logical issues in the simplified resulting piecewise expression; more specifically, in the conditions therein.



The first condition is Ne(n, 3), meaning "the first value will be used when n is not equal to 3". That's fine on it's own.



However, the second condition is Ne(n, 0), which in light of the first condition is completely nonsensical. If n were 0, the first condition would be true and the first branch value would be used, thus it's logically guaranteed that n is not 0 if the second condition is being evaluated.



Worse yet, the last condition is True (i.e., "otherwise"), which is the default condition should those of the earlier branches not be met. However, it is logically impossible to reach this branch, since the prior two conditions partition the full space of integers (and n is defined as an integer; however, the same problem occurs when n's number type is left unspecified).



(I want to also note that this problem does not exist in either of the original Piecewise expressions before simplifying. While they do use Ne for their first branch condition, the second condition is the default True, which is perfectly valid.)



My Question



Can anyone explain this as an intended behavior?



If not, I plan to submit this as a bug to SymPy. I did briefly search the SymPy issue tracker for my problem before posting, but I didn't see anything that matched it. I just wanted to double-check here that I'm not overlooking anything first.










share|improve this question
















My Code



I effectively have the following reduced code snippet within a larger program:



import sympy as sp
print('sympy version:', sp.__version__)

n = sp.symbols('n', integer=True)
expr = sp.Piecewise((0, sp.Ne(n, 3)), (-1/2, True))*sp.Piecewise((2, sp.Ne(n, 0)), (1, True))

print('raw expression:', expr)
print('simplified expression:', sp.simplify(expr))


For the simplified expression, I expect something equivalent to:




simplified expression: Piecewise((0, Eq(n, 0)), (-1.0, Eq(n, 3)), (0, True))




(This potentially could be simplified further to just two branches, but something like that.)



However, my actual output is:




sympy version: 1.3



raw expression: Piecewise((0, Ne(n, 3)), (-0.5, True))*Piecewise((2, Ne(n, 0)), (1, True))



simplified expression: Piecewise((0, Ne(n, 3)), (-1.0, Ne(n, 0)), (-0.5, True))




My Problem



The obvious issue is that I did not get what I expected. But more than that, there are blatant logical issues in the simplified resulting piecewise expression; more specifically, in the conditions therein.



The first condition is Ne(n, 3), meaning "the first value will be used when n is not equal to 3". That's fine on it's own.



However, the second condition is Ne(n, 0), which in light of the first condition is completely nonsensical. If n were 0, the first condition would be true and the first branch value would be used, thus it's logically guaranteed that n is not 0 if the second condition is being evaluated.



Worse yet, the last condition is True (i.e., "otherwise"), which is the default condition should those of the earlier branches not be met. However, it is logically impossible to reach this branch, since the prior two conditions partition the full space of integers (and n is defined as an integer; however, the same problem occurs when n's number type is left unspecified).



(I want to also note that this problem does not exist in either of the original Piecewise expressions before simplifying. While they do use Ne for their first branch condition, the second condition is the default True, which is perfectly valid.)



My Question



Can anyone explain this as an intended behavior?



If not, I plan to submit this as a bug to SymPy. I did briefly search the SymPy issue tracker for my problem before posting, but I didn't see anything that matched it. I just wanted to double-check here that I'm not overlooking anything first.







python sympy






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 13 '18 at 18:29









Mark Rotteveel

59.8k1476119




59.8k1476119










asked Nov 13 '18 at 18:10









CrepeGoatCrepeGoat

893914




893914








  • 1





    Have never used Symply, but a well written question!

    – narendra-choudhary
    Nov 13 '18 at 18:29








  • 1





    @narendra-choudhary aside from technical support, emotional support is also appreciated :) thanks!

    – CrepeGoat
    Nov 13 '18 at 18:34














  • 1





    Have never used Symply, but a well written question!

    – narendra-choudhary
    Nov 13 '18 at 18:29








  • 1





    @narendra-choudhary aside from technical support, emotional support is also appreciated :) thanks!

    – CrepeGoat
    Nov 13 '18 at 18:34








1




1





Have never used Symply, but a well written question!

– narendra-choudhary
Nov 13 '18 at 18:29







Have never used Symply, but a well written question!

– narendra-choudhary
Nov 13 '18 at 18:29






1




1





@narendra-choudhary aside from technical support, emotional support is also appreciated :) thanks!

– CrepeGoat
Nov 13 '18 at 18:34





@narendra-choudhary aside from technical support, emotional support is also appreciated :) thanks!

– CrepeGoat
Nov 13 '18 at 18:34












1 Answer
1






active

oldest

votes


















1














The output is not "broken" or "nonsensical". It is logically correct, although not presented in the simplest form possible.



The condition if n == 3 and n != 0 could be simplified to if n == 3. There is a difference between "could be simplified" and "is completely nonsensical".



But yes, please report it on SymPy tracker, since the simplification is incomplete; a better result would be Piecewise((0, Ne(n, 3)), (-1.0, True)).






share|improve this answer























    Your Answer






    StackExchange.ifUsing("editor", function () {
    StackExchange.using("externalEditor", function () {
    StackExchange.using("snippets", function () {
    StackExchange.snippets.init();
    });
    });
    }, "code-snippets");

    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "1"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: true,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: 10,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });














    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53287120%2fsympy-generating-broken-piecewise-conditions-when-simplifying%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    1 Answer
    1






    active

    oldest

    votes








    1 Answer
    1






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    1














    The output is not "broken" or "nonsensical". It is logically correct, although not presented in the simplest form possible.



    The condition if n == 3 and n != 0 could be simplified to if n == 3. There is a difference between "could be simplified" and "is completely nonsensical".



    But yes, please report it on SymPy tracker, since the simplification is incomplete; a better result would be Piecewise((0, Ne(n, 3)), (-1.0, True)).






    share|improve this answer




























      1














      The output is not "broken" or "nonsensical". It is logically correct, although not presented in the simplest form possible.



      The condition if n == 3 and n != 0 could be simplified to if n == 3. There is a difference between "could be simplified" and "is completely nonsensical".



      But yes, please report it on SymPy tracker, since the simplification is incomplete; a better result would be Piecewise((0, Ne(n, 3)), (-1.0, True)).






      share|improve this answer


























        1












        1








        1







        The output is not "broken" or "nonsensical". It is logically correct, although not presented in the simplest form possible.



        The condition if n == 3 and n != 0 could be simplified to if n == 3. There is a difference between "could be simplified" and "is completely nonsensical".



        But yes, please report it on SymPy tracker, since the simplification is incomplete; a better result would be Piecewise((0, Ne(n, 3)), (-1.0, True)).






        share|improve this answer













        The output is not "broken" or "nonsensical". It is logically correct, although not presented in the simplest form possible.



        The condition if n == 3 and n != 0 could be simplified to if n == 3. There is a difference between "could be simplified" and "is completely nonsensical".



        But yes, please report it on SymPy tracker, since the simplification is incomplete; a better result would be Piecewise((0, Ne(n, 3)), (-1.0, True)).







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Nov 13 '18 at 18:54







        user6655984





































            draft saved

            draft discarded




















































            Thanks for contributing an answer to Stack Overflow!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53287120%2fsympy-generating-broken-piecewise-conditions-when-simplifying%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            Bressuire

            Vorschmack

            Quarantine