pared down mod2pi pull request #4862
Conversation
…tants. for modpi(Int64), we check that the argument converts to a float64 losslessly, and throw an error otherwise.
This is kind of a painful edit since there's a lot of great work in here, but it's just too much to add three functions to Base. mod2pi seems like the most sensible of these functions. If we find that there is great need for the other versions, we can always resurrect them in the future by the wonders of git history.
|
So one issue is that there does seem to be a limit to the range in which this is accurate: julia> mod2pi(1e100)
5.892699463987461Wolfram|Alpha says the correct value is 3.52316061552557... |
|
cc: @fabianlischka |
|
Hi Stefan, well actually (sorry), 1e100 is a Float64, and it is not 10^100 (which is what WolframAlpha interprets it as), but rather (1+643957962097533/2^52)*2^332 or 10000000000000000159028911097599180468360808563945281389781327557747838772170381060813469985856815104. It might not be what the user intended, but it's hard to catch, because 1e100 comes in as a Float64. |
|
BTW, looks like you took out modpi and modpio2 (sniff...), but left them in the documentation (both files). |
|
The gaps between consecutive Float64 (while all integers) are rather severe there: :-) mod2pi becomes pretty meaningless there (though surprisingly accurate) |
|
Right. I wonder if we should check for it and throw an error or what. |
|
Good question, but I think we should NOT throw an error: a) where do you cut off? We know that from about 2^53 we can't represent every integer as a Float64, but maybe the user typed in an int that can be represented. Or maybe he typed in 0.5 plus that, and it got rounded. mod2pi() will return the result for the Float64 passed in, not for the decimal representation that the user typed in. We know that eps increases gradually. The Float64 could be off by eps/2 from the decimal the user typed in, so mod2pi could be off by eps/2 from the number the user intended. At which point do we cut off? This is a fundamental property of IEEE754 Float64s, not of the mod2pi function. b) Compare: Alpha: sin(1e100) But: And we don't throw an error for sin(x) for large x. |
|
Ah, yes. You are right, of course. I was forgetting that w|α was interpreting my 1e100 as an exact decimal value. |
|
+1 for adding a definition for τ to Julia. (I was meaning to propose this right before Tau Day this year, but just missed it...) |
|
Distributions.jl defines |
|
Perhaps we should just have |
|
+1 (am I allowed more than one vote? :-) On Wednesday, November 20, 2013, Stefan Karpinski wrote:
|
|
Bump. |
|
If you want to merge and then remove the extra docs for functions I deleted, go for it. I'm going to speak at Code Mesh in the morning, so I'm not going to mess with it now. |
pared down mod2pi pull request
This is a counterpoint pull request, building on the excellent work of #4799. It's basically purely editorial – I just removed (and moved) things. For a first pass, adding three functions to Base seems like far too much. I decided to keep
mod2piof the three originally introduced functions since it's the most sensible one, modding down to a single turn of the unit circle. I'm really beginning to agree with the "pi is wrong" sentiment – if we used τ instead of π thenmodtauwould be the unequivocal right choice.