What is the shortest way to check the followings?

1. non-negative real scalar
2. real valued vector having the length 2
3. real valued numeric cell array containing 2 elements (length 2 also)

Answer 1

[Image Analyst]

Hints: These functions may be useful isreal(), real(), length(), and isvector(). And, obviously the ">= 0" and "==" operations. I don't think you should need additional help beyond this.

[Mr M.]

Yes I know all of these, but my question was about any tricky method which is shorter or any predefined function which can be useful.

[Walter Roberson]

The predefined function is http://www.mathworks.com/help/matlab/ref/validateattributes.html

[Jan]

@Mr M: How do you define "shorter"? The run time of the command will not matter. Then the readability during debugging has the largest effect. Therefore the standard methods are optimal, although you might be able to create a cryptic command which is 1 or 2 characters shorter.

[Image Analyst]

You said "my question was about any tricky method which is shorter or any predefined function which can be useful." You did not mention requiring a "tricky method" so I gave you the "predefined/built-in methods". Since you are now asking about tricky or predefined methods, then the predefined methods I listed should be sufficient. No need for tricks.

Answer 2

[Mr M.]

One of my problem is that isreal() is not good! For example isreal('ab') is TRUE. Why?

[Walter Roberson]

Because the documentation says so:

"For numeric data types, if A does not have an imaginary part, isreal returns true; if A does have an imaginary part isreal returns false."

"For logical and char data types, isreal always returns true."

"For table, cell, struct, datetime, function_handle, and object data types, isreal always returns false."

logical and char are essentially unsigned integer datatypes with special printing rules. For example

'b' + true

is valid because "really" 'b' is 98 and "really" true is 1.

isreal() should not be used for checking datatype: it should be used for checking complex component. You should be testing something else as well. For example see isnumeric()

[dpb]

@Walter -- I turned your quotes of doc into italicized text to get away from the silliness of the new (and not improved) code formatting that requires the scrolling to read. Seemed "more better" for following the thread...--dpb

[dpb]

There seems to be some problems with the doc for isreal though, at least in my mind its description of the results it describes for the case of complex with zero-valued imaginary component are misleading.

I don't see any way to do the described of finding a T result from a complex value with 0 complex component as Matlab doesn't store that with the complex attribute. Hence, while those given constructs return the results they do, it's because they negate the actual test and thereby are negating the actual condition to match the desired result. Not knowing that was the result on an array in general, one would get the negative of the actual conclusion.

[Walter Roberson]

When you use the complex() constructor the result is stored as complex even if all the imaginary components are 0 and the attributes of such a variable can be tested as complex. However, as soon as any operation is done on the data producing an expression result MATLAB discards the all-zero imaginary component of the result.

[James Tursa]

This behavior of isreal returning the equivalent of "is there no physical complex part stored" has been discussed on this forum before. E.g.,

http://www.mathworks.com/matlabcentral/answers/45597-how-can-i-maintain-to-complex-type-when-copying-arrays

http://www.mathworks.com/matlabcentral/answers/168333-how-to-test-if-each-element-of-a-matrix-is-not-a-real-number

And the current doc for isreal seems pretty clear on this:

"If A has a stored imaginary part with value 0, then isreal(A) returns logical 0 (false)."

For a real valued test on a complex variable as OP has stated (and dpb details), one would have to examine the imaginary part element-by-element. I don't know of a way to do this or a function that can be used for this at the m-code level that would not require a data copy of the imaginary part first (e.g., copying the imaginary part out first with imag(A)). But it is easily done in a C mex routine without the data copy, so maybe it is time I write this C mex routine and post it.

[dpb]

Ah, that's the unstated "gotcha", Walter. I was using explicit complex values like 1+[1|0]i in testing.

[Walter Roberson]

dpb, the documentation of isreal() has a specific discussion of the point. See "Define Complex Number with Zero-Valued Imaginary Part"

[dpb]

Yeah, there is some additional info/examples under doc. I was also reading help isreal which is lacking the explicit cast via complex

ADDENDUM The cast of which or an equivalent is required for the examples in help to work as advertised which is what caught my attention earlier. I'll note that it seems a "quality of implementation" issue that writing c=a+bi; for b==0 results in a real; it would be expected imo that if one goes to the effort of writing an explicit complex part that one would expect (and get) a complex result.

[James Tursa]

"... if one goes to the effort of writing an explicit complex part that one would expect (and get) a complex result ..."

Except that MATLAB doesn't see it that way. MATLAB parses it as two separate numbers that are added together, a real number (a) and a complex number(bi). Then once they are added the result gets checked for identical 0 imaginary part, which then gets discarded and the result of the addition turned into a pure real. Which means constructs like the following take more memory (at least temporarily) than you might think:

rand(10000) + rand(10000)*1i

because you start with a 763MB real variable and a 2 x 763MB complex variable (in the result of the product rand(10000)*1i the 0 real part is forced to be stored in memory), then add them together to get a 2 x 763MB result (so now the total in memory is 5 x 763MB), before the first two temporary variables get deleted (getting rid of 3 x 763MB and leaving the 2 x 763MB result).

[dpb]

"Except that MATLAB doesn't see it that way..."

Precisely; that was my point re: "quality of implementation" (for lack of better nomenclature). That there are "issues" regarding memory on how it's used are certainly true but generally optimizers these days should be able to deal with what can be dealt with. If, otoh, the complex part is there, it's there and memory is required to deal with it (which may, depending upon how something is written, have the consequence one can't do as large a problem as one might if one took advantage of knowing a priori that the imaginary part is going to end up going away.

I'm not arguing strongly that it should be changed; simply noting that it fooled me after 30 year w/ Matlab as I was expecting it to be.

[James Tursa]

Once TMW embraced the philosophy of getting rid of identical 0 imaginary parts in calculation results, I think they were stuck. For the following two constructs:

a = 1 + 0i;

z = 0;
b = 1 + z*1i;

I think you could probably get a high percentage of votes that they should yield identical results for a and b (imaginary part physically removed), and another camp voting the opposite (the user typed in 0i explicitly so they must have wanted a complex result with 0 imaginary part physically present).