Alright, so i have two large complex values. Top, and Bottom:

Top = 4.0107e+030

Bot = 5.46725E26 -2.806428e26i

when i divide these two numbers in Math.Net's Complex32, it gives me a NaN for both the real and imaginray. I am assuming that it has smething to do with the precision.

When i use Matlab i get the following:

Top/Bot = 5.8060e+003 +2.9803e+003i

When i use System.Numerics i get something very close to matlabs, at least in the correct order of magnitute:

Top/Bot = +5575.19343780947 +2676.09270239214i System.Numerics.Complex

i wonder, which one is the right one? and why is Math.Net giving me a wrong answer I am running simulations and i very much care about the accuracy of the numerics? Anyway to fix this? i will be dealing with a lot of large complex numbers.

Plus, if anyone knows of a good Complex library for .net with support for special functions such as the complemetary error function and the error function of Complex parameters, that would be great. As i found out that Math.Net doesn't support cerf of a complex32

有帮助吗?

解决方案

If you care about accuracy you should obviously use the double precision/64 bit type, not the single precision/32 bit one. Note that we only provide a Complex32 but no Complex (64) type in the normal package because we want you to use the Complex type provided in System.Numerics for compatibility - we only provide an equivalent Complex (64) type in the portable build as System.Numerics is not available there.

But in this specific case, this is not a problem of precision (or accuracy), but about range. Remember that 32 bit floating point numbers can not be larger than ~3.4e+38. Computing a complex division in normal direct form requires computing the square of both real and imaginary components of the denominator, which in your case will get out of range and become "infinity" and thus NaN in the final result.

Now, it might be possible to implement the division in a form that avoids computing the square when the denominator is larger than about 1e+19, but we have not done that yet in Math.NET Numerics (as there was no demand for it up to now). This would also not be a problem if the complex type would implement the polar form, but that is quite uncommon.

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top