dplyr and function length()

Dear All,

I have an observation / question about how the function length() works once package dplyr is loaded.

Say we have a data.frame  df with n rows and m columns. Then a way to get the number of rows is to use

length(df$m1)  (m1 here stand is as the header of the first column)

or, alternatively

length(df[,1]).

Both commands will return n.

However, once dplyr is loaded,

length(df[,1]) will return a value of 1.

length(df$m1) and also length(df[[1]]) will correctly return n.

I know that using length() may not be the most elegant or efficient way to get the value of n. However, what puzzles (and somewhat disturbs) me is that loading of dplyr affects how length() works, without there being a warning or masking message upon loading it.

Any clarification or comment would be welcome.

Thank you so much,

Karl


-- 
Karl Schilling

On 04 Aug 2015, at 10:50 , Karl Schilling <karl.schilling at uni-bonn.de>
wrote:

Dear All,

I have an observation / question about how the function length()

works once package dplyr is loaded.

Say we have a data.frame  df with n rows and m columns. Then a way to

get the number of rows is to use

length(df$m1)  (m1 here stand is as the header of the first column)

or, alternatively

length(df[,1]).

Both commands will return n.

However, once dplyr is loaded,

length(df[,1]) will return a value of 1.

length(df$m1) and also length(df[[1]]) will correctly return n.

I know that using length() may not be the most elegant or efficient

way to get the value of n. However, what puzzles (and somewhat
disturbs) me is that loading of dplyr affects how length() works,
without there being a warning or masking message upon loading it.

Any clarification or comment would be welcome.

Presumably, dplyr changes how [.data.frame works (by altering the
default for drop=, I expect) so that df[,1] is a data frame with 1
variable and not a vector. And yes, that _is_ somewhat disturbing.

-pd 

Thank you so much,

Karl


-- 
Karl Schilling

I can confirm that the drop default is different, but keep in mind that it is only changed for a tbl_df so just convert back to data.frame at the end of your dplr operations to get back to your familiar data.frame behavior.
---------------------------------------------------------------------------
Jeff Newmiller                        The     .....       .....  Go Live...
DCN:<jdnewmil at dcn.davis.ca.us>         Basics: ##.#.       ##.#.  Live Go...
                                       Live:   OO#.. Dead: OO#..  Playing
Research Engineer (Solar/Batteries            O.O#.       #.O#.  with
/Software/Embedded Controllers)               .OO#.       .OO#.  rocks...1k
---------------------------------------------------------------------------
Sent from my phone. Please excuse my brevity.

On August 4, 2015 5:06:44 AM EDT, peter dalgaard<pdalgd at gmail.com>  wrote:

On 04 Aug 2015, at 10:50 , Karl Schilling<karl.schilling at uni-bonn.de>
wrote:

Dear All,

I have an observation / question about how the function length()

works once package dplyr is loaded.

Say we have a data.frame  df with n rows and m columns. Then a way to

get the number of rows is to use

length(df$m1)  (m1 here stand is as the header of the first column)

or, alternatively

length(df[,1]).

Both commands will return n.

However, once dplyr is loaded,

length(df[,1]) will return a value of 1.

length(df$m1) and also length(df[[1]]) will correctly return n.

I know that using length() may not be the most elegant or efficient

way to get the value of n. However, what puzzles (and somewhat
disturbs) me is that loading of dplyr affects how length() works,
without there being a warning or masking message upon loading it.

Any clarification or comment would be welcome.

Presumably, dplyr changes how [.data.frame works (by altering the
default for drop=, I expect) so that df[,1] is a data frame with 1
variable and not a vector. And yes, that_is_  somewhat disturbing.

-pd

Thank you so much,

Karl


--
Karl Schilling

No, the effect I described has nothing to do wit USING dplyr. It occurs with
any (preexisting) data.frame once dplyr is LOADED (require(dplyr). It is
this silent, sort of "backward acting" effect that disturbs me.

length(df[,1]).

Both commands will return n.

However, once dplyr is loaded,

length(df[,1]) will return a value of 1.

length(df$m1) and also length(df[[1]]) will correctly return n.

I know that using length() may not be the most elegant or efficient way to get the value of n. However, what puzzles (and somewhat disturbs) me is that loading of dplyr affects how length() works, without there being a warning or masking message upon loading it.

Any clarification or comment would be welcome.

Presumably, dplyr changes how [.data.frame works (by altering the default for drop=, I expect) so that df[,1] is a data frame with 1 variable and not a vector. And yes, that _is_ somewhat disturbing.

No, the effect I described has nothing to do wit USING dplyr. It occurs with

any (preexisting) data.frame once dplyr is LOADED (require(dplyr). It is
this silent, sort of "backward acting" effect that disturbs me.

You're going to need to provide some evidence for that charge: dplyr
does not affect the behaviour of data.frames (only tbl_dfs)

Hadley