Teie kommentaarid
This is true for pure theoretical & rigorous world. But for computations, there are a lot of cases when algorithms change numbers from real to complex automatically. All matrix functions detect if input is pure real (even if it is stored as complex) to use real-tailored algorithms since they are way faster. Same for routines which might generate complex outputs, e.g. sqrt(-1), eig, etc.
The system which rigorously treats reals as subset of complex numbers just doesn't exist in practice (I think). Instead complex-rules are applied only where necessary, depending of situation. I tried to investigate this in short notes here: http://www.advanpix.com/2015/10/19/devnotes-1-multiplicative-operations-with-complex-infinity
I promise that I will implement this storage format as soon as I see its importance in some application :).
(The only important case I see is complex infinities, but again MATLAB converts real to complex automatically in this case - so should do the toolbox)
Also whole family of subs*** methods should be changed, and others. Plus overhead of detecting the pure reals before every operation (one pass over array) and many other complications.
Anyway it is doable of course, but the question is do we need this at all :).
Thank you very much for your insights!
Toolbox does follow MATLAB syntax and semantic to the maximum possible extent.
Along the way I add/remove some features (which do not harm the whole idea).
I thought about this particular feature of having real number as complex - I couldn't come up with any mathematical code which can benefit from this. Why it is needed?
I would understand if MATLAB would allow +/- zeros - then this feature would be vital for branch cuts, etc.
But now,when there is only one zero - this feature is pointless from computational point of view.
Could you please educate me with some computational/math code where this might be important?
I haven't seen one so far (possibly working with complex infinities?)
Other math systems have no such feature as well (as far as I know). Usually complexity of numbers are automatically detected and treated as such.
I would greatly appreciate example of real-life code where storage format of a real number is important.
In reality, complex(12) setups the storage format of a number, not the semantic - since it is treated as real number in all mathematical operations anyway. Thus I concluded it was related to legacy storage format in MATLAB.
Please teach me where my reasoning is wrong.
This happens because you added the line to double():
if ~(mp.OverrideDoubleBasicArrays && ismp(x))
Now ip = triperm('H',double(a)) in MSCALE doesn't work since double() produces mp-numbers anyway.
This is related to your another ticket: https://mct.userecho.com/topics/50-overridedoublebasicarrays-option-and-double-method/
@"On the other hand, in "classic" Matlab, no one uses the builtin function "double" with explicit intentionality to reduce the precision for data"
This is very true. However, in case of multiprecision, user needs double() for reducing precision in many cases.
For example, for plotting, or for passing mp-arrays to internal MATLAB's MEX modules (as we did for ip = triperm('H',double(a));)
My idea is to overload all implicit floating-point functionality.
But, user should have possibility to switch to double, by using explicit conversion function.
Thank you very much for excellent report(s)!
The second issue (complex(0,mp(pi)*rand(0,1))) has been fixed in our trunk - will be available in a few days.
Corner cases with empty inputs are nightmare - code becomes macaroni type.
But the first issue (complex(mp(12))) is not a bug. It is by design :).
Toolbox automatically detects if numbers are complex or real. There is no point to push the user to do this manually.
I believe Matlab allows real numbers (without imaginary part) to assign as complex for historical reasons. Probably they needed to pre-allocate planar memory or similar.
But there is no practical reason for this right now, especially for toolbox where memory architecture is very different. So that toolbox just does nothing if user assigns pure real number as complex - this doesn't influence subsequent math functionality.
Or do you know the case when it is needed from mathematical point of view? I might miss something here.
Thank you very much for correction!
I have added both types of cast to mp class - cast(A,'mp') and cast(A,'like',B).
But I prefer to avoid intermediate conversion to double like this:
try r = eval([newclass,'(A)']); catch, r = eval([newclass,'(double(A))']); end %<-----
Also I added test matrices - hilb, invhilb, hadamard, pascal, magic, rosser, wilkinson. Now all of them can create mp-matrices with last parameter classname='mp':
>> magic(3,'mp')
Would greatly appreciate if you would test the new version. Let me know if you find anything strange
Customer support service by UserEcho
You are absolutely right.
I changed semantic of 'isreal' on purpose, with the idea to improve MATLAB.
Now 'isreal' checks if array is pure real (imag(x)==0), independently of how it was created.
Back then I saw no serious consequences for this change. Probably I need to re-think this.