Kein Committer, aber können wir bitte PySpark API für 1.0 ansprechen?
Ausgabe: #3370
Aktuelle PR: #4656

Für andere Mitwirkende, die keine Berechtigung zum Bearbeiten des Beitrags haben, kommentieren Sie bitte hier, was Ihrer Meinung nach in 1.0.0 enthalten sollte

Sollten wir außerdem in 1.0 ausschließlich auf den Scala-basierten Rabit-Tracker (für Spark) umsteigen?

Ich bin auch kein Committer, aber ich und das Unternehmen, in dem ich arbeite, sind sehr daran interessiert, das Leistungsproblem mit Checkpointing zu beheben (oder es zumindest zu mildern) #3946

@trams @thesuperzapper Ich denke, dies ist ein Überblick für alle, um ein Gefühl dafür zu bekommen, was als nächstes kommt. Es wäre schwierig, alles aufzulisten, was kommt, da XGBoost ein Community-getriebenes Projekt ist. Öffnen Sie einfach eine PR, wenn sie fertig ist.

Kein Committer, aber können wir bitte PySpark API für 1.0 ansprechen?

@thesuperzapper Lassen Sie uns den Fortschritt verfolgen. Ich hoffe natürlich, dass ich mit dem Testen beginnen kann. :-)

Es gibt auch die sekundäre Überlegung, dass wir möglicherweise nicht für 1.0 bereit sind, und die API-Garantien, die damit einhergehen, könnten wir beispielsweise stattdessen 0.10.0 als nächstes tun?

@thesuperzapper 1.0 wird keine endgültige Version sein. Wir versuchen nur, eine semantische Versionierung durchzuführen.

Einige GPU-bezogene Elemente hinzugefügt.

möchte einen nativen xgb-Fix enthalten.
https://github.com/dmlc/xgboost/issues/4753

JSON wird aus der Liste entfernt. Siehe https://github.com/dmlc/xgboost/pull/4683#issuecomment -520485615

Ich habe ein Problem für meinen obigen Vorschlag angesprochen: #4781 (Um den Python-Rabit-Tracker zu entfernen)

FeatureImportance in der Spark-Version wird auch großartig sein (dh leicht das Feature Importance haben)
https://github.com/dmlc/xgboost/pull/988

Regressionstest hinzugefügt.

@chenqin Ich würde gerne von Ihnen zu Regressionstests hören, da Sie Erfahrung mit der Verwaltung von ML in der Produktion haben. Irgendwelche Vorschläge?

@chenqin Ich würde gerne von Ihnen zu Regressionstests hören, da Sie Erfahrung mit der Verwaltung von ML in der Produktion haben. Irgendwelche Vorschläge?

Ich denke, wir sollten Regressionstests für verschiedene Workloads und Benchmarks gegen Vorhersagegenauigkeit und -stabilität (gleich oder besser) als die vorherige Version in ungefähr derselben Zeit abdecken. Zwei Kandidaten auf meinem Kopf sind

https://archive.ics.uci.edu/ml/datasets/HIGGS

spärliche Dmatrix
https://www.kaggle.com/c/ClaimPredictionChallenge

Wir können verschiedene Baummethoden und -konfigurationen ausprobieren, um eine gute Abdeckung zu gewährleisten

tree_method, Konfigurationen / Datensatz / Standalone oder Cluster

Deklamation:
Ich denke, es lohnt sich, ein wenig zu klären.

• Release-Regression ist nichts, was wir in der Firma, in der ich gearbeitet habe, bereits gemacht haben.

• Die von mir vorgeschlagenen Datensätze sind willkürlich und dürfen nicht als Benchmark verwendet werden, um ein Framework besser als ein anderes zu beanspruchen. (Dies ist am besorgniserregendsten, wenn ich von Zeit zu Zeit verzerrte Benchmarks sah)

• Tatsächlich war die Essenz des Tunens und Aufdeckens der richtigen Funktionen/Einstellungen immer wichtiger. Leider können wir dies in Regressionstests nicht berücksichtigen.

Ein möglicherweise besser organisierter Plan besteht darin, ein Automatisierungstool zu erstellen, mit dem Benutzer verschiedene Einstellungen vornehmen und mit ihrem privaten Datensatz und Modell in ihrem eigenen Rechenzentrum vergleichen können.

Wir sollten Fixierung #4779 als Voraussetzung für den Versand von 1.0 hinzufügen

Ich füge #4899 als Bereinigungsschritt hinzu.

@dmlc/xgboost-committer Da wir noch einige Aufgaben für 1.0 haben, sollten wir vielleicht eine Zwischenversion 0.91 machen?

@hcho3 Oder vielleicht 0.10.0

@thesuperzapper Das wird das Versionssystem verwirren. Ich habe nichts gegen eine 0.91-Version, aber ich möchte trotzdem die richtigen Verfahren für Regressionstests sehen.

@trivialfis Wenn der Master API-Änderungen hat, sollten wir nicht eine Hauptversion stoßen, die meiner Meinung nach wie 0.100.0 aussehen würde?

@thesuperzapper Die Version 1.0.0 ist die erste Version, die wir ein semantisches Versionierungsschema übernehmen würden, also nein, die semantische Versionierung wird nicht auf die Zwischenversion angewendet. Es ist ein bisschen knifflig, da wir noch einiges zu tun haben, bis 1.0.0 veröffentlicht wird.

Wenn wir 0,91 wollen, sollten wir alle Änderungen überprüfen und sicherstellen, dass 0,91 ein ist
inkrementelles Update basierend auf 0,90, und als solches verletzen wir unsere Roadmap von
1.0.0 durch Verschieben mehrerer Funktionen auf 0.9x oder eine andere Version

Mein Vorschlag wäre die Version 1.0.0.preview.1, einige andere Projekte auch
macht das vor einem Major Release

Am Sa., 5. Okt. 2019 um 10:19 Uhr Philip Hyunsu Cho [email protected]
schrieb:

@thesuperzapper https://github.com/thesuperzapper Die Version 1.0.0 ist
die erste Version würden wir ein semantisches Versionierungsschema verwenden, also nein,
Die semantische Versionsverwaltung gilt nicht für die Zwischenversion.

—
Sie erhalten dies, weil Sie den Thread verfasst haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/dmlc/xgboost/issues/4680?email_source=notifications&email_token=AAFFQ6GBEQSXJKFW6QDPN53QNDEALA5CNFSM4IE5CQGKYY3PNVWWK3TUL52HS4DFVREXG43VMVBWLOG63LNMVXHJKT53
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AAFFQ6BYMDES3537PDMGE5DQNDEALANCNFSM4IE5CQGA
.

@CodingCat 1.0.0.preview.1 ist ein interessanter Vorschlag. Akzeptiert Maven diese Version?

Ja, die Versionsnummer kann nicht-numerische Buchstaben enthalten

Am Sa., 5. Okt. 2019 um 11:11 Uhr Philip Hyunsu Cho [email protected]
schrieb:

@CodingCat https://github.com/CodingCat 1.0.0.preview.1 ist ein
interessanter Vorschlag. Akzeptiert Maven diese Version?

—
Sie erhalten dies, weil Sie erwähnt wurden.

Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/dmlc/xgboost/issues/4680?email_source=notifications&email_token=AAFFQ6H64Y75JBSSDRVYIS3QNDKFNA5CNFSM4IE5CQGKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMV275Y75JBSSDRVYIS3QNDKFNA5CNFSM4IE5CQGKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMV275JKtDNQ
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AAFFQ6BHKVVMQIDMRPY4DSTQNDKFNANCNFSM4IE5CQGA
.

Eine Zwischenversion ist eine gute Idee, es gibt viele Verbesserungen seit 0.9.

Verstanden, ich werde in den nächsten Tagen einige Klempnerarbeiten im CI-System durchführen und dann die Version 1.0.0.preview.1 vorbereiten.

@CodingCat Wie wäre es mit 0,100 oder 0,95? "Vorschau" klingt, als würde die Version 1.0.0 gleich um die Ecke sein, aber wir haben einige wichtige Funktionen (PySpark) auf dem Spiel.

Unterstützt es das Gewicht xgboost?

Ich mache mir keine Sorgen über den Eindruck von 1.0.0 auf Benutzer

Die Spark 3.0-Vorschau wird in diesem Monat veröffentlicht, aber die offizielle Veröffentlichung steht als nächstes an
April (um Funkengipfel) vielleicht

Am Di, 8. Oktober 2019 um 11:41 Uhr Philip Hyunsu Cho [email protected]
schrieb:

@CodingCat https://github.com/CodingCat Wie wäre es mit 0,100 oder 0,95?
"Vorschau" klingt, als würde die Version 1.0.0 gleich um die Ecke sein, aber wir
haben einige wichtige Funktionen (PySpark) auf der Linie.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/dmlc/xgboost/issues/4680?email_source=notifications&email_token=AAFFQ6AOGIWIB6W6TW3R5W3QNTH6TA5CNFSM4IE5CQGKYY3PNVWWK3TUL52HS4DFVREXG43VMVBWLOKTLNWWXGO96
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AAFFQ6HF52HBR7ZNSKLIY3TQNTH6TANCNFSM4IE5CQGA
.

@CodingCat Zumindest aus der Sicht von xgboost4j-spark wird diese 1.0.0-Vorschau für die meisten Leute nicht nützlich sein, da fast niemand Spark auf 2.12 ausführt. Darüber hinaus können Sie nicht einfach eine kompilierte Binärdatei erhalten, da https://spark.apache.org/downloads.html keine kompilierten Versionen von Spark für 2.12 mit den enthaltenen Hadoop-Binärdateien verteilt.

Dann sollten wir nichts veröffentlichen?

Am Do, 10.10.2019 um 22:05 Uhr Mathew Wicks [email protected]
schrieb:

@CodingCat https://github.com/CodingCat zumindest aus Sicht
von xgboost4j-spark wird diese Vorschau von 1.0.0 für die meisten Leute nicht nützlich sein, da
Spark läuft am 2.12 fast niemand. Außerdem kannst du nicht einfach bekommen
eine kompilierte Binärdatei als https://spark.apache.org/downloads.html
kompilierte Versionen von Spark für 2.12 mit den Hadoop-Binärdateien verteilen
inbegriffen.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/dmlc/xgboost/issues/4680?email_source=notifications&email_token=AAFFQ6AN3FJQ7ZE7EOTXLW3QOACSFA5CNFSM4IE5CQGKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63DNW2HZ6KTLNMV2HZ
oder abmelden
https://github.com/notifications/unsubscribe-auth/AAFFQ6EJRRMTNY7R7JVALTDQOACSFANCNFSM4IE5CQGA
.

@CodingCat @thesuperzapper Ich dachte, #4574 würde es ermöglichen, XGBoost mit Scala 2.11 und 2.12 zu kompilieren? In diesem Fall sollten wir XGBoost mit 2.11 kompilieren und JAR auf Maven hochladen.

ENTFERNT:

• [ ] GPU-Speicher nach dem Training freigeben #4668

Ich glaube nicht, dass wir jetzt dort hinkommen.

@thesuperzapper Es wird einfacher, gegen den Apache Spark Master (3.0)-Zweig und Scala 2.12 zu entwickeln, nachdem Spark eine 3.0-Vorschau veröffentlicht hat (die bald im Herbst geplant ist). Ich würde eine viel größere Verschiebung zu Scala 2.12 in der Spark-Community nach der endgültigen 3.0-Version (angestrebt für Anfang 2020) erwarten, aber Sie haben Recht, dass derzeit nicht viel 2.12 verwendet wird. Ich habe https://github.com/dmlc/xgboost/issues/4926 erstellt, um eine Diskussion über die bevorstehende Spark-Version anzuregen.

@CodingCat @thesuperzapper Ich dachte, #4574 würde es ermöglichen, XGBoost mit Scala 2.11 und 2.12 zu kompilieren? In diesem Fall sollten wir XGBoost mit 2.11 kompilieren und JAR auf Maven hochladen.

4574 erlaubt keine Cross-Compilierung.

Es erlaubt jemandem, den Code auszuchecken, die Scala-Version manuell zu überschreiben und neu zu kompilieren

Also kann jemand ein Glas mit 2.11 kompilieren und auf Maven hochladen
Ich hatte eine Pull-Anfrage mit Migration zu SBT, die eine Cross-Compilierung ermöglichen würde
Ich kenne auch den Trick, wie man eine Cross-Compilation in Maven unterstützt (wir haben es in unserer Firma verwendet). Kann ich bei Interesse teilen

@hcho3 Ist es möglich, CPack zu verwenden, um die Installation für OSX zu erleichtern? Bitte ignorieren Sie diesen Kommentar, wenn dies nicht möglich ist.

Unterstützt es das Lernen mit mehreren Zielen?

@douglasren Leider nein. Könnten Sie eine neue Ausgabe starten, damit wir sie besprechen können? Der Begriff "Mehrfachziel" kann je nach Kontext variieren, z. B. eine Zielfunktion für mehrere Outputs, mehrere Ziele mit einem Output oder mehrere Ziele mit mehreren Outputs?

Ich möchte auch meine Stimme für eine Zwischenveröffentlichung abgeben.

5146 behebt #4477.

ENTFERNT:

• [ ] PySpark-API-Unterstützung (https://github.com/dmlc/xgboost/issues/3370) (https://github.com/dmlc/xgboost/pull/4656) .

Eine Zwischenversion wäre toll, da die Installation von macOS derzeit noch mühsam ist

Können wir mit XGBoost4J-Spark dokumentierte Unterstützung für das Erlernen des Rangs (paarweise) erhalten? Derzeit gibt es keine konkrete Lösung für die Angabe von Trainingsdaten. Es gibt einige Verwirrung bezüglich der Partitionierung nach Gruppen-ID und Trainingsdaten, die derselben Partitionsstrategie folgen müssen, aber es ist ziemlich vage.
Ein Beispiel oder eine klare Dokumentation wäre wirklich hilfreich!

Ich möchte auch für eine Zwischenveröffentlichung meine Stimme abgeben. Wir freuen uns auf die nächste Version hauptsächlich wegen des fehlenden Wertefixes von

Gibt es eine Zeitschätzung für die nächste Veröffentlichung (Major oder Interim)?

PS: @thesuperzapper wir verwenden 2.11 und 2.12 und eine Zwischenversion wäre für uns extrem hilfreich

@hcho3 Können wir einen Release-Zweig erstellen und etwa eine Woche Zeit zum Testen haben?

Jawohl!

@hcho3 Zusätzlich zu einem Branch können wir auch einen offiziellen Release Candidate auf GitHub Releases

Das hört sich toll an! Freue mich schon sehr auf die nächste Veröffentlichung. Lass es mich wissen, wenn wir helfen können. Wir werden es auf jeden Fall bei Yelp testen.

Ich werde einen neuen Branch release_1.0.0 schneiden, nachdem https://github.com/dmlc/xgboost/pull/5248 zusammengeführt wurde. Vielen Dank an alle für Ihre Geduld.

Der Release Candidate ist jetzt für Python verfügbar: https://github.com/dmlc/xgboost/issues/5253. Sie können es heute versuchen, indem Sie laufen

pip3 install xgboost==1.0.0rc1

1.0.0 ist jetzt draußen:

pip3 install xgboost==1.0.0