Re: Strange run time problem with complex numbers

[michaell]

Interesting observation.

I think that this is a consequence of the fact that octave will
automatically restrict any complex array to type double if all imaginary
parts are equal to zero. So if you copy (a part of) a matrix into another
matrix, octave has to check whether the result will be complex or not. It
will be complex if either at least one of the elements of the range to be
copied are complex, or if at least one of the elements in the target array
that are not overwritten are complex (or if both conditions are true).
Testing seems to show that for complex arrays octave stores some overhead
information whether subranges of elements are all real or not. Otherwise, if
you had a really large array where just one element has non-zero imaginary
part, and you overwrite it by a real value, it would have to test all other
values to decide whether it should convert the resulting array to real or
not. 

In any case, that explains your observation. Starting from below: Initially,
Y is real, and if it knows that also the first 2*M entries of X are real, it
could be certain that Y will always stay real. If all elements of X are
complex, it would immediately convert Y to complex and leave it at that.
Also if only the first entry of X is complex, this would suffice to make Y
immediately complex, and this first entry (actually the whole first column)
would never be overwritten. While with the first line, in each loop it has
to look over the range to be copied until it finds a complex value, to be
sure what to write into its overhead information about Y. 

I do not know if this is the optimal solution: assigning setting one element
of an already complex array to another complex value takes much, much longer
than doing the same for real values, where I do not see how this should be
necessary. Interesting that matlab behaves in just the same way. 

What I find particularly noteworthy is the following (note that I used
M=2000): if with uncommented first option after initializing Y you set its
entry at (2,1) to a complex value, it is fast. In each loop iteration octave
seems to be able to recognize that at least this element will always stay
complex, thus the array will stay complex and it need not make more effort.
However, if you shift the position of this entry for instance to (1,N), it
takes even much longer than without it! Seems like a Schlemiel the
painter-situation. So there definitely does seem to be room for improvement.
Perhaps somebody with insight into the actual code can explain what really
happens here.



--
Sent from: https://octave.1599824.n4.nabble.com/Octave-General-f1599825.html