Xgboost: Das in 1.0.0 erstellte Modell kann nicht in 0.90 geladen werden

Haben Sie es mit install.packages('xgboost') versucht?

Haben Sie es mit install.packages('xgboost') versucht?

Das funktioniert gut, aber dann erzeugen alle Vorhersagen von gespeicherten Modellen (mit saveRDS) numeric(0). Es scheint, dass mit openMP trainierte Modelle auf Computern ohne dieses Framework nicht funktionieren. Meine Hoffnung war, dass das Kompilieren aus dem Quellcode dieses Problem lösen würde.

So kompilieren Sie XGBoost aus der Quelle:

mkdir build
cd build
cmake .. -G"Visual Studio 14 2015 Win64" -DR_LIB=ON
cmake --build . --target install --config Release

Können Sie die Modelldatei freigeben, damit wir herausfinden können, warum Sie eine 0 für die Vorhersage erhalten?

Danke - möchten Sie das R-Objekt oder möchten Sie es lieber über xgb.save.raw konvertieren?

Beide

Vielen Dank für Ihre Hilfe und Unterstützung (und für die Erstellung eines so außergewöhnlichen Lernprogramms).

Angehängt ist eine gezippte .rdata-Datei. Auf 3 Systemen (Mac, MacBook, Ubuntu) kann ich den folgenden Code ausführen:

modelList <- readRDS("<path_to_folder>/modelList.rdata")
attach(modelList)
predictions_caret <- predict(object=caretModel, newdata=caretModel$trainingData[,!colnames(caretModel$trainingData) %in% ".outcome"])
predictions_xgbbase <- predict(object=xgbModel, newdata=as.matrix(caretModel$trainingData[,!colnames(caretModel$trainingData) %in% ".outcome"]))

Und bekomme folgende Ausgabe:

> predictions_caret <- predict(object=caretModel, newdata=caretModel$trainingData[,!colnames(caretModel$trainingData) %in% ".outcome"])
[23:12:50] WARNING: ../..//amalgamation/../src/objective/regression_obj.cu:167: reg:linear is now deprecated in favor of reg:squarederror.
> head(predictions_caret)
[1] 14.0180358887 13.0352602005 12.9208145142 13.2430124283 13.6698570251
[6] 12.9033651352

> predictions_xgbbase <- predict(object=xgbModel, newdata=as.matrix(caretModel$trainingData[,!colnames(caretModel$trainingData) %in% ".outcome"]))
[23:16:17] WARNING: ../..//amalgamation/../src/objective/regression_obj.cu:167: reg:linear is now deprecated in favor of reg:squarederror.
> head(predictions_xgbbase)
[1] 14.0180358887 13.0352602005 12.9208145142 13.2430124283 13.6698570251
[6] 12.9033651352

Auf System 4 (Windows Base R mit installiertem xgboost von CRAN) erhalte ich sehr unterschiedliche Ergebnisse:

> predictions_caret <- predict(object=caretModel, newdata=caretModel$trainingData[,!colnames(caretModel$trainingData) %in% ".outcome"])
[23:18:04] WARNING: amalgamation/../src/objective/regression_obj.cu:152: reg:linear is now deprecated in favor of reg:squarederror.
> head(predictions_caret)
numeric(0)

> predictions_xgbbase <- predict(object=xgbModel, newdata=as.matrix(caretModel$trainingData[,!colnames(caretModel$trainingData) %in% ".outcome"]))
[23:18:41] WARNING: amalgamation/../src/objective/regression_obj.cu:152: reg:linear is now deprecated in favor of reg:squarederror.
> head(predictions_xgbbase)
numeric(0)

Ich vermute, dass hierfür möglicherweise ein neues Problem geöffnet werden muss, aber ich freue mich über jede Anleitung, die Sie geben können, warum sich derselbe Code auf verschiedenen Systemen unterschiedlich verhalten würde.

Schließlich ist xgbRaw enthalten (sollte aufrufbar sein, wenn Sie Attach () verwenden), es wurde mit dem folgenden Code generiert:

xgbRaw=xgb.save.raw(xgb.Booster.complete(caretModel$finalModel))

Vielen Dank noch mal.

modelList.rdata.zip

Wahrscheinlich aufgrund unseres dmlc-Schutzes gegen omp-Ausnahme?

@leedrake5 Unterstützt Ihr Computer OpenMP nicht?

@hcho3 Hast du die Ursache gefunden? Ich habe gerade XGBoost ohne OpenMP kompiliert (mit einigen Patches für CMakeLists), externe Speichertests schlagen wie erwartet fehl, auch sein paralleler Gruppentest schlägt fehl (was ich im lokalen Zweig behoben habe). Aber bisher kann ich perfekte Vorhersagewerte bekommen.

@hcho3 Mein Rechner unterstützt openmp. Aber wir setzen diese Modelle im industriellen Maßstab ein, und viele Computer an bestimmten Standorten haben kein OpenMP. Wir haben dies gerade nach 6 Monaten Vorbereitung und einer Woche bis zur Implementierung entdeckt, also versuchen wir herauszufinden, warum die Modelle auf einigen Computern funktionieren und auf anderen nicht.

Wenn es eine Philosophie darüber gibt, warum Modelle nur in ihrer Konstruktionsumgebung funktionieren sollten, gäbe es dann eine Möglichkeit, einen informativen Fehler darüber zu erhalten, warum?

@leedrake5 Es ist ein Fehler. Ich habe versucht, es auf Ubuntu mit deaktiviertem Openmp zu reproduzieren, aber bisher kein Glück.

@trivialfs Wenn es hilft, ich und die meisten meiner Kollegen haben den Fehler unter Windows. Obwohl ein Kollege von mir es ohne openmp auf Ubuntu reproduzieren konnte.

Ich vermute, dass eine minimale Installation von R ohne ausgefallene Dinge (openmp, intelmkl, openblas usw.) es reproduzieren kann, aber ich mache mir immer noch Gedanken darüber, welcher Teil des Systems Probleme verursacht.

@leedrake5 Wenn es eine Möglichkeit gibt, es auf Linux-Distributionen zu reproduzieren, wäre es eine große Hilfe!

Ich habe alle Optionen deaktiviert, einschließlich Google Test, omp ... Habe aber immer noch das richtige Ergebnis beim Laden Ihrer Modelle. Die Installation von R ist die Standardverteilung von apt , ich glaube nicht, dass es etwas mit der XGBoost-Vorhersage zu tun hat.

Es kann nicht an OpenMP liegen. Da selbst die Vorhersage wirklich schief geht, gibt es immer noch eine globale Verzerrung, nicht 0.

Der einzige Grund, der mir einfällt, ist, dass XGBoost nicht wirklich installiert ist. Ich denke, wir führen Tests auf CRAN durch, richtig? @hcho3

Ich habe sowohl CMake-Build als auch Autotools-Build ausprobiert. Dies sind meine Kompilierungs-Flags, die von install.packages(...) (Autotools-Build) gemeldet wurden:

g++ -std=gnu++11 -I"/usr/share/R/include" -DNDEBUG -I../..//include -I../..//dmlc-core/include -I../..//rabit/include -I../../ -DXGBOOST_STRICT_R_MODE=1 -DDMLC_LOG_BEFORE_THROW=0 -DDMLC_ENABLE_STD_THREAD=1 -DDMLC_DISABLE_STDIN=1 -DDMLC_LOG_CUSTOMIZE=1 -DXGBOOST_CUSTOMIZE_LOGGER=1 -DRABIT_CUSTOMIZE_MSG_ -DRABIT_STRICT_CXX98_    -DDMLC_CMAKE_LITTLE_ENDIAN=1 -pthread -fpic  -g -O2 -fdebug-prefix-map=/build/r-base-el7SHG/r-base-3.5.2=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -g -c ../..//amalgamation/xgboost-all0.cc -o ../..//amalgamation/xgboost-all0.o

@trivialfis Noch merkwürdiger, da XGBoost erfolgreich von CRAN installiert wird und die Bibliothek (xgboost) problemlos funktioniert.

Obwohl ein Kollege von mir es ohne openmp auf Ubuntu reproduzieren konnte.

Ist es möglich, dass er/sie freundlicherweise mitteilen kann, wie man sich reproduziert?

Obwohl ein Kollege von mir es ohne openmp auf Ubuntu reproduzieren konnte.

Ist es möglich, dass er/sie freundlicherweise mitteilen kann, wie man sich reproduziert?

Ich bin mir nicht sicher, ob sie genug darüber wissen, wie Linux-Systeme funktionieren - aber wenn Sie eine Diagnose kennen, die sie bereitstellen können, lassen Sie es mich wissen.

Ich für meinen Teil versuche, eine Ubuntu-Installation für virtuelle Boxen zu erstellen, die das Problem replizieren kann. Wenn dies erfolgreich ist, sende ich einen Download-Link dafür.

Ich habe das Problem unter Linux erfolgreich reproduziert – siehe beigefügten Screenshot.

Ich lade die virtuelle Box auf Dropbox hoch. Aber falls Sie es vorziehen, von Grund auf neu zu installieren, lauten die Anweisungen zum Replizieren wie folgt:

1. Laden Sie virtualbox herunter und installieren Sie es
2. Laden Sie einen Build von Ubuntu Bionic Beaver herunter (ich habe Ubuntu-18.04.3-Desktop-Amd64 verwendet).
3. Befolgen Sie die Anweisungen hier: https://medium.com/@mannycodes/installing -ubuntu-18-04-on-mac-os-with-virtualbox-ac3b39678602. Ich habe ein festes virtuelles 15-Gigabyte-Laufwerk verwendet
4. Konfigurieren Sie für R 3.6.2 wie folgt:

sudo apt-get update
sudo apt-get install vim
sudo vim /etc/apt/sources.list
i
deb https://cloud.r-project.org/bin/linux/ubuntu bionic-cran35/
<esc> :wq
gpg --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys E298A3A825C0D65DFD57CBB651716619E084DAB9
gpg -a --export E298A3A825C0D65DFD57CBB651716619E084DAB9 | sudo apt-key add -
sudo apt-get update
sudo apt-get install r-base-dev

1. Pakete in R installieren

install.packages(c("caret", "xgboost"))

1. Pakete in R laden

library(caret)
library(xgboost)

1. Laden Sie die Daten

modelList <- readRDS("~/Desktop/modelList.rdata")
attach(modelList)

1. Versuch einer Vorhersage

predict(object=xgbModel, newdata=as.matrix(caretModel$trainingData[,!colnames(caretModel$trainingData) %in% ".outcome"]))

Und dies gab das jetzt Vertraute zurück:

[13:00:55] WARNUNG: amalgamation/../src/objective/regression_obj.cu:152: reg:linear ist jetzt zugunsten von reg:squarederror veraltet.
numerisch(0)

Hinweis: Ich habe versucht, Bibliotheken explizit aufzurufen und nur die Vorhersage zu versuchen. Beide führten zu derselben numerischen (0) Antwort.

Der Link zur komprimierten virtuellen 7z-Instanz ist hier: https://www.dropbox.com/s/ld06zz798m0segf/UbuntuDebug.7z?dl=0

Lassen Sie mich zuerst eine virtuelle Box erhalten. Ich benutze normalerweise KVM.

Betrachte das jetzt.

@leedrake5 Ich konnte das Problem auf der von Ihnen bereitgestellten virtuellen Maschine reproduzieren. Es scheint ein Problem mit saveRDS und xgb.save.raw zu geben. Haben Sie stattdessen versucht, xgb.save und xgb.load zu verwenden? Dieser Funktionssatz verwendet das „native“ Format des XGBoost-Modells und speichert keine Attribute, die spezifisch für die R-Umgebung sind. Es ist nützlich, wenn Sie Ihr Modell von einem R-Paket nach Python übertragen möchten.

Das Save Raw sollte kein Problem sein. Das Problem könnte darin liegen, wie R den R-Code serialisiert. Wir haben einen neuen optionalen Parameter zur Vorhersage hinzugefügt, der sich auf das Laden dieser Art von Serialisierung auswirken könnte. Ich habe versucht, es zu untersuchen, scheint aber wirklich skurril zu sein, genau wie das Problem mit Python Pickle.

@trivialfis irgendwelche Ideen zu Optionen in der Vorhersagefunktion, die dies möglicherweise umgehen könnten? Mein Gedanke ist, dass es etwas mit CPU-Anweisungen zu tun hat, möglicherweise tiefer in R, als durch das Paket adressiert werden kann.

@hcho3 Ich werde versuchen, xgb.save.raw zur aktuellen Datenpipe hinzuzufügen und zu sehen, ob das hilft. In dem von mir gesendeten Beispiel habe ich dies jedoch versucht, indem ich xgb.save.raw auf dem Computer verwendet habe, auf dem Vorhersagen funktionierten, und es führte leider immer noch zu numeric(0) auf xgb.load. Zugegeben, das war, nachdem das Modell bereits über saveRDS gespeichert worden war, vielleicht beschädigt es etwas an diesem Prozess, obwohl es immer noch in der Umgebung funktioniert, in der es erstellt wurde.

Soweit ich das beurteilen kann, gibt es immer noch etwas in der Umgebung, in der das Modell erstellt wurde, das in jeder Umgebung, in der es verwendet wird, vorhanden sein muss. Ich weiß aber nicht, was es ist.

Nein, ich meinte xgb.save , nicht xgb.save.raw .

@trivialfis Beachten Sie, dass das XGBoost-Paket auf CRAN immer noch 0,90 ist.

Ich habe xgb.save ausprobiert, es über xgb.load() in R geladen und dasselbe, numeric(0). Siehe Anhang von xgb.save

xgbModelSaved.xgb.zip

Außerdem wurde dieselbe Methode mit den Daten in modelList weiter oben in diesem Thread auf demselben Computer getestet, auf dem das Modell generiert wurde - dort funktionierte es.

Egal, wie Sie es aufteilen, xgb.save, xgb.save.raw, saveRDS usw., es gibt etwas in der Computerumgebung, in der das Modell erstellt wurde, das seine Verwendung an anderer Stelle ausschließt.

Ich kann das Problem anhand der von Ihnen bereitgestellten Modelldatei reproduzieren. Ich habe jedoch keine Ahnung, wie die Modelldatei generiert wurde. Können Sie mehr Kontext bereitstellen, z

• Betriebssystem
• XGBoost-Version
• Befehl zum Speichern des Modells

OS X (Catalina). XGBoost-Build aus Quelle, 1.0 (openMP wird auf dem System unterstützt). Modell ursprünglich mit saveRDS gespeichert. Ich werde versuchen, es erneut auszuführen und auf verschiedene Arten zu speichern, und dann Bericht erstatten.

Ich habe ein Modell von Grund auf neu generiert, es mit xgb.save gespeichert (z. B. keine Verwendung von saveRDS oder readRDS außer für Vorhersagedaten) und mit xgb.load geladen. Gleiche Ergebnisse – die Vorhersage funktioniert auf dem Computersystem, das zum Generieren des Modells verwendet wurde (OS X, XGB 1.0), und schlägt auf einem anderen System fehl (Windows 7, XGB 0.9). Hängen Sie es und die modelList an diese Nachricht an. Wenn ich sonst noch etwas tun kann, um dieses Problem zu diagnostizieren, lassen Sie es mich bitte wissen.

xgb_model <- xgb.load("Z:/Desktop/newxgbModelSaved.xgb")
modelList <- readRDS("Z:/Desktop/modelList2.rdata")
attach(modelList)
predict(object=xgb_model, newdata=as.matrix(caretModel$trainingData[,!colnames(caretModel$trainingData) %in% ".outcome"]))
numeric(0)

newxgbModelSaved.xgb.zip

modelList2.rdata.zip

@leedrake5 Ist es möglich, XGBoost 1.0 unter Windows zu verwenden?

@trivialfis Dies könnte ein Problem mit der Abwärtskompatibilität von Modelldateien sein.

Es ist definitiv die Versionierung. Ich habe gerade Version 1.0 von XGBoost vorbeigeschaut, Version 0.9 von CRAN installiert und die oben beschriebene Methode hat funktioniert.

Ich habe versucht, 0.90 aus dem Quellcode mit der neuesten Version zu installieren, aber der Ordner dmlc-core ist leer, sodass Cmake den erforderlichen Fehler ausgibt. Würde gerne die OpenMP-Funktionalität beibehalten, wie auch immer das geht.

Ich verstehe. Haben Sie versucht, Version 1.0.0 unter Windows zu installieren?

Seltsamerweise war das der ursprüngliche Grund für diesen Thread. Werde es versuchen, aber es wird eine Verzögerung geben, da das Projekt nicht länger warten kann. Wenn dies ein Problem ist, vermute ich, dass die Installation von 1.0 aus der Quelle auf dem virtuellen Ubuntu-Image, das ich gesendet habe, dasselbe Problem lösen würde.

@leedrake5 Ja, Sie sollten mit der Version von XGBoost übereinstimmen. Verwenden Sie entweder überall 0.90 oder überall 1.0.0.

@trivialfis Ich erinnere mich, dass wir eine bahnbrechende Änderung im binären Modellformat vorgenommen haben. Ist das richtig?

Nein, wir sind abwärtskompatibel, 1.0 sollte auf jeden Fall das Modell von 0.9 laden

@trivialfis Danke für die Klarstellung. In diesem Fall behandeln wir dieses Ticket als Fehler, da wir Abwärtskompatibilität erwartet und ein Gegenbeispiel gefunden haben. Ich werde es mir diese Woche anschauen.

Ich denke, die vorgeschlagene Titeländerung ist rückwärts gerichtet - das in 1.0 erstellte Modell kann nicht zur Vorhersage in 0.90 verwendet werden. Ich weiß nicht, welcher Kompatibilitätsgrad zwischen den Versionen beabsichtigt ist, aber zumindest ein informativer Fehler sollte helfen.

Ups, mein Fehler.

@trivialfis Ich glaube, was @leedrake5 verlangt, ist die Aufwärtskompatibilität, dh das Laden des Modells von 1.0.0 in 0.90. Ich bin mir nicht sicher, ob wir das versprechen.

@leedrake5 Ich habe versucht, 1.0.0 in der virtuellen Ubuntu-Maschine zu installieren, und jetzt wird die RDS-Datei einwandfrei geladen und ich erhalte einen Vektor mit reellen Zahlen. Also liegt es höchstwahrscheinlich am Versionsproblem.

BEARBEITEN. Die Warnmeldung im Screenshot ist seltsam: Loading model from < 1.0.0, consider saving it again . Dies sollte nicht hier sein, da das Modell von 1.0.0 produziert wurde.

Ich stimme zu. Sehr froh, Konvergenz zu setzen, was das Problem ist.

Leider muss ich aus Produktionssicht Modelle in der Massenversion (also CRAN-Installation) einsatzfähig machen. Aber ich weiß, wie man XGBoost von jetzt an zum Laufen bringt, was der absolut kritische Punkt ist.

Ich habe immer noch Probleme bei der Installation von 0.9 aus der Quelle, die von Releases oder dem Baum heruntergeladen wurde, aber ich glaube, ich habe das Problem gefunden. cub, dmlc-core, rabit, alle sind leere Ordner in diesen Downloads. Sie haben auch @nach den Ordnern - ich denke, das hängt damit zusammen, welche Ordner leer sind. Wenn ich diesen Links folge, kann ich Ordner neu erstellen und die Installation fortsetzen.

Siehe Screenshot:

Ja, wir verwenden Git-Submodule, daher werden Sie in der Build-Anweisung aufgefordert, git clone --recursive zu verwenden, um von der Quelle zu installieren. Befinden Sie sich in einer Situation, in der die CRAN-Installation unzureichend ist? Wenn die Verwendung von 0.90 überall Ihr Problem behebt, könnten Sie einfach CRAN install überall verwenden (Linux, Mac, Windows)?

Ja – CRAN erlaubt kein openMP, was für die Modellgenerierung ein großer Segen ist. Ich werde also einige Zeit damit verbringen, herauszufinden, wie xgboost 0.90 aus dem Quellcode kompiliert werden kann, damit es wieder funktioniert. Ich danke Ihnen für Ihre Hilfe bei der Diagnose dieses Problems.

@leadrake5

Habe es. Im Moment ist hier der Befehl, mit dem Sie den vollständigen Quellcode einschließlich der Git-Submodule abrufen können:

git clone --recursive https://github.com/dmlc/xgboost -b release_0.90

Dies sollte den XGBoost-Quellcode abrufen und die Verzeichnisse rabit, cub, dmlc-core füllen. -b release_0.90 wird verwendet, um die Version 0.90 zu erhalten, nicht die neueste.

Beiseite:

CRAN erlaubt kein openMP

Dies ist tatsächlich in 1.0.0 behoben. Ich werde versuchen, bald die Version 1.0.0 auf CRAN zu bekommen.

Vielen Dank, sehr geschätzt in allen Punkten!

@hetong007 Können wir 1.0.0 bei CRAN einreichen?

@hcho3 Klingt gut, vorausgesetzt, wir haben eine gültige Endian-Erkennung. Ich werde in einer Woche einen Antrag stellen.

@hetong007 Irgendwelche Updates? Lassen Sie mich wissen, wenn ich irgendwie helfen kann.

@hcho3 oh ja. Ich möchte fragen, ob wir die Umgebung für Solaris-Tests haben? Es gibt einen ungelösten Fehler auf Solaris ab 0.9: https://www.r-project.org/nosvn/R.check/r-patched-solaris-x86/xgboost-00check.html Ich möchte ihn vorher überprüfen lassen Vorlage.

@hetong007 Ich habe gerade ein Solaris-VM-Image von Oracle heruntergeladen, das mit VirtualBox ausgeführt werden kann. Lassen Sie mich versuchen, das Problem zu reproduzieren.

@hetong007 Ich habe viele Probleme beim Einrichten der R-Umgebung in Solaris. Insbesondere kann ich keine R-Pakete wie igraph und testthat installieren, da sich Dienstprogramme wie awk unter Solaris anders verhalten. Ich habe keine Ahnung, wie ich weiter vorgehen soll.

@hcho3 Würdest du bitte klarer sein? Ich stelle mir vor, man könnte Pakete in der R-Konsole mit install.packages('testthat') installieren, vorausgesetzt, dass testthat die Solaris-Prüfung auf CRAN bestanden hat.

@hetong007 Das Paket igraph verwendet awk im Konfigurationsschritt, und awk Solaris ist nicht funktionskompatibel mit GNU awk. Es ist möglich, GNU awk zu installieren, aber es heißt gawk . Versuchen Sie immer noch herauszufinden, wie Sie R dazu bringen können, gawk anstelle von awk zu verwenden.

@hcho3 OK, das klingt schrecklich. Ich habe auch keine Ahnung, wie ich weiter vorgehen soll. Ich habe mir gerade die Ergebnisseite igraph auf CRAN angesehen: https://cran.r-project.org/web/checks/check_results_igraph.html. Fühlt sich an, dass es uns nicht schlechter gehen wird. Ich melde mich trotzdem.

@ hetong007 Danke. Ich werde versuchen, irgendwann auf Solaris-Tests zurückzukommen. Ich bin sicher, es gibt einen Weg.

@hetong007 Ah ja, stellen Sie sicher, dass Sie beim Einreichen des Codes den Zweig release_1.0.0 verwenden.

@hcho3 Die Vorabprüfung warnt:

* checking whether package 'xgboost' can be installed ... WARNING
Found the following significant warnings:
  amalgamation/../src/common/hist_util.cc:666:72: warning: 'void* memset(void*, int, size_t)' clearing an object of non-trivial type 'struct xgboost::tree::GradStats'; use assignment or value-initialization instead [-Wclass-memaccess]
See 'd:/RCompile/CRANguest/R-devel_gcc8/xgboost.Rcheck/00install.out' for details.

und die 00install.out -Datei ist hier (verfügbar in ~72 Stunden): https://win-builder.r-project.org/v6XJQBjzgMaW/00install.out

Wäre eine schnelle Lösung möglich?

@hetong007 Ist das ein Blocker? Memset wurde verwendet, um das Nullstellen des Histogramms (Array of Structure) zu beschleunigen. Wenn dies CRAN blockiert, werde ich einen Makrowächter setzen, damit das R-Paket stattdessen den normalen Konstruktor verwendet.

@hcho3 Ja, es ist ein Blocker. Die Vorabprüfung ist automatisiert und die Einreichung sollte ohne Vorwarnung bestanden werden. Das Makro klingt gut genug, danke!

@hcho3 Könnten Sie bitte zuerst versuchen, std::fill zu verwenden? Selbst der Compiler kann es möglicherweise nicht in memset optimieren, ich denke nicht, dass es kritisch genug ist, um sichtbare Auswirkungen auf die Leistung zu haben.

@hetong007 Ich habe die notwendige Änderung vorgenommen (https://github.com/dmlc/xgboost/commit/3550b16a34055bc8ec33bf0b7006448e8c1a4eca). Kannst du es nochmal versuchen?

@trivialfis Ich werde eine separate Pull-Anforderung einreichen, um memset zu ersetzen.

@hcho3 danke für die Lösung! Wenn nichts Gravierendes schief geht, ist es auf dem Weg zu CRAN.

@hcho3 Also schlägt es auf Soalris fehl, von Prof. Ripley:

On Solaris it was quicker to diagnose the problems with the GCC compilers:

amalgamation/../src/common/io.cc:120:27: error: ‘POSIX_FADV_SEQUENTIAL’
was not declared in this scope
    posix_fadvise(fd, 0, 0, POSIX_FADV_SEQUENTIAL);

amalgamation/../src/common/io.cc:120:48: error: ‘posix_fadvise’ was not
declared in this scope
    posix_fadvise(fd, 0, 0, POSIX_FADV_SEQUENTIAL);

As 'Writing R Extensions' told you, you need to use configure to test
for the presence of non-standard C/C++ functions.  In this case, it
seems that line is not actually necessary.

@ hetong007 Schön. Bitte sagen Sie Prof. Ripley Danke, dass Sie sich die Zeit genommen haben, das Problem zu debuggen. Ich werde fortfahren und diese Zeile so schützen, dass sie nur in der richtigen Linux-Umgebung ausgeführt wird, da wir nur über eine geeignete Testeinrichtung verfügen, um XGBoost mit Windows und Linux zu testen. Im Idealfall sollten alle nicht standardmäßigen C++-Einrichtungen nicht verwendet werden, es sei denn, sie werden zuerst als Teil von CI getestet. Ich muss auch die Codebasis nach anderen nicht standardmäßigen C++-Features durchsuchen und versuchen, sie ebenfalls zu entfernen. cc @trivialfis

@hcho3 klingt gut für mich. Die Frist von Prof. Ripley für eine neue Einreichung bei CRAN ist der 06.04.2020. Wenn Sie an einem detaillierten Installationsprotokoll interessiert sind, besuchen Sie bitte https://cran.r-project.org/web/checks/check_results_xgboost.html

@hetong007 Der Commit https://github.com/dmlc/xgboost/commit/d83db4844bae5969609e58cd6bb201e7831cfaa3 sollte das Problem beheben. Ich habe es endlich geschafft, das neueste R mit meiner Solaris-VM zum Laufen zu bringen und CRAN-Prüfungen für XGBoost auszuführen.

@hcho3 Genial ! Kann ich es nehmen, da Sie es auf Solaris geprüft haben?

Ja, wir sollten es jetzt einreichen.

Hallo, ich stehe vor ähnlichen Problemen mit Python. Ich habe das Modell über xgboost 1.0.1 gespeichert und über xgboost 0.9 geladen, und die Vorhersagen sind leere Listen. Da unsere Produktionsumgebung xgboost 0.9 verwendet, frage ich mich, ob es eine Möglichkeit gibt, ein über xgboost-1.0 gespeichertes Modell in xgboost 0.9 zu laden.

@hcho3 Gibt es eine Möglichkeit, Ihren Schnappschuss zu teilen? Es ist auch für unsere weitere Vorlage wertvoll.

@sunhs Ich stehe auch vor einem ähnlichen Problem. Konntest du das lösen?

@giladmaya Nein Mann. Nachdem ich mehrere Methoden ausprobiert hatte, entschied ich schließlich, dass ich durch das erneute Trainieren des Modells Zeit sparen konnte.

Schluss damit, da wir nicht versprechen können, dass Modelle neuerer Versionen von älteren Versionen unterstützt werden. Es ist, als würde man eine PlayStation 4 kaufen und versuchen, ein für PlayStation 5 entwickeltes Spiel zu laden.

Wir versprechen nur Abwärtskompatibilität, sodass Sie Modelle mit der alten Version speichern und mit einer neuen Version wieder laden können. Dadurch kann sich das Modellformat im Laufe der Zeit schrittweise weiterentwickeln.