Dplyr: Gruppen mit der Länge Null beibehalten

Vielen Dank für das Öffnen dieser Ausgabe Hadley.

:+1: bin heute auf das gleiche Problem gestoßen, drop = FALSE wäre eine große Hilfe für mich!

Irgendeine Idee zum Zeitrahmen für das Einfügen eines .drop = FALSE-Äquivalents in dplyr? Ich benötige dies, damit bestimmte rCharts korrekt gerendert werden.

In der Zwischenzeit habe ich die Antwort in Ihrem Link zur Arbeit erhalten.
http://stackoverflow.com/questions/22523131

Ich habe nach zwei Variablen gruppiert.

+1 für die Option, keine leeren Gruppen zu löschen

Kann sich mit #486 und #413 etwas überschneiden.

Es wäre sehr nützlich, keine leeren Gruppen zu löschen. Wird häufig beim Erstellen von Übersichtstabellen benötigt.

+1 - das ist ein Deal-Breaker für viele Analysen

Ich stimme dem oben genannten zu - wäre sehr nützlich.

@romainfrancois Derzeit build_index_cpp() das Drop-Attribut nicht:

t1 <- data_frame(
  x = runif(10),
  g1 = rep(1:2, each = 5),
  g2 = factor(g1, 1:3)
)
g1 <- grouped_df(t1, list(quote(g2)), drop = FALSE)
attr(g1, "group_size")
# should be c(5L, 5L, 0L)
attr(g1, "indices")
# shoud be list(0:4, 5:9, integer(0))

Das drop-Attribut gilt nur bei der Gruppierung nach einem Faktor. In diesem Fall benötigen wir eine Gruppe pro Faktorebene, unabhängig davon, ob die Ebene tatsächlich auf die Daten zutrifft oder nicht.

Dies wirkt sich auch auf die einzelnen Tabellenverben auf folgende Weise aus:

• select() : keine Wirkung
• arrange() : keine Wirkung
• summarise() : Funktionen, die auf Nullzeilengruppen angewendet werden, sollten ganze Zahlen der Ebene 0 erhalten. n() sollte 0 zurückgeben, mean(x) sollte NaN . zurückgeben
• filter() : die Menge der Gruppen sollte konstant bleiben, auch wenn einige Gruppen jetzt keine Zeilen haben
• mutate() : Ausdrücke für leere Gruppen müssen nicht ausgewertet werden

Irgendwann wird drop = FALSE der Standard sein, und wenn es mühsam ist, sowohl drop = FALSE als auch drop = TRUE zu schreiben, würde ich gerne die Unterstützung für drop = FALSE ( da Sie den Faktor jederzeit selbst neu nivellieren oder stattdessen einen Zeichenvektor verwenden können).

Ist das sinnvoll? Wenn es viel Arbeit ist, können wir auf 0,4 abstoßen

@statwonk , @wsurles , @jennybc , @slackline , @mcfrank , @eipi10 Wenn Sie helfen möchten, arbeiten Sie am besten an einer Reihe von Testfällen, die alle möglichen Interaktionen der verschiedenen Verben ausüben mit Gruppen der Länge Null.

Ah. Ich glaube, ich wusste einfach nicht, was drop tun sollte. Das macht es klar. Ich glaube nicht, dass es viel Arbeit ist.

Ich habe Pull-Request #833 geöffnet, die testet, ob die einzelnen Tabellenverben oben mit Null-Längengruppen korrekt umgehen. Die meisten Tests sind auskommentiert, da dplyr sie derzeit natürlich nicht besteht.

+1 , gibt es hier Statusaktualisierungen? Liebe zusammenfassen, müssen leere Ebenen halten!

@ebergelson , Hier ist mein aktueller Hack, um Gruppen der Länge Null zu erhalten. Ich brauche dies oft, damit meine Balkendiagramme gestapelt werden.

Hier hat df 3 Spalten: Name, Gruppe und Metrik

df2 <- expand.grid(name = unique(df$name), group = unique(df$group)) %>%
    left_join(df, by=c("name","group")) %>%
    mutate(metric = ifelse(is.na(metric),0,metric))

Ich mache etwas Ähnliches – suche nach fehlenden Gruppen und generiere dann, falls vorhanden, alle Kombinationen und left_join .

Leider scheint dieses Problem nicht viel Aufmerksamkeit zu bekommen ... vielleicht weil es diesen einfachen Workaround gibt.

@wsurles , @bpbond danke, ja, ich habe eine ähnliche

Nur um allen oben zuzustimmen und ihnen zuzustimmen - dies ist ein superkritischer Aspekt vieler Analysen. Würde mich über eine Umsetzung freuen.

Hier werden noch einige Details benötigt:

Wenn ich das habe:

> df <- data_frame( x = c(1,1,1,2,2), f = factor( c(1,2,3,1,1) ) )
> df
Source: local data frame [5 x 2]

  x f
1 1 1
2 1 2
3 1 3
4 2 1
5 2 1

Und ich gruppiere nach x dann f , am Ende habe ich 6 (2x3) Gruppen, in denen die Gruppen (2, 2) und (2,3) leer sind. Das ist ok. Das kann ich, denke ich, umsetzen.

Was ist jetzt, wenn ich das habe:

> df <- data_frame( f = factor( c(1,1,2,2), levels = 1:3), x = c(1,2,1,4) )
> df
Source: local data frame [4 x 2]

  f x
1 1 1
2 1 2
3 2 1
4 2 4

und ich möchte nach f dann nach x gruppieren. Was wären die Gruppen? @hadley

Sowohl stats::aggregate als auch plyr::ddply geben in diesem Fall 4 Gruppen zurück (1,1; 1,2; 2,1; und 2,4) .

Sollte es nicht stattdessen mit table() übereinstimmen, dh 9 Gruppen zurückgeben?

> table(df$f, df$x)
  1 2 4
1 1 1 0
2 1 0 1
3 0 0 0

Ich würde erwarten, dass df %>% group_by(f, x) %>% tally im Grunde das gleiche Ergebnis liefert wie with(df, as.data.frame(table(f, x))) und ddply(df, .(f, x), nrow, .drop=FALSE) .

Ich dachte, unser gewünschtes Verhalten wäre, Gruppen der Länge Null beizubehalten, wenn es sich um Faktoren handelt (wie .drop in plyr), also würde ich mir vorstellen, dass wir den Vorschlag von @huftis wollen. Ich würde jedoch vorschlagen, dass der Standard drop = TRUE ist, damit sich das Standardverhalten nicht ändert, gemäß dem Vorschlag von

Hmmm, es ist schwer mir klar zu machen, wie das Verhalten aussehen soll. Sehen diese sehr einfachen Gedankenexperimente richtig aus?

df <- data_frame(x = 1, y = factor(1, levels = 2))
df %>% group_by(x) %>% summarise(n())
#> x n
#> 1 1  

df %>% group_by(y) %>% summarise(n())
#> y n
#> 1 1
#> 2 0

df %>% group_by(x, y) %>% summarise(n()
#> x y n
#> 1 1 1
#> 1 2 0

Aber was ist, wenn x mehrere Werte hat? Sollte es so funktionieren?

df <- data_frame(x = 1:2, y = factor(1, levels = 2))
df %>% group_by(x, y) %>% summarise(n()
#> x y n
#> 1 1 1
#> 2 1 1
#> 1 1 0
#> 2 2 0

Vielleicht macht das Beibehalten leerer Gruppen nur Sinn, wenn nach einer einzelnen Variablen gruppiert wird? Wenn wir es realistischer formulieren, zB data_frame(age_group = c(40, 60), sex = factor(M, levels = c("F", "M")) würden Sie wirklich die Zahlen für Frauen wollen? Ich denke, manchmal würdest du es tun und manchmal nicht. Das Erweitern aller Kombinationen erscheint mir wie eine etwas andere Operation (und unabhängig von der Verwendung von Faktoren).

Vielleicht braucht group_by sowohl drop als auch expand Argumente? drop = FALSE würde alle Gruppen der Größe Null beibehalten, die von Faktorstufen generiert wurden, die nicht in den Daten erscheinen. expand = TRUE würde alle Gruppen der Größe Null beibehalten, die durch Kombinationen von Werten generiert wurden, die nicht in den Daten vorkommen.

@hadley Deine Beispiele sehen für mich richtig aus (vorausgesetzt, du levels = 1:2 , nicht levels = 2 ). Und ich denke, es macht Sinn, leere Gruppen beizubehalten, auch wenn nach mehreren Variablen gruppiert wird. Wenn die Variablen beispielsweise sex ( male und female ) und answer (in einem Fragebogen mit den Ebenen disagree , neutral , agree ), und Sie wollten die Häufigkeit jeder Antwort für jedes Geschlecht zählen (z. B. für eine Tabelle oder zum späteren Plotten), Sie möchten keine Antwortkategorie einfach fallen lassen weil keine Frauen darauf geantwortet haben.

Ich würde auch erwarten, dass die Faktorvariablen in den resultierenden data_frame (nicht in Strings umgewandelt) und mit den _ursprünglichen Ebenen_ Faktorvariablen bleiben. (Wenn Sie also die Daten grafisch darstellen, würden die Antwortkategorien in der richtigen Reihenfolge sein, nicht die alphabetischen agree , disagree , neutral ).

Für Ihr letztes Beispiel wäre es _in einigen Fällen_ natürlich, die Variable sex wegzulassen (z. B. wenn _absichtlich_ keine Frauen befragt wurden) und _in anderen Fällen_ nicht (z. B. wenn die Anzahl der Geburtsfehler geschichtet wird nach Geschlecht (und vielleicht Jahr)). Dies kann (und sollte) jedoch leicht _nach_ der Aggregation der Daten behandelt werden. (Eine andere Lösung wäre, ein _vektorwertiges_ .drop Argument zu akzeptieren. Das wäre schön, aber ich denke, es könnte die Dinge verkomplizieren?)

(Eine andere Lösung wäre, ein vektorwertiges .drop-Argument zu akzeptieren. Das wäre schön, aber ich denke, es könnte die Dinge komplizieren?)

Ja, wahrscheinlich zu kompliziert. Ansonsten stimme ich den Kommentaren von

@hadley
Ich denke
YES erweitert alle Kombinationen von Werten zu group_by, wenn sie in den Daten vorhanden sind.
NEIN Erweitern Sie nicht auf Faktorstufen, die nicht existieren.

Mein häufigster Anwendungsfall ist das Vorbereiten eines Satzes zusammengefasster Daten für ein Diagramm (während der Erkundung). Und die Diagramme müssen alle Kombinationen von Werten enthalten. Sie müssen jedoch keine Faktorstufen mit 0 für alle Gruppen haben. Sie können zB kein Balkendiagramm ohne alle Kombinationen stapeln. Sie benötigen jedoch keine Faktorwerte, die in den Daten nicht vorhanden sind, diese wären beim Stapeln nur 0 und in der Legende ein leerer Wert.

Ich glaube, dass das Erweitern aller Werte auf group_by die Standardeinstellung sein sollte, da es viel einfacher (und viel intuitiver) ist, bei Bedarf 0 Fälle nach der Gruppe zu filtern. Ich glaube nicht, dass ein .drop-Argument notwendig ist, da es einfach genug ist, 0 Fälle danach zu filtern. Wir verwenden keine zusätzlichen Argumente für die anderen Funktionen, so dass dies die Form sprengen würde. Standardmäßig sollten nur Ergebnisse für alle Kombinationen vorhandener Werte basierend auf group_by angezeigt werden.

Ich denke, das wäre das richtige Standardverhalten. Hier erweitert das Unique nur vorhandene Werte im Faktor, nicht alle Faktorstufen. (Dies führe ich aus, nachdem ich ein group_by ausgeführt habe, das 0 Werte ablässt)

## Expand data so plot groups works correctly
  df2 <- expand.grid(name = unique(df$name), group = unique(df$group)) %>%
    left_join(df, by=c("name","group")) %>%
    mutate(
      measure = ifelse(is.na(measure),0,measure)
    )

Der einzige Fall, in dem ich sehen kann, wo Sie einen Wert wünschen würden, obwohl alle Gruppen Null hatten, sind Zeitdaten. Vielleicht fehlt irgendwo in der Mitte ein Tag an Daten. Hier wäre noch ein Erweitern und Verbinden auf einen Datumsbereich notwendig. Der Fall der Faktorstufe würde nicht gelten. Ich denke, es ist fair, dass der Datenknecht die fehlenden Daten selbst handhabt.

Vielen Dank für Ihre großartige Arbeit an dieser Bibliothek. 90% meiner Arbeit verwendet dplyr. :)

Ich stimme @huftis voll und ganz zu.

Ich denke nicht, dass das Fallenlassen von Levels oder Kombinationen von Levels etwas mit den Daten zu tun haben sollte. Möglicherweise erstellen Sie anhand eines kleinen Beispiels einen Prototyp für eine Funktion oder Figur. Oder Sie führen einen Split-Apply-Combine-Vorgang durch. In diesem Fall möchten Sie sicherstellen, dass die Ausgabe jeder Gruppe mit dem Rest übereinstimmt.

Meine Position mildern: Ich denke, es lohnt sich zu überlegen, ob sich das Standardverhalten unterscheiden sollte, wenn die Gruppierungsvariable bereits ein geeigneter Faktor ist oder wenn sie zum Faktorisieren gezwungen wird. Ich sehe, dass die Verpflichtung, ungenutzte Pegel zu halten, im Fall von Zwang geringer sein könnte. Aber wenn ich mir die Mühe gemacht habe, etwas als Faktor einzurichten und die Kontrolle über die Levels zu übernehmen ... dann gibt es meistens einen guten Grund und ich möchte nicht ständig darum kämpfen, diesen zu erhalten.

Zu Ihrer Information, ich würde diese Funktion auch gerne sehen. Ich habe ein ähnliches Szenario wie von @huftis beschrieben und muss durch die Reifen springen, um die Ergebnisse zu erhalten, die ich brauche.

Kam von SO her. Ist das nicht das, was complete von "tidyr" helfen soll?

Ja tut es. Ich habe erst kürzlich etwas über "complete" gelernt und es scheint dies auf eine durchdachte Weise zu erreichen.

Dies für SQL-Backends zu implementieren, sieht schwierig aus, da sie standardmäßig alle Gruppen löschen. Sollen wir es dabei belassen und vielleicht cleanr::complete() für SQL implementieren?

Ich habe Problem Nr. 3033 erstellt, ohne zu wissen, dass dieses Problem bereits existiert - Entschuldigung für das Duplikat. Um meinen eigenen bescheidenen Vorschlag hinzuzufügen, verwende ich derzeit pull() und forcats::fct_count() als Umgehungslösung für dieses Problem.

Ich bin jedoch kein Fan dieser Methode, weil fct_count() das Principeverse-Prinzip verrät, eine Ausgabe zu erstellen, die immer vom gleichen Typ wie die Eingabe ist (dh diese Funktion erstellt ein Tibble aus einem Vektor), und ich habe um die Spalten in der Ausgabe umzubenennen. Dies erzeugt 3 Schritte ( pull() %>% fct_count() %>% rename() ), wenn dplyr::count() einen abdecken sollte. Es wäre fantastisch, wenn forcats::fct_count() und dplyr::count() irgendwie zusammengelegt werden könnten und forcats::fct_count() veraltet wären.

Funktioniert tidyr::complete() für Faktoren?

Alle Faktorstufen und Kombinationen von Faktorstufen müssen standardmäßig beibehalten werden. Dieses Verhalten kann durch Parameter wie drop , expand usw. gesteuert werden. Daher sollte das Standardverhalten von dplyr::count() wie folgt aussehen:

df <- data.frame(x = 1:2, y = factor(c(1, 1), levels = 1:2))
df %>% dplyr::count(x, y)
#>  # A tibble: 4 x 3
#>       x        y       n
#>     <int>   <fct>    <int>
#> 1     1        1       1
#> 2     2        1       1
#> 3     1        2       0
#> 4     2        2       0

Gruppen der Länge Null (Kombinationen von Gruppen) können später gefiltert werden. Aber für eine explorative Analyse müssen wir das Gesamtbild sehen.

1. Gibt es Statusaktualisierungen zur Lösung dieses Problems?
2. Gibt es Pläne, dieses Problem vollständig zu lösen?

2: ja definitiv
1: Es gibt einige technische Implementierungsschwierigkeiten zu diesem Problem, aber ich werde es in den nächsten Wochen untersuchen.

Wir könnten damit durchkommen, indem wir die Daten nachträglich erweitern, etwa so:

library(tidyverse)

truly_group_by <- function(data, ...){
  dots <- quos(...)
  data <- group_by( data, !!!dots )

  labels <- attr( data, "labels" )
  labnames <- names(labels)
  labels <- mutate( labels, ..index.. =  attr(data, "indices") )

  expanded <- labels %>%
    tidyr::expand( !!!dots ) %>%
    left_join( labels, by = labnames ) %>%
    mutate( ..index.. = map(..index.., ~if(is.null(.x)) integer() else .x ) )

  indices <- pull( expanded, ..index..)
  group_sizes <- map_int( indices, length)
  labels <- select( expanded, -..index..)

  attr(data, "labels")  <- labels
  attr(data, "indices") <- indices
  attr(data, "group_sizes") <- group_sizes

  data
}

df  <- data_frame(
  x = 1:2,
  y = factor(c(1, 1), levels = 1:2)
)
tally( truly_group_by(df, x, y) )
#> # A tibble: 4 x 3
#> # Groups:   x [?]
#>       x y         n
#>   <int> <fct> <int>
#> 1     1 1         1
#> 2     1 2         0
#> 3     2 1         1
#> 4     2 2         0
tally( truly_group_by(df, y, x) )
#> # A tibble: 4 x 3
#> # Groups:   y [?]
#>   y         x     n
#>   <fct> <int> <int>
#> 1 1         1     1
#> 2 1         2     1
#> 3 2         1     0
#> 4 2         2     0

offensichtlich würde dies intern gehandhabt werden, ohne ordentlichr oder purrr.

Dies scheint sich um die ursprüngliche Frage zu kümmern:

> df = data.frame(a=rep(1:3,4), b=rep(1:2,6))
> df$b = factor(df$b, levels=1:3)
> df %>%
+   group_by(b) %>%
+   summarise(count_a=length(a), .drop=FALSE)
# A tibble: 2 x 3
  b     count_a .drop
  <fct>   <int> <lgl>
1 1           6 FALSE
2 2           6 FALSE
> df %>%
+   truly_group_by(b) %>%
+   summarise(count_a=length(a), .drop=FALSE)
# A tibble: 3 x 3
  b     count_a .drop
  <fct>   <int> <lgl>
1 1           6 FALSE
2 2           6 FALSE
3 3           0 FALSE

Der Schlüssel hier ist dieser

 tidyr::expand( !!!dots ) %>%

was bedeutet, alle Möglichkeiten zu erweitern, unabhängig davon, ob es sich bei den Variablen um Faktoren handelt oder nicht.

Ich würde sagen wir entweder:

• Erweitern Sie alle, wenn drop=FALSE , möglicherweise mit vielen 0-Längengruppen
• tun, was wir jetzt tun, wenn drop=TRUE

vielleicht eine Funktion zum Umschalten der Dropness.

Dies ist eine relativ billige Operation, würde ich sagen, weil sie nur die Manipulation der Metadaten beinhaltet, also ist es vielleicht weniger riskant, dies zuerst in R zu tun?

Meinten Sie crossing() statt expand() ?

Wenn Sie sich die Interna ansehen, stimmen Sie zu, dass wir "nur" build_index_cpp() ändern müssen, insbesondere die Generierung des labels Datenrahmens, um dies zu ermöglichen?

Können wir vielleicht damit beginnen, nur Faktoren mit drop = FALSE ? Ich habe eine "natürliche" Syntax in Betracht gezogen, aber das kann am Ende zu verwirrend sein (und vielleicht sogar nicht mächtig genug):

group_by(data, crossing(col1, col2), col3)

Semantik: Verwenden aller Kombinationen von col1 und col2 und dort existierenden Kombinationen mit col3 .

Ja, ich würde sagen, das betrifft nur build_index_cpp und die Generierung der Attribute labels , indices und group_sizes die ich gerne in a . quetschen möchte aufgeräumte Struktur als Teil von #3489

Der "einzige expandierende Faktoren" Teil dieser Diskussion ist, was so lange gedauert hat.

Was wären die Ergebnisse davon:

library(dplyr)

d <- data_frame(
  f1 = factor( rep( c("a", "b"), each = 4 ), levels = c("a", "b", "c") ),
  f2 = factor( rep( c("d", "e", "f", "g"), each = 2 ), levels = c("d", "e", "f", "g", "h") ),
  x  = 1:8,
  y  = rep( 1:4, each = 2)
)

f <- function(data, ...){
  group_by(data, !!!quos(...))  %>%
    tally()
}
f(d, f1, f2, x)
f(d, x, f1, f2)

f(d, f1, f2, x, y)
f(d, x, f1, f2, y)

Ich denke, f(d, f1, f2, x) sollte die gleichen Ergebnisse liefern wie f(d, x, f1, f2) , wenn die Zeilenreihenfolge ignoriert wird. Gleiches für die anderen beiden.

Auch interessant:

f(d, f2, x, f1, y)
d %>% sample_frac(0.3) %>% f(...)

Ich mag die Idee, eine vollständige Expansion nur für Faktoren zu implementieren. Für Nicht-Charakter-Daten (einschließlich Logiken) könnten wir eine faktorähnliche Klasse definieren/verwenden, die den jeweiligen Datentyp erbt. Vielleicht von Forcats bereitgestellt? Dadurch wird es schwieriger, sich selbst in den Fuß zu schießen.

Umsetzung läuft in #3492

library(dplyr)
#> 
#> Attaching package: 'dplyr'
#> The following objects are masked from 'package:stats':
#> 
#>     filter, lag
#> The following objects are masked from 'package:base':
#> 
#>     intersect, setdiff, setequal, union
df <- data_frame( f = factor( c(1,1,2,2), levels = 1:3), x = c(1,2,1,4) )

( res1 <- tally(group_by(df,f,x, drop = FALSE)) )
#> # A tibble: 9 x 3
#> # Groups:   f [?]
#>   f         x     n
#>   <fct> <dbl> <int>
#> 1 1        1.     1
#> 2 1        2.     1
#> 3 1        4.     0
#> 4 2        1.     1
#> 5 2        2.     0
#> 6 2        4.     1
#> 7 3        1.     0
#> 8 3        2.     0
#> 9 3        4.     0
( res2 <- tally(group_by(df,x,f, drop = FALSE)) )
#> # A tibble: 9 x 3
#> # Groups:   x [?]
#>       x f         n
#>   <dbl> <fct> <int>
#> 1    1. 1         1
#> 2    1. 2         1
#> 3    1. 3         0
#> 4    2. 1         1
#> 5    2. 2         0
#> 6    2. 3         0
#> 7    4. 1         0
#> 8    4. 2         1
#> 9    4. 3         0

all.equal( res1, arrange(res2, f, x) )
#> [1] TRUE

all.equal( filter(res1, n>0), tally(group_by(df, f, x)) )
#> [1] TRUE
all.equal( filter(res2, n>0), tally(group_by(df, x, f)) )
#> [1] TRUE

Erstellt am 10.04.2018 vom Reprex-Paket (v0.2.0).

Ob complete() das Problem löst - nein, nicht wirklich. Welche Zusammenfassungen auch immer berechnet werden, ihr Verhalten auf leeren Vektoren muss erhalten bleiben und darf nicht nachträglich geflickt werden. Zum Beispiel:

data.frame(x=factor(1, levels=1:2), y=4:5) %>%
     group_by(x) %>%
     summarize(min=min(y), sum=sum(y), prod=prod(y))
# Should be:
#> x       min   sum  prod
#> 1         4     9    20
#> 2       Inf     0     1

sum und prod (und in geringerem Maße min ) (und verschiedene andere Funktionen) haben eine sehr gut definierte Semantik für leere Vektoren, und es ist nicht gut, dies zu tun Komm hinterher mit complete() und definiere diese Verhaltensweisen neu.

@kenahoo Ich bin mir nicht sicher, ob ich das verstehe. Dies ist, was Sie mit der aktuellen Dev-Version erhalten. Das einzige, was Sie also nicht erhalten, ist die Warnung von min()

library(dplyr)

data.frame(x=factor(1, levels=1:2), y=4:5) %>%
  group_by(x) %>%
  summarize(min=min(y), sum=sum(y), prod=prod(y))
#> # A tibble: 2 x 4
#>   x       min   sum  prod
#>   <fct> <dbl> <int> <dbl>
#> 1 1         4     9    20
#> 2 2       Inf     0     1

min(integer())
#> Warning in min(integer()): no non-missing arguments to min; returning Inf
#> [1] Inf
sum(integer())
#> [1] 0
prod(integer())
#> [1] 1

Erstellt am 15.05.2018 vom Reprex-Paket (v0.2.0).

@romainfrancois Oh cool, ich wusste nicht, dass du bei dieser Implementierung schon so weit bist. Sieht großartig aus!

Dieses alte Problem wurde automatisch gesperrt. Wenn Sie glauben, ein verwandtes Problem gefunden zu haben, reichen Sie bitte ein neues Problem (mit Reprex) ein und verlinken Sie auf dieses Problem. https://reprex.tidyverse.org/