-
Notifications
You must be signed in to change notification settings - Fork 194
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
move statistics.jl and related methods from Base to StatsBase #379
move statistics.jl and related methods from Base to StatsBase #379
Conversation
this commit removes cor, cov, median, median!, middle, quantile, quantile!, std, stdm, var, varm and linreg and moves them to StatsBase fix #25571 (comment) (included in JuliaStats/StatsBase.jl#379) fix #23769 (included in JuliaStats/StatsBase.jl#379) fix #27140
Codecov Report
@@ Coverage Diff @@
## master #379 +/- ##
=========================================
- Coverage 90.58% 80.78% -9.8%
=========================================
Files 19 20 +1
Lines 2028 2274 +246
=========================================
Hits 1837 1837
- Misses 191 437 +246
Continue to review full report at Codecov.
|
fix #25571 (comment) (included in JuliaStats/StatsBase.jl#379) fix #23769 (included in JuliaStats/StatsBase.jl#379) fix #27140
fix #25571 (comment) (included in JuliaStats/StatsBase.jl#379) fix #23769 (included in JuliaStats/StatsBase.jl#379) fix #27140
fix #25571 (comment) (included in JuliaStats/StatsBase.jl#379) fix #23769 (included in JuliaStats/StatsBase.jl#379) fix #27140
8fe4df1
to
2c7f670
Compare
test/misc.jl
Outdated
@@ -24,17 +24,17 @@ b = [true, false, false, true, false, true, true, false] | |||
|
|||
# indicatormat | |||
|
|||
I = [false true false false false; | |||
II = [false true false false false; | |||
true false false false true; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Adjust alignment.
test/runtests.jl
Outdated
|
||
@static if StatsBase.BASESTATS_IN_STATSBASE | ||
using Random | ||
const Compatvar = var |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Couldn't we just shadow the standard var
, etc. functions instead of defining separate ones?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since var
and Compat.var
are different functions on 0.6 I couldn't come up with a better solution. How did you mean?
I don't think it matters much, presumably StatsBase
will drop 0.6 when 0.7 is released anyway, and then these will all just be var
without Compat
being involved.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was thinking of something like const var = StatsBase.var
in one branch, and const var = Compat.var
in the other one. The point is precisely to limit as much as possible the changes that will have to be applied manually when dropping 0.6 support.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But
const var = Compat.var
would mean that StatsBase
extend the unexported Compat.var
and people will have to use a fully qualified name for this. In addition, that would mean StatsBase
would export the unexported Compat.var
and break things...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is just a test file, it doesn't affect what users see at all AFAICT.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, right, was thinking about the same case we have in the source file. But again, I don't think we can do that since they are two different functions, and we use them both.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, let's keep it that way then.
test/runtests.jl
Outdated
@@ -22,6 +34,11 @@ tests = ["ambiguous", | |||
"statmodels"]#, | |||
#"statquiz"] | |||
|
|||
@static if StatsBase.BASESTATS_IN_STATSBASE |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Couldn't this be run even on 0.6? If needed, StatsBase can reexport Base functions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since the test in this file have been changed multiple times while it was in base I don't think so.
test/statistics.jl
Outdated
|
||
using Test, Random, LinearAlgebra, SparseArrays | ||
|
||
if true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Need to use StatsBase.BASESTATS_IN_STATSBASE
?
I've added comments I had prepared based on the previous state of the PR. Some still appear to be relevant. BTW, we should find a better file name than statistics.jl. |
Does it really matter what this is called? I assume that once 0.6 support is dropped we will just split this file and distribute the functions to the right place. |
Maybe call it base.jl then? |
2c7f670
to
53d5024
Compare
fix #25571 (comment) (included in JuliaStats/StatsBase.jl#379) fix #23769 (included in JuliaStats/StatsBase.jl#379) fix #27140
fix #25571 (comment) (included in JuliaStats/StatsBase.jl#379) fix #23769 (included in JuliaStats/StatsBase.jl#379) fix #27140
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's merge and tag soon since the functions have been removed from Base. Just needs to adjust the check based on the Julia version.
src/StatsBase.jl
Outdated
@@ -193,11 +193,24 @@ module StatsBase | |||
export midpoints | |||
end | |||
|
|||
const BASESTATS_IN_STATSBASE = false # VERSION >= v"1.2.3" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Need to update this now that PR has been merged in Julia?
Note the |
53d5024
to
72896d2
Compare
@fredrikekre Is the version check updated and this ready to go? |
Yes. |
Docstrings for new functions do not appear in the manual, but I guess that's just because we currently deploy it from Julia 0.6? |
I actually didn't think about the docs, but yea, they don't appear in StatsBase on julia 0.6 at all so thats also why. IMO the simplest thing for StatsBase would be to drop 0.6 at this point. |
At least we could switch to deploying docs from 0.7, assuming it becomes a supported choice on Travis once the alpha is released. |
Um, this interacts badly with Compat. Compat provides its own |
I side stepped that, see #379 (comment) |
So, what I'd like to see is to have e.g. |
Wouldn't that require |
My idea would be to export |
If that doesn't work, maybe a The two options I see is duplicating the code from here to Compat or moving the code from Compat here. Obviously, I'd favor moving code over duplicating it. Well, a third option would be to create a new package |
I agree with @martinholters. We should:
|
This would be very much simpler if we could have separate branches for pre and post 0.7.0-DEV.5238 |
Ah, some of those functions had already been extended in StatsBase, right? Then having them suddenly be distinct, unexported functions seems like a no-go. I can try to prepare a PR, putting the code from Compat into a |
I guess it's fine to make different branches if that helps. |
I don't see how that would help much. Wouldn't we still need to provide e.g. two different |
That seems like the simplest approach, and direct
I am trying this now, should be doable.
Then we can do e.g. |
Of course! If that pans out, it would be better than the submodule approach, I think. Only if people had been doing |
After trying some I think that the submodule is much simpler, albeit uglier. I think most users have not upgraded yet anyway, and when they do they will likely drop 0.6 right away, meaning that this ugly middle ground might not be visible that much. Some other things that complicates this is that |
Are you working on it or should I give it a shot? |
fix JuliaLang/julia#25571 (comment) (included in JuliaStats/StatsBase.jl#379) fix #23769 (included in JuliaStats/StatsBase.jl#379) fix #27140
fix JuliaLang/julia#25571 (comment) (included in JuliaStats/StatsBase.jl#379) fix #23769 (included in JuliaStats/StatsBase.jl#379) fix #27140
fix JuliaLang/julia#25571 (comment) (included in JuliaStats/StatsBase.jl#379) fix #23769 (included in JuliaStats/StatsBase.jl#379) fix #27140
fix JuliaLang/julia#25571 (comment) (included in JuliaStats/StatsBase.jl#379) fix #23769 (included in JuliaStats/StatsBase.jl#379) fix #27140
See JuliaLang/julia#27152
This passes on Julia
v0.6.2
,master
, and onfe/stats
.