mir folgendes inkonsistentes Verhalten von cut
begegnet, die mir Kopfschmerzen gibt:inkonsistentes Verhalten von `cut`: Verschiedene Intervalle mit dem gleichen Anzahl und gleichen angezeigten Schnittpunkten
x <- 0.2316
cut(x, c(0, 0.2315, 10)) #gives 0.232 as cutpoint and choses second interval
## [1] (0.232,10]
## Levels: (0,0.232] (0.232,10]
cut(x, c(0, 0.232, 10)) #choses first interval when taking the same cutpoint it just gave (0.232)
## [1] (0,0.232]
## Levels: (0,0.232] (0.232,10]
Das Problem ist, dass cut
die wählen scheint Intervall vor dem Formatieren (Runden) der Schnittpunkte. Dies führt zu dem inkonsistenten Verhalten im Beispiel, dass es das zweite Intervall wählt, aber das erste Intervall entsprechend dem gegebenen Schnittpunkt gewählt hätte (was in der letzten Zeile zu sehen ist).
Das ist ein Problem für mich, weil ich zwei Funktionen in meinem Paket habe: Einer berechnet die Schnittpunkte und der zweite bestimmt die richtigen Intervalle, wo neue Datenpunkte eingefügt werden. Im obigen Beispiel wird der gleiche Datenpunkt in das zweite Intervall in der ersten Funktion, aber in das erste Intervall in der zweiten Funktion eingefügt - die exakt gleichen Schnittpunkte werden angezeigt! Das kann zu seltsamen Verhaltensweisen in meinem Paket führen!
Meine Frage
Ist dies ein bekanntes Problem? Und wenn ja, gibt es Workarounds? Danke
bearbeiten
Ich weiß, dass Sie die Anzahl der Dezimalstellen mit dig.lab
noch das gleiche Problem würde auftreten, ändern können, wenn Sie Schnittpunkte mit mehr Dezimalstellen hatte. Das obige Beispiel ist nur eine Demonstration eines allgemeineren Problems!
Möchten Sie mehr Ziffern für die Schnittpunkte? Das wäre "cut (x, c (0, 0.2315, 10), dig.lab = 4)". – lukeA
@lukeA: Ich weiß, aber das gleiche Problem würde eine Dezimalstelle weiter unten auftreten, wenn Sie eine Zahl mit mehr Dezimalstellen als Schnittpunkt hatten. Das obige ist nur ein illustratives Beispiel! – vonjd
@lukeA: Bitte sehe meine Bearbeitung. – vonjd