Der von sklearn.cross_validation.cross_val_score zurückgegebene mittlere quadratische Fehler ist immer negativ. Obwohl dies eine geplante Entscheidung ist, mit der die Ausgabe dieser Funktion bei bestimmten Hyperparametern zur Maximierung verwendet werden kann, ist es äußerst verwirrend, wenn cross_val_score direkt verwendet wird. Zumindest habe ich mich gefragt, wie der Mittelwert eines Quadrats möglicherweise negativ sein kann, und dachte, dass cross_val_score nicht richtig funktioniert oder die angegebene Metrik nicht verwendet. Erst nachdem ich den sklearn-Quellcode eingegraben hatte, stellte ich fest, dass das Zeichen umgedreht war.
Dieses Verhalten wird in make_scorer in scorer.py erwähnt, jedoch nicht in cross_val_score, und ich denke, es sollte so sein, da die Leute sonst denken, dass cross_val_score nicht richtig funktioniert.
Sie beziehen sich auf
greater_is_better : boolean, default=True
Whether score_func is a score function (default), meaning high is good,
or a loss function, meaning low is good. In the latter case, the scorer
object will sign-flip the outcome of the score_func.
in http://scikit-learn.org/stable/modules/generated/sklearn.metrics.make_scorer.html
? (nur als Referenz)
Ich bin damit einverstanden, dass dies in cross_val_score-Dokumenten klarer sein kann
Vielen Dank für die Berichterstattung
In der Tat haben wir dieses Problem beim Refactoring des Scorers übersehen. Folgendes ist sehr kontraintuitiv:
>>> import numpy as np
>>> from sklearn.datasets import load_boston
>>> from sklearn.linear_model import RidgeCV
>>> from sklearn.cross_validation import cross_val_score
>>> boston = load_boston()
>>> np.mean(cross_val_score(RidgeCV(), boston.data, boston.target, scoring='mean_squared_error'))
-154.53681864311497
/ cc @larsmans
Übrigens stimme ich nicht zu, dass es sich um ein Dokumentationsproblem handelt. Es ist cross_val_score
sollte den Wert mit dem Vorzeichen zurückgeben, das dem Scoring-Namen entspricht. Idealerweise sollte auch GridSearchCV(*params).fit(X, y).best_score_
konsistent sein. Ansonsten ist die API sehr verwirrend.
Ich stimme auch zu, dass eine Änderung zur Rückgabe der tatsächlichen MSE ohne umgeschaltetes Vorzeichen die bessere Option wäre.
Das Scorer-Objekt könnte nur das greater_is_better
-Flag speichern, und wenn der Scorer verwendet wird, könnte das Zeichen umgedreht werden, falls es benötigt wird, z. B. in GridSearchCV
.
Ich bin damit einverstanden, dass wir hier ein Usability-Problem haben, aber ich stimme der Lösung von @ogrisel , die wir sollten, nicht vollständig zu
Geben Sie den Wert mit dem Vorzeichen zurück, das dem Bewertungsnamen entspricht
denn das ist auf lange Sicht ein unzuverlässiger Hack. Was ist, wenn jemand einen benutzerdefinierten Scorer mit einem Namen wie mse
? Was ist, wenn sie dem Namensmuster folgen, den Scorer jedoch in einen Dekorateur einwickeln, der den Namen ändert?
Das Scorer-Objekt könnte einfach das Flag "Greater_is_better" speichern, und wenn der Scorer verwendet wird, kann das Zeichen bei Bedarf umgedreht werden, z. B. in GridSearchCV.
Dies ist, was Scorer ursprünglich während der Entwicklung zwischen den Versionen 0.13 und 0.14 getan haben, und es hat ihre Definition viel schwieriger gemacht. Es machte es auch schwierig, dem Code zu folgen, da das Attribut greater_is_better
im Scorer-Code zu verschwinden schien und nur in der Mitte des Rastersuchcodes wieder angezeigt wurde. Eine spezielle Scorer
-Klasse wurde benötigt, um etwas zu tun, was im Idealfall eine einfache Funktion tun würde.
Ich glaube, wenn wir die Ergebnisse optimieren wollen, sollten sie maximiert werden. Aus Gründen der Benutzerfreundlichkeit denke ich, dass wir einen Parameter score_is_loss
∈ ["auto", True, False]
einführen könnten, der nur die Anzeige der Ergebnisse ändert und eine Heuristik verwenden kann, die auf den integrierten Namen basiert.
Das war eine eilige Antwort, weil ich aus dem Zug steigen musste. Was ich mit "Anzeige" gemeint habe, ist wirklich der Rückgabewert von cross_val_score
. Ich denke, die Torschützen sollten einfach und einheitlich sein und die Algorithmen sollten immer maximiert werden.
Dies führt zu einer Asymmetrie zwischen integrierten und benutzerdefinierten Scorern.
Ping @GaelVaroquaux.
Ich mag die score_is_loss-Lösung oder etwas in diesem Sinne. Der Vorzeichenwechsel, der mit dem Scoring-Namen übereinstimmt, scheint schwer zu pflegen zu sein, könnte Probleme verursachen, wie @larsmans erwähnte
Was ist die Schlussfolgerung, für welche Lösung sollten wir uns entscheiden? :) :)
@tdomhan @jaquesgrobler @larsmans Wissen Sie, ob dies auch für r2
? Ich stelle fest, dass die von GridSearchCV
r2
Scores auch für ElasticNet
, Lasso
und Ridge
meistens negativ sind.
R² kann entweder positiv oder negativ sein, und negativ bedeutet einfach, dass Ihr Modell eine sehr schlechte Leistung erbringt.
IIRC, @GaelVaroquaux war ein Befürworter der Rückgabe einer negativen Zahl, wenn greater_is_better=False
.
r2
ist eine Bewertungsfunktion (größer ist besser), die positiv sein sollte, wenn Ihr Modell gut ist - aber es ist eine der wenigen Leistungsmetriken, die tatsächlich negativ sein können, dh schlechter als 0.
Was ist der Konsens zu diesem Thema? Meiner Meinung nach ist cross_val_score
ein Bewertungswerkzeug, kein Modellauswahlwerkzeug. Es sollte daher die ursprünglichen Werte zurückgeben.
Ich kann es in meinem PR # 2759 beheben, da die von mir vorgenommenen Änderungen die Behebung sehr einfach machen. Der Trick besteht darin, das Zeichen nicht im Voraus umzudrehen, sondern greater_is_better
Rastersuche auf das Attribut
Was ist der Konsens zu diesem Thema? Meiner Meinung nach ist cross_val_score
ein Bewertungswerkzeug, kein Modellauswahlwerkzeug. Es sollte also zurückkehren
die ursprünglichen Werte.
Sonderfälle sind unterschiedliche Verhaltensweisen, die zu Problemen in der Software führen.
Ich denke einfach, dass wir "mse" in "negated_mse" in der Liste umbenennen sollten
von akzeptablen Scoring-Saiten.
Was ist, wenn jemand einen benutzerdefinierten Scorer mit einem Namen wie mse definiert? Was ist, wenn sie dem Namensmuster folgen, den Scorer jedoch in einen Dekorateur einwickeln, der den Namen ändert?
Ich glaube nicht, dass @ogrisel vorgeschlagen hat , übereinzustimmen . Korrigieren Sie mich, wenn ich falsch liege @ogrisel.
Ich denke einfach, dass wir "mse" in "negated_mse" in der Liste der akzeptablen Bewertungszeichenfolgen umbenennen sollten.
Das ist völlig unintuitiv, wenn Sie die Interna von Scikit-Learn nicht kennen. Wenn Sie das System so biegen müssen, ist dies meiner Meinung nach ein Zeichen dafür, dass ein Designproblem vorliegt.
Das ist völlig unintuitiv, wenn Sie die Interna von Scikit-Learn nicht kennen.
Wenn Sie das System so biegen müssen, denke ich, dass es ein Zeichen dafür ist, dass es ein gibt
Designproblem.
Ich stimme dir nicht zu. Menschen verstehen Dinge mit viel Vorwissen und
Kontext. Sie sind alles andere als systematisch. Der Versuch, dies in Software einzubetten
gibt Einkaufslisten wie eine Reihe von Sonderfällen. Das macht es nicht nur
Software schwer zu warten, aber es bedeutet auch, dass Menschen, die nicht haben
Denken Sie daran, dass diese Ausnahmen auf überraschende Verhaltensweisen stoßen und fehlerhaft schreiben
Code über die Bibliothek.
Welchen Sonderfall haben Sie im Sinn?
Um klar zu sein, denke ich, dass die im Objekt GridSearchCV
gespeicherten Kreuzvalidierungsergebnisse _auch_ die ursprünglichen Werte sein sollten (nicht mit umgedrehtem Vorzeichen).
AFAIK, das Umdrehen des Zeichens, wurde eingeführt, um die Implementierung der Rastersuche ein wenig zu vereinfachen, sollte aber die Benutzerfreundlichkeit nicht beeinträchtigen.
Welchen Sonderfall haben Sie im Sinn?
Nun, die Tatsache, dass für einige Metriken größer ist, ist besser, während für andere
es ist das Gegenteil.
AFAIK, das Umdrehen des Zeichens wurde eingeführt, um die Rastersuche durchzuführen
Implementierung etwas einfacher, sollte aber nicht beeinflussen
Benutzerfreundlichkeit.
Es geht nicht um die Rastersuche, es geht um die Trennung von Bedenken: Punktzahlen
müssen verwendbar sein, ohne etwas über sie zu wissen, oder Code zu
Der Umgang mit ihren Besonderheiten wird sich auf die gesamte Codebasis ausbreiten. Es gibt
schon viel Scoring-Code.
Aber das verschiebt das Problem etwas auf Benutzercode. Niemand möchte "negierte MSE" zeichnen, daher müssen Benutzer Zeichen in ihrem Code zurückdrehen. Dies ist unpraktisch, insbesondere bei Kreuzvalidierungsberichten mit mehreren Metriken (PR # 2759), da Sie jede Metrik einzeln behandeln müssen. Ich frage mich, ob wir das Beste aus beiden Welten haben können: generischen Code und intuitive Ergebnisse.
Aber das verschiebt das Problem etwas auf Benutzercode. Niemand will
um "negierte MSE" zu zeichnen, müssen Benutzer Zeichen in ihre zurückblättern
Code.
Mit Sicherheit nicht das Ende der Welt. Beachten Sie, dass beim Lesen von Papieren oder
Beim Betrachten von Präsentationen habe ich das gleiche Problem: Wenn das Diagramm nicht ist
Gut gemacht, ich verliere ein bisschen Zeit und mentale Bandbreite, um es zu versuchen
Figur, ob größer besser ist oder nicht.
Dies ist unpraktisch, insbesondere bei der Kreuzvalidierung mit mehreren Metriken
Berichte (PR # 2759), da Sie jede Metrik einzeln behandeln müssen.
Warum. Wenn Sie nur akzeptieren, dass es immer größer ist, ist es besser
alles einfacher, einschließlich der Interpretation der Ergebnisse.
Ich frage mich, ob wir das Beste aus beiden Welten haben können: generischen Code und
intuitive Ergebnisse.
Das Risiko besteht darin, einen sehr komplexen Code zu haben, der uns für die Wartung verlangsamt
und Entwicklung. Scikit-Learn nimmt zu.
Wenn Sie nur akzeptieren, dass es immer größer ist, ist es besser
Das hat sie gesagt :)
Im Ernst, ich denke, ein Grund, warum dies die Leute verwirrt, ist, dass die Ausgabe von cross_val_score
nicht mit den Metriken übereinstimmt. Wenn wir Ihrer Logik folgen, sollten alle Metriken in sklearn.metrics "größer ist besser" folgen.
Das hat sie gesagt :)
Schön!
Im Ernst, ich denke, ein Grund, warum dies die Leute verwirrt, ist, dass
Die Ausgabe von cross_val_score stimmt nicht mit den Metriken überein. Wenn wir
Folgen Sie Ihrer Logik, alle Metriken in sklearn.metrics sollten "größer" folgen
ist besser".
Einverstanden. Deshalb gefällt mir die Idee, den Namen zu ändern: Es würde auftauchen
in die Augen der Menschen.
Im Ernst, ich denke, ein Grund, warum dies die Leute verwirrt, ist, dass die Ausgabe von cross_val_score nicht mit den Metriken übereinstimmt.
Und dies wiederum lässt scoring
mysteriöser erscheinen als es ist.
Wurde heute in 0.16.1 davon gebissen, als ich versuchte, eine lineare Regression durchzuführen. Während das Vorzeichen der Punktzahl für Klassifikatoren anscheinend nicht mehr umgedreht wird, wird es für die lineare Regression immer noch umgedreht. Um die Verwirrung zu vergrößern, gibt LinearRegression.score () eine nicht gespiegelte Version der Partitur zurück.
Ich würde vorschlagen, alles konsistent zu machen und die Punktzahl ohne Vorzeichen auch für lineare Modelle zurückzugeben.
Beispiel:
from sklearn import linear_model
from sklearn.naive_bayes import GaussianNB
from sklearn import cross_validation
from sklearn import datasets
iris = datasets.load_iris()
nb = GaussianNB()
scores = cross_validation.cross_val_score(nb, iris.data, iris.target)
print("NB score:\t %0.3f" % scores.mean() )
iris_reg_data = iris.data[:,:3]
iris_reg_target = iris.data[:,3]
lr = linear_model.LinearRegression()
scores = cross_validation.cross_val_score(lr, iris_reg_data, iris_reg_target)
print("LR score:\t %0.3f" % scores.mean() )
lrf = lr.fit(iris_reg_data, iris_reg_target)
score = lrf.score(iris_reg_data, iris_reg_target)
print("LR.score():\t %0.3f" % score )
Das gibt:
NB score: 0.934 # sign is not flipped
LR score: -0.755 # sign is flipped
LR.score(): 0.938 # sign is not flipped
Durch die Kreuzvalidierung werden alle Anzeichen von Modellen umgedreht, bei denen größer besser ist. Ich bin immer noch nicht mit dieser Entscheidung einverstanden. Ich denke, der Hauptbefürworter war @GaelVaroquaux und vielleicht @mblondel [Ich erinnerte mich, dass Sie den Scorer-Code
Oh egal, die ganze Diskussion ist oben.
Ich habe das Gefühl, dass das Vorzeichen in mse standardmäßig umgedreht wird und r2 noch weniger intuitiv ist: - /
@ Huitzilo GaussianNB ist ein Klassifikator und verwendet Genauigkeit als Standard-Scorer. LinearRegression ist ein Regressor und verwendet den r2-Score als Standard-Scorer. Die zweite Punktzahl ist negativ, aber denken Sie daran, dass die r2-Punktzahl negativ sein kann. Außerdem ist Iris ein Datensatz mit mehreren Klassen. Daher sind die Ziele kategorisch. Sie können keinen Regressor verwenden.
richtig, ich war ein bisschen verwirrt darüber, was passiert, r2 wird nicht umgedreht ... nur mse wäre.
Vielleicht besteht eine Lösung für das ganze Problem darin, das Ding negmse
umzubenennen?
@mblondel natürlich hast du recht, sorry. Ich habe gerade schnell ein Beispiel für eine Regression zusammengestellt, und in meinem übermäßigen Vertrauen in die Irisdaten dachte ich, dass die Vorhersage von Merkmal Nr. 4 von den anderen funktionieren würde (mit positivem R2). Aber es war daher kein negatives R2. Hier kippt kein Schild. IN ORDNUNG. Mein Fehler.
Trotzdem ist das Zeichen in der MSE umgedreht, die ich von cross_val_score
bekomme.
Vielleicht bin ich es nur, aber ich finde diese Inkonsistenz äußerst verwirrend (was mich zu diesem Thema gebracht hat). Warum sollte MSE mit einem Vorzeichen versehen werden, nicht jedoch R2?
Vielleicht bin ich es nur, aber ich finde diese Inkonsistenz äußerst verwirrend (was mich zu diesem Thema gebracht hat). Warum sollte MSE mit einem Vorzeichen versehen werden, nicht jedoch R2?
Weil die Semantik der Punktzahl höher ist, ist sie besser. Hohe MSE ist schlecht.
Vielleicht würde Negmse das Problem lösen
@amueller Ich stimme zu, das explizite
Vielleicht könnte die Dokumentation unter [1] auch noch expliziter darüber sein, wie sich die Zeichen für einige Partituren drehen. In meinem Fall brauchte ich schnell Informationen und schaute nur in die Tabelle unter 3.1.1.1, las aber den Text nicht (was das Prinzip "Größer ist besser" erklärt). IMHO würde das Hinzufügen eines Kommentars für mse, Median und mittleren absoluten Fehler in der Tabelle unter 3.1.1.1, der deren Negation angibt, bereits viel helfen, ohne dass Änderungen am tatsächlichen Code vorgenommen würden.
[1] http://scikit-learn.org/stable/modules/model_evaluation.html#scoring -parameter
Ich bin auf einen sehr interessanten Fall gestoßen:
from sklearn.cross_validation import cross_val_score
model = LinearRegression()
scores = cross_val_score(model, X, target, cv=2, scoring='r2')
scores
Ergebnisse in
array([-0.17026282, -2.21315179])
Für denselben Datensatz den folgenden Code
model = LinearRegression()
model.fit(X, target)
prediction = model.predict(X)
print r2_score(target, prediction)
ergibt einen angemessenen Wert
0.353035789318
AFAIK für lineares Regressionsmodell (mit Achsenabschnitt) kann man nicht R ^ 2> 1 oder R ^ 2 <0 erhalten
Daher sieht das Lebenslaufergebnis nicht wie R ^ 2 mit einem umgedrehten Vorzeichen aus. Liege ich irgendwann falsch
r2 kann negativ sein (für schlechte Modelle). Es kann nicht größer als 1 sein.
Sie sind wahrscheinlich überpassend. Versuchen:
from sklearn.cross_validation import train_test_split
X_train, X_test, y_train, y_test = train_test_split(X, target, test_size=0.2, random_state=0)
model = LinearRegression()
model.fit(X_train, y_train)
pred_train = model.predict(X_train)
print("train r2: %f" % r2_score(y_train, pred_train))
pred_test = model.predict(X_test)
print("test r2: %f" % r2_score(y_test, pred_test))
Versuchen Sie es mit verschiedenen Werten für den random_state
Integer-Startwert, der die zufällige Aufteilung steuert.
Vielleicht würde Negmse das Problem lösen
+1 für 'neg_mse' (Ich denke, dieser Unterstrich macht die Dinge besser lesbar).
Löst das alle Probleme? Gibt es andere Punkte, bei denen höhere Werte nicht besser sind?
Es gibt:
log_loss
mean_absolute_error
median_absolute_error
Laut doc/modules/model_evaluation.rst
sollten das alle sein.
Und hinge_loss
denke ich?
Das Hinzufügen des Präfixes neg_
zu all diesen Verlusten ist unangenehm.
Eine Idee wäre, die ursprünglichen Partituren zurückzugeben (ohne Vorzeichenwechsel), aber anstatt ein ndarray zurückzugeben, geben wir eine Klasse zurück, die ndarray mit Methoden wie best()
, arg_best()
, best_sorted()
. Auf diese Weise sind die Ergebnisse nicht überraschend und wir verfügen über praktische Methoden, um die besten Ergebnisse zu erzielen.
Es gibt keinen Wert für Scharnierverlust (und ich habe noch nie gesehen, dass er zur Bewertung verwendet wird).
Der Scorer gibt kein Numpy-Array zurück, sondern einen Float, oder?
Wir könnten ein Score-Objekt zurückgeben, das ein benutzerdefiniertes ">" hat, aber wie ein Float aussieht.
Das fühlt sich für mich besser an als die vorherige Lösung, bei der der Torschütze mit einem Bool "lower_is_better" versehen wurde, das dann in GridSearchCV verwendet wurde.
cross_val_score
gibt ein Array zurück.
Tatsächlich müssen die von cross_val_score
Punktzahlen normalerweise nicht sortiert, sondern nur gemittelt werden.
Eine andere Idee ist, _BaseScorer
eine sorted
-Methode hinzuzufügen.
my_scorer = make_scorer(my_metric, greater_is_better=False)
scores = my_scorer.sorted(scores) # takes into account my_scorer._sign
best = scores[0]
cross_val_score
gibt ein Array zurück, aber die Scorer geben einen Float zurück. Ich halte es für seltsam, eine bestimmte Logik in cross_val_score
da Sie in GridSearchCV und in allen anderen CV-Objekten dasselbe Verhalten wünschen.
Sie benötigen außerdem eine Argsort-Methode, da Sie in GridSearchCV die beste Punktzahl und den besten Index erzielen möchten.
Wie kann man durch Scikit-Learn "Schätzen der Mittelwerte und Abweichungen der Fehler der Arbeiter aus den Kontrollfragen und Berechnen des gewichteten Durchschnitts nach Entfernen der geschätzten Verzerrung für die Vorhersagen" implementieren?
IIRC Wir haben dies im Sprint besprochen (letzten Sommer?!) Und beschlossen, mit neg_mse
(oder war es neg-mse
) zu gehen und alle Torschützen / Strings, bei denen wir jetzt ein negatives Vorzeichen haben, zu verwerfen.
Ist das noch der Konsens? Wir sollten das dann vor 0.18 machen.
Ping @GaelVaroquaux @agramfort @jnothman @ogrisel @raghavrv
ja wir haben uns auf neg_mse AFAIK geeinigt
Es war neg_mse
Wir brauchen auch:
neg_log_loss
neg_mean_absolute_error
neg_median_absolute_error
model = Sequential ()
keras.layers.Flatten ()
model.add (Dense (11, input_dim = 3, kernel_initializer = keras.initializers.he_normal (seed = 2),
kernel_regularizer = Regularizers.l2 (2)))
keras.layers.LeakyReLU (alpha = 0,1)
model.add (Dense (8, kernel_initializer = keras.initializers.he_normal (seed = 2)))
keras.layers.LeakyReLU (alpha = 0,1)
model.add (Dense (4, kernel_initializer = keras.initializers.he_normal (seed = 2)))
keras.layers.LeakyReLU (alpha = 0,1)
model.add (Dense (1, kernel_initializer = keras.initializers.he_normal (seed = 2)))
keras.layers.LeakyReLU (alpha = 0,2)
adag = RMSprop (lr = 0,0002)
model.compile (loss = loss.mean_squared_error,
Optimierer = Adag
)
history = model.fit (X_train, Y_train, Epochen = 2000,
batch_size = 20, shuffle = True)
Wie kann der obige Code überprüft werden? Ich möchte eine ausgelassene Kreuzvalidierungsmethode weglassen.
@shreyassks Dies ist nicht der richtige Ort für Ihre Frage, aber ich würde dies überprüfen: https://keras.io/scikit-learn-api . Wickeln Sie Ihr Netzwerk in einen scikit-learn
Schätzer ein und verwenden Sie dann w / model_selection.cross_val_score
Ja. Ich bin vollkommen einverstanden! Dies ist auch Brier_score_loss passiert. Mit Brier_score_loss funktioniert es einwandfrei, aber es wird verwirrend, wenn es vom GridSearchCV kommt. Der negative Brier_score_loss kehrt zurück. Zumindest wäre es besser, so etwas auszugeben, weil Brier_score_loss ein Verlust ist (je niedriger desto besser), die Bewertungsfunktion hier dreht das Vorzeichen um, um es negativ zu machen.
Die Idee ist, dass cross_val_score sich vollständig auf den absoluten Wert des Ergebnisses konzentrieren sollte. Meines Wissens ist die Bedeutung des negativen Vorzeichens (-) für MSE (mittlerer quadratischer Fehler) in cross_val_score nicht vordefiniert. Warten wir auf die aktualisierte Version von sklearn, in der dieses Problem behoben ist.
Für den Regressionsfall:
model_score = cross_val_score (Modell, df_input, df_target, Scoring = 'neg_mean_squared_error', cv = 3)
Ich erhalte die Werte wie folgt:
SVR:
[-6.20938025 -1.397376 -1.94519]
-3.183982080147279
Lineare Regression:
[-5.94898085 -9.30931808 -1.15760676]
-5.4719685646934275
Lasso:
[-7.22363814 -10.47734135 -2.20807684]
-6.6363521107522345
Grat:
[-5.95990385 -4.17946756 -1.36885809]
-3,8360764993832004
Welches ist das Beste?
SVR?
Für den Regressionsfall:
Ich erhalte unterschiedliche Ergebnisse, wenn ich benutze
(1) "cross_val_score" mit Scoring = 'neg_mean_squared_error'
und
(2) Für die gleichen Eingaben, wenn ich "GridSearchCV" verwende und den 'best_score_' überprüfe.
Welches ist für Regressionsmodelle besser?
@ Pritishban
Sie stellen eine Verwendungsfrage. Der Issue-Tracker ist hauptsächlich für Fehler und neue Funktionen gedacht. Bei Fragen zur Verwendung wird empfohlen, Stack Overflow oder die Mailingliste zu verwenden .
Hilfreichster Kommentar
Vielleicht würde Negmse das Problem lösen