Complex numbers in C#
-
It is not related to language-specific issues, but to floating point representation. Every language has these problems with basic floating-point data structures.
My concern isn't language specific nor floating point specific. I'd rather not trust anything running on a PC for high security purposes.
Wrong is evil and must be defeated. - Jeff Ello
-
But is it actually controlling the reactor?
Wrong is evil and must be defeated. - Jeff Ello
Not directly but a crash will cause an emergency stop. // E
-
Not directly but a crash will cause an emergency stop. // E
Ok, that's interesting. :~ I suppose it's not an off the shelf PC it's running on?
Wrong is evil and must be defeated. - Jeff Ello
-
Ok, that's interesting. :~ I suppose it's not an off the shelf PC it's running on?
Wrong is evil and must be defeated. - Jeff Ello
Everything runs on off the shelf pcs. That are 5+ years old. But on the other hand, the backups have backups. There's some really, REALLY old stuff in there that's custom built, but that's even more scary. That's it, I better stop before I bust some NDA and get SÄPO after my ass. =) // E
-
Everything runs on off the shelf pcs. That are 5+ years old. But on the other hand, the backups have backups. There's some really, REALLY old stuff in there that's custom built, but that's even more scary. That's it, I better stop before I bust some NDA and get SÄPO after my ass. =) // E
Oh fuck. :wtf: It's not like as if it's an unknown problem: Malware Discovered in German Nuclear Power Plant - Security News[^] But I really thought critical systems were running on a Safety-Critical System[^].
Wrong is evil and must be defeated. - Jeff Ello
-
Oh fuck. :wtf: It's not like as if it's an unknown problem: Malware Discovered in German Nuclear Power Plant - Security News[^] But I really thought critical systems were running on a Safety-Critical System[^].
Wrong is evil and must be defeated. - Jeff Ello
Two more words: Windows. XP. :'( // E
-
Well, I had to [try it in C++](https://godbolt.org/z/9ajWdG5j5)... ```c++ #include #include #include int main() { const auto a = std::complex{-1, 0}; const auto b = std::sqrt(a); std::cout << std::setprecision(20) << "sqrt" << a << " -> " << b << "\n"; } ``` and that output ``` sqrt(-1,0) -> (0,1) ``` in gcc and clang. And, as you have been a physicist, I figured maybe [Fortran](https://godbolt.org/z/Tzvhxv7s1) might be an alternative... ```fortran program test implicit none COMPLEX*8 a,b a = (-1,0) b = sqrt(a) write (*,*) a,b endprogram test ``` Guess what - sqrt(-1) == i there too: ``` (-1.00000000,0.00000000) (0.00000000,1.00000000) ``` And all the [other](https://godbolt.org/z/Wqa3zc9MY) [non .NET](https://godbolt.org/z/9z553jvee) [languages](https://godbolt.org/z/b8rGrqYce) I tried also gave the same answer... So I guess .NET is the outlier here! With all that, though, they're still missing the negative root :doh:
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
Are we sure that we are comparing like-with-like? The original answers were (6.12303176911189E-17, 1) or (6.12323399573677E-17,1) Your answers were (0.00000000,1.00000000) If you display 6.12303176911189E-17 in a non-exponent form, it will come out as 0.00000000 because it is a rounded version of 0.000000000000000006123... (I may have miscounted the zeros) So both answers may be representations of the same number. This is easy to test e.g. in FORTRAN which has an E format type for exponential and F for floating point.
-
Well, I had to [try it in C++](https://godbolt.org/z/9ajWdG5j5)... ```c++ #include #include #include int main() { const auto a = std::complex{-1, 0}; const auto b = std::sqrt(a); std::cout << std::setprecision(20) << "sqrt" << a << " -> " << b << "\n"; } ``` and that output ``` sqrt(-1,0) -> (0,1) ``` in gcc and clang. And, as you have been a physicist, I figured maybe [Fortran](https://godbolt.org/z/Tzvhxv7s1) might be an alternative... ```fortran program test implicit none COMPLEX*8 a,b a = (-1,0) b = sqrt(a) write (*,*) a,b endprogram test ``` Guess what - sqrt(-1) == i there too: ``` (-1.00000000,0.00000000) (0.00000000,1.00000000) ``` And all the [other](https://godbolt.org/z/Wqa3zc9MY) [non .NET](https://godbolt.org/z/9z553jvee) [languages](https://godbolt.org/z/b8rGrqYce) I tried also gave the same answer... So I guess .NET is the outlier here! With all that, though, they're still missing the negative root :doh:
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
That is awesome. Thank you.
cheers Chris Maunder
-
Well, I had to [try it in C++](https://godbolt.org/z/9ajWdG5j5)... ```c++ #include #include #include int main() { const auto a = std::complex{-1, 0}; const auto b = std::sqrt(a); std::cout << std::setprecision(20) << "sqrt" << a << " -> " << b << "\n"; } ``` and that output ``` sqrt(-1,0) -> (0,1) ``` in gcc and clang. And, as you have been a physicist, I figured maybe [Fortran](https://godbolt.org/z/Tzvhxv7s1) might be an alternative... ```fortran program test implicit none COMPLEX*8 a,b a = (-1,0) b = sqrt(a) write (*,*) a,b endprogram test ``` Guess what - sqrt(-1) == i there too: ``` (-1.00000000,0.00000000) (0.00000000,1.00000000) ``` And all the [other](https://godbolt.org/z/Wqa3zc9MY) [non .NET](https://godbolt.org/z/9z553jvee) [languages](https://godbolt.org/z/b8rGrqYce) I tried also gave the same answer... So I guess .NET is the outlier here! With all that, though, they're still missing the negative root :doh:
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
I had a message-passing algorithm written in MATLAB, but our SW Dev department wanted it written in C#. After I wrote it in C#, I found a numerical instability in the C# version. Later I wanted to run the same algorithm on a Spark Cluster, so I rewrote it again in Python. The MATLAB version running on my Windows 10 machine yields the same answers as the Python version (whether I run on my local machine or a Spark Cluster in Azure). The only fix I could find for C# was to round the output of one method to 11 or 12 decimal digits so that the numbers that ought to remain identical would remain identical. I think something funky is happening to double precision (maybe all floating point) calculations in .NET. Thanks for introducing me to GodBolt.org. I think it's going to be very useful.
-
Are we sure that we are comparing like-with-like? The original answers were (6.12303176911189E-17, 1) or (6.12323399573677E-17,1) Your answers were (0.00000000,1.00000000) If you display 6.12303176911189E-17 in a non-exponent form, it will come out as 0.00000000 because it is a rounded version of 0.000000000000000006123... (I may have miscounted the zeros) So both answers may be representations of the same number. This is easy to test e.g. in FORTRAN which has an E format type for exponential and F for floating point.
Ugh. Excellent point.
cheers Chris Maunder
-
Are we sure that we are comparing like-with-like? The original answers were (6.12303176911189E-17, 1) or (6.12323399573677E-17,1) Your answers were (0.00000000,1.00000000) If you display 6.12303176911189E-17 in a non-exponent form, it will come out as 0.00000000 because it is a rounded version of 0.000000000000000006123... (I may have miscounted the zeros) So both answers may be representations of the same number. This is easy to test e.g. in FORTRAN which has an E format type for exponential and F for floating point.
Good point! For C++, I would say so, as I turned precision up to 20, which should show 20 sig figs (I turned it up to 100 before posting, but went back down to 20 - wouldn't want to overdo it!). Fortran... I changed my sample to use this format: ```fortran write (*,fmt='(E18.10/)') a,b ``` and it wrote ``` -0.1000000000E+01 0.0000000000E+00 0.0000000000E+00 0.1000000000E+01 ``` so - looks like fortran is good too. Just need to work out how to format exponentials in Haskell, Go and Ada to verify those ones!
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
-
Two more words: Windows. XP. :'( // E
-
I was reading about complex numbers in C# and saw [this](https://docs.microsoft.com/en-us/dotnet/api/system.numerics.complex?view=net-5.0)
Complex minusOne = new Complex(-1, 0);
Console.WriteLine(Complex.Sqrt(minusOne));
// The example displays the following output:
// (6.12303176911189E-17, 1) on 32-bit systems.
// (6.12323399573677E-17,1) on IA64 systems.I'm curious: is there any reason one would not simply hardcode
Complex.Sqrt(-1)to equalnew Complex(0, 1);? The whole thing about complex numbers is they are based on the fundamental concept that i2 = -1. Why wouldn't you bake that in as an absolute and let the representational errors happen elsewhere? I get that actually detecting all cases of √-1 is tricky and messy at best, but it's not like you can actually compare, with arbitrary precision, two floating point values anyway. Future warning: if I ever get access to the .NET code in a way that lets me sneak in a change, then this will happen. It may cause manned spacecraft to veer off course and crash into the moon, or nuclear reactors to overheat and take out half a continent. But, dammit, √-1 will equal i.cheers Chris Maunder
To be precise Sqrt(-1) corresponds to (0,1) and (0,-1) complex values (+/-i). From the implementation point of view I believe simple cases to detect like this should be considered at the code level for avoid introducing calculations and corresponding errors for free. If the software can easily do better then it should.