Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
fix bug in TuneWrapper for param in used in predict function, issue 2472 #2479
referenced this pull request
Nov 9, 2018
Some notes regarding my observation:
we should probably not rely on this; right now the parameter values are given both inside the
How would that happen (assuming the user does not directly modify the
You mean the ones being tuned over? It might be worth considering to remove the parameters found in the tuning param set from the wrapped learner's param set, so the user gets an error message when he tries to set a param that will be overwritten later.
I'm confused again, how would that happen? Does any part of
That is the architecture of mlr at the moment and we are relying on it everywhere. In
Like that, yes., ?
A warning somewhere might be useful. But I am afraid we would generate warnings for cases where we have set the par.vals in the definition of the learner. This can entail a lot of work.
My suggestion: We should merge this PR asap and can add convenience later.
Do you consider this to be a bug?
I would not call it a bug as it's just affecting some error message. But the whole code is strange. How do we know that it's really the wrong family that leads to NAs? But this is another issue and should not be discussed here.