Jerry Ling
Jerry Ling
I got this comment from @vtjnash so maybe we should just return the original object, what do you think? But maybe the consideration is that, iterating the `copy()` shouldn't change...
that sounds good to me! I personally think `no-op` is okay, because I *think vast majority use cases are similar to when you want to do something in a different...
>then that is a violation of the copy API, which states that operations on b do not affect a ah ok we can't do `no-op`, so I think we know...
how can we improve this, it feels weird `xmin, xmax` for `hlines` and `ymin, ymax` for `vlines` are in scene coordinates. Can we add one more pair of arguments to...
if I have to guess I'd say all they are doing is saves you the trouble of manually one hot encoding a categorical columne into N columns of Bools?
I guess my question is what does XGBoost.jl do fundamentally when training / inference on large data -- is there a way to manually tell it to partition more finely?
```julia 106 function cross_train(df_all; model = XGBoostClassifier(; tree_method="hist", eta=0.08, max_depth=7, num_round=90), Nfolds=5) 107 y, eventNumber, X = unpack(df_all, ==(:proc), ==(:eventNumber), ∈(BDT_in put_names)) 108 eventNumber_modN = mod1.(eventNumber, Nfolds) 109 machines =...
``` 3292MiB / 16384MiB 5252MiB / 16384MiB 7468MiB / 16384MiB ... ``` setting `mach_bdt = machine(model, fold_X, fold_y; cache=false)` doesn't help, @ablaom do you have any suggestion? how to stripe...
according to https://github.com/JuliaAI/MLJBase.jl/issues/750 it doesn't fully remove reference to data somehow? But looks like it helps quite a lot at least w/ the "fix": ``` 2366MiB / 16384M # GC.gc()...