Since you and Antoine are volunteering to do the work, why not start in
the way I suggested? Write up a comparison of the known ifelse
implementations, and either pick the best one, or choose the best parts
of each. Put the result in a package containing nothing else, and
invite comment from the wider community.
My only comment in advance is that the package should have no
dependencies other than base packages, for two reasons:
1. The hope is to have it adopted in base R, and for that it can't have
any other dependencies.
2. If it's never adopted by R Core, I might still want to use it, but I
don't want to add extra dependencies for just one little function.
Duncan Murdoch
On 2025-07-08 12:46 p.m., Josiah Parry wrote:
Avi, appreciate the puns!
I don't think anyone is suggesting R-core dedicate all of their time to
this problem.
To me, the thread is about consensus making (as there is no formal way to
do that).
Quoting OP here:
"It's not about asking others to do it really, that was a harsh assumption.
I'd be happy to propose a version if it helps, I'd be also very happy if it
were just a copy of if_else or fifelse (both MIT FWIW)."
The initial email, IMO, was to show that there already are community
implementations of faster
and type-safer of ifelse (notably dplyr and data.table and I'd add
kit::iif, too) and perhaps now
is the time to add this enhancement to the language.
It is tough to get a sense of total usage of each though but some code
searching on GitHub:
- data.table::fifelse:
https://github.com/search?q=%22fifelse%28%22+language%3AR&type=code
- dplyr::if_else:
https://github.com/search?q=%22if_else%28%22+language%3AR&type=code
- kit::iif:
https://github.com/search?q=%2F%28%3F-i%29iif%5C%28%2F+language%3AR+&type=code
On Tue, Jul 8, 2025 at 8:23 AM Avraham Adler <avraham.ad...@gmail.com>
wrote:
On Tue, Jul 8, 2025 at 10:55 AM Josiah Parry <josiah.pa...@gmail.com>
wrote:
I think the point is not that there needs to be a smaller package for yet
another if-else (https://xkcd.com/927/). It is that if the R-language,
as a
whole, had a performant if-else in the base of the language would benefit
**everyone** such that a data.table or dplyr or gtools etc. alternative
would not be necessary.
While that may be true, Josiah, R Core's time is very limited.
Following Duncan's idea, if a small, simple package were created and
was proven to dominate the performance of standard ifelse without
causing any issues with the ten thousand plus packages in the R
environment, that would make R Core's decision much simpler, whether
or not to use the existing, proved performant code. Asking R Core to
do the research and testing for something which currently _works_,
albeit not in the most efficient way possible, is pretty much a
non-starter. Do as much work as possible for R Core to have even a
possibility of consideration. For something similar, albeit much less
core (pun intended) to R's code, see this discussion [1] from June
2012 on Kendall's tau, where the code already existed but was deemed
unimportant enough to add to base R.
[1] https://stat.ethz.ch/pipermail/r-devel/2012-June/064351.html
Thanks,
Avi
On Tue, Jul 8, 2025 at 5:09 AM Ben Bolker <bbol...@gmail.com> wrote:
I think Duncan's point is that R-core are (reasonably) very, very,
very conservative about adding things to base R. It would be useful to
the community, and would indeed further the discussion, to make a tiny
package containing just that function. (Even just copying it from some
other package might require some work to disentangle it from
dependencies: for example, a quick glance at dplyr::if_else shows that
it uses functions from rlang, vctrs, ...)
I'd be happy to accept a pull request in `gtools`, which is a
zero-dependency (except base R) package for small utility functions ...
cheers
Ben Bolker
On 7/8/25 07:36, Antoine Fabri wrote:
It's not about asking others to do it really, that was a harsh
assumption.
I'd be happy to propose a version if it helps, I'd be also very
happy if
it
were just a copy of if_else or fifelse (both MIT FWIW).
It's a low level building block and it's broken, IMO it's way better
to
have it available and documented in base R and incite everyone to
use it,
so not only we don't suffer from it in the code we write, but also
in the
code we use or inherit from.
Le mar. 8 juil. 2025 à 13:25, Duncan Murdoch <
murdoch.dun...@gmail.com>
a
écrit :
Rather than asking others to do this, why don't you create a tiny
package containing nothing other than an ifelse() replacement? I
wouldn't want to depend on dplyr or data.table just to get their
versions, but depending on your tiny package wouldn't be an issue.
Duncan Murdoch
On 2025-07-08 6:12 a.m., Antoine Fabri wrote:
Dear r-devel,
`ifelse()` has a lot of issues, and for these reasons it has been
redone
in
`dplyr::if_else()` and `data.table::fifelse()`, which are both
great.
Yet
it's an important base R function, it's really hard to program in
base
R
without it and scores probably as high as it gets in the most_used
*
most_problematic metric.
Obviously we can't change it without breaking a ton of code, but
with
all
the experience we now have with it and the dplyr and data.table
alternative
maybe it might not be absurd to have a good alternative, say
`if.else`
in
base R, that we can document on the same page and recommend for
future
use.
It would require a common type in yes/no, not return logical() for
all
zero
length input, work with dates, datetimes and factors, handle a na
condition
etc. The test suites of dplyr and data.table probably tell us
everything
about the edge cases we want to look at. Maybe the old ifelse could
even
warn when called from the top level, to incite us to work with the
new
one.
It feels wrong to me to be stuck with ifelse() forever just
because it
has
been like this for a long time. I'm sure some of you learnt your
way
around
it but I work with R every day and after 10+ years of R it still
bites
me
all the time, I'm probably not alone, at least chatGPT called it a
"footgun", and we don't want that :).
Thanks,
Antoine
[[alternative HTML version deleted]]
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[[alternative HTML version deleted]]
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Dr. Benjamin Bolker
Professor, Mathematics & Statistics and Biology, McMaster University
Director, School of Computational Science and Engineering
* E-mail is sent at my convenience; I don't expect replies outside of
working hours.
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[[alternative HTML version deleted]]
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[[alternative HTML version deleted]]
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
