-
-
Notifications
You must be signed in to change notification settings - Fork 1
Better workaround for predict_newdata_fast() #50
Copy link
Copy link
Open
Labels
internalsAffects internals, not user-facingAffects internals, not user-facingmlr3Issue related to (or caused by) upstream mlr3 behaviorIssue related to (or caused by) upstream mlr3 behaviorperformanceDoesn't make it more correct but faster or less memory hungryDoesn't make it more correct but faster or less memory hungry
Description
Metadata
Metadata
Assignees
Labels
internalsAffects internals, not user-facingAffects internals, not user-facingmlr3Issue related to (or caused by) upstream mlr3 behaviorIssue related to (or caused by) upstream mlr3 behaviorperformanceDoesn't make it more correct but faster or less memory hungryDoesn't make it more correct but faster or less memory hungry
Type
Fields
Give feedbackNo fields configured for issues without a type.
It provides a massive speed improvement which we definitely want in all methods where we use it, but due to mlr-org/mlr3pipelines#961 we have to anticipate it not being available for
GraphLearners, which I use for simple things likepo("removeconstants")or so in the benchmark comparing various methods on various tasks.When doing performance benchmarking I also need to take into account whether
predict_newdata_fast()was used or not.As an aside: Currently I think there's technically nothing that prevents things like
PFIor so to work with survival data, and sincepredict_newdata_fast()would need a dedicated implementation for survival learners, that's another edge case.