use compose caculate piecewise fun

,

caculate ,,,

but different picecwise expression get different outcome on ,: f(x)=piecewise(x<=0,0,x) or f(x)=piecewise(x>0,x,0); g(x)=piecewise(x<=0,0,-x^2) or g(x)=piecewise(x>0,-x^2,0).

clc,clear
syms x
f(x)=piecewise(x<=0,0,x);
g(x)=piecewise(x<=0,0,-x^2);
compose(f,f)
compose(g,g)
compose(f,g)
compose(g,f)

clc,clear
syms x
f(x)=piecewise(x>0,x,0);
g(x)=piecewise(x>0,-x^2,0);
compose(f,f)
compose(g,g)
compose(f,g)
compose(g,f)

Answer 1

[Paul]

Hi jin,

Perhapse I misunderstand the question, but the results all seem to be functionally equivalent.

syms x
f(x)=piecewise(x<=0,0,x);
g(x)=piecewise(x<=0,0,-x^2);

f1(x)=piecewise(x>0,x,0);
g1(x)=piecewise(x>0,-x^2,0);

fplot([compose(f,f) compose(f1,f1)])

fplot([compose(g,g) compose(g1,g1)])

fplot([compose(f,g) compose(f1,g1)])

fplot([compose(g,f) compose(g1,f1)])

[jin yong]

Hi，Paul，

Thanks your help and answer. I mean that the compose(f,g)'s ans not equal to compose(f1,g1) ,and compose(g,g)'s ans not equal to compose(g1 g1).

[Paul]

syms x
f(x)=piecewise(x<=0,0,x);
g(x)=piecewise(x<=0,0,-x^2);
f1(x)=piecewise(x>0,x,0);
g1(x)=piecewise(x>0,-x^2,0);

h = compose(f,g)

h(x) = 

h1 = compose(f1,g1)

h1(x) = 

0

As long as x is real, h(x) = h1(x) = 0. However, the Symbolic Math Toolbox assumes that all variables are complex unless assumed otherwise. So it has to account for what happens in h and h1 when the function inputs have non-zero imaginary parts. It looks like the compostion that forms h would not be zero in that case, keeping in mind the rules for how the SMT evaluates relational operators for non-real inputs.

If in this problem (and any other, actually) x is intended to be real, then it's best to include that assumption in the analysis. We can add that assumption now by using assume and then simplify

assume(x,'real')
h = simplify(h)

h(x) = 

0

It would be better to use

syms x real

at the top of the code.

[jin yong]

thanks

Answer 2

[Walter Roberson]

@jin yong

syms x truecase falsecase
g(x) = piecewise(x<=0, truecase, falsecase)

g(x) = 

g1(x) = piecewise(x>0, truecase, falsecase)

g1(x) = 

g(1i)

ans = 

falsecase

g1(1i)

ans = 

falsecase

g(1+1i)

ans = 

falsecase

g1(1+1i)

ans = 

falsecase

g(-1+1i)

ans = 

falsecase

g1(-1+1i)

ans = 

falsecase

g(1-1i)

ans = 

falsecase

g1(1-1i)

ans = 

falsecase

Notice that all of the comparisons against complex numbers are treated as false. This makes the tests asymmetric and is why one of your cases allows for non-real elements but the other case does not.

[Paul]

I would say the comparisons against complex numbers evaluate to false based on the SMT rules for relational operators with non-real inputs. "Treated" could lead someone to infer that comparison with at least one non-real operand will always evalute to false, and that's not the case

[Walter Roberson]

I do not know what "SMT rules" are. If you are referring to TMW rules for comparisons with complex values -- rules that say that the imaginary components are discarded for the purpose of the inequality operators -- then No, that would not explain the piecewise results. There is something inside of the symbolic engine that is treating symbolic comparisons differently.

g(1i)

ans = 'truecase'

g1(1i)

ans = 'falsecase'

g(1+1i)

ans = 'falsecase'

g1(1+1i)

ans = 'truecase'

g(-1+1i)

ans = 'truecase'

g1(-1+1i)

ans = 'falsecase'

g(1-1i)

ans = 'falsecase'

g1(1-1i)

ans = 'truecase'

function result = g(expression)
   if expression <= 0
       result = 'truecase';
   else
       result = 'falsecase';
   end
end

function result = g1(expression)
   if expression > 0
       result = 'truecase';
   else
       result = 'falsecase';
   end
end

[Paul]

By "SMT rules" I was referring to this from the SMT documentation for gt (and similar for ge, lt, le):

• The field of complex numbers is not an ordered field. MATLAB projects complex numbers in relations to a real axis. For example, x > i becomes x > 0, and x > 3 + 2*i becomes x > 3.

I didn't check carefully and just assumed that these rules were the culprit.

It seems like the rule doesn't apply when evaluating symbolic functions

syms x
cond(x) = x <= 0;
simplify(cond(sym(1i)))

ans = 

symfalse

Nor does it apply to subsing into symbolic expressions

condexp = x <= 0;
simplify(subs(condexp,x,sym(1i)))

ans = 

symfalse

But it does apply to symbolic constants in symbolic expressions

condexp = sym(1i) <= 0;
simplify(condexp)

ans = 

symtrue

[Walter Roberson]

Ah, I did not recognize the abbreviation SMT

The implementation of symfun evaluation involves taking formula() of the function and subs() the values for the variables, so there is potentially something odd going on in subs() of a piecewise.

[Paul]

Seems like something odd in subs in general, not just piecewise, based on the second test in my previous comment

[Walter Roberson]

Additional oddness: as soon as the symbolic toolbox notices that it is dealing with an imaginary component in a relational operator, it takes the real() part of it

syms x y
condexp = x <= 0;
result = subs(condexp,x,sym(1i))

result = 

simplify(result)

ans = 

symfalse

condexp2 = sym(1i) <= y

condexp2 = 

result2 = subs(condexp2,y,0)

result2 = 

simplify(result2)

ans = 

symtrue

condexp3 = str2sym('1i <= y')

condexp3 = 

result3 = subs(condexp2,y,0)

result3 = 

simplify(result3)

ans = 

symtrue

condexp4a = str2sym('1i')

condexp4a = 

i

condexp4 = condexp4a <= y

condexp4 = 

result4 = subs(condexp4, y, 0)

result4 = 

simplify(result4)

ans = 

symtrue

[jin yong]

g1(x) should be defined as g1(x) = piecewise(x>0, falsecase,truecase),different with g(x)= piecewise(x<=0,truecase,falsecase)

[Walter Roberson]

We were testing which branch piecewise was evaluating to. In each case the symbolic toolbox resolved the piecewise to the second branch, the one associated with failure of the condition. It should have been a mix of first branch and second branch when complex values were passed in.

If you were to restrict your inputs to R then in each case the piecewise for both variations would give the same result for all real inputs.

The difference you observe between the two cases is that in one case the result is piecewise 0 if the input is an element of R and -x^2 otherwise, but that piecewise test is missing in the other case and it gives just 0 there.

I tracked that difference down to the fact that piecewise appears to consider the test to fail if the input is not in R, instead of converting the test to check the real() of the input as is otherwise documented for the Symbolic Toolbox. The two versions differ in how they treat complex inputs with an imaginary component known to be non-zero.

Consider -1+2i. Is that <= 0 ? Complex numbers are not mathematically orderable so you would have to say "No, it is not <= 0 because it cannot be ordered". Then test, is it > 0 ? Again you would have to say that it is mathematically not > 0 because it cannot be ordered. So -1+2i <= 0 can be said to be false, but -1+2i > 0 can also be said to be false. Whereas you are using binary reasoning to say that if the first test is false that the "opposite" of the first test must be true. Which turns out not to be the case. The situation is like trying to reason about NaN (Not A Number)