Re: [Rd] ifelse() woes ... can we agree on a ifelse2() ?
> Gabriel Becker
> on Tue, 15 Nov 2016 11:56:04 -0800 writes:
> All,
> Martin: Thanks for this and all the other things you are doing to both
> drive R forward and engage more with the community about things like this.
> Apologies for missing this discussion the first time it came around and if
> anything here has already been brought up, but I wonder what exactly you
> mean when you want recycling behavior.
Thank you, Gabe.
Note that my premise was really to get *away* from inheriting
too much from 'test'.
Hence, I have *not* been talking about replacing ifelse() but
rather of providing a new ifelse2()
[ or if_else() if Hadley was willing to ditch the dplyr one
in favor of a base one]
> Specifically, based on an unrelated discussion with Henrik Bengtsson on
> Twitter, I wonder if preserving the recycling behavior test is longer than
> yes, no, but making the case where
> length( test ) < max(length( yes ), length( no ))
> would simplify usage for userRs in a useful way.
I'm sorry I don't understand the sentence above.
> I suspect it's easy to
> forget that the result is not guaranteed to be the length of test, even
> for intermediate and advanced users familiar with ifelse and it's
> strengths/weaknesses.
> I certainly agree (for what that's worth...) that
> x = rnorm(100)
> y = ifelse2(x > 0, 1L, 2L)
> should continue to work.
(and give a a length 10 result).
Also
ifelse2(x > 0, sqrt(x), 0L)
should work even though class(sqrt(x)) is "numeric" and the one
of 0L is "integer", and I'd argue
ifelse2(x < 0, sqrt(x + 0i), sqrt(x))
should also continue to work as with ifelse().
> Also, If we combine a stricter contract that the output will always be of
> length with the suggestion of a specified output class
that was not my intent here but would be another interesting
extension. However, I would like to keep R-semantic silent coercions
such as
logical < integer < double < complex
and your pseudo code below would not work so easily I think.
> the pseudo code could be
(I'm changing assignment '=' to '<-' ... [please!] )
> ifelse2 <- function(test, yes, no, outclass) {
> lenout <- length(test)
> out <- as( rep(yes, length.out <- lenout), outclass)
> out[!test] <- as(rep(no, length.out = lenout)[!test], outclass)
> # handle NA stuff
> out
> }
> NAs could be tricky if outclass were allowed to be completely general, but
> doable, I think? Another approach if we ARE fast-passing while leaving
> ifelse intact is that maybe NA's in test just aren't allowed in ifelse2.
> I'm not saying we should definitely do that, but it's possible and would
> make things faster.
> Finally, In terms of efficiency, with the stuff that Luke and I are
working
> on, the NA detection could be virtually free in certain cases, which could
> give a nice boost for long vectors that don't have any NAs (and 'know'
> that they don't).
That *is* indeed a very promising prospect!
Thank you in advance!
> Best,
> ~G
I still am bit disappointed by the fact that it seems nobody has
taken a good look at my ifelse2() proposal.
I really would like an alternative to ifelse() in *addition* to
the current ifelse(), but hopefully in the future being used in
quite a few places instead of ifelse()
efficiency but for changed semantics, namely working for considerably
more "vector like" classes of 'yes' and 'no' than the current
ifelse().
As I said, the current proposal works for objects of class
"Date", "POSIXct", "POSIXlt", "factor", "mpfr" (pkg 'Rmpfr')
and hopefully for "sparseVector" (in a next version of the 'Matrix' pkg).
Martin
> On Tue, Nov 15, 2016 at 3:58 AM, Martin Maechler
> wrote:
>> Finally getting back to this :
>>
>> > Hadley Wickham
>> > on Mon, 15 Aug 2016 07:51:35 -0500 writes:
>>
>> > On Fri, Aug 12, 2016 at 11:31 AM, Hadley Wickham
>> > wrote:
>> >>> >> One possibility would also be to consider a
>> >>> "numbers-only" or >> rather "same type"-only {e.g.,
>> >>> would also work for characters} >> version.
>> >>>
>> >>> > I don't know what you mean by these.
>> >>>
>> >>> In the mean time, Bob Rudis mentioned dplyr::if_else(),
>> >>> which is very relevant, thank you Bob!
>> >>>
>> >>> As I have found, that actually works in such a "same
>> >>> type"-only way: It does not try to coerce, but gives an
>> >>> error when the classes differ, even in this somewhat
>> >>> debatable case :
>> >>>
>> >>> > dplyr::if_else(c(TRUE, FALSE), 2:3, 0+10:11) Error:
>> >>> `false` has type 'double' not 'integer'
>> >>> >
>> >>>
>> >>> As documented, if_else() is clearly stricter than
>> >>> ifelse() and e.g., also does no recycling (but of
>
Re: [Rd] ifelse() woes ... can we agree on a ifelse2() ?
Martin et al.,
On Tue, Nov 22, 2016 at 2:12 AM, Martin Maechler wrote:
>
> Note that my premise was really to get *away* from inheriting
> too much from 'test'.
> Hence, I have *not* been talking about replacing ifelse() but
> rather of providing a new ifelse2()
>
>[ or if_else() if Hadley was willing to ditch the dplyr one
>in favor of a base one]
>
> > Specifically, based on an unrelated discussion with Henrik Bengtsson
> on
> > Twitter, I wonder if preserving the recycling behavior test is
> longer than
> > yes, no, but making the case where
>
> > length( test ) < max(length( yes ), length( no ))
>
> > would simplify usage for userRs in a useful way.
>
That was a copyediting bug on my part, it seems I hit send with my message
only half-edited/proofread. Apologies.
That should have said that making the case where test is the one that will
be recycled (because it is shorter than either yes or no) an error. My
claim is that the fact that test itself can be recycled, rather than just
yes or no, is confusing to many R users. If we are writing an ifelse2 we
might want to drop that feature and just throw an error in that case.
(Users could still use the original ifelse if they understand and
specifically want that behavior).
Does that make more sense?
>
> > Also, If we combine a stricter contract that the output will always
> be of
> > length with the suggestion of a specified output class
>
>
Here, again, I was talking about the restriction that the output be
guaranteed to be the length of test, regardless of the length of yes and
no. That, combined with a specific, guaranteed output class would make a
much narrower/more restricted but also (I argue) much easier to understand
function. Particularly for beginning and intermediate users.
I do hear what you're saying about silent conversion, though, so what I'm
describing might be a third function (ifelse3 for lack of a better name for
now), as you pointed out.
> that was not my intent here but would be another interesting
> extension. However, I would like to keep R-semantic silent coercions
> such as
> logical < integer < double < complex
>
> and your pseudo code below would not work so easily I think.
>
> > the pseudo code could be
>
> (I'm changing assignment '=' to '<-' ... [please!] )
>
> > ifelse2 <- function(test, yes, no, outclass) {
> > lenout <- length(test)
> > out <- as( rep(yes, length.out <- lenout), outclass)
> > out[!test] <- as(rep(no, length.out = lenout)[!test], outclass)
> > # handle NA stuff
> > out
> > }
>
>
> > NAs could be tricky if outclass were allowed to be completely
> general, but
> > doable, I think? Another approach if we ARE fast-passing while
> leaving
> > ifelse intact is that maybe NA's in test just aren't allowed in
> ifelse2.
> > I'm not saying we should definitely do that, but it's possible and
> would
> > make things faster.
>
> > Finally, In terms of efficiency, with the stuff that Luke and I are
> working
> > on, the NA detection could be virtually free in certain cases, which
> could
> > give a nice boost for long vectors that don't have any NAs (and
> 'know'
> > that they don't).
>
> That *is* indeed a very promising prospect!
> Thank you in advance!
>
> > Best,
> > ~G
>
> I still am bit disappointed by the fact that it seems nobody has
> taken a good look at my ifelse2() proposal.
>
I plan to look at it soon. Thanks again for all your work.
~G
>
> I really would like an alternative to ifelse() in *addition* to
> the current ifelse(), but hopefully in the future being used in
> quite a few places instead of ifelse()
> efficiency but for changed semantics, namely working for considerably
> more "vector like" classes of 'yes' and 'no' than the current
> ifelse().
>
> As I said, the current proposal works for objects of class
>"Date", "POSIXct", "POSIXlt", "factor", "mpfr" (pkg 'Rmpfr')
> and hopefully for "sparseVector" (in a next version of the 'Matrix' pkg).
>
> Martin
>
> > On Tue, Nov 15, 2016 at 3:58 AM, Martin Maechler <
> maech...@stat.math.ethz.ch
> >> wrote:
>
> >> Finally getting back to this :
> >>
> >> > Hadley Wickham
> >> > on Mon, 15 Aug 2016 07:51:35 -0500 writes:
> >>
> >> > On Fri, Aug 12, 2016 at 11:31 AM, Hadley Wickham
> >> > wrote:
> >> >>> >> One possibility would also be to consider a
> >> >>> "numbers-only" or >> rather "same type"-only {e.g.,
> >> >>> would also work for characters} >> version.
> >> >>>
> >> >>> > I don't know what you mean by these.
> >> >>>
> >> >>> In the mean time, Bob Rudis mentioned dplyr::if_else(),
> >> >>> which is very relevant, thank you Bob!
> >> >>>
> >> >>> As I have found, that actually works in such a "same
> >> >>> type"-only way: It does not try to coerce, but gives an
> >>
Re: [Rd] shared libraries: missing soname
Dirk Eddelbuettel writes: > On 22 November 2016 at 00:02, Joseph Mingrone wrote: > | These are also not fatal errors on FreeBSD, where everything, for now, also > just > | works. ...until a library's interface changes. You seem to be arguing that > | sonmaes are pointless. We disagree. > You are putting words in my mouth. In my very first reply to you, I pointed > out that (for non-BSD systems at least) the sonames do not matter as R loads > the libraries itself, rather than via ldd. No more, no less. Let me restate. You seem to be arguing that, because R itself doesn't consume it's shared libraries via ldd(), sonames serve no purpose, in this case. Please correct me if I'm putting words in your mouth. > | I can't say for certain (I'm not an rkward user), but looking at the build > Why did _you_ then bring up rkward as an example? That was your suggestion. Because you asked, "Yes, well, but are there other customers?" Also, I'm trying to put myself in the perspective of package users. Is this a more appropriate example? # ldd /usr/local/lib/R/library/tseries/libs/tseries.so | grep libR libRblas.so => /usr/local/lib/R/lib/libRblas.so (0x80120c000) libR.so => /usr/local/lib/R/lib/libR.so (0x801c0) signature.asc Description: PGP signature __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
