-
Notifications
You must be signed in to change notification settings - Fork 51
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Imprecision of complex natural logarithm for arguments close to 1 #122
Comments
What is the basis for your expected answer? e.g. Wolfram Alpha says something even more different, although I'm sure that isn't accounting for the error in the floating point representation we're working with.
Still the current implementation here is pretty naive: Lines 239 to 243 in 0eb3e90
Improvements are welcome! |
My reference value is from Mathematica 13.3.0. I've written the input value
I am pretty confident that Mathematica's result is correct, because one obtains the same result with a Taylor expansion, evaluated in terms of rational numbers (increasing the order of the Taylor polynomial does not change the result):
I've cross-checked with julia, which even gives a different answer: z = 0.999995168714454 - 0.004396919500211628im;
log(z) # yields: 4.835153291589251e-6 - 0.0043969124079359465im |
That ratio is not the input we have here, nor the 17-digit decimal approximation, but rather a pair of
Julia's answer looks really good! |
Thank a lot for this excellent comment! You are of course right! :) Just for my understanding: My reference value for Anyway, I think it is possible to mimic the julia implementation (or any other appropriate one) to obtain a more precise value for the complex logarithm. |
Even further, the decimal value that you wrote in your source does not match the binary |
I found that in version 0.4.5 for complex numbers close to 1 the implementation of the complex logarithm
ln
looses many digits of precision:Link to rust playground: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=d300b26da9fc5bed4304f52b99989386
To my knowledge there are algorithms to avoid such problems, for example by scaling the magnitude of the complex number accordingly.
The text was updated successfully, but these errors were encountered: