-
Notifications
You must be signed in to change notification settings - Fork 84
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
removed some dollar signs in intro to r lab #9
Conversation
From a quick glance, it looks like you are only doing this to view the data, is that correct? This matters because you are now getting a data frame rather than a vector (that's why the display is different). Any computations done with these objects might break, but if you are only using this for the sake of viewing, that doesn't matter. Have you considered using arbuthnot %>%
select(boys) instead? This make it easier to read and to perform multiple operations. |
I like that! It probably means adding some expository text about the pipe operator, but nothing wrong with getting students thinking about it in the first week. |
+1 on teaching piping! |
If you do it, I suggest the following code formatting: NewData <-
OriginalData %>%
first_operation( ... ) %>%
second_operation(...) %>%
etc., etc., etc. The first line can be omitted if there is no need to store the result. |
Also the use of the
|
Though we haven't made the commits to this repo, Mine and I both taught the intro to data lab in a way that introduces the pipe operator. @rpruim , do you have a reason for not doing any assignment on the first line? I really like this code block that you provided, though, with the general function names. I think I'll bring it up in class tomorrow to show a general form of what we've been doing. One thing that I've realized needs to be addressed when teaching chaining to new users is spacing/line breaks. New users can develop all sorts of superstitions surrounding why code runs or doesn't run, so it can be useful to explicitly address what will and will not break the code in terms of formatting. This is another topic for tomorrow's class =) |
Btw, what's the best practice for handling a pull request like this that will likely be updated (in this case for the piping format of select())? If @AmeliaMN submits a new pull request, will it overwrite this one? Or would I "close and comment" this thread/pull request and then we start afresh with the new request? |
The assignment (in the sense of naming the variable that will contain the results) is on the first line. And it is the only thing on that line. Here's why I like it:
By the way, when I use commands like NewData <-
OldData %>%
mutate(
x = foo(a, b, pretty = TRUE),
y = bar(a, b, pretty = FALSE)) %>%
additional_operation( ... ) Last note: I have gotten more and more into the habit of inserting a line break after the assignment arrow whenever what is being assigned takes more than one line of code. x <-
multiline_stuff( ...,
...) I'm torn about whether the final closing paren should be on a line by itself or at the end of the last "action" line. I like the former for style, but I don't like using up the extra vertical line. |
@rpruim |
Regarding spaces: I'm trying to retrain myself to always put spaces around operators like +, -, *, =, etc. It's not quite in my fingers yet, so I often have to do a consistency edit of my code. (@hadley requires this of any code contributed to his projects, and I think I've decided it adds enough by way of readability to adopt it.) I'm a bit inconsistent about spaces inside parens. Most people don't put a space after far( boo(foo( bar(x, y) )) ) # spaces help match up parens -- emphasize boo(foo())
far(boo( foo(bar(x, y)) )) # spaces help match up parens -- emphasize far(boo()) and foo(bar())
# in the above examples, I might just use chaining now
histogram( ~ x, data = mydata) # torn about whether there should be a space
# before closing paren here |
Regarding pull requests, I'm not sure I understand what "like this" means or what you are concerned about, so I can't answer what the best practice would be. It's probably best for people who are working on different things to keep them on separate branches and issue a pull request from each branch when they are ready. On your end, from the commandline you can choose to fetch rather than pull (pull = fetch + merge) if you want to investigate the pull request without merging it into your current work. At that point, you can decide whether or not to merge, cherrypick, discard, etc. the work that was done in that branch. If you want a visual way to "see" how git works, I recommend this visualization tool and tutorial: |
@rpruim , By like this, I mean pull request where the subsequent discussion has made it clear that further modifications will be made. With this one, for example, I could either go ahead and merge the change (using The main reason I'm wondering if because in this github interface, it seems like this discussion is tied to the first pull request. I'd kinda like it if a new pull request (including the subsequent commits) could happen in the context of this same thread, but I don't think that's possible. |
I think that can indeed happen (I recently submitted a rather stupid pull ~Amelia On Thu, Sep 10, 2015 at 2:50 PM, Andrew Bray notifications@github.com
Amelia McNamara |
That sounds right. Until the pull requester gets rid of the pull request, it hangs around as a branch and more work can be done along the branch and that work can (I think) be fetched at any time. We'll have to see how Amelia's experiment goes in terms of the github features. But if it is just a branch, you can probably pull it and then pull it again if more work is done. But best to keep pull requests fairly limited in scope anyway, else they get harder to deal with -- especially if you want some, but not all, of the changes in the pull request. |
Okay, as expected my new commits just got added into this long thread. I briefly explained the |
It's easier to understand once you realise that pull request = branch. If you push to the same branch, the PR gets updated. |
devtools::install_github("andrewpbray/oilabs") | ||
install.packages(c("dplyr", "ggplot2")) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You could simplify this a bit by making dplyr and ggplot2 dependencies (even if slightly spurious) of the oilabs package.
The big picture here seems the same as what we've been running into in many places-- just changing from base R to dplyr/ggplot2 is not the way to go. We need to think more deeply about what should really be in an introductory lab. @beanumber and I are doing dplyr-flavored mosaic labs (with lattice graphics) in our intro courses this semester. Like I said above, I've done the first lab, which included: |
I heartily concur. I'd suggest taking another look at the Minimal R vignette that Randy crafted: there's a lot to be said about the "Less is More" philosophy that he espouses for intro students. I'm working on a even more Minimal Vignette, that could be more useful for folks in community colleges or high school. Just my $0.02, Nick
Nicholas Horton |
There was a short offline conversation about @beanumber and I talking about a dplyr/mosiac/lattice version (we've started this a bit this semester), and in that branch it might make sense to use |
I concur with @nicholasjhorton that you don't want to merely "translate" from one toolkit to another at a micro level. And big thumbs up to doing a "Less Volume, More Creativity / Minimal R" exercise. In this exercise, you cull out all of the R Code for a course and organize it to see what you are using with the goal of reducing to a small, coherent set that gets the job done. @AmeliaMN, I'd like to see the use cases where you think you need |
Also, if you think there are important use cases that are hard to do in dplyr, I'd really like to hear about them! |
The injection of Also, no one has mentioned the |
I'm not a fan of
I don't think saving a few characters of typing is worth this. Does anyone else use it? |
I'm not a fan of |
This afternoon in class I reviewed the chaining syntax that we covered in the Intro to Data lab on Tuesday. I found myself talking about a data analysis pipeline and actually drawing a Super Mario Brothers style pipe with "Raw Data" at one end and at the other end a list of possible "Data Products". Those included
I find this to be a useful format to help students think through a statistical question. For a given question you can ask them: a) what sort of data product (I'm open to a better term here) would be well-suited to answer the question b) what would a data set look like that could create that product? From there, it's a matter of thinking through the turns and twists in the pipe - the various lines of the chain - that get from here to there. It strikes me that So I'm inclined to use the |
Yeah, part of the point of ggvis was to provide a pipe-friendly syntax. But I definitely wouldn't advise using ggvis in an intro course yet. Alternatively you could just teach that |
@hadley you asked "Also, if you think there are important use cases that are hard to do in dplyr, I'd really like to hear about them!" -- one such case I came across is the use of things like Here is a MWE:
behaves as expected but neither
nor
does (due to
or
but they don't. I think this is related to this. I also think that this would be a welcome addition, but correct me if I'm missing something important about why On a different note I haven't had any issues with convincing newbies that |
I would second this for functions that produce either (possibly named) vectors or 1-row data frames/tbls. You can get the desired result like this: HELPrct %>% group_by(substance) %>% do( favstats(.$age))
## Source: local data frame [3 x 10]
## Groups: substance [3]
##
## substance min Q1 median Q3 max mean sd n missing
## (fctr) (dbl) (dbl) (dbl) (dbl) (dbl) (dbl) (dbl) (int) (int)
## 1 alcohol 20 33 38.0 43.00 58 38.19774 7.652272 177 0
## 2 cocaine 23 30 33.5 37.25 60 34.49342 6.692881 152 0
## 3 heroin 19 27 33.0 39.00 55 33.44355 7.986068 124 0 But this requires both a |
Update intro_to_data.Rmd
Update intro_to_data.Rmd
Merge branch 'master' of https://github.com/AmeliaMN/oiLabs-dplyr-ggplot
Update simple_regression.Rmd
Update simple_regression.Rmd
Update intro_to_r.Rmd
Update simple_regression.Rmd
updated exercise to correct typo(?)
… distribution lab
Ugh, forgot to make a new branch AGAIN. |
I've made some minor changes that may have major philosophical repercussions! In particular, I have replaced all the usages of the dollar sign, eg.
arbuthnot$boys
, with dplyr commands, likeselect(arbuthnot, boys)
. This means taking out the references to vectors in this lab, as well as the expository text about what the wrapped display of vectors means.