Does isAlways Make an Unwarranted Assumption that a Variable is real?

Define a sym variable

syms v

isAlways can't prove that v is real. Makes sense.

isAlways(in(v,'real'))

Warning: Unable to prove 'in(v, 'real')'.

ans = logical
   0

Now make an assumption

assume(v > 0);  % (1)

Is that assumption a sufficient condition to imply that v is real?

isAlways(in(v,'real'))  %(2)

ans = logical
   1

Apparently it does.

But we don't see that v is real in the assumptions

assumptions(v)

ans = 

as we would if stated explicitly

assumeAlso(v,'real');
assumptions(v)

ans = 

Now define v as a complex number, which clears all of the assumptions

v = sym(1+1i);
assumptions(v)

 
ans =
 
Empty sym: 1-by-0
 

Here, v satisfies assumption (1) because symbolic gt only compares the real parts of both sides (though the doc page does not state that explicitly)

isAlways(v > 0)

ans = logical
   1

But satisfying assumption (1) in this case does not imply the truth of condition (2) (thankfully)

isAlways(in(v,'real'))

ans = logical
   0

Seems like the correct way for the software to interpret (1) would be Re(v) > 0, in accordance with the de facto definition of symbolic gt, which would provide no information for evaluating (2).

[Matt J]

In my opinion, the thing that is wrong is,

>> isAlways( sym(1+1i) > 0)

ans =

logical

1

I never really understood this convention even for numeric variables, but certainly not for symbolic variables.

[Paul]

Any thoughts on what the convention should be? For example, what should be the result of

[-1+1i,2] > [0, 0]

ans = 1×2 logical array
   0   1

Or should gt (numeric or symbolic) just throw an error if any operand is complex?

[Matt J]

The result is correct, but for the wrong reasons.. A number is positive, by definition, if it lies on the positive real axis. Numbers with a non-zero imaginary part should be considered neither positive nor negative, IMHO.

[Paul]

So gt, lt, ge, and le should all return false if either side of the comparison has non-zero imaginary part? Just want to make sure I understand how you think these operators should work.

[Matt J]

That's my opinion, yes.

[Paul]

Upon reflection, would that approach be a problem for ge and le being inconsistent with eq ?

Let x have a non-zero imaginary part. Then

x == x  % returns true
x >= x  % returns false?

Any idea how other languages treat gt, lt, ge, le with complex inputs? Google AI response says in FORTRAN that attempting to use those operators with complex inputs will result in compiler error.

[the cyclist]

I guess I would have expected

1 + i > 0

to return NaN, since ordering is not defined on complex numbers.

[Paul]

The doc page for gt, > states: "The test compares only the real part of numeric arrays", so at least it's documented.

If gt(1+i,0) would return NaN, what should ge return for complex inputs? True if the inputs are equal and NaN if they are not?

Also, a logical NaN is not allowed, so returning NaN for gt would mean changing the returned data type, which is probably not desirable.

[Matt J]

x >= x % returns false?

I can see the case for returning true iff the inequality is satisfied with equality.