Comments (13)
The silent failure doesn't seem like good behavior to me, it might be worth opening an issue at xgboost. I was not able to find anything in the documentation about what it considers a valid version difference, and I am confused by the fact that there seem to be 3 different methods for dumping a model, only one of which is explicitly documented as not used for re-constructing the model.
I am re-opening this because this should not silently fail, it should either work or throw an error. As of right now we can't implement that in XGBoost.jl because I don't even know how to check whether libxgboost
thinks it's a compatible version.
from xgboost.jl.
I can't reproduce any problem with this on linux. Are you sure you are on latest? (XGBoost.jl
2.3.2
and XGBoost_jll1.7.6
)
that was it! I was on 2.3.1 on linux, just upgraded to 2.3.2 and the load with an empty DMatrix Booster works fine. Also tested the model replication on windows and predictions all work out correctly. Sorry for the confusion but we can close this.
from xgboost.jl.
FWIW, the example snippet from tests:
model_fname = "model.json"
bst2 = Booster(DMatrix[])
XGBoost.load!(bst2, model_fname)
results in an empty Booster when I load the JSON downloaded from Linux to Windows.
from xgboost.jl.
You should be able to load models saved with XGBoost.save
with XGBoost.load
. I was under the impression that save
would dump the object in a binary format, not a JSON.
Note also that whether or not the exported model is compatible across versions is up to libxgboost
, and I don't know what compatibility it claims, you can try checking the docs. Therefore, if you are still having problems, you should at least verify that the model exported with save
can be retrieved with load
on the same runtime. If that does not work it may be a bug. If it works within the same program, but not when exported to windows, it is likely that libxgboost
doesn't support exports across subtly different versions.
from xgboost.jl.
I went through the elimination process and the save/load procedure does work properly on the same runtime. It doesn't work properly when transporting from linux to windows - e.g., the booster remains empty after the load! command.
from xgboost.jl.
Also, if the xgboost version is exactly the same between the linux and windows machines, this might be a windows-specific bug.
If it's working in the Python and R wrappers, it ought to work here, I just don't know what's going on without knowing what those wrappers are doing.
from xgboost.jl.
Actually I did some more digging and am no longer confident the save/load! works in the linux runtime with an empty DMatrix. For example:
bst = xgboost(dtrain; watchlist=watchlist, params...)
model_fname = "../models/xgboost/xgboost_$(target)_$(replace(string(now()), ":" => "_"))_model.json"
XGBoost.save(bst, model_fname)
model_booster_2 = XGBoost.load!(XGBoost.Booster(DMatrix[]), model_fname)
XGBoost.load!(model_booster_2, model_fname)
julia> model_booster_2.feature_names
String[]
This works:
model_booster = XGBoost.Booster(dtest);
julia> model_booster.feature_names
108-element Vector{String}:
....
```
Unless I am missing something, this looks like a bug, or I am just using the functions the wrong way.
from xgboost.jl.
The feature names are expected not to be saved (this is something that should be documented but isn't). This is because the libxgboost
model object doesn't support them, so they have to be saved in the Julia object, and we don't write this to disk because then we'd have to come up with our own (incompatible) file format. The python wrapper documents that it behaves the same way for the same reason. The only reliable way that I'm aware of to check if the model object is being properly loaded is to check the output of predict
. This is unfortunate, but it's a constraint of the library we are wrapping.
from xgboost.jl.
@trivialfis , is there anything you can tell us about how we should be checking for this? Are we safe in assuming that if it loads without error then the library thinks it's a valid object? If that's the case there is likely a bug somewhere since @gyansinha couldn't load the object in windows, though I can't rule out that it's a windows-specific bug in the Julia wrapper.
from xgboost.jl.
The feature names are expected not to be saved (this is something that should be documented but isn't). This is because the
libxgboost
model object doesn't support them, so they have to be saved in the Julia object, and we don't write this to disk because then we'd have to come up with our own (incompatible) file format. The python wrapper documents that it behaves the same way for the same reason. The only reliable way that I'm aware of to check if the model object is being properly loaded is to check the output ofpredict
. This is unfortunate, but it's a constraint of the library we are wrapping.
If I try to use model_booster_2 with the dtest matrix, it runs without error - but returns zeros. That tells me that somewhere the prediction vector is allocated with zeros but then never properly assigned to.
from xgboost.jl.
@trivialfis , is there anything you can tell us about how we should be checking for this? Are we safe in assuming that if it loads without error then the library thinks it's a valid object? If that's the case there is likely a bug somewhere since @gyansinha couldn't load the object in windows, though I can't rule out that it's a windows-specific bug in the Julia wrapper.
@ExpandingMan note the last round of tests is on the linux runtimes for both save and load!.
from xgboost.jl.
from xgboost.jl.
I can't reproduce any problem with this on linux. Are you sure you are on latest? (XGBoost.jl 2.3.2
and XGBoost_jll 1.7.6
)
from xgboost.jl.
Related Issues (20)
- Package now requires a Julia built with GPL libraries enabled HOT 2
- early_stopping_rounds? HOT 18
- what is the role of sparse `DMatrix` constructors? HOT 24
- Can not reduce verbosity HOT 4
- Classification: Support multiple metrics HOT 9
- XGBoost rewrite on Julia using Metal.jl HOT 8
- question on XGBoost_jll HOT 3
- TreeSHAP, libxgboost, and implications for predict function HOT 10
- Update term.jl dependency HOT 3
- Add GPU tests with buildkite
- Quick question on Custom objective HOT 3
- xgboost failing with julia 1.8.5 HOT 22
- issue finding libomp popped up after updating environment HOT 1
- xgboost fails to find libxgboost HOT 13
- Watchlist error HOT 1
- `predict` overwrites previously returned predictions HOT 2
- Precompile fails on Julia 1.10 HOT 5
- Saving and reloading boosters using IOBuffer HOT 5
- Occasional segfaults on m1 apple silicon HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from xgboost.jl.