Anthony Blaom, PhD
Anthony Blaom, PhD
But I agree with @sylvaticus that it's worth special casing this algorithm which can deal with arbitrary column types.
No objection. @vollmersj
Looking good. 60% is great boost 🎉 > @ablaom for Integration tests I have added check Accuracy > value or should we use predict with random number to get reoccurring...
> Do we need tests for data loading functions? Couldn't hurt. Start with those with the most complex logic.
> - [x] select_sort > - [x] InvFeatureGen Where are these? I could not find them.
Thanks @jeremiedb for spending time wading through the PR and trying it out with EvoTrees. I've made some tweaks. Note that I've changed `LiteralTarget` to `Point`. And the data-slurping signatures...
Thanks for that suggestion. | No need for a separate fit implementation for transformers. I dunno. It seems like a non-trivial complication to the API. No separate `fit` means some...
Okay, here's a variation on your idea that doesn't require adding to the namespace. Each transformer implements one `transform` and one `fit`: ### Case 1: static (non-generalizing) transformers ```julia fit(strategy,...
### Case 2: generalizing transformers: ```julia fit(strategy, X) -> model # storing `learned_parameters` and any inspectable byproducts of algorithm transform(model, Xnew) -> transformed_Xnew # uses `model.learned_parameters` ``` with a convenience...
In #30 an implementation can explicitly overload `transform(strategy, data)` to provide a one-shot method with no issues. I think providing a universal fallback is a bad idea, as it could...