-
Notifications
You must be signed in to change notification settings - Fork 40
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
Consider allowing default in quantile and median #132
Comments
Would make sense for Btw, |
Yes, but at least it does not throw an error in standard case (but indeed we could allow for providing the other value of default as
The reason is that |
Would be weird to have
Dunno, I like
Yeah, |
FWIW, R returns |
For However, if these functions all returned
|
These are all good ideas. But then the question is how to convert it to API in a non-breaking way? |
Maybe, |
Another idea is a general wrapper function so that the interface looks like |
It would be non-breaking, but I feared proposing it for such a common function 😄.
This general wrapper function would require special casing for each function passed as its first argument to be efficient. The point is that
But maybe it is good enough? |
Good point! I mostly considered applying functions to an actual materialized array, not to An advantage of OTOH, advantages of |
@nalimilan - what do you think? |
I don't think there's a precedent of a function that returns |
Some Julia functions throw an exception when no result is available (eg |
In general where possible I personally prefer special value-based behavior rather than error-based. For However, I understand the concern of @nalimilan that it requires a careful design so that we have one common solution rather than many special cases. E.g.
|
It's unfortunate, but is a fact, that functions in Julia tend not to really consider that # can distinguish these two:
julia> findfirst(x -> true, Dict(1 => 2))
1
julia> findfirst(x -> false, Dict(1 => 2))
# but not these two:
julia> findfirst(x -> true, Dict(nothing => 2))
julia> findfirst(x -> false, Dict(nothing => 2))
Potentially, |
Following this https://discourse.julialang.org/t/summarizing-grouped-dataframe-where-a-group-is-entirely-missing/90920/20?u=mreichmpi-bgc my 5 cents from a user perspective (and with a Tidyverse background as the most recent): I like the general wrapper In general I believe the user base will expand if such function are added, even at the expense of performance or other design aspects. |
I was thinking what is best and came to the conclusion that we could define somewhere:
(name is tentative) With In this post I have shown an example usage. |
I also like this solution, but wonder if it's possible to generalize in the following sense, while keeping simple and intuitive. Often, one wants to compute Maybe, there's some clean solution to both?.. Anything to borrow from R/others? |
We could define:
(I proposed adding defaults, but we could skip them). Then, by default we would have "return |
That sounds overkilll to me. The point of such a function is to be simple and convenient, as users can easily define other functions if needed. Actually we could almost have |
I would be also OK with such a solution as it likely covers most of the use cases. |
After reading @bkamins blog post I came here to suggest
It works for |
|
There are two points that can be considered:
|
BTW, I'm not totally sold on the argument order being Tangential, but I don't really like that the predicate functions we have are positive in the degenerate case rather than the good case. If there were better words for |
I really like that most. I like, when there are reasonable, intuitive defaults that cover most of the cases, but then allow the user to decide to make things as complicated as she/he wants. If would probably like to see these three functions (at least):
The last one would just allow avoiding typing I would like to be able to pass the
Agree - that's why I'd suggest having "catch" in the name, which makes it more intuitive logically IMO.
I really like the keyword version with defaults much more. Also I think for the user it is very important to have a consistent design, e.g. here always have |
Another idea for a general and convenient interface, that encompasses both isempty and length checks: iflength(median, 0 => NaN)(x) # NaN if x is empty
iflength(median, 0:3 => NaN)(x) # NaN if length(x) is <= 3 Also, no matter what predicates are incorporated, I believe
shouldn't be included by default. If anything, the default value should be |
Apart from the general solution discussed here, in JuliaData/Missings.jl#143 I propose adding |
Thanks @bkamins. Regarding the discussion about more general suggestions, note that this issue is currently in Statistics.jl, but it wouldn't be super logical to add such a general function in this package IMO. It's important to think about where it would go if that function was to be added. |
I agree. That is why I thought adding I thought, that once a consensus is reached about the API, a decision can be made where such a function should live (maybe even Base Julia if it is general enough) |
In generic code the fact that the following operations error:
is inconvenient (as the only work-around is try-catch). Maybe we could allow passing
default
kwarg that would be returned when the passed collection is empty?The text was updated successfully, but these errors were encountered: