From 8b15a588d91285a6ce52581bb60ea44b4e94b305 Mon Sep 17 00:00:00 2001 From: Quarto GHA Workflow Runner Date: Fri, 17 Nov 2023 22:08:31 +0000 Subject: [PATCH] Built site for gh-pages --- .nojekyll | 2 +- EDA.html | 4 +- arrow.html | 4 +- base-R.html | 4 +- communicate.html | 4 +- communication.html | 4 +- data-import.html | 6 +- data-tidy.html | 4 +- data-transform.html | 4 +- data-visualize.html | 4 +- databases.html | 10 +-- datetimes.html | 122 ++++++++++++++++----------------- factors.html | 4 +- functions.html | 4 +- import.html | 4 +- index.html | 4 +- intro.html | 4 +- iteration.html | 16 ++--- joins.html | 4 +- layers.html | 4 +- logicals.html | 4 +- missing-values.html | 4 +- numbers.html | 4 +- preface-2e.html | 4 +- program.html | 4 +- quarto-formats.html | 4 +- quarto.html | 4 +- rectangling.html | 4 +- regexps.html | 4 +- robots.txt | 2 +- search.json | 10 +-- sitemap.xml | 152 +++++++++++++++++++++--------------------- spreadsheets.html | 4 +- strings.html | 4 +- transform.html | 4 +- visualize.html | 4 +- webscraping.html | 4 +- whole-game.html | 4 +- workflow-basics.html | 4 +- workflow-help.html | 4 +- workflow-scripts.html | 4 +- workflow-style.html | 4 +- 42 files changed, 228 insertions(+), 228 deletions(-) diff --git a/.nojekyll b/.nojekyll index bdd080be2..891c331bc 100644 --- a/.nojekyll +++ b/.nojekyll @@ -1 +1 @@ -dfddee1e \ No newline at end of file +f5fd3962 \ No newline at end of file diff --git a/EDA.html b/EDA.html index 8b9e7f43e..bcd99de3f 100644 --- a/EDA.html +++ b/EDA.html @@ -113,7 +113,7 @@
R para Ciência de Dados (2ª edição)
- +
@@ -426,7 +426,7 @@
  • 10.6 Patterns and models
  • 10.7 Summary
    • -

    Editar essa página

    Criar uma issue

    +

    Editar essa página

    Criar uma issue

    diff --git a/arrow.html b/arrow.html index 0516141b4..405d5c54d 100644 --- a/arrow.html +++ b/arrow.html @@ -113,7 +113,7 @@
    R para Ciência de Dados (2ª edição)
    - +
    @@ -420,7 +420,7 @@
  • 22.6 Summary
    • -

    Editar essa página

    Criar uma issue

    +

    Editar essa página

    Criar uma issue

    diff --git a/base-R.html b/base-R.html index b01fffe91..5fe7e9df9 100644 --- a/base-R.html +++ b/base-R.html @@ -113,7 +113,7 @@
    R para Ciência de Dados (2ª edição)
    - +
    @@ -423,7 +423,7 @@
  • 27.5 for loops
  • 27.6 Plots
  • 27.7 Summary
    • -

    Editar essa página

    Criar uma issue

    +

    Editar essa página

    Criar uma issue

    diff --git a/communicate.html b/communicate.html index 28dbc7958..13fdac9c1 100644 --- a/communicate.html +++ b/communicate.html @@ -79,7 +79,7 @@
    R para Ciência de Dados (2ª edição)
    - +
    @@ -641,7 +641,7 @@

    R para Ciência de Dados (2ª edição) foi escrito por Hadley Wickham, Mine Çetinkaya-Rundel, e Garrett Grolemund.

      -

    Editar essa página

    Criar uma issue

    +

    Editar essa página

    Criar uma issue

    Este livro foi contruído com Quarto.
    diff --git a/communication.html b/communication.html index 96034790d..de795d6c8 100644 --- a/communication.html +++ b/communication.html @@ -113,7 +113,7 @@
    R para Ciência de Dados (2ª edição)
    - +
    @@ -437,7 +437,7 @@
  • 11.7 Summary
    • -

    Editar essa página

    Criar uma issue

    +

    Editar essa página

    Criar uma issue

    diff --git a/data-import.html b/data-import.html index 4345f5c29..c3b828545 100644 --- a/data-import.html +++ b/data-import.html @@ -113,7 +113,7 @@
    R para Ciência de Dados (2ª edição)
    - +
    @@ -422,7 +422,7 @@
  • 7.5 Writing to a file
  • 7.6 Data entry
  • 7.7 Summary
    • -

    Editar essa página

    Criar uma issue

    +

    Editar essa página

    Criar uma issue

    @@ -835,7 +835,7 @@

    < #> # A tibble: 1 × 5 #> row col expected actual file #> <int> <int> <chr> <chr> <chr> -#> 1 3 1 a double . /tmp/RtmprQ7oUD/file1e2549f0663d

    +#> 1 3 1 a double . /tmp/RtmpmQKHAo/file1e8c59e6768d

    This tells us that there was a problem in row 3, col 1 where readr expected a double but got a .. That suggests this dataset uses . for missing values. So then we set na = ".", the automatic guessing succeeds, giving us the numeric column that we want:

    diff --git a/data-tidy.html b/data-tidy.html index d640aa754..87dbe5868 100644 --- a/data-tidy.html +++ b/data-tidy.html @@ -113,7 +113,7 @@
    R para Ciência de Dados (2ª edição)
    - +
    @@ -423,7 +423,7 @@
  • 5.5 Summary
    • -

    Editar essa página

    Criar uma issue

    +

    Editar essa página

    Criar uma issue

    diff --git a/data-transform.html b/data-transform.html index 5991ba60f..524d48fea 100644 --- a/data-transform.html +++ b/data-transform.html @@ -113,7 +113,7 @@
    R para Ciência de Dados (2ª edição)
    - +
    @@ -438,7 +438,7 @@
  • 3.6 Case study: aggregates and sample size
  • 3.7 Summary
    • -

    Editar essa página

    Criar uma issue

    +

    Editar essa página

    Criar uma issue

    diff --git a/data-visualize.html b/data-visualize.html index 588c4e168..17094d09a 100644 --- a/data-visualize.html +++ b/data-visualize.html @@ -113,7 +113,7 @@
    R para Ciência de Dados (2ª edição)
    - +
    @@ -438,7 +438,7 @@
  • 1.7 Problemas comuns
  • 1.8 Resumo
    • -

    Editar essa página

    Criar uma issue

    +

    Editar essa página

    Criar uma issue

    diff --git a/databases.html b/databases.html index b6d6cb3ad..8e11945dc 100644 --- a/databases.html +++ b/databases.html @@ -113,7 +113,7 @@
    R para Ciência de Dados (2ª edição)
    - +
    @@ -428,7 +428,7 @@
  • 21.6 Function translations
  • 21.7 Summary
    • -

    Editar essa página

    Criar uma issue

    +

    Editar essa página

    Criar uma issue

    @@ -573,7 +573,7 @@ 

    diamonds_db <- tbl(con, "diamonds")
 diamonds_db
 #> # Source:   table<diamonds> [?? x 10]
-#> # Database: DuckDB v0.9.1 [unknown@Linux 6.2.0-1016-azure:R 4.3.2/:memory:]
+#> # Database: DuckDB v0.9.1 [unknown@Linux 6.2.0-1015-azure:R 4.3.2/:memory:]
 #>   carat cut       color clarity depth table price     x     y     z
 #>   <dbl> <fct>     <fct> <fct>   <dbl> <dbl> <int> <dbl> <dbl> <dbl>
 #> 1  0.23 Ideal     E     SI2      61.5    55   326  3.95  3.98  2.43
@@ -610,7 +610,7 @@ 
    big_diamonds_db
 #> # Source:   SQL [?? x 5]
-#> # Database: DuckDB v0.9.1 [unknown@Linux 6.2.0-1016-azure:R 4.3.2/:memory:]
+#> # Database: DuckDB v0.9.1 [unknown@Linux 6.2.0-1015-azure:R 4.3.2/:memory:]
 #>   carat cut       color clarity price
 #>   <dbl> <fct>     <fct> <fct>   <int>
 #> 1  1.54 Premium   E     VS2     15002
@@ -838,7 +838,7 @@ 
    #> Use `na.rm = TRUE` to silence this warning
 #> This warning is displayed once every 8 hours.
 #> # Source:   SQL [?? x 2]
-#> # Database: DuckDB v0.9.1 [unknown@Linux 6.2.0-1016-azure:R 4.3.2/:memory:]
+#> # Database: DuckDB v0.9.1 [unknown@Linux 6.2.0-1015-azure:R 4.3.2/:memory:]
 #>   dest  delay
 #>   <chr> <dbl>
 #> 1 SFO    2.67
diff --git a/datetimes.html b/datetimes.html
index b6463b45d..360b84290 100644
--- a/datetimes.html
+++ b/datetimes.html
@@ -113,7 +113,7 @@
     
    
       R para Ciência de Dados (2ª edição) 
         
    
-    
+    
   
   
    
   
@@ -431,7 +431,7 @@
 
   
  • 17.5 Time zones
    • 
   
  • 17.6 Summary
    • 
-  
    Editar essa página
    Criar uma issue
    
+  
    Editar essa página
    Criar uma issue
    
     
    
 
 
    
@@ -448,14 +448,14 @@ 
    
-
    
-
    
-::: {.callout-warning} 
-Olá! Este capítulo do livro ainda **não está traduzido** para a versão Português-BR.
- <br> Caso você queira contribuir com o projeto de tradução, leia as instruções em: <https://github.com/cienciadedatos/pt-r4ds/wiki> <br> 
-A versão original (em inglês) do livro R for Data Science está disponível em: <https://r4ds.hadley.nz/> 
-:::
    
+
    
+
    
+
    
+
+
    
+
    
+
    Olá! Este capítulo do livro ainda não está traduzido para a versão Português-BR. 
     Caso você queira contribuir com o projeto de tradução, leia as instruções em: https://github.com/cienciadedatos/pt-r4ds/wiki 
     A versão original (em inglês) do livro R for Data Science está disponível em: https://r4ds.hadley.nz/
    
+
    
 
    
 
    
 
    
@@ -468,7 +468,7 @@ 
    17.1.1 Prerequisites
    
 
    This chapter will focus on the lubridate package, which makes it easier to work with dates and times in R. As of the latest tidyverse release, lubridate is part of core tidyverse. We will also need nycflights13 for practice data.
    
 
    
-
 
    
@@ -483,10 +483,10 @@ 
    today() or now():
    
 
    
-
    today()
+
    today()
 #> [1] "2023-11-17"
 now()
-#> [1] "2023-11-17 21:36:55 UTC"
    
+#> [1] "2023-11-17 22:04:44 UTC"
    
 
    
 
    Otherwise, the following sections describe the four ways you’re likely to create a date/time:
    
 
      
@@ -499,7 +499,7 @@ 
      17.2.1 During import
      
 
      If your CSV contains an ISO8601 date or date-time, you don’t need to do anything; readr will automatically recognize it:
      
 
      
-
      csv <- "
+
      csv <- "
   date,datetime
   2022-01-02,2022-01-02 05:12
 "
@@ -628,7 +628,7 @@ 
      
-
      csv <- "
+
      csv <- "
   date
   01/02/15
 "
@@ -657,7 +657,7 @@ 
      17.2.2 From strings
      
 
      The date-time specification language is powerful, but requires careful analysis of the date format. An alternative approach is to use lubridate’s helpers which attempt to automatically determine the format once you specify the order of the component. To use them, identify the order in which year, month, and day appear in your dates, then arrange “y”, “m”, and “d” in the same order. That gives you the name of the lubridate function that will parse your date. For example:
      
 
      
-
      ymd("2017-01-31")
+
      ymd("2017-01-31")
 #> [1] "2017-01-31"
 mdy("January 31st, 2017")
 #> [1] "2017-01-31"
@@ -666,14 +666,14 @@ 
      ymd() and friends create dates. To create a date-time, add an underscore and one or more of “h”, “m”, and “s” to the name of the parsing function:
      
 
      
-
      ymd_hms("2017-01-31 20:11:59")
+
      ymd_hms("2017-01-31 20:11:59")
 #> [1] "2017-01-31 20:11:59 UTC"
 mdy_hm("01/31/2017 08:01")
 #> [1] "2017-01-31 08:01:00 UTC"
      
 
      
 
      You can also force the creation of a date-time from a date by supplying a timezone:
      
 
      
-
      ymd("2017-01-31", tz = "UTC")
+
      ymd("2017-01-31", tz = "UTC")
 #> [1] "2017-01-31 UTC"
      
 
      
 
      Here I use the UTC3 timezone which you might also know as GMT, or Greenwich Mean Time, the time at 0° longitude4 . It doesn’t use daylight saving time, making it a bit easier to compute with .
      
@@ -681,7 +681,7 @@ 
      17.2.3 From individual components
      
 
      Instead of a single string, sometimes you’ll have the individual components of the date-time spread across multiple columns. This is what we have in the flights data:
      
 
      
-
      flights |> 
+
      flights |> 
   select(year, month, day, hour, minute)
 #> # A tibble: 336,776 × 5
 #>    year month   day  hour minute
@@ -696,7 +696,7 @@ 
      make_date() for dates, or make_datetime() for date-times:
      
 
      
-
      flights |> 
+
      flights |> 
   select(year, month, day, hour, minute) |> 
   mutate(departure = make_datetime(year, month, day, hour, minute))
 #> # A tibble: 336,776 × 6
@@ -712,7 +712,7 @@ 
      
-
      make_datetime_100 <- function(year, month, day, time) {
+
      make_datetime_100 <- function(year, month, day, time) {
   make_datetime(year, month, day, time %/% 100, time %% 100)
 }
 
@@ -741,7 +741,7 @@ 
      
-
      flights_dt |> 
+
      flights_dt |> 
   ggplot(aes(x = dep_time)) + 
   geom_freqpoly(binwidth = 86400) # 86400 seconds = 1 day
      
 
      
@@ -750,7 +750,7 @@ 
      
-
      flights_dt |> 
+
      flights_dt |> 
   filter(dep_time < ymd(20130102)) |> 
   ggplot(aes(x = dep_time)) + 
   geom_freqpoly(binwidth = 600) # 600 s = 10 minutes
      
@@ -763,14 +763,14 @@ 
      17.2.4 From other types
      
 
      You may want to switch between a date-time and a date. That’s the job of as_datetime() and as_date():
      
 
      
-
      as_datetime(today())
+
      as_datetime(today())
 #> [1] "2023-11-17 UTC"
 as_date(now())
 #> [1] "2023-11-17"
      
 
      
 
      Sometimes you’ll get date/times as numeric offsets from the “Unix Epoch”, 1970-01-01. If the offset is in seconds, use as_datetime(); if it’s in days, use as_date().
      
 
      
-
      as_datetime(60 * 60 * 10)
+
      as_datetime(60 * 60 * 10)
 #> [1] "1970-01-01 10:00:00 UTC"
 as_date(365 * 10 + 2)
 #> [1] "1980-01-01"
      
@@ -781,14 +781,14 @@ 
      
-
      ymd(c("2010-10-10", "bananas"))
      
+
      ymd(c("2010-10-10", "bananas"))
      
 
      
 
 
    • What does the tzone argument to today() do? Why is it important?
      • 
 
    • 
 
      For each of the following date-times, show how you’d parse it using a readr column specification and a lubridate function.
      
 
      
-
      d1 <- "January 1, 2010"
+
      d1 <- "January 1, 2010"
 d2 <- "2015-Mar-07"
 d3 <- "06-Jun-2017"
 d4 <- c("August 19 (2015)", "July 1 (2015)")
@@ -804,7 +804,7 @@ 
      17.3.1 Getting components
      
 
      You can pull out individual parts of the date with the accessor functions year(), month(), mday() (day of the month), yday() (day of the year), wday() (day of the week), hour(), minute(), and second(). These are effectively the opposites of make_datetime().
      
 
      
-
      datetime <- ymd_hms("2026-07-08 12:34:56")
+
      datetime <- ymd_hms("2026-07-08 12:34:56")
 
 year(datetime)
 #> [1] 2026
@@ -820,7 +820,7 @@ 
      month() and wday() you can set label = TRUE to return the abbreviated name of the month or day of the week. Set abbr = FALSE to return the full name.
      
 
      
-
      month(datetime, label = TRUE)
+
      month(datetime, label = TRUE)
 #> [1] Jul
 #> 12 Levels: Jan < Feb < Mar < Apr < May < Jun < Jul < Aug < Sep < ... < Dec
 wday(datetime, label = TRUE, abbr = FALSE)
@@ -829,7 +829,7 @@ 
      wday() to see that more flights depart during the week than on the weekend:
      
 
      
-
      flights_dt |> 
+
      flights_dt |> 
   mutate(wday = wday(dep_time, label = TRUE)) |> 
   ggplot(aes(x = wday)) +
   geom_bar()
      
@@ -839,7 +839,7 @@ 
      
-
      flights_dt |> 
+
      flights_dt |> 
   mutate(minute = minute(dep_time)) |> 
   group_by(minute) |> 
   summarize(
@@ -854,7 +854,7 @@ 
      
-
      sched_dep <- flights_dt |> 
+
      sched_dep <- flights_dt |> 
   mutate(minute = minute(sched_dep_time)) |> 
   group_by(minute) |> 
   summarize(
@@ -881,7 +881,7 @@ 
      17.3.2 Rounding
      
 
      An alternative approach to plotting individual components is to round the date to a nearby unit of time, with floor_date(), round_date(), and ceiling_date(). Each function takes a vector of dates to adjust and then the name of the unit to round down (floor), round up (ceiling), or round to. This, for example, allows us to plot the number of flights per week:
      
 
      
-
      flights_dt |> 
+
      flights_dt |> 
   count(week = floor_date(dep_time, "week")) |> 
   ggplot(aes(x = week, y = n)) +
   geom_line() + 
@@ -892,7 +892,7 @@ 
      
-
      flights_dt |> 
+
      flights_dt |> 
   mutate(dep_hour = dep_time - floor_date(dep_time, "day")) |> 
   ggplot(aes(x = dep_hour)) +
   geom_freqpoly(binwidth = 60 * 30)
@@ -904,7 +904,7 @@ 
      Seção 17.4.3). We can convert that to an hms object to get a more useful x-axis:
      
 
      
-
      flights_dt |> 
+
      flights_dt |> 
   mutate(dep_hour = hms::as_hms(dep_time - floor_date(dep_time, "day"))) |> 
   ggplot(aes(x = dep_hour)) +
   geom_freqpoly(binwidth = 60 * 30)
      
@@ -916,7 +916,7 @@ 
      17.3.3 Modifying components
      
 
      You can also use each accessor function to modify the components of a date/time. This doesn’t come up much in data analysis, but can be useful when cleaning data that has clearly incorrect dates.
      
 
      
-
      (datetime <- ymd_hms("2026-07-08 12:34:56"))
+
      (datetime <- ymd_hms("2026-07-08 12:34:56"))
 #> [1] "2026-07-08 12:34:56 UTC"
 
 year(datetime) <- 2030
@@ -931,12 +931,12 @@ 
      update(). This also allows you to set multiple values in one step:
      
 
      
-
      update(datetime, year = 2030, month = 2, mday = 2, hour = 2)
+
      update(datetime, year = 2030, month = 2, mday = 2, hour = 2)
 #> [1] "2030-02-02 02:34:56 UTC"
      
 
      
 
      If values are too big, they will roll-over:
      
 
      
-
      update(ymd("2023-02-01"), mday = 30)
+
      update(ymd("2023-02-01"), mday = 30)
 #> [1] "2023-03-02"
 update(ymd("2023-02-01"), hour = 400)
 #> [1] "2023-02-17 16:00:00 UTC"
      
@@ -967,19 +967,19 @@ 
      17.4.1 Durations
      
 
      In R, when you subtract two dates, you get a difftime object:
      
 
      
-
      # How old is Hadley?
+
      # How old is Hadley?
 h_age <- today() - ymd("1979-10-14")
 h_age
 #> Time difference of 16105 days
      
 
      
 
      A difftime class object records a time span of seconds, minutes, hours, days, or weeks. This ambiguity can make difftimes a little painful to work with, so lubridate provides an alternative which always uses seconds: the duration.
      
 
      
-
      as.duration(h_age)
+
      as.duration(h_age)
 #> [1] "1391472000s (~44.09 years)"
      
 
      
 
      Durations come with a bunch of convenient constructors:
      
 
      
-
      dseconds(15)
+
      dseconds(15)
 #> [1] "15s"
 dminutes(10)
 #> [1] "600s (~10 minutes)"
@@ -996,19 +996,19 @@ 
      
-
      2 * dyears(1)
+
      2 * dyears(1)
 #> [1] "63115200s (~2 years)"
 dyears(1) + dweeks(12) + dhours(15)
 #> [1] "38869200s (~1.23 years)"
      
 
      
 
      You can add and subtract durations to and from days:
      
 
      
-
      tomorrow <- today() + ddays(1)
+
      tomorrow <- today() + ddays(1)
 last_year <- today() - dyears(1)
      
 
      
 
      However, because durations represent an exact number of seconds, sometimes you might get an unexpected result:
      
 
      
-
      one_am <- ymd_hms("2026-03-08 01:00:00", tz = "America/New_York")
+
      one_am <- ymd_hms("2026-03-08 01:00:00", tz = "America/New_York")
 
 one_am
 #> [1] "2026-03-08 01:00:00 EST"
@@ -1020,14 +1020,14 @@ 
      17.4.2 Periods
      
 
      To solve this problem, lubridate provides periods. Periods are time spans but don’t have a fixed length in seconds, instead they work with “human” times, like days and months. That allows them to work in a more intuitive way:
      
 
      
-
      one_am
+
      one_am
 #> [1] "2026-03-08 01:00:00 EST"
 one_am + days(1)
 #> [1] "2026-03-09 01:00:00 EDT"
      
 
      
 
      Like durations, periods can be created with a number of friendly constructor functions.
      
 
      
-
      hours(c(12, 24))
+
      hours(c(12, 24))
 #> [1] "12H 0M 0S" "24H 0M 0S"
 days(7)
 #> [1] "7d 0H 0M 0S"
@@ -1037,14 +1037,14 @@ 
      
-
      10 * (months(6) + days(1))
+
      10 * (months(6) + days(1))
 #> [1] "60m 10d 0H 0M 0S"
 days(50) + hours(25) + minutes(2)
 #> [1] "50d 25H 2M 0S"
      
 
      
 
      And of course, add them to dates. Compared to durations, periods are more likely to do what you expect:
      
 
      
-
      # A leap year
+
      # A leap year
 ymd("2024-01-01") + dyears(1)
 #> [1] "2024-12-31 06:00:00 UTC"
 ymd("2024-01-01") + years(1)
@@ -1058,7 +1058,7 @@ 
      
-
      flights_dt |> 
+
      flights_dt |> 
   filter(arr_time < dep_time) 
 #> # A tibble: 10,633 × 9
 #>   origin dest  dep_delay arr_delay dep_time            sched_dep_time     
@@ -1074,7 +1074,7 @@ 
      
-
      flights_dt <- flights_dt |> 
+
      flights_dt <- flights_dt |> 
   mutate(
     overnight = arr_time < dep_time,
     arr_time = arr_time + days(overnight),
@@ -1083,7 +1083,7 @@ 
      
-
      flights_dt |> 
+
      flights_dt |> 
   filter(arr_time < dep_time) 
 #> # A tibble: 0 × 10
 #> # ℹ 10 variables: origin <chr>, dest <chr>, dep_delay <dbl>,
@@ -1094,13 +1094,13 @@ 
      dyears() is defined as the number of seconds per average year, which is 365.25 days.
      
 
      What does years(1) / days(1) return? Well, if the year was 2015 it should return 365, but if it was 2016, it should return 366! There’s not quite enough information for lubridate to give a single clear answer. What it does instead is give an estimate:
      
 
      
-
      years(1) / days(1)
+
      years(1) / days(1)
 #> [1] 365.25
      
 
      
 
      If you want a more accurate measurement, you’ll have to use an interval. An interval is a pair of starting and ending date times, or you can think of it as a duration with a starting point.
      
 
      You can create an interval by writing start %--% end:
      
 
      
-
      y2023 <- ymd("2023-01-01") %--% ymd("2024-01-01")
+
      y2023 <- ymd("2023-01-01") %--% ymd("2024-01-01")
 y2024 <- ymd("2024-01-01") %--% ymd("2025-01-01")
 
 y2023
@@ -1110,7 +1110,7 @@ 
      days() to find out how many days fit in the year:
      
 
      
-
      y2023 / days(1)
+
      y2023 / days(1)
 #> [1] 365
 y2024 / days(1)
 #> [1] 366
      
@@ -1130,13 +1130,13 @@ 
      • 
   
    • 16.6 Ordered factors
      • 
   
    • 16.7 Summary
      • 
-  
    Editar essa página
    Criar uma issue
    
+  
    Editar essa página
    Criar uma issue
    
     
    
 
 
    
diff --git a/functions.html b/functions.html
index 491ad9b50..8691b1fdb 100644
--- a/functions.html
+++ b/functions.html
@@ -113,7 +113,7 @@
     
    
       R para Ciência de Dados (2ª edição) 
         
    
-    
+    
   
   
    
   
@@ -437,7 +437,7 @@
   
 
   
  • 25.6 Summary
    • 
-  
    Editar essa página
    Criar uma issue
    
+  
    Editar essa página
    Criar uma issue
    
     
    
 
 
    
diff --git a/import.html b/import.html
index b97563016..059de9ca6 100644
--- a/import.html
+++ b/import.html
@@ -79,7 +79,7 @@
     
    
       R para Ciência de Dados (2ª edição) 
         
    
-    
+    
   
   
    
   
@@ -644,7 +644,7 @@ 
    Import
     
    R para Ciência de Dados (2ª edição) foi escrito por Hadley Wickham, Mine Çetinkaya-Rundel, e Garrett Grolemund.
       
     
    
        
-    
    Editar essa página
    Criar uma issue
    
+    
    Editar essa página
    Criar uma issue
    
     
    Este livro foi contruído com Quarto.
    
   
    
 
diff --git a/index.html b/index.html
index e6d1a854f..aa43c172b 100644
--- a/index.html
+++ b/index.html
@@ -93,7 +93,7 @@
     
    
       R para Ciência de Dados (2ª edição) 
         
    
-    
+    
   
   
    
   
@@ -382,7 +382,7 @@ 
    Índice
    
   
  • Agradecimentos
    • 
   
   
-
    Editar essa página
    Criar uma issue
    
+
    Editar essa página
    Criar uma issue
    
     
    
 
 
    
diff --git a/intro.html b/intro.html
index 7658a245e..8a245fb88 100644
--- a/intro.html
+++ b/intro.html
@@ -113,7 +113,7 @@
     
    
       R para Ciência de Dados (2ª edição) 
         
    
-    
+    
   
   
    
   
@@ -417,7 +417,7 @@
   
  • Executando código em R
    • 
   
  • Agradecimentos
    • 
   
  • Considerações Finais
    • 
-  
    Editar essa página
    Criar uma issue
    
+  
    Editar essa página
    Criar uma issue
    
     
    
 
 
    
diff --git a/iteration.html b/iteration.html
index 6676656e4..51d63a006 100644
--- a/iteration.html
+++ b/iteration.html
@@ -113,7 +113,7 @@
     
    
       R para Ciência de Dados (2ª edição) 
         
    
-    
+    
   
   
    
   
@@ -436,7 +436,7 @@
   
 
   
  • 26.5 Summary
    • 
-  
    Editar essa página
    Criar uma issue
    
+  
    Editar essa página
    Criar uma issue
    
     
    
 
 
    
@@ -1274,7 +1274,7 @@ 
    
 
    con |> tbl("gapminder")
 #> # Source:   table<gapminder> [0 x 6]
-#> # Database: DuckDB v0.9.1 [unknown@Linux 6.2.0-1016-azure:R 4.3.2/:memory:]
+#> # Database: DuckDB v0.9.1 [unknown@Linux 6.2.0-1015-azure:R 4.3.2/:memory:]
 #> # ℹ 6 variables: country <chr>, continent <chr>, lifeExp <dbl>, pop <dbl>,
 #> #   gdpPercap <dbl>, year <dbl>
    
 
    
@@ -1301,13 +1301,13 @@ 
      tbl("gapminder") |> 
   count(year)
 #> # Source:   SQL [?? x 2]
-#> # Database: DuckDB v0.9.1 [unknown@Linux 6.2.0-1016-azure:R 4.3.2/:memory:]
+#> # Database: DuckDB v0.9.1 [unknown@Linux 6.2.0-1015-azure:R 4.3.2/:memory:]
 #>    year     n
 #>   <dbl> <dbl>
-#> 1  1967   142
-#> 2  1977   142
-#> 3  1987   142
-#> 4  2007   142
+#> 1  2007   142
+#> 2  1967   142
+#> 3  1977   142
+#> 4  1987   142
 #> 5  1952   142
 #> 6  1957   142
 #> # ℹ more rows

    diff --git a/joins.html b/joins.html index cffc13b46..c93d61445 100644 --- a/joins.html +++ b/joins.html @@ -113,7 +113,7 @@
    R para Ciência de Dados (2ª edição)
    - +
    @@ -437,7 +437,7 @@
  • 19.6 Summary
    • -

    Editar essa página

    Criar uma issue

    +

    Editar essa página

    Criar uma issue

    diff --git a/layers.html b/layers.html index d4c8e40c8..9e4841f2b 100644 --- a/layers.html +++ b/layers.html @@ -113,7 +113,7 @@
    R para Ciência de Dados (2ª edição)
    - +
    @@ -439,7 +439,7 @@
  • 9.8 The layered grammar of graphics
  • 9.9 Summary
    • -

    Editar essa página

    Criar uma issue

    +

    Editar essa página

    Criar uma issue

    diff --git a/logicals.html b/logicals.html index d2e02c4ae..2df1bd9c0 100644 --- a/logicals.html +++ b/logicals.html @@ -113,7 +113,7 @@
    R para Ciência de Dados (2ª edição)
    - +
    @@ -438,7 +438,7 @@
  • 12.6 Summary
    • -

    Editar essa página

    Criar uma issue

    +

    Editar essa página

    Criar uma issue

    diff --git a/missing-values.html b/missing-values.html index 27418188a..dfae5452f 100644 --- a/missing-values.html +++ b/missing-values.html @@ -113,7 +113,7 @@
    R para Ciência de Dados (2ª edição)
    - +
    @@ -420,7 +420,7 @@
  • 18.4 Factors and empty groups
  • 18.5 Summary
    • -

    Editar essa página

    Criar uma issue

    +

    Editar essa página

    Criar uma issue

    diff --git a/numbers.html b/numbers.html index 2c1897a0f..633e78bd1 100644 --- a/numbers.html +++ b/numbers.html @@ -113,7 +113,7 @@
    R para Ciência de Dados (2ª edição)
    - +
    @@ -443,7 +443,7 @@
  • 13.7 Summary
    • -

    Editar essa página

    Criar uma issue

    +

    Editar essa página

    Criar uma issue

    diff --git a/preface-2e.html b/preface-2e.html index 6c3c29235..c7be4c855 100644 --- a/preface-2e.html +++ b/preface-2e.html @@ -94,7 +94,7 @@
    R para Ciência de Dados (2ª edição)
    - +
    @@ -662,7 +662,7 @@

    Prefácio da segunda edição

    R para Ciência de Dados (2ª edição) foi escrito por Hadley Wickham, Mine Çetinkaya-Rundel, e Garrett Grolemund.
      -

    Editar essa página

    Criar uma issue

    +

    Editar essa página

    Criar uma issue

    Este livro foi contruído com Quarto.
    diff --git a/program.html b/program.html index 77efe1e7d..3760c678a 100644 --- a/program.html +++ b/program.html @@ -79,7 +79,7 @@
    R para Ciência de Dados (2ª edição)
    - +
    @@ -643,7 +643,7 @@

    R para Ciência de Dados (2ª edição) foi escrito por Hadley Wickham, Mine Çetinkaya-Rundel, e Garrett Grolemund.

      -

    Editar essa página

    Criar uma issue

    +

    Editar essa página

    Criar uma issue

    Este livro foi contruído com Quarto.
    diff --git a/quarto-formats.html b/quarto-formats.html index e6848cbed..dae0c3b29 100644 --- a/quarto-formats.html +++ b/quarto-formats.html @@ -115,7 +115,7 @@
    R para Ciência de Dados (2ª edição)
    - +
    @@ -411,7 +411,7 @@
  • 29.6 Websites and books
  • 29.7 Other formats
  • 29.8 Summary
    • -

    Editar essa página

    Criar uma issue

    +

    Editar essa página

    Criar uma issue

    diff --git a/quarto.html b/quarto.html index 2a01bf24f..d3bb96edb 100644 --- a/quarto.html +++ b/quarto.html @@ -113,7 +113,7 @@
    R para Ciência de Dados (2ª edição)
    - +
    @@ -460,7 +460,7 @@
  • 28.11 Workflow
  • 28.12 Summary
    • -

    Editar essa página

    Criar uma issue

    +

    Editar essa página

    Criar uma issue

    diff --git a/rectangling.html b/rectangling.html index 871bb6bee..813556b51 100644 --- a/rectangling.html +++ b/rectangling.html @@ -113,7 +113,7 @@
    R para Ciência de Dados (2ª edição)
    - +
    @@ -437,7 +437,7 @@
  • 23.6 Summary
    • -

    Editar essa página

    Criar uma issue

    +

    Editar essa página

    Criar uma issue

    diff --git a/regexps.html b/regexps.html index f389bb0eb..60f069c12 100644 --- a/regexps.html +++ b/regexps.html @@ -113,7 +113,7 @@
    R para Ciência de Dados (2ª edição)
    - +
    @@ -448,7 +448,7 @@
  • 15.8 Summary
    • -

    Editar essa página

    Criar uma issue

    +

    Editar essa página

    Criar uma issue

    diff --git a/robots.txt b/robots.txt index b1fc7ef84..0ac8fbe39 100644 --- a/robots.txt +++ b/robots.txt @@ -1 +1 @@ -Sitemap: https://r4ds.hadley.nz/sitemap.xml +Sitemap: https://cienciadedatos.github.io/pt-r4ds/sitemap.xml diff --git a/search.json b/search.json index 73a5d3ed7..eb09f5f12 100644 --- a/search.json +++ b/search.json @@ -396,7 +396,7 @@ "href": "data-import.html#sec-col-types", "title": "7  Data import", "section": "\n7.3 Controlling column types", - "text": "7.3 Controlling column types\nA CSV file doesn’t contain any information about the type of each variable (i.e. whether it’s a logical, number, string, etc.), so readr will try to guess the type. This section describes how the guessing process works, how to resolve some common problems that cause it to fail, and, if needed, how to supply the column types yourself. Finally, we’ll mention a few general strategies that are useful if readr is failing catastrophically and you need to get more insight into the structure of your file.\n\n7.3.1 Guessing types\nreadr uses a heuristic to figure out the column types. For each column, it pulls the values of 1,0002 rows spaced evenly from the first row to the last, ignoring missing values. It then works through the following questions:\n\nDoes it contain only F, T, FALSE, or TRUE (ignoring case)? If so, it’s a logical.\nDoes it contain only numbers (e.g., 1, -4.5, 5e6, Inf)? If so, it’s a number.\nDoes it match the ISO8601 standard? If so, it’s a date or date-time. (We’ll return to date-times in more detail in Seção 17.2).\nOtherwise, it must be a string.\n\nYou can see that behavior in action in this simple example:\n\nread_csv(\"\n logical,numeric,date,string\n TRUE,1,2021-01-15,abc\n false,4.5,2021-02-15,def\n T,Inf,2021-02-16,ghi\n\")\n#> # A tibble: 3 × 4\n#> logical numeric date string\n#> <lgl> <dbl> <date> <chr> \n#> 1 TRUE 1 2021-01-15 abc \n#> 2 FALSE 4.5 2021-02-15 def \n#> 3 TRUE Inf 2021-02-16 ghi\n\nThis heuristic works well if you have a clean dataset, but in real life, you’ll encounter a selection of weird and beautiful failures.\n\n7.3.2 Missing values, column types, and problems\nThe most common way column detection fails is that a column contains unexpected values, and you get a character column instead of a more specific type. One of the most common causes for this is a missing value, recorded using something other than the NA that readr expects.\nTake this simple 1 column CSV file as an example:\n\nsimple_csv <- \"\n x\n 10\n .\n 20\n 30\"\n\nIf we read it without any additional arguments, x becomes a character column:\n\nread_csv(simple_csv)\n#> # A tibble: 4 × 1\n#> x \n#> <chr>\n#> 1 10 \n#> 2 . \n#> 3 20 \n#> 4 30\n\nIn this very small case, you can easily see the missing value .. But what happens if you have thousands of rows with only a few missing values represented by .s sprinkled among them? One approach is to tell readr that x is a numeric column, and then see where it fails. You can do that with the col_types argument, which takes a named list where the names match the column names in the CSV file:\n\ndf <- read_csv(\n simple_csv, \n col_types = list(x = col_double())\n)\n#> Warning: One or more parsing issues, call `problems()` on your data frame for\n#> details, e.g.:\n#> dat <- vroom(...)\n#> problems(dat)\n\nNow read_csv() reports that there was a problem, and tells us we can find out more with problems():\n\nproblems(df)\n#> # A tibble: 1 × 5\n#> row col expected actual file \n#> <int> <int> <chr> <chr> <chr> \n#> 1 3 1 a double . /tmp/RtmprQ7oUD/file1e2549f0663d\n\nThis tells us that there was a problem in row 3, col 1 where readr expected a double but got a .. That suggests this dataset uses . for missing values. So then we set na = \".\", the automatic guessing succeeds, giving us the numeric column that we want:\n\nread_csv(simple_csv, na = \".\")\n#> # A tibble: 4 × 1\n#> x\n#> <dbl>\n#> 1 10\n#> 2 NA\n#> 3 20\n#> 4 30\n\n\n7.3.3 Column types\nreadr provides a total of nine column types for you to use:\n\n\ncol_logical() and col_double() read logicals and real numbers. They’re relatively rarely needed (except as above), since readr will usually guess them for you.\n\ncol_integer() reads integers. We seldom distinguish integers and doubles in this book because they’re functionally equivalent, but reading integers explicitly can occasionally be useful because they occupy half the memory of doubles.\n\ncol_character() reads strings. This can be useful to specify explicitly when you have a column that is a numeric identifier, i.e., long series of digits that identifies an object but doesn’t make sense to apply mathematical operations to. Examples include phone numbers, social security numbers, credit card numbers, etc.\n\ncol_factor(), col_date(), and col_datetime() create factors, dates, and date-times respectively; you’ll learn more about those when we get to those data types in Capítulo 16 and Capítulo 17.\n\ncol_number() is a permissive numeric parser that will ignore non-numeric components, and is particularly useful for currencies. You’ll learn more about it in Capítulo 13.\n\ncol_skip() skips a column so it’s not included in the result, which can be useful for speeding up reading the data if you have a large CSV file and you only want to use some of the columns.\n\nIt’s also possible to override the default column by switching from list() to cols() and specifying .default:\n\nanother_csv <- \"\nx,y,z\n1,2,3\"\n\nread_csv(\n another_csv, \n col_types = cols(.default = col_character())\n)\n#> # A tibble: 1 × 3\n#> x y z \n#> <chr> <chr> <chr>\n#> 1 1 2 3\n\nAnother useful helper is cols_only() which will read in only the columns you specify:\n\nread_csv(\n another_csv,\n col_types = cols_only(x = col_character())\n)\n#> # A tibble: 1 × 1\n#> x \n#> <chr>\n#> 1 1" + "text": "7.3 Controlling column types\nA CSV file doesn’t contain any information about the type of each variable (i.e. whether it’s a logical, number, string, etc.), so readr will try to guess the type. This section describes how the guessing process works, how to resolve some common problems that cause it to fail, and, if needed, how to supply the column types yourself. Finally, we’ll mention a few general strategies that are useful if readr is failing catastrophically and you need to get more insight into the structure of your file.\n\n7.3.1 Guessing types\nreadr uses a heuristic to figure out the column types. For each column, it pulls the values of 1,0002 rows spaced evenly from the first row to the last, ignoring missing values. It then works through the following questions:\n\nDoes it contain only F, T, FALSE, or TRUE (ignoring case)? If so, it’s a logical.\nDoes it contain only numbers (e.g., 1, -4.5, 5e6, Inf)? If so, it’s a number.\nDoes it match the ISO8601 standard? If so, it’s a date or date-time. (We’ll return to date-times in more detail in Seção 17.2).\nOtherwise, it must be a string.\n\nYou can see that behavior in action in this simple example:\n\nread_csv(\"\n logical,numeric,date,string\n TRUE,1,2021-01-15,abc\n false,4.5,2021-02-15,def\n T,Inf,2021-02-16,ghi\n\")\n#> # A tibble: 3 × 4\n#> logical numeric date string\n#> <lgl> <dbl> <date> <chr> \n#> 1 TRUE 1 2021-01-15 abc \n#> 2 FALSE 4.5 2021-02-15 def \n#> 3 TRUE Inf 2021-02-16 ghi\n\nThis heuristic works well if you have a clean dataset, but in real life, you’ll encounter a selection of weird and beautiful failures.\n\n7.3.2 Missing values, column types, and problems\nThe most common way column detection fails is that a column contains unexpected values, and you get a character column instead of a more specific type. One of the most common causes for this is a missing value, recorded using something other than the NA that readr expects.\nTake this simple 1 column CSV file as an example:\n\nsimple_csv <- \"\n x\n 10\n .\n 20\n 30\"\n\nIf we read it without any additional arguments, x becomes a character column:\n\nread_csv(simple_csv)\n#> # A tibble: 4 × 1\n#> x \n#> <chr>\n#> 1 10 \n#> 2 . \n#> 3 20 \n#> 4 30\n\nIn this very small case, you can easily see the missing value .. But what happens if you have thousands of rows with only a few missing values represented by .s sprinkled among them? One approach is to tell readr that x is a numeric column, and then see where it fails. You can do that with the col_types argument, which takes a named list where the names match the column names in the CSV file:\n\ndf <- read_csv(\n simple_csv, \n col_types = list(x = col_double())\n)\n#> Warning: One or more parsing issues, call `problems()` on your data frame for\n#> details, e.g.:\n#> dat <- vroom(...)\n#> problems(dat)\n\nNow read_csv() reports that there was a problem, and tells us we can find out more with problems():\n\nproblems(df)\n#> # A tibble: 1 × 5\n#> row col expected actual file \n#> <int> <int> <chr> <chr> <chr> \n#> 1 3 1 a double . /tmp/RtmpmQKHAo/file1e8c59e6768d\n\nThis tells us that there was a problem in row 3, col 1 where readr expected a double but got a .. That suggests this dataset uses . for missing values. So then we set na = \".\", the automatic guessing succeeds, giving us the numeric column that we want:\n\nread_csv(simple_csv, na = \".\")\n#> # A tibble: 4 × 1\n#> x\n#> <dbl>\n#> 1 10\n#> 2 NA\n#> 3 20\n#> 4 30\n\n\n7.3.3 Column types\nreadr provides a total of nine column types for you to use:\n\n\ncol_logical() and col_double() read logicals and real numbers. They’re relatively rarely needed (except as above), since readr will usually guess them for you.\n\ncol_integer() reads integers. We seldom distinguish integers and doubles in this book because they’re functionally equivalent, but reading integers explicitly can occasionally be useful because they occupy half the memory of doubles.\n\ncol_character() reads strings. This can be useful to specify explicitly when you have a column that is a numeric identifier, i.e., long series of digits that identifies an object but doesn’t make sense to apply mathematical operations to. Examples include phone numbers, social security numbers, credit card numbers, etc.\n\ncol_factor(), col_date(), and col_datetime() create factors, dates, and date-times respectively; you’ll learn more about those when we get to those data types in Capítulo 16 and Capítulo 17.\n\ncol_number() is a permissive numeric parser that will ignore non-numeric components, and is particularly useful for currencies. You’ll learn more about it in Capítulo 13.\n\ncol_skip() skips a column so it’s not included in the result, which can be useful for speeding up reading the data if you have a large CSV file and you only want to use some of the columns.\n\nIt’s also possible to override the default column by switching from list() to cols() and specifying .default:\n\nanother_csv <- \"\nx,y,z\n1,2,3\"\n\nread_csv(\n another_csv, \n col_types = cols(.default = col_character())\n)\n#> # A tibble: 1 × 3\n#> x y z \n#> <chr> <chr> <chr>\n#> 1 1 2 3\n\nAnother useful helper is cols_only() which will read in only the columns you specify:\n\nread_csv(\n another_csv,\n col_types = cols_only(x = col_character())\n)\n#> # A tibble: 1 × 1\n#> x \n#> <chr>\n#> 1 1" }, { "objectID": "data-import.html#sec-readr-directory", @@ -942,7 +942,7 @@ "href": "datetimes.html#sec-creating-datetimes", "title": "17  Dates and times", "section": "\n17.2 Creating date/times", - "text": "17.2 Creating date/times\nThere are three types of date/time data that refer to an instant in time:\n\nA date. Tibbles print this as <date>.\nA time within a day. Tibbles print this as <time>.\nA date-time is a date plus a time: it uniquely identifies an instant in time (typically to the nearest second). Tibbles print this as <dttm>. Base R calls these POSIXct, but doesn’t exactly trip off the tongue.\n\nIn this chapter we are going to focus on dates and date-times as R doesn’t have a native class for storing times. If you need one, you can use the hms package.\nYou should always use the simplest possible data type that works for your needs. That means if you can use a date instead of a date-time, you should. Date-times are substantially more complicated because of the need to handle time zones, which we’ll come back to at the end of the chapter.\nTo get the current date or date-time you can use today() or now():\n\ntoday()\n#> [1] \"2023-11-17\"\nnow()\n#> [1] \"2023-11-17 21:36:55 UTC\"\n\nOtherwise, the following sections describe the four ways you’re likely to create a date/time:\n\nWhile reading a file with readr.\nFrom a string.\nFrom individual date-time components.\nFrom an existing date/time object.\n\n\n17.2.1 During import\nIf your CSV contains an ISO8601 date or date-time, you don’t need to do anything; readr will automatically recognize it:\n\ncsv <- \"\n date,datetime\n 2022-01-02,2022-01-02 05:12\n\"\nread_csv(csv)\n#> # A tibble: 1 × 2\n#> date datetime \n#> <date> <dttm> \n#> 1 2022-01-02 2022-01-02 05:12:00\n\nIf you haven’t heard of ISO8601 before, it’s an international standard2 for writing dates where the components of a date are organized from biggest to smallest separated by -. For example, in ISO8601 May 3 2022 is 2022-05-03. ISO8601 dates can also include times, where hour, minute, and second are separated by :, and the date and time components are separated by either a T or a space. For example, you could write 4:26pm on May 3 2022 as either 2022-05-03 16:26 or 2022-05-03T16:26.\nFor other date-time formats, you’ll need to use col_types plus col_date() or col_datetime() along with a date-time format. The date-time format used by readr is a standard used across many programming languages, describing a date component with a % followed by a single character. For example, %Y-%m-%d specifies a date that’s a year, -, month (as number) -, day. Table Tabela 17.1 lists all the options.\n\n\nTabela 17.1: All date formats understood by readr\n\nType\nCode\nMeaning\nExample\n\n\n\nYear\n%Y\n4 digit year\n2021\n\n\n\n%y\n2 digit year\n21\n\n\nMonth\n%m\nNumber\n2\n\n\n\n%b\nAbbreviated name\nFeb\n\n\n\n%B\nFull name\nFebruary\n\n\nDay\n%d\nOne or two digits\n2\n\n\n\n%e\nTwo digits\n02\n\n\nTime\n%H\n24-hour hour\n13\n\n\n\n%I\n12-hour hour\n1\n\n\n\n%p\nAM/PM\npm\n\n\n\n%M\nMinutes\n35\n\n\n\n%S\nSeconds\n45\n\n\n\n%OS\nSeconds with decimal component\n45.35\n\n\n\n%Z\nTime zone name\nAmerica/Chicago\n\n\n\n%z\nOffset from UTC\n+0800\n\n\nOther\n%.\nSkip one non-digit\n:\n\n\n\n%*\nSkip any number of non-digits\n\n\n\n\n\nAnd this code shows a few options applied to a very ambiguous date:\n\ncsv <- \"\n date\n 01/02/15\n\"\n\nread_csv(csv, col_types = cols(date = col_date(\"%m/%d/%y\")))\n#> # A tibble: 1 × 1\n#> date \n#> <date> \n#> 1 2015-01-02\n\nread_csv(csv, col_types = cols(date = col_date(\"%d/%m/%y\")))\n#> # A tibble: 1 × 1\n#> date \n#> <date> \n#> 1 2015-02-01\n\nread_csv(csv, col_types = cols(date = col_date(\"%y/%m/%d\")))\n#> # A tibble: 1 × 1\n#> date \n#> <date> \n#> 1 2001-02-15\n\nNote that no matter how you specify the date format, it’s always displayed the same way once you get it into R.\nIf you’re using %b or %B and working with non-English dates, you’ll also need to provide a locale(). See the list of built-in languages in date_names_langs(), or create your own with date_names(),\n\n17.2.2 From strings\nThe date-time specification language is powerful, but requires careful analysis of the date format. An alternative approach is to use lubridate’s helpers which attempt to automatically determine the format once you specify the order of the component. To use them, identify the order in which year, month, and day appear in your dates, then arrange “y”, “m”, and “d” in the same order. That gives you the name of the lubridate function that will parse your date. For example:\n\nymd(\"2017-01-31\")\n#> [1] \"2017-01-31\"\nmdy(\"January 31st, 2017\")\n#> [1] \"2017-01-31\"\ndmy(\"31-Jan-2017\")\n#> [1] \"2017-01-31\"\n\nymd() and friends create dates. To create a date-time, add an underscore and one or more of “h”, “m”, and “s” to the name of the parsing function:\n\nymd_hms(\"2017-01-31 20:11:59\")\n#> [1] \"2017-01-31 20:11:59 UTC\"\nmdy_hm(\"01/31/2017 08:01\")\n#> [1] \"2017-01-31 08:01:00 UTC\"\n\nYou can also force the creation of a date-time from a date by supplying a timezone:\n\nymd(\"2017-01-31\", tz = \"UTC\")\n#> [1] \"2017-01-31 UTC\"\n\nHere I use the UTC3 timezone which you might also know as GMT, or Greenwich Mean Time, the time at 0° longitude4 . It doesn’t use daylight saving time, making it a bit easier to compute with .\n\n17.2.3 From individual components\nInstead of a single string, sometimes you’ll have the individual components of the date-time spread across multiple columns. This is what we have in the flights data:\n\nflights |> \n select(year, month, day, hour, minute)\n#> # A tibble: 336,776 × 5\n#> year month day hour minute\n#> <int> <int> <int> <dbl> <dbl>\n#> 1 2013 1 1 5 15\n#> 2 2013 1 1 5 29\n#> 3 2013 1 1 5 40\n#> 4 2013 1 1 5 45\n#> 5 2013 1 1 6 0\n#> 6 2013 1 1 5 58\n#> # ℹ 336,770 more rows\n\nTo create a date/time from this sort of input, use make_date() for dates, or make_datetime() for date-times:\n\nflights |> \n select(year, month, day, hour, minute) |> \n mutate(departure = make_datetime(year, month, day, hour, minute))\n#> # A tibble: 336,776 × 6\n#> year month day hour minute departure \n#> <int> <int> <int> <dbl> <dbl> <dttm> \n#> 1 2013 1 1 5 15 2013-01-01 05:15:00\n#> 2 2013 1 1 5 29 2013-01-01 05:29:00\n#> 3 2013 1 1 5 40 2013-01-01 05:40:00\n#> 4 2013 1 1 5 45 2013-01-01 05:45:00\n#> 5 2013 1 1 6 0 2013-01-01 06:00:00\n#> 6 2013 1 1 5 58 2013-01-01 05:58:00\n#> # ℹ 336,770 more rows\n\nLet’s do the same thing for each of the four time columns in flights. The times are represented in a slightly odd format, so we use modulus arithmetic to pull out the hour and minute components. Once we’ve created the date-time variables, we focus in on the variables we’ll explore in the rest of the chapter.\n\nmake_datetime_100 <- function(year, month, day, time) {\n make_datetime(year, month, day, time %/% 100, time %% 100)\n}\n\nflights_dt <- flights |> \n filter(!is.na(dep_time), !is.na(arr_time)) |> \n mutate(\n dep_time = make_datetime_100(year, month, day, dep_time),\n arr_time = make_datetime_100(year, month, day, arr_time),\n sched_dep_time = make_datetime_100(year, month, day, sched_dep_time),\n sched_arr_time = make_datetime_100(year, month, day, sched_arr_time)\n ) |> \n select(origin, dest, ends_with(\"delay\"), ends_with(\"time\"))\n\nflights_dt\n#> # A tibble: 328,063 × 9\n#> origin dest dep_delay arr_delay dep_time sched_dep_time \n#> <chr> <chr> <dbl> <dbl> <dttm> <dttm> \n#> 1 EWR IAH 2 11 2013-01-01 05:17:00 2013-01-01 05:15:00\n#> 2 LGA IAH 4 20 2013-01-01 05:33:00 2013-01-01 05:29:00\n#> 3 JFK MIA 2 33 2013-01-01 05:42:00 2013-01-01 05:40:00\n#> 4 JFK BQN -1 -18 2013-01-01 05:44:00 2013-01-01 05:45:00\n#> 5 LGA ATL -6 -25 2013-01-01 05:54:00 2013-01-01 06:00:00\n#> 6 EWR ORD -4 12 2013-01-01 05:54:00 2013-01-01 05:58:00\n#> # ℹ 328,057 more rows\n#> # ℹ 3 more variables: arr_time <dttm>, sched_arr_time <dttm>, …\n\nWith this data, we can visualize the distribution of departure times across the year:\n\nflights_dt |> \n ggplot(aes(x = dep_time)) + \n geom_freqpoly(binwidth = 86400) # 86400 seconds = 1 day\n\n\n\n\nOr within a single day:\n\nflights_dt |> \n filter(dep_time < ymd(20130102)) |> \n ggplot(aes(x = dep_time)) + \n geom_freqpoly(binwidth = 600) # 600 s = 10 minutes\n\n\n\n\nNote that when you use date-times in a numeric context (like in a histogram), 1 means 1 second, so a binwidth of 86400 means one day. For dates, 1 means 1 day.\n\n17.2.4 From other types\nYou may want to switch between a date-time and a date. That’s the job of as_datetime() and as_date():\n\nas_datetime(today())\n#> [1] \"2023-11-17 UTC\"\nas_date(now())\n#> [1] \"2023-11-17\"\n\nSometimes you’ll get date/times as numeric offsets from the “Unix Epoch”, 1970-01-01. If the offset is in seconds, use as_datetime(); if it’s in days, use as_date().\n\nas_datetime(60 * 60 * 10)\n#> [1] \"1970-01-01 10:00:00 UTC\"\nas_date(365 * 10 + 2)\n#> [1] \"1980-01-01\"\n\n\n17.2.5 Exercises\n\n\nWhat happens if you parse a string that contains invalid dates?\n\nymd(c(\"2010-10-10\", \"bananas\"))\n\n\nWhat does the tzone argument to today() do? Why is it important?\n\nFor each of the following date-times, show how you’d parse it using a readr column specification and a lubridate function.\n\nd1 <- \"January 1, 2010\"\nd2 <- \"2015-Mar-07\"\nd3 <- \"06-Jun-2017\"\nd4 <- c(\"August 19 (2015)\", \"July 1 (2015)\")\nd5 <- \"12/30/14\" # Dec 30, 2014\nt1 <- \"1705\"\nt2 <- \"11:15:10.12 PM\"" + "text": "17.2 Creating date/times\nThere are three types of date/time data that refer to an instant in time:\n\nA date. Tibbles print this as <date>.\nA time within a day. Tibbles print this as <time>.\nA date-time is a date plus a time: it uniquely identifies an instant in time (typically to the nearest second). Tibbles print this as <dttm>. Base R calls these POSIXct, but doesn’t exactly trip off the tongue.\n\nIn this chapter we are going to focus on dates and date-times as R doesn’t have a native class for storing times. If you need one, you can use the hms package.\nYou should always use the simplest possible data type that works for your needs. That means if you can use a date instead of a date-time, you should. Date-times are substantially more complicated because of the need to handle time zones, which we’ll come back to at the end of the chapter.\nTo get the current date or date-time you can use today() or now():\n\ntoday()\n#> [1] \"2023-11-17\"\nnow()\n#> [1] \"2023-11-17 22:04:44 UTC\"\n\nOtherwise, the following sections describe the four ways you’re likely to create a date/time:\n\nWhile reading a file with readr.\nFrom a string.\nFrom individual date-time components.\nFrom an existing date/time object.\n\n\n17.2.1 During import\nIf your CSV contains an ISO8601 date or date-time, you don’t need to do anything; readr will automatically recognize it:\n\ncsv <- \"\n date,datetime\n 2022-01-02,2022-01-02 05:12\n\"\nread_csv(csv)\n#> # A tibble: 1 × 2\n#> date datetime \n#> <date> <dttm> \n#> 1 2022-01-02 2022-01-02 05:12:00\n\nIf you haven’t heard of ISO8601 before, it’s an international standard2 for writing dates where the components of a date are organized from biggest to smallest separated by -. For example, in ISO8601 May 3 2022 is 2022-05-03. ISO8601 dates can also include times, where hour, minute, and second are separated by :, and the date and time components are separated by either a T or a space. For example, you could write 4:26pm on May 3 2022 as either 2022-05-03 16:26 or 2022-05-03T16:26.\nFor other date-time formats, you’ll need to use col_types plus col_date() or col_datetime() along with a date-time format. The date-time format used by readr is a standard used across many programming languages, describing a date component with a % followed by a single character. For example, %Y-%m-%d specifies a date that’s a year, -, month (as number) -, day. Table Tabela 17.1 lists all the options.\n\n\nTabela 17.1: All date formats understood by readr\n\nType\nCode\nMeaning\nExample\n\n\n\nYear\n%Y\n4 digit year\n2021\n\n\n\n%y\n2 digit year\n21\n\n\nMonth\n%m\nNumber\n2\n\n\n\n%b\nAbbreviated name\nFeb\n\n\n\n%B\nFull name\nFebruary\n\n\nDay\n%d\nOne or two digits\n2\n\n\n\n%e\nTwo digits\n02\n\n\nTime\n%H\n24-hour hour\n13\n\n\n\n%I\n12-hour hour\n1\n\n\n\n%p\nAM/PM\npm\n\n\n\n%M\nMinutes\n35\n\n\n\n%S\nSeconds\n45\n\n\n\n%OS\nSeconds with decimal component\n45.35\n\n\n\n%Z\nTime zone name\nAmerica/Chicago\n\n\n\n%z\nOffset from UTC\n+0800\n\n\nOther\n%.\nSkip one non-digit\n:\n\n\n\n%*\nSkip any number of non-digits\n\n\n\n\n\nAnd this code shows a few options applied to a very ambiguous date:\n\ncsv <- \"\n date\n 01/02/15\n\"\n\nread_csv(csv, col_types = cols(date = col_date(\"%m/%d/%y\")))\n#> # A tibble: 1 × 1\n#> date \n#> <date> \n#> 1 2015-01-02\n\nread_csv(csv, col_types = cols(date = col_date(\"%d/%m/%y\")))\n#> # A tibble: 1 × 1\n#> date \n#> <date> \n#> 1 2015-02-01\n\nread_csv(csv, col_types = cols(date = col_date(\"%y/%m/%d\")))\n#> # A tibble: 1 × 1\n#> date \n#> <date> \n#> 1 2001-02-15\n\nNote that no matter how you specify the date format, it’s always displayed the same way once you get it into R.\nIf you’re using %b or %B and working with non-English dates, you’ll also need to provide a locale(). See the list of built-in languages in date_names_langs(), or create your own with date_names(),\n\n17.2.2 From strings\nThe date-time specification language is powerful, but requires careful analysis of the date format. An alternative approach is to use lubridate’s helpers which attempt to automatically determine the format once you specify the order of the component. To use them, identify the order in which year, month, and day appear in your dates, then arrange “y”, “m”, and “d” in the same order. That gives you the name of the lubridate function that will parse your date. For example:\n\nymd(\"2017-01-31\")\n#> [1] \"2017-01-31\"\nmdy(\"January 31st, 2017\")\n#> [1] \"2017-01-31\"\ndmy(\"31-Jan-2017\")\n#> [1] \"2017-01-31\"\n\nymd() and friends create dates. To create a date-time, add an underscore and one or more of “h”, “m”, and “s” to the name of the parsing function:\n\nymd_hms(\"2017-01-31 20:11:59\")\n#> [1] \"2017-01-31 20:11:59 UTC\"\nmdy_hm(\"01/31/2017 08:01\")\n#> [1] \"2017-01-31 08:01:00 UTC\"\n\nYou can also force the creation of a date-time from a date by supplying a timezone:\n\nymd(\"2017-01-31\", tz = \"UTC\")\n#> [1] \"2017-01-31 UTC\"\n\nHere I use the UTC3 timezone which you might also know as GMT, or Greenwich Mean Time, the time at 0° longitude4 . It doesn’t use daylight saving time, making it a bit easier to compute with .\n\n17.2.3 From individual components\nInstead of a single string, sometimes you’ll have the individual components of the date-time spread across multiple columns. This is what we have in the flights data:\n\nflights |> \n select(year, month, day, hour, minute)\n#> # A tibble: 336,776 × 5\n#> year month day hour minute\n#> <int> <int> <int> <dbl> <dbl>\n#> 1 2013 1 1 5 15\n#> 2 2013 1 1 5 29\n#> 3 2013 1 1 5 40\n#> 4 2013 1 1 5 45\n#> 5 2013 1 1 6 0\n#> 6 2013 1 1 5 58\n#> # ℹ 336,770 more rows\n\nTo create a date/time from this sort of input, use make_date() for dates, or make_datetime() for date-times:\n\nflights |> \n select(year, month, day, hour, minute) |> \n mutate(departure = make_datetime(year, month, day, hour, minute))\n#> # A tibble: 336,776 × 6\n#> year month day hour minute departure \n#> <int> <int> <int> <dbl> <dbl> <dttm> \n#> 1 2013 1 1 5 15 2013-01-01 05:15:00\n#> 2 2013 1 1 5 29 2013-01-01 05:29:00\n#> 3 2013 1 1 5 40 2013-01-01 05:40:00\n#> 4 2013 1 1 5 45 2013-01-01 05:45:00\n#> 5 2013 1 1 6 0 2013-01-01 06:00:00\n#> 6 2013 1 1 5 58 2013-01-01 05:58:00\n#> # ℹ 336,770 more rows\n\nLet’s do the same thing for each of the four time columns in flights. The times are represented in a slightly odd format, so we use modulus arithmetic to pull out the hour and minute components. Once we’ve created the date-time variables, we focus in on the variables we’ll explore in the rest of the chapter.\n\nmake_datetime_100 <- function(year, month, day, time) {\n make_datetime(year, month, day, time %/% 100, time %% 100)\n}\n\nflights_dt <- flights |> \n filter(!is.na(dep_time), !is.na(arr_time)) |> \n mutate(\n dep_time = make_datetime_100(year, month, day, dep_time),\n arr_time = make_datetime_100(year, month, day, arr_time),\n sched_dep_time = make_datetime_100(year, month, day, sched_dep_time),\n sched_arr_time = make_datetime_100(year, month, day, sched_arr_time)\n ) |> \n select(origin, dest, ends_with(\"delay\"), ends_with(\"time\"))\n\nflights_dt\n#> # A tibble: 328,063 × 9\n#> origin dest dep_delay arr_delay dep_time sched_dep_time \n#> <chr> <chr> <dbl> <dbl> <dttm> <dttm> \n#> 1 EWR IAH 2 11 2013-01-01 05:17:00 2013-01-01 05:15:00\n#> 2 LGA IAH 4 20 2013-01-01 05:33:00 2013-01-01 05:29:00\n#> 3 JFK MIA 2 33 2013-01-01 05:42:00 2013-01-01 05:40:00\n#> 4 JFK BQN -1 -18 2013-01-01 05:44:00 2013-01-01 05:45:00\n#> 5 LGA ATL -6 -25 2013-01-01 05:54:00 2013-01-01 06:00:00\n#> 6 EWR ORD -4 12 2013-01-01 05:54:00 2013-01-01 05:58:00\n#> # ℹ 328,057 more rows\n#> # ℹ 3 more variables: arr_time <dttm>, sched_arr_time <dttm>, …\n\nWith this data, we can visualize the distribution of departure times across the year:\n\nflights_dt |> \n ggplot(aes(x = dep_time)) + \n geom_freqpoly(binwidth = 86400) # 86400 seconds = 1 day\n\n\n\n\nOr within a single day:\n\nflights_dt |> \n filter(dep_time < ymd(20130102)) |> \n ggplot(aes(x = dep_time)) + \n geom_freqpoly(binwidth = 600) # 600 s = 10 minutes\n\n\n\n\nNote that when you use date-times in a numeric context (like in a histogram), 1 means 1 second, so a binwidth of 86400 means one day. For dates, 1 means 1 day.\n\n17.2.4 From other types\nYou may want to switch between a date-time and a date. That’s the job of as_datetime() and as_date():\n\nas_datetime(today())\n#> [1] \"2023-11-17 UTC\"\nas_date(now())\n#> [1] \"2023-11-17\"\n\nSometimes you’ll get date/times as numeric offsets from the “Unix Epoch”, 1970-01-01. If the offset is in seconds, use as_datetime(); if it’s in days, use as_date().\n\nas_datetime(60 * 60 * 10)\n#> [1] \"1970-01-01 10:00:00 UTC\"\nas_date(365 * 10 + 2)\n#> [1] \"1980-01-01\"\n\n\n17.2.5 Exercises\n\n\nWhat happens if you parse a string that contains invalid dates?\n\nymd(c(\"2010-10-10\", \"bananas\"))\n\n\nWhat does the tzone argument to today() do? Why is it important?\n\nFor each of the following date-times, show how you’d parse it using a readr column specification and a lubridate function.\n\nd1 <- \"January 1, 2010\"\nd2 <- \"2015-Mar-07\"\nd3 <- \"06-Jun-2017\"\nd4 <- c(\"August 19 (2015)\", \"July 1 (2015)\")\nd5 <- \"12/30/14\" # Dec 30, 2014\nt1 <- \"1705\"\nt2 <- \"11:15:10.12 PM\"" }, { "objectID": "datetimes.html#date-time-components", @@ -1131,14 +1131,14 @@ "href": "databases.html#dbplyr-basics", "title": "21  Databases", "section": "\n21.4 dbplyr basics", - "text": "21.4 dbplyr basics\nNow that we’ve connected to a database and loaded up some data, we can start to learn about dbplyr. dbplyr is a dplyr backend, which means that you keep writing dplyr code but the backend executes it differently. In this, dbplyr translates to SQL; other backends include dtplyr which translates to data.table, and multidplyr which executes your code on multiple cores.\nTo use dbplyr, you must first use tbl() to create an object that represents a database table:\n\ndiamonds_db <- tbl(con, \"diamonds\")\ndiamonds_db\n#> # Source: table<diamonds> [?? x 10]\n#> # Database: DuckDB v0.9.1 [unknown@Linux 6.2.0-1016-azure:R 4.3.2/:memory:]\n#> carat cut color clarity depth table price x y z\n#> <dbl> <fct> <fct> <fct> <dbl> <dbl> <int> <dbl> <dbl> <dbl>\n#> 1 0.23 Ideal E SI2 61.5 55 326 3.95 3.98 2.43\n#> 2 0.21 Premium E SI1 59.8 61 326 3.89 3.84 2.31\n#> 3 0.23 Good E VS1 56.9 65 327 4.05 4.07 2.31\n#> 4 0.29 Premium I VS2 62.4 58 334 4.2 4.23 2.63\n#> 5 0.31 Good J SI2 63.3 58 335 4.34 4.35 2.75\n#> 6 0.24 Very Good J VVS2 62.8 57 336 3.94 3.96 2.48\n#> # ℹ more rows\n\n\n\n\n\n\n\nThere are two other common ways to interact with a database. First, many corporate databases are very large so you need some hierarchy to keep all the tables organized. In that case you might need to supply a schema, or a catalog and a schema, in order to pick the table you’re interested in:\n\ndiamonds_db <- tbl(con, in_schema(\"sales\", \"diamonds\"))\ndiamonds_db <- tbl(con, in_catalog(\"north_america\", \"sales\", \"diamonds\"))\n\nOther times you might want to use your own SQL query as a starting point:\n\ndiamonds_db <- tbl(con, sql(\"SELECT * FROM diamonds\"))\n\n\n\n\nThis object is lazy; when you use dplyr verbs on it, dplyr doesn’t do any work: it just records the sequence of operations that you want to perform and only performs them when needed. For example, take the following pipeline:\n\nbig_diamonds_db <- diamonds_db |> \n filter(price > 15000) |> \n select(carat:clarity, price)\n\nbig_diamonds_db\n#> # Source: SQL [?? x 5]\n#> # Database: DuckDB v0.9.1 [unknown@Linux 6.2.0-1016-azure:R 4.3.2/:memory:]\n#> carat cut color clarity price\n#> <dbl> <fct> <fct> <fct> <int>\n#> 1 1.54 Premium E VS2 15002\n#> 2 1.19 Ideal F VVS1 15005\n#> 3 2.1 Premium I SI1 15007\n#> 4 1.69 Ideal D SI1 15011\n#> 5 1.5 Very Good G VVS2 15013\n#> 6 1.73 Very Good G VS1 15014\n#> # ℹ more rows\n\nYou can tell this object represents a database query because it prints the DBMS name at the top, and while it tells you the number of columns, it typically doesn’t know the number of rows. This is because finding the total number of rows usually requires executing the complete query, something we’re trying to avoid.\nYou can see the SQL code generated by the dplyr function show_query(). If you know dplyr, this is a great way to learn SQL! Write some dplyr code, get dbplyr to translate it to SQL, and then try to figure out how the two languages match up.\n\nbig_diamonds_db |>\n show_query()\n#> <SQL>\n#> SELECT carat, cut, color, clarity, price\n#> FROM diamonds\n#> WHERE (price > 15000.0)\n\nTo get all the data back into R, you call collect(). Behind the scenes, this generates the SQL, calls dbGetQuery() to get the data, then turns the result into a tibble:\n\nbig_diamonds <- big_diamonds_db |> \n collect()\nbig_diamonds\n#> # A tibble: 1,655 × 5\n#> carat cut color clarity price\n#> <dbl> <fct> <fct> <fct> <int>\n#> 1 1.54 Premium E VS2 15002\n#> 2 1.19 Ideal F VVS1 15005\n#> 3 2.1 Premium I SI1 15007\n#> 4 1.69 Ideal D SI1 15011\n#> 5 1.5 Very Good G VVS2 15013\n#> 6 1.73 Very Good G VS1 15014\n#> # ℹ 1,649 more rows\n\nTypically, you’ll use dbplyr to select the data you want from the database, performing basic filtering and aggregation using the translations described below. Then, once you’re ready to analyse the data with functions that are unique to R, you’ll collect() the data to get an in-memory tibble, and continue your work with pure R code." + "text": "21.4 dbplyr basics\nNow that we’ve connected to a database and loaded up some data, we can start to learn about dbplyr. dbplyr is a dplyr backend, which means that you keep writing dplyr code but the backend executes it differently. In this, dbplyr translates to SQL; other backends include dtplyr which translates to data.table, and multidplyr which executes your code on multiple cores.\nTo use dbplyr, you must first use tbl() to create an object that represents a database table:\n\ndiamonds_db <- tbl(con, \"diamonds\")\ndiamonds_db\n#> # Source: table<diamonds> [?? x 10]\n#> # Database: DuckDB v0.9.1 [unknown@Linux 6.2.0-1015-azure:R 4.3.2/:memory:]\n#> carat cut color clarity depth table price x y z\n#> <dbl> <fct> <fct> <fct> <dbl> <dbl> <int> <dbl> <dbl> <dbl>\n#> 1 0.23 Ideal E SI2 61.5 55 326 3.95 3.98 2.43\n#> 2 0.21 Premium E SI1 59.8 61 326 3.89 3.84 2.31\n#> 3 0.23 Good E VS1 56.9 65 327 4.05 4.07 2.31\n#> 4 0.29 Premium I VS2 62.4 58 334 4.2 4.23 2.63\n#> 5 0.31 Good J SI2 63.3 58 335 4.34 4.35 2.75\n#> 6 0.24 Very Good J VVS2 62.8 57 336 3.94 3.96 2.48\n#> # ℹ more rows\n\n\n\n\n\n\n\nThere are two other common ways to interact with a database. First, many corporate databases are very large so you need some hierarchy to keep all the tables organized. In that case you might need to supply a schema, or a catalog and a schema, in order to pick the table you’re interested in:\n\ndiamonds_db <- tbl(con, in_schema(\"sales\", \"diamonds\"))\ndiamonds_db <- tbl(con, in_catalog(\"north_america\", \"sales\", \"diamonds\"))\n\nOther times you might want to use your own SQL query as a starting point:\n\ndiamonds_db <- tbl(con, sql(\"SELECT * FROM diamonds\"))\n\n\n\n\nThis object is lazy; when you use dplyr verbs on it, dplyr doesn’t do any work: it just records the sequence of operations that you want to perform and only performs them when needed. For example, take the following pipeline:\n\nbig_diamonds_db <- diamonds_db |> \n filter(price > 15000) |> \n select(carat:clarity, price)\n\nbig_diamonds_db\n#> # Source: SQL [?? x 5]\n#> # Database: DuckDB v0.9.1 [unknown@Linux 6.2.0-1015-azure:R 4.3.2/:memory:]\n#> carat cut color clarity price\n#> <dbl> <fct> <fct> <fct> <int>\n#> 1 1.54 Premium E VS2 15002\n#> 2 1.19 Ideal F VVS1 15005\n#> 3 2.1 Premium I SI1 15007\n#> 4 1.69 Ideal D SI1 15011\n#> 5 1.5 Very Good G VVS2 15013\n#> 6 1.73 Very Good G VS1 15014\n#> # ℹ more rows\n\nYou can tell this object represents a database query because it prints the DBMS name at the top, and while it tells you the number of columns, it typically doesn’t know the number of rows. This is because finding the total number of rows usually requires executing the complete query, something we’re trying to avoid.\nYou can see the SQL code generated by the dplyr function show_query(). If you know dplyr, this is a great way to learn SQL! Write some dplyr code, get dbplyr to translate it to SQL, and then try to figure out how the two languages match up.\n\nbig_diamonds_db |>\n show_query()\n#> <SQL>\n#> SELECT carat, cut, color, clarity, price\n#> FROM diamonds\n#> WHERE (price > 15000.0)\n\nTo get all the data back into R, you call collect(). Behind the scenes, this generates the SQL, calls dbGetQuery() to get the data, then turns the result into a tibble:\n\nbig_diamonds <- big_diamonds_db |> \n collect()\nbig_diamonds\n#> # A tibble: 1,655 × 5\n#> carat cut color clarity price\n#> <dbl> <fct> <fct> <fct> <int>\n#> 1 1.54 Premium E VS2 15002\n#> 2 1.19 Ideal F VVS1 15005\n#> 3 2.1 Premium I SI1 15007\n#> 4 1.69 Ideal D SI1 15011\n#> 5 1.5 Very Good G VVS2 15013\n#> 6 1.73 Very Good G VS1 15014\n#> # ℹ 1,649 more rows\n\nTypically, you’ll use dbplyr to select the data you want from the database, performing basic filtering and aggregation using the translations described below. Then, once you’re ready to analyse the data with functions that are unique to R, you’ll collect() the data to get an in-memory tibble, and continue your work with pure R code." }, { "objectID": "databases.html#sql", "href": "databases.html#sql", "title": "21  Databases", "section": "\n21.5 SQL", - "text": "21.5 SQL\nThe rest of the chapter will teach you a little SQL through the lens of dbplyr. It’s a rather non-traditional introduction to SQL but we hope it will get you quickly up to speed with the basics. Luckily, if you understand dplyr you’re in a great place to quickly pick up SQL because so many of the concepts are the same.\nWe’ll explore the relationship between dplyr and SQL using a couple of old friends from the nycflights13 package: flights and planes. These datasets are easy to get into our learning database because dbplyr comes with a function that copies the tables from nycflights13 to our database:\n\ndbplyr::copy_nycflights13(con)\n#> Creating table: airlines\n#> Creating table: airports\n#> Creating table: flights\n#> Creating table: planes\n#> Creating table: weather\nflights <- tbl(con, \"flights\")\nplanes <- tbl(con, \"planes\")\n\n\n21.5.1 SQL basics\nThe top-level components of SQL are called statements. Common statements include CREATE for defining new tables, INSERT for adding data, and SELECT for retrieving data. We will focus on SELECT statements, also called queries, because they are almost exclusively what you’ll use as a data scientist.\nA query is made up of clauses. There are five important clauses: SELECT, FROM, WHERE, ORDER BY, and GROUP BY. Every query must have the SELECT4 and FROM5 clauses and the simplest query is SELECT * FROM table, which selects all columns from the specified table . This is what dbplyr generates for an unadulterated table :\n\nflights |> show_query()\n#> <SQL>\n#> SELECT *\n#> FROM flights\nplanes |> show_query()\n#> <SQL>\n#> SELECT *\n#> FROM planes\n\nWHERE and ORDER BY control which rows are included and how they are ordered:\n\nflights |> \n filter(dest == \"IAH\") |> \n arrange(dep_delay) |>\n show_query()\n#> <SQL>\n#> SELECT flights.*\n#> FROM flights\n#> WHERE (dest = 'IAH')\n#> ORDER BY dep_delay\n\nGROUP BY converts the query to a summary, causing aggregation to happen:\n\nflights |> \n group_by(dest) |> \n summarize(dep_delay = mean(dep_delay, na.rm = TRUE)) |> \n show_query()\n#> <SQL>\n#> SELECT dest, AVG(dep_delay) AS dep_delay\n#> FROM flights\n#> GROUP BY dest\n\nThere are two important differences between dplyr verbs and SELECT clauses:\n\nIn SQL, case doesn’t matter: you can write select, SELECT, or even SeLeCt. In this book we’ll stick with the common convention of writing SQL keywords in uppercase to distinguish them from table or variables names.\nIn SQL, order matters: you must always write the clauses in the order SELECT, FROM, WHERE, GROUP BY, ORDER BY. Confusingly, this order doesn’t match how the clauses actually evaluated which is first FROM, then WHERE, GROUP BY, SELECT, and ORDER BY.\n\nThe following sections explore each clause in more detail.\n\n\n\n\n\n\nNote that while SQL is a standard, it is extremely complex and no database follows it exactly. While the main components that we’ll focus on in this book are very similar between DBMS’s, there are many minor variations. Fortunately, dbplyr is designed to handle this problem and generates different translations for different databases. It’s not perfect, but it’s continually improving, and if you hit a problem you can file an issue on GitHub to help us do better.\n\n\n\n\n21.5.2 SELECT\nThe SELECT clause is the workhorse of queries and performs the same job as select(), mutate(), rename(), relocate(), and, as you’ll learn in the next section, summarize().\nselect(), rename(), and relocate() have very direct translations to SELECT as they just affect where a column appears (if at all) along with its name:\n\nplanes |> \n select(tailnum, type, manufacturer, model, year) |> \n show_query()\n#> <SQL>\n#> SELECT tailnum, \"type\", manufacturer, model, \"year\"\n#> FROM planes\n\nplanes |> \n select(tailnum, type, manufacturer, model, year) |> \n rename(year_built = year) |> \n show_query()\n#> <SQL>\n#> SELECT tailnum, \"type\", manufacturer, model, \"year\" AS year_built\n#> FROM planes\n\nplanes |> \n select(tailnum, type, manufacturer, model, year) |> \n relocate(manufacturer, model, .before = type) |> \n show_query()\n#> <SQL>\n#> SELECT tailnum, manufacturer, model, \"type\", \"year\"\n#> FROM planes\n\nThis example also shows you how SQL does renaming. In SQL terminology renaming is called aliasing and is done with AS. Note that unlike mutate(), the old name is on the left and the new name is on the right.\n\n\n\n\n\n\nIn the examples above note that \"year\" and \"type\" are wrapped in double quotes. That’s because these are reserved words in duckdb, so dbplyr quotes them to avoid any potential confusion between column/table names and SQL operators.\nWhen working with other databases you’re likely to see every variable name quotes because only a handful of client packages, like duckdb, know what all the reserved words are, so they quote everything to be safe.\nSELECT \"tailnum\", \"type\", \"manufacturer\", \"model\", \"year\"\nFROM \"planes\"\nSome other database systems use backticks instead of quotes:\nSELECT `tailnum`, `type`, `manufacturer`, `model`, `year`\nFROM `planes`\n\n\n\nThe translations for mutate() are similarly straightforward: each variable becomes a new expression in SELECT:\n\nflights |> \n mutate(\n speed = distance / (air_time / 60)\n ) |> \n show_query()\n#> <SQL>\n#> SELECT flights.*, distance / (air_time / 60.0) AS speed\n#> FROM flights\n\nWe’ll come back to the translation of individual components (like /) in Seção 21.6.\n\n21.5.3 FROM\nThe FROM clause defines the data source. It’s going to be rather uninteresting for a little while, because we’re just using single tables. You’ll see more complex examples once we hit the join functions.\n\n21.5.4 GROUP BY\ngroup_by() is translated to the GROUP BY6 clause and summarize() is translated to the SELECT clause:\n\ndiamonds_db |> \n group_by(cut) |> \n summarize(\n n = n(),\n avg_price = mean(price, na.rm = TRUE)\n ) |> \n show_query()\n#> <SQL>\n#> SELECT cut, COUNT(*) AS n, AVG(price) AS avg_price\n#> FROM diamonds\n#> GROUP BY cut\n\nWe’ll come back to what’s happening with translation n() and mean() in Seção 21.6.\n\n21.5.5 WHERE\nfilter() is translated to the WHERE clause:\n\nflights |> \n filter(dest == \"IAH\" | dest == \"HOU\") |> \n show_query()\n#> <SQL>\n#> SELECT flights.*\n#> FROM flights\n#> WHERE (dest = 'IAH' OR dest = 'HOU')\n\nflights |> \n filter(arr_delay > 0 & arr_delay < 20) |> \n show_query()\n#> <SQL>\n#> SELECT flights.*\n#> FROM flights\n#> WHERE (arr_delay > 0.0 AND arr_delay < 20.0)\n\nThere are a few important details to note here:\n\n\n| becomes OR and & becomes AND.\nSQL uses = for comparison, not ==. SQL doesn’t have assignment, so there’s no potential for confusion there.\nSQL uses only '' for strings, not \"\". In SQL, \"\" is used to identify variables, like R’s ``.\n\nAnother useful SQL operator is IN, which is very close to R’s %in%:\n\nflights |> \n filter(dest %in% c(\"IAH\", \"HOU\")) |> \n show_query()\n#> <SQL>\n#> SELECT flights.*\n#> FROM flights\n#> WHERE (dest IN ('IAH', 'HOU'))\n\nSQL uses NULL instead of NA. NULLs behave similarly to NAs. The main difference is that while they’re “infectious” in comparisons and arithmetic, they are silently dropped when summarizing. dbplyr will remind you about this behavior the first time you hit it:\n\nflights |> \n group_by(dest) |> \n summarize(delay = mean(arr_delay))\n#> Warning: Missing values are always removed in SQL aggregation functions.\n#> Use `na.rm = TRUE` to silence this warning\n#> This warning is displayed once every 8 hours.\n#> # Source: SQL [?? x 2]\n#> # Database: DuckDB v0.9.1 [unknown@Linux 6.2.0-1016-azure:R 4.3.2/:memory:]\n#> dest delay\n#> <chr> <dbl>\n#> 1 SFO 2.67\n#> 2 SJU 2.52\n#> 3 SNA -7.87\n#> 4 SRQ 3.08\n#> 5 CHS 10.6 \n#> 6 SAN 3.14\n#> # ℹ more rows\n\nIf you want to learn more about how NULLs work, you might enjoy “Three valued logic” by Markus Winand.\nIn general, you can work with NULLs using the functions you’d use for NAs in R:\n\nflights |> \n filter(!is.na(dep_delay)) |> \n show_query()\n#> <SQL>\n#> SELECT flights.*\n#> FROM flights\n#> WHERE (NOT((dep_delay IS NULL)))\n\nThis SQL query illustrates one of the drawbacks of dbplyr: while the SQL is correct, it isn’t as simple as you might write by hand. In this case, you could drop the parentheses and use a special operator that’s easier to read:\nWHERE \"dep_delay\" IS NOT NULL\nNote that if you filter() a variable that you created using a summarize, dbplyr will generate a HAVING clause, rather than a WHERE clause. This is a one of the idiosyncrasies of SQL: WHERE is evaluated before SELECT and GROUP BY, so SQL needs another clause that’s evaluated afterwards.\n\ndiamonds_db |> \n group_by(cut) |> \n summarize(n = n()) |> \n filter(n > 100) |> \n show_query()\n#> <SQL>\n#> SELECT cut, COUNT(*) AS n\n#> FROM diamonds\n#> GROUP BY cut\n#> HAVING (COUNT(*) > 100.0)\n\n\n21.5.6 ORDER BY\nOrdering rows involves a straightforward translation from arrange() to the ORDER BY clause:\n\nflights |> \n arrange(year, month, day, desc(dep_delay)) |> \n show_query()\n#> <SQL>\n#> SELECT flights.*\n#> FROM flights\n#> ORDER BY \"year\", \"month\", \"day\", dep_delay DESC\n\nNotice how desc() is translated to DESC: this is one of the many dplyr functions whose name was directly inspired by SQL.\n\n21.5.7 Subqueries\nSometimes it’s not possible to translate a dplyr pipeline into a single SELECT statement and you need to use a subquery. A subquery is just a query used as a data source in the FROM clause, instead of the usual table.\ndbplyr typically uses subqueries to work around limitations of SQL. For example, expressions in the SELECT clause can’t refer to columns that were just created. That means that the following (silly) dplyr pipeline needs to happen in two steps: the first (inner) query computes year1 and then the second (outer) query can compute year2.\n\nflights |> \n mutate(\n year1 = year + 1,\n year2 = year1 + 1\n ) |> \n show_query()\n#> <SQL>\n#> SELECT q01.*, year1 + 1.0 AS year2\n#> FROM (\n#> SELECT flights.*, \"year\" + 1.0 AS year1\n#> FROM flights\n#> ) q01\n\nYou’ll also see this if you attempted to filter() a variable that you just created. Remember, even though WHERE is written after SELECT, it’s evaluated before it, so we need a subquery in this (silly) example:\n\nflights |> \n mutate(year1 = year + 1) |> \n filter(year1 == 2014) |> \n show_query()\n#> <SQL>\n#> SELECT q01.*\n#> FROM (\n#> SELECT flights.*, \"year\" + 1.0 AS year1\n#> FROM flights\n#> ) q01\n#> WHERE (year1 = 2014.0)\n\nSometimes dbplyr will create a subquery where it’s not needed because it doesn’t yet know how to optimize that translation. As dbplyr improves over time, these cases will get rarer but will probably never go away.\n\n21.5.8 Joins\nIf you’re familiar with dplyr’s joins, SQL joins are very similar. Here’s a simple example:\n\nflights |> \n left_join(planes |> rename(year_built = year), by = \"tailnum\") |> \n show_query()\n#> <SQL>\n#> SELECT\n#> flights.*,\n#> planes.\"year\" AS year_built,\n#> \"type\",\n#> manufacturer,\n#> model,\n#> engines,\n#> seats,\n#> speed,\n#> engine\n#> FROM flights\n#> LEFT JOIN planes\n#> ON (flights.tailnum = planes.tailnum)\n\nThe main thing to notice here is the syntax: SQL joins use sub-clauses of the FROM clause to bring in additional tables, using ON to define how the tables are related.\ndplyr’s names for these functions are so closely connected to SQL that you can easily guess the equivalent SQL for inner_join(), right_join(), and full_join():\nSELECT flights.*, \"type\", manufacturer, model, engines, seats, speed\nFROM flights\nINNER JOIN planes ON (flights.tailnum = planes.tailnum)\n\nSELECT flights.*, \"type\", manufacturer, model, engines, seats, speed\nFROM flights\nRIGHT JOIN planes ON (flights.tailnum = planes.tailnum)\n\nSELECT flights.*, \"type\", manufacturer, model, engines, seats, speed\nFROM flights\nFULL JOIN planes ON (flights.tailnum = planes.tailnum)\nYou’re likely to need many joins when working with data from a database. That’s because database tables are often stored in a highly normalized form, where each “fact” is stored in a single place and to keep a complete dataset for analysis you need to navigate a complex network of tables connected by primary and foreign keys. If you hit this scenario, the dm package, by Tobias Schieferdecker, Kirill Müller, and Darko Bergant, is a life saver. It can automatically determine the connections between tables using the constraints that DBAs often supply, visualize the connections so you can see what’s going on, and generate the joins you need to connect one table to another.\n\n21.5.9 Other verbs\ndbplyr also translates other verbs like distinct(), slice_*(), and intersect(), and a growing selection of tidyr functions like pivot_longer() and pivot_wider(). The easiest way to see the full set of what’s currently available is to visit the dbplyr website: https://dbplyr.tidyverse.org/reference/.\n\n21.5.10 Exercises\n\nWhat is distinct() translated to? How about head()?\n\nExplain what each of the following SQL queries do and try recreate them using dbplyr.\nSELECT * \nFROM flights\nWHERE dep_delay < arr_delay\n\nSELECT *, distance / (air_time / 60) AS speed\nFROM flights" + "text": "21.5 SQL\nThe rest of the chapter will teach you a little SQL through the lens of dbplyr. It’s a rather non-traditional introduction to SQL but we hope it will get you quickly up to speed with the basics. Luckily, if you understand dplyr you’re in a great place to quickly pick up SQL because so many of the concepts are the same.\nWe’ll explore the relationship between dplyr and SQL using a couple of old friends from the nycflights13 package: flights and planes. These datasets are easy to get into our learning database because dbplyr comes with a function that copies the tables from nycflights13 to our database:\n\ndbplyr::copy_nycflights13(con)\n#> Creating table: airlines\n#> Creating table: airports\n#> Creating table: flights\n#> Creating table: planes\n#> Creating table: weather\nflights <- tbl(con, \"flights\")\nplanes <- tbl(con, \"planes\")\n\n\n21.5.1 SQL basics\nThe top-level components of SQL are called statements. Common statements include CREATE for defining new tables, INSERT for adding data, and SELECT for retrieving data. We will focus on SELECT statements, also called queries, because they are almost exclusively what you’ll use as a data scientist.\nA query is made up of clauses. There are five important clauses: SELECT, FROM, WHERE, ORDER BY, and GROUP BY. Every query must have the SELECT4 and FROM5 clauses and the simplest query is SELECT * FROM table, which selects all columns from the specified table . This is what dbplyr generates for an unadulterated table :\n\nflights |> show_query()\n#> <SQL>\n#> SELECT *\n#> FROM flights\nplanes |> show_query()\n#> <SQL>\n#> SELECT *\n#> FROM planes\n\nWHERE and ORDER BY control which rows are included and how they are ordered:\n\nflights |> \n filter(dest == \"IAH\") |> \n arrange(dep_delay) |>\n show_query()\n#> <SQL>\n#> SELECT flights.*\n#> FROM flights\n#> WHERE (dest = 'IAH')\n#> ORDER BY dep_delay\n\nGROUP BY converts the query to a summary, causing aggregation to happen:\n\nflights |> \n group_by(dest) |> \n summarize(dep_delay = mean(dep_delay, na.rm = TRUE)) |> \n show_query()\n#> <SQL>\n#> SELECT dest, AVG(dep_delay) AS dep_delay\n#> FROM flights\n#> GROUP BY dest\n\nThere are two important differences between dplyr verbs and SELECT clauses:\n\nIn SQL, case doesn’t matter: you can write select, SELECT, or even SeLeCt. In this book we’ll stick with the common convention of writing SQL keywords in uppercase to distinguish them from table or variables names.\nIn SQL, order matters: you must always write the clauses in the order SELECT, FROM, WHERE, GROUP BY, ORDER BY. Confusingly, this order doesn’t match how the clauses actually evaluated which is first FROM, then WHERE, GROUP BY, SELECT, and ORDER BY.\n\nThe following sections explore each clause in more detail.\n\n\n\n\n\n\nNote that while SQL is a standard, it is extremely complex and no database follows it exactly. While the main components that we’ll focus on in this book are very similar between DBMS’s, there are many minor variations. Fortunately, dbplyr is designed to handle this problem and generates different translations for different databases. It’s not perfect, but it’s continually improving, and if you hit a problem you can file an issue on GitHub to help us do better.\n\n\n\n\n21.5.2 SELECT\nThe SELECT clause is the workhorse of queries and performs the same job as select(), mutate(), rename(), relocate(), and, as you’ll learn in the next section, summarize().\nselect(), rename(), and relocate() have very direct translations to SELECT as they just affect where a column appears (if at all) along with its name:\n\nplanes |> \n select(tailnum, type, manufacturer, model, year) |> \n show_query()\n#> <SQL>\n#> SELECT tailnum, \"type\", manufacturer, model, \"year\"\n#> FROM planes\n\nplanes |> \n select(tailnum, type, manufacturer, model, year) |> \n rename(year_built = year) |> \n show_query()\n#> <SQL>\n#> SELECT tailnum, \"type\", manufacturer, model, \"year\" AS year_built\n#> FROM planes\n\nplanes |> \n select(tailnum, type, manufacturer, model, year) |> \n relocate(manufacturer, model, .before = type) |> \n show_query()\n#> <SQL>\n#> SELECT tailnum, manufacturer, model, \"type\", \"year\"\n#> FROM planes\n\nThis example also shows you how SQL does renaming. In SQL terminology renaming is called aliasing and is done with AS. Note that unlike mutate(), the old name is on the left and the new name is on the right.\n\n\n\n\n\n\nIn the examples above note that \"year\" and \"type\" are wrapped in double quotes. That’s because these are reserved words in duckdb, so dbplyr quotes them to avoid any potential confusion between column/table names and SQL operators.\nWhen working with other databases you’re likely to see every variable name quotes because only a handful of client packages, like duckdb, know what all the reserved words are, so they quote everything to be safe.\nSELECT \"tailnum\", \"type\", \"manufacturer\", \"model\", \"year\"\nFROM \"planes\"\nSome other database systems use backticks instead of quotes:\nSELECT `tailnum`, `type`, `manufacturer`, `model`, `year`\nFROM `planes`\n\n\n\nThe translations for mutate() are similarly straightforward: each variable becomes a new expression in SELECT:\n\nflights |> \n mutate(\n speed = distance / (air_time / 60)\n ) |> \n show_query()\n#> <SQL>\n#> SELECT flights.*, distance / (air_time / 60.0) AS speed\n#> FROM flights\n\nWe’ll come back to the translation of individual components (like /) in Seção 21.6.\n\n21.5.3 FROM\nThe FROM clause defines the data source. It’s going to be rather uninteresting for a little while, because we’re just using single tables. You’ll see more complex examples once we hit the join functions.\n\n21.5.4 GROUP BY\ngroup_by() is translated to the GROUP BY6 clause and summarize() is translated to the SELECT clause:\n\ndiamonds_db |> \n group_by(cut) |> \n summarize(\n n = n(),\n avg_price = mean(price, na.rm = TRUE)\n ) |> \n show_query()\n#> <SQL>\n#> SELECT cut, COUNT(*) AS n, AVG(price) AS avg_price\n#> FROM diamonds\n#> GROUP BY cut\n\nWe’ll come back to what’s happening with translation n() and mean() in Seção 21.6.\n\n21.5.5 WHERE\nfilter() is translated to the WHERE clause:\n\nflights |> \n filter(dest == \"IAH\" | dest == \"HOU\") |> \n show_query()\n#> <SQL>\n#> SELECT flights.*\n#> FROM flights\n#> WHERE (dest = 'IAH' OR dest = 'HOU')\n\nflights |> \n filter(arr_delay > 0 & arr_delay < 20) |> \n show_query()\n#> <SQL>\n#> SELECT flights.*\n#> FROM flights\n#> WHERE (arr_delay > 0.0 AND arr_delay < 20.0)\n\nThere are a few important details to note here:\n\n\n| becomes OR and & becomes AND.\nSQL uses = for comparison, not ==. SQL doesn’t have assignment, so there’s no potential for confusion there.\nSQL uses only '' for strings, not \"\". In SQL, \"\" is used to identify variables, like R’s ``.\n\nAnother useful SQL operator is IN, which is very close to R’s %in%:\n\nflights |> \n filter(dest %in% c(\"IAH\", \"HOU\")) |> \n show_query()\n#> <SQL>\n#> SELECT flights.*\n#> FROM flights\n#> WHERE (dest IN ('IAH', 'HOU'))\n\nSQL uses NULL instead of NA. NULLs behave similarly to NAs. The main difference is that while they’re “infectious” in comparisons and arithmetic, they are silently dropped when summarizing. dbplyr will remind you about this behavior the first time you hit it:\n\nflights |> \n group_by(dest) |> \n summarize(delay = mean(arr_delay))\n#> Warning: Missing values are always removed in SQL aggregation functions.\n#> Use `na.rm = TRUE` to silence this warning\n#> This warning is displayed once every 8 hours.\n#> # Source: SQL [?? x 2]\n#> # Database: DuckDB v0.9.1 [unknown@Linux 6.2.0-1015-azure:R 4.3.2/:memory:]\n#> dest delay\n#> <chr> <dbl>\n#> 1 SFO 2.67\n#> 2 SJU 2.52\n#> 3 SNA -7.87\n#> 4 SRQ 3.08\n#> 5 CHS 10.6 \n#> 6 SAN 3.14\n#> # ℹ more rows\n\nIf you want to learn more about how NULLs work, you might enjoy “Three valued logic” by Markus Winand.\nIn general, you can work with NULLs using the functions you’d use for NAs in R:\n\nflights |> \n filter(!is.na(dep_delay)) |> \n show_query()\n#> <SQL>\n#> SELECT flights.*\n#> FROM flights\n#> WHERE (NOT((dep_delay IS NULL)))\n\nThis SQL query illustrates one of the drawbacks of dbplyr: while the SQL is correct, it isn’t as simple as you might write by hand. In this case, you could drop the parentheses and use a special operator that’s easier to read:\nWHERE \"dep_delay\" IS NOT NULL\nNote that if you filter() a variable that you created using a summarize, dbplyr will generate a HAVING clause, rather than a WHERE clause. This is a one of the idiosyncrasies of SQL: WHERE is evaluated before SELECT and GROUP BY, so SQL needs another clause that’s evaluated afterwards.\n\ndiamonds_db |> \n group_by(cut) |> \n summarize(n = n()) |> \n filter(n > 100) |> \n show_query()\n#> <SQL>\n#> SELECT cut, COUNT(*) AS n\n#> FROM diamonds\n#> GROUP BY cut\n#> HAVING (COUNT(*) > 100.0)\n\n\n21.5.6 ORDER BY\nOrdering rows involves a straightforward translation from arrange() to the ORDER BY clause:\n\nflights |> \n arrange(year, month, day, desc(dep_delay)) |> \n show_query()\n#> <SQL>\n#> SELECT flights.*\n#> FROM flights\n#> ORDER BY \"year\", \"month\", \"day\", dep_delay DESC\n\nNotice how desc() is translated to DESC: this is one of the many dplyr functions whose name was directly inspired by SQL.\n\n21.5.7 Subqueries\nSometimes it’s not possible to translate a dplyr pipeline into a single SELECT statement and you need to use a subquery. A subquery is just a query used as a data source in the FROM clause, instead of the usual table.\ndbplyr typically uses subqueries to work around limitations of SQL. For example, expressions in the SELECT clause can’t refer to columns that were just created. That means that the following (silly) dplyr pipeline needs to happen in two steps: the first (inner) query computes year1 and then the second (outer) query can compute year2.\n\nflights |> \n mutate(\n year1 = year + 1,\n year2 = year1 + 1\n ) |> \n show_query()\n#> <SQL>\n#> SELECT q01.*, year1 + 1.0 AS year2\n#> FROM (\n#> SELECT flights.*, \"year\" + 1.0 AS year1\n#> FROM flights\n#> ) q01\n\nYou’ll also see this if you attempted to filter() a variable that you just created. Remember, even though WHERE is written after SELECT, it’s evaluated before it, so we need a subquery in this (silly) example:\n\nflights |> \n mutate(year1 = year + 1) |> \n filter(year1 == 2014) |> \n show_query()\n#> <SQL>\n#> SELECT q01.*\n#> FROM (\n#> SELECT flights.*, \"year\" + 1.0 AS year1\n#> FROM flights\n#> ) q01\n#> WHERE (year1 = 2014.0)\n\nSometimes dbplyr will create a subquery where it’s not needed because it doesn’t yet know how to optimize that translation. As dbplyr improves over time, these cases will get rarer but will probably never go away.\n\n21.5.8 Joins\nIf you’re familiar with dplyr’s joins, SQL joins are very similar. Here’s a simple example:\n\nflights |> \n left_join(planes |> rename(year_built = year), by = \"tailnum\") |> \n show_query()\n#> <SQL>\n#> SELECT\n#> flights.*,\n#> planes.\"year\" AS year_built,\n#> \"type\",\n#> manufacturer,\n#> model,\n#> engines,\n#> seats,\n#> speed,\n#> engine\n#> FROM flights\n#> LEFT JOIN planes\n#> ON (flights.tailnum = planes.tailnum)\n\nThe main thing to notice here is the syntax: SQL joins use sub-clauses of the FROM clause to bring in additional tables, using ON to define how the tables are related.\ndplyr’s names for these functions are so closely connected to SQL that you can easily guess the equivalent SQL for inner_join(), right_join(), and full_join():\nSELECT flights.*, \"type\", manufacturer, model, engines, seats, speed\nFROM flights\nINNER JOIN planes ON (flights.tailnum = planes.tailnum)\n\nSELECT flights.*, \"type\", manufacturer, model, engines, seats, speed\nFROM flights\nRIGHT JOIN planes ON (flights.tailnum = planes.tailnum)\n\nSELECT flights.*, \"type\", manufacturer, model, engines, seats, speed\nFROM flights\nFULL JOIN planes ON (flights.tailnum = planes.tailnum)\nYou’re likely to need many joins when working with data from a database. That’s because database tables are often stored in a highly normalized form, where each “fact” is stored in a single place and to keep a complete dataset for analysis you need to navigate a complex network of tables connected by primary and foreign keys. If you hit this scenario, the dm package, by Tobias Schieferdecker, Kirill Müller, and Darko Bergant, is a life saver. It can automatically determine the connections between tables using the constraints that DBAs often supply, visualize the connections so you can see what’s going on, and generate the joins you need to connect one table to another.\n\n21.5.9 Other verbs\ndbplyr also translates other verbs like distinct(), slice_*(), and intersect(), and a growing selection of tidyr functions like pivot_longer() and pivot_wider(). The easiest way to see the full set of what’s currently available is to visit the dbplyr website: https://dbplyr.tidyverse.org/reference/.\n\n21.5.10 Exercises\n\nWhat is distinct() translated to? How about head()?\n\nExplain what each of the following SQL queries do and try recreate them using dbplyr.\nSELECT * \nFROM flights\nWHERE dep_delay < arr_delay\n\nSELECT *, distance / (air_time / 60) AS speed\nFROM flights" }, { "objectID": "databases.html#sec-sql-expressions", @@ -1390,7 +1390,7 @@ "href": "iteration.html#saving-multiple-outputs", "title": "26  Iteration", "section": "\n26.4 Saving multiple outputs", - "text": "26.4 Saving multiple outputs\nIn the last section, you learned about map(), which is useful for reading multiple files into a single object. In this section, we’ll now explore sort of the opposite problem: how can you take one or more R objects and save it to one or more files? We’ll explore this challenge using three examples:\n\nSaving multiple data frames into one database.\nSaving multiple data frames into multiple .csv files.\nSaving multiple plots to multiple .png files.\n\n\n26.4.1 Writing to a database\nSometimes when working with many files at once, it’s not possible to fit all your data into memory at once, and you can’t do map(files, read_csv). One approach to deal with this problem is to load your data into a database so you can access just the bits you need with dbplyr.\nIf you’re lucky, the database package you’re using will provide a handy function that takes a vector of paths and loads them all into the database. This is the case with duckdb’s duckdb_read_csv():\n\ncon <- DBI::dbConnect(duckdb::duckdb())\nduckdb::duckdb_read_csv(con, \"gapminder\", paths)\n\nThis would work well here, but we don’t have csv files, instead we have excel spreadsheets. So we’re going to have to do it “by hand”. Learning to do it by hand will also help you when you have a bunch of csvs and the database that you’re working with doesn’t have one function that will load them all in.\nWe need to start by creating a table that will fill in with data. The easiest way to do this is by creating a template, a dummy data frame that contains all the columns we want, but only a sampling of the data. For the gapminder data, we can make that template by reading a single file and adding the year to it:\n\ntemplate <- readxl::read_excel(paths[[1]])\ntemplate$year <- 1952\ntemplate\n#> # A tibble: 142 × 6\n#> country continent lifeExp pop gdpPercap year\n#> <chr> <chr> <dbl> <dbl> <dbl> <dbl>\n#> 1 Afghanistan Asia 28.8 8425333 779. 1952\n#> 2 Albania Europe 55.2 1282697 1601. 1952\n#> 3 Algeria Africa 43.1 9279525 2449. 1952\n#> 4 Angola Africa 30.0 4232095 3521. 1952\n#> 5 Argentina Americas 62.5 17876956 5911. 1952\n#> 6 Australia Oceania 69.1 8691212 10040. 1952\n#> # ℹ 136 more rows\n\nNow we can connect to the database, and use DBI::dbCreateTable() to turn our template into a database table:\n\ncon <- DBI::dbConnect(duckdb::duckdb())\nDBI::dbCreateTable(con, \"gapminder\", template)\n\ndbCreateTable() doesn’t use the data in template, just the variable names and types. So if we inspect the gapminder table now you’ll see that it’s empty but it has the variables we need with the types we expect:\n\ncon |> tbl(\"gapminder\")\n#> # Source: table<gapminder> [0 x 6]\n#> # Database: DuckDB v0.9.1 [unknown@Linux 6.2.0-1016-azure:R 4.3.2/:memory:]\n#> # ℹ 6 variables: country <chr>, continent <chr>, lifeExp <dbl>, pop <dbl>,\n#> # gdpPercap <dbl>, year <dbl>\n\nNext, we need a function that takes a single file path, reads it into R, and adds the result to the gapminder table. We can do that by combining read_excel() with DBI::dbAppendTable():\n\nappend_file <- function(path) {\n df <- readxl::read_excel(path)\n df$year <- parse_number(basename(path))\n \n DBI::dbAppendTable(con, \"gapminder\", df)\n}\n\nNow we need to call append_file() once for each element of paths. That’s certainly possible with map():\n\npaths |> map(append_file)\n\nBut we don’t care about the output of append_file(), so instead of map() it’s slightly nicer to use walk(). walk() does exactly the same thing as map() but throws the output away:\n\npaths |> walk(append_file)\n\nNow we can see if we have all the data in our table:\n\ncon |> \n tbl(\"gapminder\") |> \n count(year)\n#> # Source: SQL [?? x 2]\n#> # Database: DuckDB v0.9.1 [unknown@Linux 6.2.0-1016-azure:R 4.3.2/:memory:]\n#> year n\n#> <dbl> <dbl>\n#> 1 1967 142\n#> 2 1977 142\n#> 3 1987 142\n#> 4 2007 142\n#> 5 1952 142\n#> 6 1957 142\n#> # ℹ more rows\n\n\n26.4.2 Writing csv files\nThe same basic principle applies if we want to write multiple csv files, one for each group. Let’s imagine that we want to take the ggplot2::diamonds data and save one csv file for each clarity. First we need to make those individual datasets. There are many ways you could do that, but there’s one way we particularly like: group_nest().\n\nby_clarity <- diamonds |> \n group_nest(clarity)\n\nby_clarity\n#> # A tibble: 8 × 2\n#> clarity data\n#> <ord> <list<tibble[,9]>>\n#> 1 I1 [741 × 9]\n#> 2 SI2 [9,194 × 9]\n#> 3 SI1 [13,065 × 9]\n#> 4 VS2 [12,258 × 9]\n#> 5 VS1 [8,171 × 9]\n#> 6 VVS2 [5,066 × 9]\n#> # ℹ 2 more rows\n\nThis gives us a new tibble with eight rows and two columns. clarity is our grouping variable and data is a list-column containing one tibble for each unique value of clarity:\n\nby_clarity$data[[1]]\n#> # A tibble: 741 × 9\n#> carat cut color depth table price x y z\n#> <dbl> <ord> <ord> <dbl> <dbl> <int> <dbl> <dbl> <dbl>\n#> 1 0.32 Premium E 60.9 58 345 4.38 4.42 2.68\n#> 2 1.17 Very Good J 60.2 61 2774 6.83 6.9 4.13\n#> 3 1.01 Premium F 61.8 60 2781 6.39 6.36 3.94\n#> 4 1.01 Fair E 64.5 58 2788 6.29 6.21 4.03\n#> 5 0.96 Ideal F 60.7 55 2801 6.37 6.41 3.88\n#> 6 1.04 Premium G 62.2 58 2801 6.46 6.41 4 \n#> # ℹ 735 more rows\n\nWhile we’re here, let’s create a column that gives the name of output file, using mutate() and str_glue():\n\nby_clarity <- by_clarity |> \n mutate(path = str_glue(\"diamonds-{clarity}.csv\"))\n\nby_clarity\n#> # A tibble: 8 × 3\n#> clarity data path \n#> <ord> <list<tibble[,9]>> <glue> \n#> 1 I1 [741 × 9] diamonds-I1.csv \n#> 2 SI2 [9,194 × 9] diamonds-SI2.csv \n#> 3 SI1 [13,065 × 9] diamonds-SI1.csv \n#> 4 VS2 [12,258 × 9] diamonds-VS2.csv \n#> 5 VS1 [8,171 × 9] diamonds-VS1.csv \n#> 6 VVS2 [5,066 × 9] diamonds-VVS2.csv\n#> # ℹ 2 more rows\n\nSo if we were going to save these data frames by hand, we might write something like:\n\nwrite_csv(by_clarity$data[[1]], by_clarity$path[[1]])\nwrite_csv(by_clarity$data[[2]], by_clarity$path[[2]])\nwrite_csv(by_clarity$data[[3]], by_clarity$path[[3]])\n...\nwrite_csv(by_clarity$by_clarity[[8]], by_clarity$path[[8]])\n\nThis is a little different to our previous uses of map() because there are two arguments that are changing, not just one. That means we need a new function: map2(), which varies both the first and second arguments. And because we again don’t care about the output, we want walk2() rather than map2(). That gives us:\n\nwalk2(by_clarity$data, by_clarity$path, write_csv)\n\n\n26.4.3 Saving plots\nWe can take the same basic approach to create many plots. Let’s first make a function that draws the plot we want:\n\ncarat_histogram <- function(df) {\n ggplot(df, aes(x = carat)) + geom_histogram(binwidth = 0.1) \n}\n\ncarat_histogram(by_clarity$data[[1]])\n\n\n\n\nNow we can use map() to create a list of many plots7 and their eventual file paths:\n\nby_clarity <- by_clarity |> \n mutate(\n plot = map(data, carat_histogram),\n path = str_glue(\"clarity-{clarity}.png\")\n )\n\nThen use walk2() with ggsave() to save each plot:\n\nwalk2(\n by_clarity$path,\n by_clarity$plot,\n \\(path, plot) ggsave(path, plot, width = 6, height = 6)\n)\n\nThis is shorthand for:\n\nggsave(by_clarity$path[[1]], by_clarity$plot[[1]], width = 6, height = 6)\nggsave(by_clarity$path[[2]], by_clarity$plot[[2]], width = 6, height = 6)\nggsave(by_clarity$path[[3]], by_clarity$plot[[3]], width = 6, height = 6)\n...\nggsave(by_clarity$path[[8]], by_clarity$plot[[8]], width = 6, height = 6)" + "text": "26.4 Saving multiple outputs\nIn the last section, you learned about map(), which is useful for reading multiple files into a single object. In this section, we’ll now explore sort of the opposite problem: how can you take one or more R objects and save it to one or more files? We’ll explore this challenge using three examples:\n\nSaving multiple data frames into one database.\nSaving multiple data frames into multiple .csv files.\nSaving multiple plots to multiple .png files.\n\n\n26.4.1 Writing to a database\nSometimes when working with many files at once, it’s not possible to fit all your data into memory at once, and you can’t do map(files, read_csv). One approach to deal with this problem is to load your data into a database so you can access just the bits you need with dbplyr.\nIf you’re lucky, the database package you’re using will provide a handy function that takes a vector of paths and loads them all into the database. This is the case with duckdb’s duckdb_read_csv():\n\ncon <- DBI::dbConnect(duckdb::duckdb())\nduckdb::duckdb_read_csv(con, \"gapminder\", paths)\n\nThis would work well here, but we don’t have csv files, instead we have excel spreadsheets. So we’re going to have to do it “by hand”. Learning to do it by hand will also help you when you have a bunch of csvs and the database that you’re working with doesn’t have one function that will load them all in.\nWe need to start by creating a table that will fill in with data. The easiest way to do this is by creating a template, a dummy data frame that contains all the columns we want, but only a sampling of the data. For the gapminder data, we can make that template by reading a single file and adding the year to it:\n\ntemplate <- readxl::read_excel(paths[[1]])\ntemplate$year <- 1952\ntemplate\n#> # A tibble: 142 × 6\n#> country continent lifeExp pop gdpPercap year\n#> <chr> <chr> <dbl> <dbl> <dbl> <dbl>\n#> 1 Afghanistan Asia 28.8 8425333 779. 1952\n#> 2 Albania Europe 55.2 1282697 1601. 1952\n#> 3 Algeria Africa 43.1 9279525 2449. 1952\n#> 4 Angola Africa 30.0 4232095 3521. 1952\n#> 5 Argentina Americas 62.5 17876956 5911. 1952\n#> 6 Australia Oceania 69.1 8691212 10040. 1952\n#> # ℹ 136 more rows\n\nNow we can connect to the database, and use DBI::dbCreateTable() to turn our template into a database table:\n\ncon <- DBI::dbConnect(duckdb::duckdb())\nDBI::dbCreateTable(con, \"gapminder\", template)\n\ndbCreateTable() doesn’t use the data in template, just the variable names and types. So if we inspect the gapminder table now you’ll see that it’s empty but it has the variables we need with the types we expect:\n\ncon |> tbl(\"gapminder\")\n#> # Source: table<gapminder> [0 x 6]\n#> # Database: DuckDB v0.9.1 [unknown@Linux 6.2.0-1015-azure:R 4.3.2/:memory:]\n#> # ℹ 6 variables: country <chr>, continent <chr>, lifeExp <dbl>, pop <dbl>,\n#> # gdpPercap <dbl>, year <dbl>\n\nNext, we need a function that takes a single file path, reads it into R, and adds the result to the gapminder table. We can do that by combining read_excel() with DBI::dbAppendTable():\n\nappend_file <- function(path) {\n df <- readxl::read_excel(path)\n df$year <- parse_number(basename(path))\n \n DBI::dbAppendTable(con, \"gapminder\", df)\n}\n\nNow we need to call append_file() once for each element of paths. That’s certainly possible with map():\n\npaths |> map(append_file)\n\nBut we don’t care about the output of append_file(), so instead of map() it’s slightly nicer to use walk(). walk() does exactly the same thing as map() but throws the output away:\n\npaths |> walk(append_file)\n\nNow we can see if we have all the data in our table:\n\ncon |> \n tbl(\"gapminder\") |> \n count(year)\n#> # Source: SQL [?? x 2]\n#> # Database: DuckDB v0.9.1 [unknown@Linux 6.2.0-1015-azure:R 4.3.2/:memory:]\n#> year n\n#> <dbl> <dbl>\n#> 1 2007 142\n#> 2 1967 142\n#> 3 1977 142\n#> 4 1987 142\n#> 5 1952 142\n#> 6 1957 142\n#> # ℹ more rows\n\n\n26.4.2 Writing csv files\nThe same basic principle applies if we want to write multiple csv files, one for each group. Let’s imagine that we want to take the ggplot2::diamonds data and save one csv file for each clarity. First we need to make those individual datasets. There are many ways you could do that, but there’s one way we particularly like: group_nest().\n\nby_clarity <- diamonds |> \n group_nest(clarity)\n\nby_clarity\n#> # A tibble: 8 × 2\n#> clarity data\n#> <ord> <list<tibble[,9]>>\n#> 1 I1 [741 × 9]\n#> 2 SI2 [9,194 × 9]\n#> 3 SI1 [13,065 × 9]\n#> 4 VS2 [12,258 × 9]\n#> 5 VS1 [8,171 × 9]\n#> 6 VVS2 [5,066 × 9]\n#> # ℹ 2 more rows\n\nThis gives us a new tibble with eight rows and two columns. clarity is our grouping variable and data is a list-column containing one tibble for each unique value of clarity:\n\nby_clarity$data[[1]]\n#> # A tibble: 741 × 9\n#> carat cut color depth table price x y z\n#> <dbl> <ord> <ord> <dbl> <dbl> <int> <dbl> <dbl> <dbl>\n#> 1 0.32 Premium E 60.9 58 345 4.38 4.42 2.68\n#> 2 1.17 Very Good J 60.2 61 2774 6.83 6.9 4.13\n#> 3 1.01 Premium F 61.8 60 2781 6.39 6.36 3.94\n#> 4 1.01 Fair E 64.5 58 2788 6.29 6.21 4.03\n#> 5 0.96 Ideal F 60.7 55 2801 6.37 6.41 3.88\n#> 6 1.04 Premium G 62.2 58 2801 6.46 6.41 4 \n#> # ℹ 735 more rows\n\nWhile we’re here, let’s create a column that gives the name of output file, using mutate() and str_glue():\n\nby_clarity <- by_clarity |> \n mutate(path = str_glue(\"diamonds-{clarity}.csv\"))\n\nby_clarity\n#> # A tibble: 8 × 3\n#> clarity data path \n#> <ord> <list<tibble[,9]>> <glue> \n#> 1 I1 [741 × 9] diamonds-I1.csv \n#> 2 SI2 [9,194 × 9] diamonds-SI2.csv \n#> 3 SI1 [13,065 × 9] diamonds-SI1.csv \n#> 4 VS2 [12,258 × 9] diamonds-VS2.csv \n#> 5 VS1 [8,171 × 9] diamonds-VS1.csv \n#> 6 VVS2 [5,066 × 9] diamonds-VVS2.csv\n#> # ℹ 2 more rows\n\nSo if we were going to save these data frames by hand, we might write something like:\n\nwrite_csv(by_clarity$data[[1]], by_clarity$path[[1]])\nwrite_csv(by_clarity$data[[2]], by_clarity$path[[2]])\nwrite_csv(by_clarity$data[[3]], by_clarity$path[[3]])\n...\nwrite_csv(by_clarity$by_clarity[[8]], by_clarity$path[[8]])\n\nThis is a little different to our previous uses of map() because there are two arguments that are changing, not just one. That means we need a new function: map2(), which varies both the first and second arguments. And because we again don’t care about the output, we want walk2() rather than map2(). That gives us:\n\nwalk2(by_clarity$data, by_clarity$path, write_csv)\n\n\n26.4.3 Saving plots\nWe can take the same basic approach to create many plots. Let’s first make a function that draws the plot we want:\n\ncarat_histogram <- function(df) {\n ggplot(df, aes(x = carat)) + geom_histogram(binwidth = 0.1) \n}\n\ncarat_histogram(by_clarity$data[[1]])\n\n\n\n\nNow we can use map() to create a list of many plots7 and their eventual file paths:\n\nby_clarity <- by_clarity |> \n mutate(\n plot = map(data, carat_histogram),\n path = str_glue(\"clarity-{clarity}.png\")\n )\n\nThen use walk2() with ggsave() to save each plot:\n\nwalk2(\n by_clarity$path,\n by_clarity$plot,\n \\(path, plot) ggsave(path, plot, width = 6, height = 6)\n)\n\nThis is shorthand for:\n\nggsave(by_clarity$path[[1]], by_clarity$plot[[1]], width = 6, height = 6)\nggsave(by_clarity$path[[2]], by_clarity$plot[[2]], width = 6, height = 6)\nggsave(by_clarity$path[[3]], by_clarity$plot[[3]], width = 6, height = 6)\n...\nggsave(by_clarity$path[[8]], by_clarity$plot[[8]], width = 6, height = 6)" }, { "objectID": "iteration.html#summary", diff --git a/sitemap.xml b/sitemap.xml index aebb4a21a..5c102f5e6 100644 --- a/sitemap.xml +++ b/sitemap.xml @@ -1,155 +1,155 @@ - https://r4ds.hadley.nz/index.html - 2023-11-17T21:40:39.836Z + https://cienciadedatos.github.io/pt-r4ds/index.html + 2023-11-17T22:08:26.363Z - https://r4ds.hadley.nz/preface-2e.html - 2023-11-17T21:40:39.844Z + https://cienciadedatos.github.io/pt-r4ds/preface-2e.html + 2023-11-17T22:08:26.371Z - https://r4ds.hadley.nz/intro.html - 2023-11-17T21:40:39.856Z + https://cienciadedatos.github.io/pt-r4ds/intro.html + 2023-11-17T22:08:26.383Z - https://r4ds.hadley.nz/whole-game.html - 2023-11-17T21:40:39.864Z + https://cienciadedatos.github.io/pt-r4ds/whole-game.html + 2023-11-17T22:08:26.391Z - https://r4ds.hadley.nz/data-visualize.html - 2023-11-17T21:40:39.900Z + https://cienciadedatos.github.io/pt-r4ds/data-visualize.html + 2023-11-17T22:08:26.427Z - https://r4ds.hadley.nz/workflow-basics.html - 2023-11-17T21:40:39.912Z + https://cienciadedatos.github.io/pt-r4ds/workflow-basics.html + 2023-11-17T22:08:26.439Z - https://r4ds.hadley.nz/data-transform.html - 2023-11-17T21:40:39.968Z + https://cienciadedatos.github.io/pt-r4ds/data-transform.html + 2023-11-17T22:08:26.515Z - https://r4ds.hadley.nz/workflow-style.html - 2023-11-17T21:40:39.984Z + https://cienciadedatos.github.io/pt-r4ds/workflow-style.html + 2023-11-17T22:08:26.531Z - https://r4ds.hadley.nz/data-tidy.html - 2023-11-17T21:40:40.044Z + https://cienciadedatos.github.io/pt-r4ds/data-tidy.html + 2023-11-17T22:08:26.567Z - https://r4ds.hadley.nz/workflow-scripts.html - 2023-11-17T21:40:40.056Z + https://cienciadedatos.github.io/pt-r4ds/workflow-scripts.html + 2023-11-17T22:08:26.579Z - https://r4ds.hadley.nz/data-import.html - 2023-11-17T21:40:40.088Z + https://cienciadedatos.github.io/pt-r4ds/data-import.html + 2023-11-17T22:08:26.607Z - https://r4ds.hadley.nz/workflow-help.html - 2023-11-17T21:40:40.096Z + https://cienciadedatos.github.io/pt-r4ds/workflow-help.html + 2023-11-17T22:08:26.619Z - https://r4ds.hadley.nz/visualize.html - 2023-11-17T21:40:40.108Z + https://cienciadedatos.github.io/pt-r4ds/visualize.html + 2023-11-17T22:08:26.623Z - https://r4ds.hadley.nz/layers.html - 2023-11-17T21:40:40.152Z + https://cienciadedatos.github.io/pt-r4ds/layers.html + 2023-11-17T22:08:26.667Z - https://r4ds.hadley.nz/EDA.html - 2023-11-17T21:40:40.184Z + https://cienciadedatos.github.io/pt-r4ds/EDA.html + 2023-11-17T22:08:26.695Z - https://r4ds.hadley.nz/communication.html - 2023-11-17T21:40:40.244Z + https://cienciadedatos.github.io/pt-r4ds/communication.html + 2023-11-17T22:08:26.803Z - https://r4ds.hadley.nz/transform.html - 2023-11-17T21:40:40.252Z + https://cienciadedatos.github.io/pt-r4ds/transform.html + 2023-11-17T22:08:26.811Z - https://r4ds.hadley.nz/logicals.html - 2023-11-17T21:40:40.292Z + https://cienciadedatos.github.io/pt-r4ds/logicals.html + 2023-11-17T22:08:26.847Z - https://r4ds.hadley.nz/numbers.html - 2023-11-17T21:40:40.340Z + https://cienciadedatos.github.io/pt-r4ds/numbers.html + 2023-11-17T22:08:26.903Z - https://r4ds.hadley.nz/strings.html - 2023-11-17T21:40:40.440Z + https://cienciadedatos.github.io/pt-r4ds/strings.html + 2023-11-17T22:08:26.939Z - https://r4ds.hadley.nz/regexps.html - 2023-11-17T21:40:40.488Z + https://cienciadedatos.github.io/pt-r4ds/regexps.html + 2023-11-17T22:08:26.987Z - https://r4ds.hadley.nz/factors.html - 2023-11-17T21:40:40.520Z + https://cienciadedatos.github.io/pt-r4ds/factors.html + 2023-11-17T22:08:27.015Z - https://r4ds.hadley.nz/datetimes.html - 2023-11-17T21:40:40.564Z + https://cienciadedatos.github.io/pt-r4ds/datetimes.html + 2023-11-17T22:08:27.063Z - https://r4ds.hadley.nz/missing-values.html - 2023-11-17T21:40:40.588Z + https://cienciadedatos.github.io/pt-r4ds/missing-values.html + 2023-11-17T22:08:27.083Z - https://r4ds.hadley.nz/joins.html - 2023-11-17T21:40:40.632Z + https://cienciadedatos.github.io/pt-r4ds/joins.html + 2023-11-17T22:08:27.131Z - https://r4ds.hadley.nz/import.html - 2023-11-17T21:40:40.640Z + https://cienciadedatos.github.io/pt-r4ds/import.html + 2023-11-17T22:08:27.135Z - https://r4ds.hadley.nz/spreadsheets.html - 2023-11-17T21:40:40.668Z + https://cienciadedatos.github.io/pt-r4ds/spreadsheets.html + 2023-11-17T22:08:27.167Z - https://r4ds.hadley.nz/databases.html - 2023-11-17T21:40:40.712Z + https://cienciadedatos.github.io/pt-r4ds/databases.html + 2023-11-17T22:08:27.207Z - https://r4ds.hadley.nz/arrow.html - 2023-11-17T21:40:40.732Z + https://cienciadedatos.github.io/pt-r4ds/arrow.html + 2023-11-17T22:08:27.227Z - https://r4ds.hadley.nz/rectangling.html - 2023-11-17T21:40:40.784Z + https://cienciadedatos.github.io/pt-r4ds/rectangling.html + 2023-11-17T22:08:27.275Z - https://r4ds.hadley.nz/webscraping.html - 2023-11-17T21:40:40.812Z + https://cienciadedatos.github.io/pt-r4ds/webscraping.html + 2023-11-17T22:08:27.303Z - https://r4ds.hadley.nz/program.html - 2023-11-17T21:40:40.820Z + https://cienciadedatos.github.io/pt-r4ds/program.html + 2023-11-17T22:08:27.311Z - https://r4ds.hadley.nz/functions.html - 2023-11-17T21:40:40.884Z + https://cienciadedatos.github.io/pt-r4ds/functions.html + 2023-11-17T22:08:27.375Z - https://r4ds.hadley.nz/iteration.html - 2023-11-17T21:40:40.952Z + https://cienciadedatos.github.io/pt-r4ds/iteration.html + 2023-11-17T22:08:27.447Z - https://r4ds.hadley.nz/base-R.html - 2023-11-17T21:40:40.984Z + https://cienciadedatos.github.io/pt-r4ds/base-R.html + 2023-11-17T22:08:27.475Z - https://r4ds.hadley.nz/communicate.html - 2023-11-17T21:40:40.988Z + https://cienciadedatos.github.io/pt-r4ds/communicate.html + 2023-11-17T22:08:27.483Z - https://r4ds.hadley.nz/quarto.html - 2023-11-17T21:40:41.016Z + https://cienciadedatos.github.io/pt-r4ds/quarto.html + 2023-11-17T22:08:27.515Z - https://r4ds.hadley.nz/quarto-formats.html - 2023-11-17T21:40:41.032Z + https://cienciadedatos.github.io/pt-r4ds/quarto-formats.html + 2023-11-17T22:08:27.559Z diff --git a/spreadsheets.html b/spreadsheets.html index c2d428aa3..b7d614090 100644 --- a/spreadsheets.html +++ b/spreadsheets.html @@ -113,7 +113,7 @@
    R para Ciência de Dados (2ª edição)
    - +
    @@ -422,7 +422,7 @@
  • 20.4 Summary
    • -

    Editar essa página

    Criar uma issue

    +

    Editar essa página

    Criar uma issue

    diff --git a/strings.html b/strings.html index 06a75f0f1..f6552282f 100644 --- a/strings.html +++ b/strings.html @@ -113,7 +113,7 @@
    R para Ciência de Dados (2ª edição)
    - +
    @@ -444,7 +444,7 @@
  • 14.7 Summary
    • -

    Editar essa página

    Criar uma issue

    +

    Editar essa página

    Criar uma issue

    diff --git a/transform.html b/transform.html index 33e5fd685..f5abc74c8 100644 --- a/transform.html +++ b/transform.html @@ -79,7 +79,7 @@
    R para Ciência de Dados (2ª edição)
    - +
    @@ -656,7 +656,7 @@

    R para Ciência de Dados (2ª edição) foi escrito por Hadley Wickham, Mine Çetinkaya-Rundel, e Garrett Grolemund.

      -

    Editar essa página

    Criar uma issue

    +

    Editar essa página

    Criar uma issue

    Este livro foi contruído com Quarto.
    diff --git a/visualize.html b/visualize.html index 153336eac..b317d62a7 100644 --- a/visualize.html +++ b/visualize.html @@ -79,7 +79,7 @@
    R para Ciência de Dados (2ª edição)
    - +
    @@ -642,7 +642,7 @@

    Vis
    R para Ciência de Dados (2ª edição) foi escrito por Hadley Wickham, Mine Çetinkaya-Rundel, e Garrett Grolemund.
      -

    Editar essa página

    Criar uma issue

    +

    Editar essa página

    Criar uma issue

    Este livro foi contruído com Quarto.
    diff --git a/webscraping.html b/webscraping.html index 161d96edc..88a184162 100644 --- a/webscraping.html +++ b/webscraping.html @@ -113,7 +113,7 @@
    R para Ciência de Dados (2ª edição)
    - +
    @@ -435,7 +435,7 @@
  • 24.7 Dynamic sites
  • 24.8 Summary
    • -

    Editar essa página

    Criar uma issue

    +

    Editar essa página

    Criar uma issue

    diff --git a/whole-game.html b/whole-game.html index e0ca85a0d..9a4107535 100644 --- a/whole-game.html +++ b/whole-game.html @@ -79,7 +79,7 @@
    R para Ciência de Dados (2ª edição)
    - +
    @@ -643,7 +643,7 @@

    R para Ciência de Dados (2ª edição) foi escrito por Hadley Wickham, Mine Çetinkaya-Rundel, e Garrett Grolemund.

      -

    Editar essa página

    Criar uma issue

    +

    Editar essa página

    Criar uma issue

    Este livro foi contruído com Quarto.
    diff --git a/workflow-basics.html b/workflow-basics.html index 51bf0c665..5be5389cc 100644 --- a/workflow-basics.html +++ b/workflow-basics.html @@ -113,7 +113,7 @@
    R para Ciência de Dados (2ª edição)
    - +
    @@ -401,7 +401,7 @@
  • 2.4 Chamando funções
  • 2.5 Exercícios
  • 2.6 Sumário
    • -

    Editar essa página

    Criar uma issue

    +

    Editar essa página

    Criar uma issue

    diff --git a/workflow-help.html b/workflow-help.html index 571e2fa6b..7560352d3 100644 --- a/workflow-help.html +++ b/workflow-help.html @@ -113,7 +113,7 @@
    R para Ciência de Dados (2ª edição)
    - +
    @@ -399,7 +399,7 @@
  • 8.2 Making a reprex
  • 8.3 Investing in yourself
  • 8.4 Summary
    • -

    Editar essa página

    Criar uma issue

    +

    Editar essa página

    Criar uma issue

    diff --git a/workflow-scripts.html b/workflow-scripts.html index 537191391..cd1f49b21 100644 --- a/workflow-scripts.html +++ b/workflow-scripts.html @@ -113,7 +113,7 @@
    R para Ciência de Dados (2ª edição)
    - +
    @@ -414,7 +414,7 @@
  • 6.3 Exercises
  • 6.4 Summary
    • -

    Editar essa página

    Criar uma issue

    +

    Editar essa página

    Criar uma issue

    diff --git a/workflow-style.html b/workflow-style.html index 9e884f1d7..f9437c8f7 100644 --- a/workflow-style.html +++ b/workflow-style.html @@ -113,7 +113,7 @@
    R para Ciência de Dados (2ª edição)
    - +
    @@ -402,7 +402,7 @@
  • 4.5 Sectioning comments
  • 4.6 Exercises
  • 4.7 Summary
    • -

    Editar essa página

    Criar uma issue

    +

    Editar essa página

    Criar uma issue