Merge history from StatsFuns #11
Conversation
Fix 0.4 deprecation warnings
Dual number compatibility
* Use the Rmath package since libRmath is gone in 0.5 * Add coverage to Travis * RIP 0.3 support * Set the git clone depth in the travis yml (thanks @tkelman)
…le function for the normal distribution. Use erfcinv to compute the quantiles of the normal distribution. Adjust test tolerance to be dependent on input type precision Fixes JuliaStats/Distributions.jl#516
Only convert back to input type for Float16 and Float32 in the quantile function for the normal distribution.
* Added handling of Infs and NaNs to logsumexp, with tests. This version avoids the Inf-Inf errors which (incorrectly) resulted in NaNs before, and also takes care to pass through actual NaNs. New tests for both vector and bivariate forms. 0.4.0 does not have Base.promote_op(f, T), hence the workaround.
* Add doc strings and explicit BigInt method for lstirling_asym. * Suppress warning on v0.7 * some minor changes. * Changes suggested by Simon B. and Andreas * Add link to DLMF. * Clean up tests with testset and Compat.Test * Add links to `lstirling_asym` * log -> \log * Allow failures on nightly Julia version
Remove calls to vectorization macros
Double backslashes in math expressions
This uses Julia's reduction functionality to improve the `logsumexp` functionality. It no longer relies on 1-based indexing, is fast on CuArrays, and there is now a generic fallback for iterable collections. I've also renamed the 2-arg `logsumexp` to `logaddexp`, since Julia convention is to use different functions for reductions and reducers (e.g. `max` vs `maximum`).
* Updates for 0.7 * Suppress tests on 0.6
Co-authored-by: John Myles White <johnmyleswhite@fb.com>
cleans up xlogy and logaddexp
|
Thanks. Where should one look to see the diff between StatsFuns and LogExpFunctions? I thought it would be in the merge commit, but it seems to be empty? |
|
It seems the merge commit was created automatically when I pulled in LogExpFunctions... The last commits show how I merged the different changes manually: https://github.com/JuliaStats/LogExpFunctions.jl/pull/11/files/e1fe1a4a979ce2e3fe48349069bd715383718e62..603a364503b5df08cbb3eaf574d6be536535d478 However, I assume it is easier to keep track of the changes by inspecting them one after another. |
|
That's weird. In case of conflicts I would have expected git to ask you to resolve them manually. How about squashing the relevant commits into the merge commit? That should be clearer when looking at the git history in the future. |
|
I could squash the last commits but I am not sure if it is helpful to squash them into the merge commit. The merge commit really just introduced the history and the files from LogExpFunctions but there were no actual merge conflicts to resolve. In this step I just ended up with duplicate implementations in different files (e.g. |
|
Ah got it, so that's because the files have different names. Maybe at least make it clear in commit messages which ones are just moving code around without modifying anything? Otherwise it's super hard to spot actual changes. |
Does not affect implementations.
Syncs list of exports with StatsFuns.
Implementation unaffected, only reorganizes code in a similar way as in LogExpFunctions 0.2.0
|
I squashed and reorganized the manual commits. I also added some more detailed explanation in the commit messages. |
This PR adds the git history from StatsFuns extracted with
and merges it with the modified docstrings in this repo. Additionally, the list of exports is synced with StatsFuns and now additionally the constants and aliases are exported.