-
Notifications
You must be signed in to change notification settings - Fork 190
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
Make PValue and TestStat behave like Reals #668
Conversation
src/statmodels.jl
Outdated
@@ -460,6 +460,14 @@ struct PValue | |||
end | |||
PValue(p::PValue) = p | |||
|
|||
float(p::PValue) = float(p.v) | |||
|
|||
for op in [Symbol("=="), :≈, :<, :≤, :>, :≥] |
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.
for op in [Symbol("=="), :≈, :<, :≤, :>, :≥] | |
for op in [:(==), :≈, :<, :≤, :>, :≥] |
Maybe also define isequal
and isless
?
Actually I wonder whether it would be simpler to define promote_type(::Type{PValue{S}}, y::T) where {S, T<:Real} = promote_type(S, T)
, making S
a type parameter with v::S
. Then I think we'll get all operations on numbers defined for free.
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.
You get isequal
and isless
for free with the symbolic forms (and I use isequal
and isless
) in the tests.
I was also thinking about whether promote_type
might be the easier route. I'll try that later. :)
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 yes so isless
falls back to <
, but it's not correct for NaN
, right?
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.
Uh.... good question
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.
Oh wait, I know why I didn't do promote_type
: that would be technically breaking, both for PValue
and TestStat
. We're pre 1.0 so another release isn't a big deal. But that might be something to get one more opinion on (e.g. @ararslan).
(I also want PValue
and TestStat
to have a consistent interface between themselves since they're both essentially just pretty printers for a semantically annotated Real
.)
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.
You mean it would be breaking if you do something like [pval, 1.0]
? Yes that would be slightly breaking so that would probably warrant tagging a minor release.
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.
Yeah, and adding a type parameter to a struct also breaks (de)serialization.
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.
Maybe let's keep your current approach then, and only use promote_type
in another PR that would be merged only once we have other breaking changes to tag.
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.
As soon as this one (and CoefTable show method) lands, I'll open that PR 😄
Co-Authored-By: Milan Bouchet-Valat <[email protected]> Co-authored-by: Alex Arslan <[email protected]>
Damn, this is really tricky. Since we now define AFAICT that's the case thanks to the Out of curiosity, in what use case did you feel the need to this? :-) I realize that |
Hahahahah, I'll add this as well. And as soon as we get this and the
We had something at the dayjob where there was some conditional behavior based on a p-value threshold (I know, I don't like it either, but so much of the applied stats world still does that). In one instance, the p-values were already wrapped for pretty printing (and expensive to re-compute) and we had to add the filter at the very end. When doing that, I noticed that |
Thanks!
OK. But do you mean you get |
Uh.... I don't know. (We're not using |
...come to think of it, how did we end up with |
A custom And when this comparison wasn't implemented, everything broke. |
PValue
andTestStat
show(::TestStat)
PValue
a subtype ofReal