For compatibility with Matlab, the result of 0*i is automatically converted to a real value but complex (0) is not. Octave doesnâ€™t have a special case for 1 / (0, 0) so you get the Inf - NaNi result from the C++ library division operator for std::complex<T> objects.

Thanks John. I can adjust the answer to Inf for my needs.
The code is doing a difference operation when it hits a NaN then it goes bad but Inf is ok.
I will add a line of code to fix this.

We could have a special case in the interpreter for the scalar case.

We could define and use our own complex<T> class to provide the special case so that we get more consistent behavior. But that still wonâ€™t fix the same problem that could occur in Fortran, C, or other C++ code.

But, I donâ€™t know, maybe we should just do what is compatible so that things appear to be â€ścorrectâ€ť.

Be aware that this expression replaces all NaN values with Inf. That includes values that might have resulted from, e.g., 0/0 (which in general isnâ€™t expected to result in Inf).

similar to why I also added on the isnan part. not knowing what matters where youâ€™re trying to fix this, Inf+3i is a valid number that would be lost if just checking for isinf(real(b))

Yeah. Depends on where you use it if Inf or Inf+3i actually mean something different for you. If they do, you could probably use b(isinf (real (b)) & isnan (imag (b))) = real (b); and maybe also b(isnan (real (b)) & isinf (imag (b))) = complex(0, imag (b));.