Is this a bug? real(magsqr(z)) won't compile.

I have an equation that won't compile. A test function has narrowed the problem down to this:

Function TestMagSqr()
Variable result
variable /C radical
result= real(magsqr(radical)) // this gives a compiler error.


The compiler highlights "magsqr" and reports "function not available for this number type."

If I remove the function "real," it compiles fine.

I can work around the problem for my actual expression by defining a new "intermediate" variable, setting the variable equal to magsqr(radical), and using the intermediate variable in the expression, but I thought the forum might have ideas on what's happening.


I think this function does not compile because the syntax is really wrong. magsqr() is already returning a real number (the sum of the squares of the real and imaginary parts), so I do not know why you would want to apply real() to that. You might argue that the real part of a real number is nice and it should work, but the manual states that the input to real() must be a complex number. Also, I do not know how your intermediate variable works but I assume you are doing something like

Variable/C temp = magsqr(radical)

which just casts the real result of magsqr back into (the real part of) a complex number. Then you can apply real of course, but all you did was casting the variable type.

In reply to by chozo

Chozo, Thanks for taking a look.

I can see that if real(z) requires that z have an imaginary part, then the compiler would bark. However, I find that the compiler has no problem with real(A) where a is real variable.

But more to the point, I first found a problem when I used magsqr() in an expression like the one for "result" in the following code, which also does not compile for me:

Function TestMagSqr()
Variable result, A, B
variable /C radical
A= 2
B= 3
radical= sqrt(-1)

result= real(A + magsqr(radical)*B/radical)



OK, I see the point. Could well be that the compiler is confusing variable types when evaluating this expression. I guess it is a bug then or at least not expected. I am sorry, but I cannot help further with that. Let's wait until Monday comes around and have the staff a look (btw, if you need an answer fast, then it might be best to write an email to the support).

Igor's (not very bright) compiler is either in real or complex mode (ignoring string and integers for the moment.) When in complex mode, it does allow real literals and variables and promote those to complex. In your 

result= real(A + magsqr(radical)*B/radical)

the compiler starts out as real because the destination is real, then the function real()  switches to complex for its argument. So the A is allowed but the function magsqr is not as it is a real function only, that happens to switch to complex for its argument. Admittedly, magsqr could also have been defined as a complex function returning a zero imaginary part. But, for now, that is how it works.