Re: [Rd] named arguments discouraged in `[.data.frame` and `[<-.data.frame`
Thanks Bill and Michael for taking the time to share your knowledge!
As a further background to my question, here are two examples that I forgot to
include in my original post (reminded by Michael's answer). I swapped the i and
j arguments in `[.data.frame` and `[<-.data.frame`. With warnings, but else
without (?) problem. Using Bill's data:
`[.data.frame`(x = d, i = 1, j = 2)
# [1] 12
`[.data.frame`(x = d, j = 2, i = 1)
# [1] 12
And similar for `[<-.data.frame` :
`[<-.data.frame`(x = d, i = 1, j = 2, value = 1122)
`[<-.data.frame`(x = d, j = 2, i = 1, value = 12)
Because this seemed to work, I made the hasty conclusion that argument
switching _wasn't_ a problem for `[.data frame`, and that we could rely on
exact matching on tags. But apparently not: despite that `[.data.frame` and
`[<-.data.frame` are _not_ primitive functions, positional matching is done
there as well. Sometimes. At least when 'x' argument is not first, as shown in
Bill's examples. Obviously my "test" was insufficient...
Cheers,
Henrik
From: William Dunlap
Sent: Wednesday, November 28, 2018 9:10 PM
To: Henrik Pärn
Cc: r-devel@r-project.org
Subject: Re: [Rd] named arguments discouraged in `[.data.frame` and
`[<-.data.frame`
They can get bitten in the last two lines of this example, where the 'x'
argument is not first:
> d <- data.frame(C1=c(r1=11,r2=21,r3=31), C2=c(12,22,32))
> d[1,1:2]
C1 C2
r1 11 12
> `[`(d,j=1:2,i=1)
C1 C2
r1 11 12
Warning message:
In `[.data.frame`(d, j = 1:2, i = 1) :
named arguments other than 'drop' are discouraged
> `[`(j=1:2,d,i=1)
Error in (1:2)[d, i = 1] : incorrect number of dimensions
> do.call("[", list(j=1:2, i=1, x=d))
Error in 1:2[i = 1, x = list(C1 = c(11, 21, 31), C2 = c(12, 22, 32))] :
incorrect number of dimensions
Bill Dunlap
TIBCO Software
wdunlap http://tibco.com
On Wed, Nov 28, 2018 at 11:30 AM Henrik Pärn wrote:
tl;dr:
Why are named arguments discouraged in `[.data.frame`, `[<-.data.frame` and
`[[.data.frame`?
(because this question is of the kind 'why is R designed like this?', I though
R-devel would be more appropriate than R-help)
#
Background:
Now and then students presents there fancy functions like this:
myfancyfun(d,12,0.3,0.2,500,1000,FALSE,TRUE,FALSE,TRUE,FALSE)
Incomprehensible. Thus, I encourage them to use spaces and name arguments, _at
least_ when trying to communicate their code with others. Something like:
myfancyfun(data = d, n = 12, gamma = 0.3, prob = 0.2,
size = 500, niter = 1000, model = FALSE,
scale = TRUE, drop = FALSE, plot = TRUE, save = FALSE)
Then some overzealous students started to use named arguments everywhere.
E-v-e-r-y-w-h-e-r-e. Even in the most basic situation when indexing vectors (as
a subtle protest?), like:
vec <- 1:9
vec[i = 4]
`[`(x = vec, i = 4)
vec[[i = 4]]
`[[`(x = vec, i = 4)
vec[i = 4] <- 10
`[<-`(x = vec, i = 4, value = 10)
...or when indexing matrices:
m <- matrix(vec, ncol = 3)
m[i = 2, j = 2]
`[`(x = m, i = 2, j = 2)
# 5
m[i = 2, j = 2] <- 0
`[<-`(x = m, i = 2, j = 2, value = 0)
##
This practice indeed feels like overkill, but it didn't seem to hurt either.
Until they used it on data frames. Then suddenly warnings appeared that named
arguments are discouraged:
d <- data.frame(m)
d[[i = "X2"]]
# [1] 4 5 6
# Warning message:
# In `[[.data.frame`(d, i = "X2") :
# named arguments other than 'exact' are discouraged
d[i = 2, j = 2]
# [1] 0
# Warning message:
# In `[.data.frame`(d, i = 2, j = 2) :
# named arguments other than 'drop' are discouraged
d[i = 2, j = 2] <- 5
# Warning message:
# In `[<-.data.frame`(`*tmp*`, i = 2, j = 2, value = 5) :
# named arguments are discouraged
##
Of course I could tell them "don't do it, it's overkill and not common
practice" or "it's just a warning, don't worry". However, I assume the warnings
are there for a good reason.
So how do I explain to the students that named arguments are actively
discouraged in `[.data.frame` and `[<-.data.frame`, but not in `[` and `[<-`?
When will they get bitten?
__
mailto: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
Re: [Rd] named arguments discouraged in `[.data.frame` and `[<-.data.frame`
Well, the situation with `[.data.frame` (and [<-) is complicated by the fact
that the data.frame-method is not a primitive, but the generic IS.
I'm not sure about dispatch for primitive-generics, but I bet it's done on the
first argument (as with S3). Which means `[`(j=1:2,d,i=1) has nothing to do
with `[.data.frame`, as some internal code equivalent to something like
`[.integer` is called (`[.integer` is not an R-function, but I guess it's
implemented in the C-code for `[`)
And note that `[.data.frame`(j=1:2,d,i=1) does work (throws a warning, but
returns the right result), because then you're simply calling the direct
R-function, and matching by name is done.
But I think the main reason for the warning is forwards compatibility (and
maybe backwards?). As of this version, `[.data.frame`(x = d, j = 2, i = 1)
works fine, and `[.data.frame` is a regular R-function. But it's used a lot, I
wouldn't be surprised if some future R-version would implement it as a
primitive.
Without the warning, implementing [.data.frame as a primitive would involve a
LOT of issues where older code breaks. With the warning, we can make clear to
any users that calls like this one are undefined. They may work for now, but
one shouldn't rely on it. Which means only the "right" order may be used, and
then naming them is superfluous.
By the way, when trying some things I noticed something else, which I'll send a
separate mail about...
Cheers,
Emil
On 29/11/2018, 09:20, "R-devel on behalf of Henrik Pärn"
wrote:
Thanks Bill and Michael for taking the time to share your knowledge!
As a further background to my question, here are two examples that I forgot
to include in my original post (reminded by Michael's answer). I swapped the i
and j arguments in `[.data.frame` and `[<-.data.frame`. With warnings, but else
without (?) problem. Using Bill's data:
`[.data.frame`(x = d, i = 1, j = 2)
# [1] 12
`[.data.frame`(x = d, j = 2, i = 1)
# [1] 12
And similar for `[<-.data.frame` :
`[<-.data.frame`(x = d, i = 1, j = 2, value = 1122)
`[<-.data.frame`(x = d, j = 2, i = 1, value = 12)
Because this seemed to work, I made the hasty conclusion that argument
switching _wasn't_ a problem for `[.data frame`, and that we could rely on
exact matching on tags. But apparently not: despite that `[.data.frame` and
`[<-.data.frame` are _not_ primitive functions, positional matching is done
there as well. Sometimes. At least when 'x' argument is not first, as shown in
Bill's examples. Obviously my "test" was insufficient...
Cheers,
Henrik
From: William Dunlap
Sent: Wednesday, November 28, 2018 9:10 PM
To: Henrik Pärn
Cc: r-devel@r-project.org
Subject: Re: [Rd] named arguments discouraged in `[.data.frame` and
`[<-.data.frame`
They can get bitten in the last two lines of this example, where the 'x'
argument is not first:
> d <- data.frame(C1=c(r1=11,r2=21,r3=31), C2=c(12,22,32))
> d[1,1:2]
C1 C2
r1 11 12
> `[`(d,j=1:2,i=1)
C1 C2
r1 11 12
Warning message:
In `[.data.frame`(d, j = 1:2, i = 1) :
named arguments other than 'drop' are discouraged
> `[`(j=1:2,d,i=1)
Error in (1:2)[d, i = 1] : incorrect number of dimensions
> do.call("[", list(j=1:2, i=1, x=d))
Error in 1:2[i = 1, x = list(C1 = c(11, 21, 31), C2 = c(12, 22, 32))] :
incorrect number of dimensions
Bill Dunlap
TIBCO Software
wdunlap http://tibco.com
On Wed, Nov 28, 2018 at 11:30 AM Henrik Pärn
wrote:
tl;dr:
Why are named arguments discouraged in `[.data.frame`, `[<-.data.frame` and
`[[.data.frame`?
(because this question is of the kind 'why is R designed like this?', I
though R-devel would be more appropriate than R-help)
#
Background:
Now and then students presents there fancy functions like this:
myfancyfun(d,12,0.3,0.2,500,1000,FALSE,TRUE,FALSE,TRUE,FALSE)
Incomprehensible. Thus, I encourage them to use spaces and name arguments,
_at least_ when trying to communicate their code with others. Something like:
myfancyfun(data = d, n = 12, gamma = 0.3, prob = 0.2,
size = 500, niter = 1000, model = FALSE,
scale = TRUE, drop = FALSE, plot = TRUE, save = FALSE)
Then some overzealous students started to use named arguments everywhere.
E-v-e-r-y-w-h-e-r-e. Even in the most basic situation when indexing vectors (as
a subtle protest?), like:
vec <- 1:9
vec[i = 4]
`[`(x = vec, i = 4)
vec[[i = 4]]
`[[`(x = vec, i = 4)
vec[i = 4] <- 10
`[<-`(x = vec, i = 4, value = 10)
...or when indexing matrices:
m <- matrix(vec, ncol = 3)
m[i = 2, j = 2]
`[`(x = m, i = 2, j = 2)
# 5
m[
Re: [Rd] named arguments discouraged in `[.data.frame` and `[<-.data.frame`
Thanks Emil for your thorough answer. It really clarified a lot to me. And
revealed (even more of) my ignorance.
>-Original Message-
>From: Emil Bode
>Sent: Thursday, November 29, 2018 10:48 AM
>To: Henrik Pärn ; r-devel@r-project.org
>Subject: Re: [Rd] named arguments discouraged in `[.data.frame` and `[<-
>.data.frame`
>
>Well, the situation with `[.data.frame` (and [<-) is complicated by the fact
>that
>the data.frame-method is not a primitive, but the generic IS.
>I'm not sure about dispatch for primitive-generics, but I bet it's done on the
>first argument (as with S3). Which means `[`(j=1:2,d,i=1) has nothing to do
>with `[.data.frame`, as some internal code equivalent to something like
>`[.integer` is called (`[.integer` is not an R-function, but I guess it's
>implemented in the C-code for `[`)
>And note that `[.data.frame`(j=1:2,d,i=1) does work (throws a warning, but
>returns the right result), because then you're simply calling the direct R-
>function, and matching by name is done.
>
>But I think the main reason for the warning is forwards compatibility (and
>maybe backwards?). As of this version, `[.data.frame`(x = d, j = 2, i = 1)
>works
>fine, and `[.data.frame` is a regular R-function. But it's used a lot, I
>wouldn't be
>surprised if some future R-version would implement it as a primitive.
>Without the warning, implementing [.data.frame as a primitive would involve
>a LOT of issues where older code breaks. With the warning, we can make clear
>to any users that calls like this one are undefined. They may work for now, but
>one shouldn't rely on it. Which means only the "right" order may be used, and
>then naming them is superfluous.
>
>By the way, when trying some things I noticed something else, which I'll send
>a separate mail about...
>
>Cheers,
>Emil
>
>On 29/11/2018, 09:20, "R-devel on behalf of Henrik Pärn" boun...@r-project.org on behalf of henrik.p...@ntnu.no> wrote:
>
>Thanks Bill and Michael for taking the time to share your knowledge!
>
>As a further background to my question, here are two examples that I
>forgot to include in my original post (reminded by Michael's answer). I
>swapped the i and j arguments in `[.data.frame` and `[<-.data.frame`. With
>warnings, but else without (?) problem. Using Bill's data:
>
>`[.data.frame`(x = d, i = 1, j = 2)
># [1] 12
>
>`[.data.frame`(x = d, j = 2, i = 1)
># [1] 12
>
>And similar for `[<-.data.frame` :
>`[<-.data.frame`(x = d, i = 1, j = 2, value = 1122)
>`[<-.data.frame`(x = d, j = 2, i = 1, value = 12)
>
>Because this seemed to work, I made the hasty conclusion that argument
>switching _wasn't_ a problem for `[.data frame`, and that we could rely on
>exact matching on tags. But apparently not: despite that `[.data.frame` and
>`[<-.data.frame` are _not_ primitive functions, positional matching is done
>there as well. Sometimes. At least when 'x' argument is not first, as shown in
>Bill's examples. Obviously my "test" was insufficient...
>
>Cheers,
>
>Henrik
>
>
>
>From: William Dunlap
>Sent: Wednesday, November 28, 2018 9:10 PM
>To: Henrik Pärn
>Cc: r-devel@r-project.org
>Subject: Re: [Rd] named arguments discouraged in `[.data.frame` and `[<-
>.data.frame`
>
>They can get bitten in the last two lines of this example, where the 'x'
>argument is not first:
>> d <- data.frame(C1=c(r1=11,r2=21,r3=31), C2=c(12,22,32))
>> d[1,1:2]
> C1 C2
>r1 11 12
>> `[`(d,j=1:2,i=1)
> C1 C2
>r1 11 12
>Warning message:
>In `[.data.frame`(d, j = 1:2, i = 1) :
> named arguments other than 'drop' are discouraged
>> `[`(j=1:2,d,i=1)
>Error in (1:2)[d, i = 1] : incorrect number of dimensions
>> do.call("[", list(j=1:2, i=1, x=d))
>Error in 1:2[i = 1, x = list(C1 = c(11, 21, 31), C2 = c(12, 22, 32))] :
> incorrect number of dimensions
>
>Bill Dunlap
>TIBCO Software
>wdunlap http://tibco.com
>
>
>On Wed, Nov 28, 2018 at 11:30 AM Henrik Pärn
> wrote:
>tl;dr:
>
>Why are named arguments discouraged in `[.data.frame`, `[<-.data.frame`
>and `[[.data.frame`?
>
>(because this question is of the kind 'why is R designed like this?', I
> though
>R-devel would be more appropriate than R-help)
>
>#
>
>Background:
>
>Now and then students presents there fancy functions like this:
>
>myfancyfun(d,12,0.3,0.2,500,1000,FALSE,TRUE,FALSE,TRUE,FALSE)
>
>Incomprehensible. Thus, I encourage them to use spaces and name
>arguments, _at least_ when trying to communicate their code with others.
>Something like:
>
>myfancyfun(data = d, n = 12, gamma = 0.3, prob = 0.2,
> size = 500, niter = 1000, model = FALSE,
> scale = TRUE, drop = FALSE, plot = TRUE, save = FALSE)
>
>
>Then some overzealous students started to use named arguments
>everywhere. E-v-e-r-y-w-h-e-r-e. Even in the most
[Rd] Unexpected argument-matching when some are missing
When trying out some variations with `[.data.frame` I noticed some (to me) odd
behaviour, which I found out has nothing to do with `[.data.frame`, but rather
with the way arguments are matched, when mixing named/unnamed and
missing/non-missing arguments. Consider the following example:
myfun <- function(x,y,z) {
print(match.call())
cat('x=',if(missing(x)) 'missing' else x, '\n')
cat('y=',if(missing(y)) 'missing' else y, '\n')
cat('z=',if(missing(z)) 'missing' else z, '\n')
}
myfun(x=, y=, "z's value")
gives:
# myfun(x = "z's value")
# x= z's value
# y= missing
# z= missing
This seems very counterintuitive to me, I expect the arguments x and y to be
missing, and z to get “z’s value”.
When I call myfun(,y=,"z's value"), x is missing, and y gets “z’s value”.
Are my expectations wrong or is this a bug? And if my expectations are wrong,
where can I find more information on argument-matching?
My gut-feeling says to call this a bug, but then I’m surprised no-one else has
encountered it before.
And I don’t have multiple installations to work from, so could somebody else
confirm this (if it’s not my expectations that are wrong) for R-devel/other
R-versions/other platforms?
My setup: R 3.5.1, MacOS 10.13.6, both Rstudio 1.1.453 and R --vanilla from Bash
Best regards,
Emil Bode
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Unexpected argument-matching when some are missing
On Thu, Nov 29, 2018 at 5:09 AM Emil Bode wrote:
>
> When trying out some variations with `[.data.frame` I noticed some (to me)
> odd behaviour, which I found out has nothing to do with `[.data.frame`, but
> rather with the way arguments are matched, when mixing named/unnamed and
> missing/non-missing arguments. Consider the following example:
>
>
>
> myfun <- function(x,y,z) {
>
> print(match.call())
>
> cat('x=',if(missing(x)) 'missing' else x, '\n')
>
> cat('y=',if(missing(y)) 'missing' else y, '\n')
>
> cat('z=',if(missing(z)) 'missing' else z, '\n')
>
> }
>
> myfun(x=, y=, "z's value")
>
>
>
> gives:
>
>
>
> # myfun(x = "z's value")
>
> # x= z's value
>
> # y= missing
>
> # z= missing
>
>
>
> This seems very counterintuitive to me, I expect the arguments x and y to be
> missing, and z to get “z’s value”.
Interesting. I would expect it to throw an error, since "x=" is not
syntactically complete. What does "x=" mean anyway? It looks like R
interprets it as "x was not set to anything, i.e., is missing". That
seems reasonable, though I think the example itself is pathological
and would prefer that it produced an error.
--Ista
>
> When I call myfun(,y=,"z's value"), x is missing, and y gets “z’s value”.
>
> Are my expectations wrong or is this a bug? And if my expectations are wrong,
> where can I find more information on argument-matching?
>
> My gut-feeling says to call this a bug, but then I’m surprised no-one else
> has encountered it before.
>
>
>
> And I don’t have multiple installations to work from, so could somebody else
> confirm this (if it’s not my expectations that are wrong) for R-devel/other
> R-versions/other platforms?
>
> My setup: R 3.5.1, MacOS 10.13.6, both Rstudio 1.1.453 and R --vanilla from
> Bash
>
>
>
> Best regards,
>
> Emil Bode
>
> __
> 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
[Rd] Small bug in the documentation of 'cut'
The documentation of 'base::cut' says: ... the factor level labels are constructed as "(b1, b2]", "(b2, b3]" etc... In reality, the spaces after the commas are missing. I like the documented behavior better than the actual, though. > sessionInfo() R version 3.5.1 (2018-07-02) Platform: x86_64-pc-linux-gnu (64-bit) Running under: Ubuntu 18.04.1 LTS gb __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Unexpected argument-matching when some are missing
> When trying out some variations with `[.data.frame` I noticed some (to me)
> odd behaviour,
Not just in 'myfun' ...
plot(x=1:10, y=)
plot(x=1:10, y=, 10:1)
In both cases, 'y=' is ignored. In the first, the plot is for y=NULL (so not
'missing' y)
In the second case, 10:1 is positionally matched to y despite the intervening
'missing' 'y='
So it isn't just 'missing'; it's 'not there at all'
Steve E
> -Original Message-
> From: R-devel [mailto:r-devel-boun...@r-project.org] On Behalf Of Emil
> Bode
> Sent: 29 November 2018 10:09
> To: r-devel@r-project.org
> Subject: [Rd] Unexpected argument-matching when some are missing
>
> When trying out some variations with `[.data.frame` I noticed some (to me)
> odd behaviour, which I found out has nothing to do with `[.data.frame`, but
> rather with the way arguments are matched, when mixing named/unnamed
> and missing/non-missing arguments. Consider the following example:
>
>
>
> myfun <- function(x,y,z) {
>
> print(match.call())
>
> cat('x=',if(missing(x)) 'missing' else x, '\n')
>
> cat('y=',if(missing(y)) 'missing' else y, '\n')
>
> cat('z=',if(missing(z)) 'missing' else z, '\n')
>
> }
>
> myfun(x=, y=, "z's value")
>
>
>
> gives:
>
>
>
> # myfun(x = "z's value")
>
> # x= z's value
>
> # y= missing
>
> # z= missing
>
>
>
> This seems very counterintuitive to me, I expect the arguments x and y to be
> missing, and z to get “z’s value”.
>
> When I call myfun(,y=,"z's value"), x is missing, and y gets “z’s value”.
>
> Are my expectations wrong or is this a bug? And if my expectations are
> wrong, where can I find more information on argument-matching?
>
> My gut-feeling says to call this a bug, but then I’m surprised no-one else has
> encountered it before.
>
>
>
> And I don’t have multiple installations to work from, so could somebody else
> confirm this (if it’s not my expectations that are wrong) for R-devel/other R-
> versions/other platforms?
>
> My setup: R 3.5.1, MacOS 10.13.6, both Rstudio 1.1.453 and R --vanilla from
> Bash
>
>
>
> Best regards,
>
> Emil Bode
***
This email and any attachments are confidential. Any use, copying or
disclosure other than by the intended recipient is unauthorised. If
you have received this message in error, please notify the sender
immediately via +44(0)20 8943 7000 or notify postmas...@lgcgroup.com
and delete this message and any copies from your computer and network.
LGC Limited. Registered in England 2991879.
Registered office: Queens Road, Teddington, Middlesex, TW11 0LY, UK
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Unexpected argument-matching when some are missing
On Thu, Nov 29, 2018 at 10:51 AM S Ellison wrote:
>
> > When trying out some variations with `[.data.frame` I noticed some (to me)
> > odd behaviour,
>
> Not just in 'myfun' ...
>
> plot(x=1:10, y=)
> plot(x=1:10, y=, 10:1)
>
> In both cases, 'y=' is ignored. In the first, the plot is for y=NULL (so not
> 'missing' y)
> In the second case, 10:1 is positionally matched to y despite the intervening
> 'missing' 'y='
>
> So it isn't just 'missing'; it's 'not there at all'
What exactly is the difference between "missing" and "not there at all"?
--Ista
>
> Steve E
>
> > -Original Message-
> > From: R-devel [mailto:r-devel-boun...@r-project.org] On Behalf Of Emil
> > Bode
> > Sent: 29 November 2018 10:09
> > To: r-devel@r-project.org
> > Subject: [Rd] Unexpected argument-matching when some are missing
> >
> > When trying out some variations with `[.data.frame` I noticed some (to me)
> > odd behaviour, which I found out has nothing to do with `[.data.frame`, but
> > rather with the way arguments are matched, when mixing named/unnamed
> > and missing/non-missing arguments. Consider the following example:
> >
> >
> >
> > myfun <- function(x,y,z) {
> >
> > print(match.call())
> >
> > cat('x=',if(missing(x)) 'missing' else x, '\n')
> >
> > cat('y=',if(missing(y)) 'missing' else y, '\n')
> >
> > cat('z=',if(missing(z)) 'missing' else z, '\n')
> >
> > }
> >
> > myfun(x=, y=, "z's value")
> >
> >
> >
> > gives:
> >
> >
> >
> > # myfun(x = "z's value")
> >
> > # x= z's value
> >
> > # y= missing
> >
> > # z= missing
> >
> >
> >
> > This seems very counterintuitive to me, I expect the arguments x and y to be
> > missing, and z to get “z’s value”.
> >
> > When I call myfun(,y=,"z's value"), x is missing, and y gets “z’s value”.
> >
> > Are my expectations wrong or is this a bug? And if my expectations are
> > wrong, where can I find more information on argument-matching?
> >
> > My gut-feeling says to call this a bug, but then I’m surprised no-one else
> > has
> > encountered it before.
> >
> >
> >
> > And I don’t have multiple installations to work from, so could somebody else
> > confirm this (if it’s not my expectations that are wrong) for R-devel/other
> > R-
> > versions/other platforms?
> >
> > My setup: R 3.5.1, MacOS 10.13.6, both Rstudio 1.1.453 and R --vanilla from
> > Bash
> >
> >
> >
> > Best regards,
> >
> > Emil Bode
>
>
>
> ***
> This email and any attachments are confidential. Any u...{{dropped:11}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Unexpected argument-matching when some are missing
Well, I did mean it as "missing".
To me, it felt just as natural as providing an empty index for subsetting (e.g.
some.data.frame[,,drop=FALSE])
I can't think of a whole lot of other uses than subsetting, but I think this
issue may be mostly important when you're not entirely sure what a call is
going to end up, when passing along arguments, or when calling an unknown
function (as in variants of the apply-family, where you provide a function as
an argument).
Or what happens if I use do.call(FUN, args=MyNamedList)? I have a bit more
extensive example further down where you can more clearly see the unexpected
output.
But the problem is that R does NOT treat it as simply "missing". That would
have been reasonable, but instead, as in the example in my previous mail,
myfun(x=, y=, "z's value") means x is assigned "z's value", and y and z are
seen as missing. Which is not at all what I was expecting.
And is also not consistent with other behaviour, as myfun(,,"z's value") and
myfun(x=, y=, z="z's value") do work as expected (at least what I was expecting)
The extensice example:
Suppose I want to write a function that selects data from some external source.
In order to do this, we put the data in its own environment, where we look for
variables called "df", "rows", "cols" and "drop", and use these to make a
selection. I write this function:
doselect <- function(env) {
do.call(`[.data.frame`, list(env$df, if(!is.null(env$rows)) env$rows,
if(!is.null(env$cols)) env$cols, drop=if(!is.null(env$drop)) env$drop))
}
It works for this code:
myenv <- new.env()
assign('df', data.frame(a=1:2, b=3:4), myenv, inherits=FALSE)
assign('rows', 1, myenv, inherits=FALSE) # Code breaks if we don't have this
line
assign('cols', 1, myenv, inherits=FALSE) # Code breaks if we don't have this
line
assign('drop', FALSE, myenv, inherits=FALSE)
doselect(myenv)
But if we don't assign "rows" and/or "cols", the variable "drop" is inserted in
the place of the first unnamed variable, so the result is the same as if calling
df[FALSE,,]:
[1] a b
<0 rows> (or 0-length row.names)
What I did expect was the same result as df[,,FALSE], i.e. the full data.frame.
Of course I can rewrite the function "doselect", but I think my current call is
how most people would write it (even though I admit the example in its entirety
is far-fetched)
Best regards,
Emil Bode
On 29/11/2018, 14:58, "Ista Zahn" wrote:
On Thu, Nov 29, 2018 at 5:09 AM Emil Bode wrote:
>
> When trying out some variations with `[.data.frame` I noticed some (to
me) odd behaviour, which I found out has nothing to do with `[.data.frame`, but
rather with the way arguments are matched, when mixing named/unnamed and
missing/non-missing arguments. Consider the following example:
>
> myfun <- function(x,y,z) {
> print(match.call())
> cat('x=',if(missing(x)) 'missing' else x, '\n')
> cat('y=',if(missing(y)) 'missing' else y, '\n')
> cat('z=',if(missing(z)) 'missing' else z, '\n')
> }
> myfun(x=, y=, "z's value")
>
> gives:
>
> # myfun(x = "z's value")
> # x= z's value
> # y= missing
> # z= missing
>
> This seems very counterintuitive to me, I expect the arguments x and y to
be missing, and z to get “z’s value”.
Interesting. I would expect it to throw an error, since "x=" is not
syntactically complete. What does "x=" mean anyway? It looks like R
interprets it as "x was not set to anything, i.e., is missing". That
seems reasonable, though I think the example itself is pathological
and would prefer that it produced an error.
--Ista
>
> When I call myfun(,y=,"z's value"), x is missing, and y gets “z’s value”.
> Are my expectations wrong or is this a bug? And if my expectations are
wrong, where can I find more information on argument-matching?
> My gut-feeling says to call this a bug, but then I’m surprised no-one else
has encountered it before.
>
> And I don’t have multiple installations to work from, so could somebody
else confirm this (if it’s not my expectations that are wrong) for
R-devel/other R-versions/other platforms?
>
> My setup: R 3.5.1, MacOS 10.13.6, both Rstudio 1.1.453 and R --vanilla
from Bash
>
> Best regards,
>
> Emil Bode
>
> __
> 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
Re: [Rd] Unexpected argument-matching when some are missing
> > plot(x=1:10, y=) > > plot(x=1:10, y=, 10:1) > > > > In both cases, 'y=' is ignored. In the first, the plot is for y=NULL (so not > 'missing' y) > > In the second case, 10:1 is positionally matched to y despite the > > intervening > 'missing' 'y=' > > > > So it isn't just 'missing'; it's 'not there at all' > > What exactly is the difference between "missing" and "not there at all"? A "missing argument" in R means that an argument with no default value was omitted from the call, and that is what I meant by "missing". But that is not what is happening here. I was talking about "y=" apparently being treated as not present in the call, rather than the argument y being treated as a missing argument. In these examples, plot.default has a default value for y (NULL) so y can never be "missing" in the sense of the 'missing argument' error (compare what happens with plot(y=1:10), which reports x as 'missing'). In the first example, y was (from the plot behaviour) taken as NULL - the default - so was not considered a missing argument. In the second, it was taken as 10:1 - again, non-missing, despite 10:1 being in the normal position for the (character) argument "type". But neither call did anything at all with "y=". Instead, the behaviour is consistent with what would have happened if 'y=' were "not present at all" when counting position or named argument list, rather than if 'y' were an absent required argument. It _looks_ as if the initial call parsing silently ignored the malformed expression "y=" before any argument matching - positional or by name - takes place. But I'm thinking that it'll take an R-core guru to explain what's going on here, so I was going to wait and see. Steve Ellison *** This email and any attachments are confidential. Any use, copying or disclosure other than by the intended recipient is unauthorised. If you have received this message in error, please notify the sender immediately via +44(0)20 8943 7000 or notify postmas...@lgcgroup.com and delete this message and any copies from your computer and network. LGC Limited. Registered in England 2991879. Registered office: Queens Road, Teddington, Middlesex, TW11 0LY, UK __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Unexpected argument-matching when some are missing
On Thu, Nov 29, 2018 at 1:10 PM S Ellison wrote:
>
>
> > > plot(x=1:10, y=)
> > > plot(x=1:10, y=, 10:1)
> > >
> > > In both cases, 'y=' is ignored. In the first, the plot is for y=NULL (so
> > > not
> > 'missing' y)
> > > In the second case, 10:1 is positionally matched to y despite the
> > > intervening
> > 'missing' 'y='
> > >
> > > So it isn't just 'missing'; it's 'not there at all'
> >
> > What exactly is the difference between "missing" and "not there at all"?
>
> A "missing argument" in R means that an argument with no default value was
> omitted from the call, and that is what I meant by "missing".
> But that is not what is happening here. I was talking about "y=" apparently
> being treated as not present in the call, rather than the argument y being
> treated as a missing argument.
>
> In these examples, plot.default has a default value for y (NULL) so y can
> never be "missing" in the sense of the 'missing argument' error (compare what
> happens with plot(y=1:10), which reports x as 'missing').
> In the first example, y was (from the plot behaviour) taken as NULL - the
> default - so was not considered a missing argument. In the second, it was
> taken as 10:1 - again, non-missing, despite 10:1 being in the normal position
> for the (character) argument "type".
> But neither call did anything at all with "y=". Instead, the behaviour is
> consistent with what would have happened if 'y=' were "not present at all"
> when counting position or named argument list, rather than if 'y' were an
> absent required argument.
> It _looks_ as if the initial call parsing silently ignored the malformed
> expression "y=" before any argument matching - positional or by name - takes
> place.
Yes, I think all of that is correct. But y _is_ missing in this sense:
> debug(plot)
> plot(1:10, y=)
debugging in: plot(1:10, y = )
debug: UseMethod("plot")
Browse[2]> missing(y)
[1] TRUE
though this does not explain the behavior since
> plot( , , "l")
debugging in: plot(, , "l")
debug: UseMethod("plot")
Browse[2]> missing(y)
[1] TRUE
--Ista
>
> But I'm thinking that it'll take an R-core guru to explain what's going on
> here, so I was going to wait and see.
>
> Steve Ellison
>
>
>
> ***
> This email and any attachments are confidential. Any u...{{dropped:8}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
