@jbrea Thanks very much indeed for this fine contribution. It is clear you have invested considerable time wrapping your head around the MLJ model API.
My main comment on the interface is that in MLJ it is conventional to flatten out the various parameters in the structs, rather than bundle them into a single kwarg as you have here.
So,
mutable struct MyModel
alpha::A
beta::B
gamma::C
end
rather than
mutable struct MyModel{K}
kwargs::K
end
You could leave the struct as is, but then you would have to overload Base.getproperty/Base.properties/Base.setproperty! to make it appear as if the fields are flattened out. We have done this for composite model types, where the number of fields (component models) is variable, but it hardly seems worth your while here. Is there a reason for this?
It would be nice to implement clean! methods to do sanity checks on the parameters.
Otherwise, this looks good to go.
Next steps:
[ ] Move to JuliaAI ? Let me know and I can make you a member to enable transfer.
@jbrea Thanks very much indeed for this fine contribution. It is clear you have invested considerable time wrapping your head around the MLJ model API.
My main comment on the interface is that in MLJ it is conventional to flatten out the various parameters in the structs, rather than bundle them into a single
kwarg
as you have here.So,
rather than
You could leave the struct as is, but then you would have to overload
Base.getproperty
/Base.properties
/Base.setproperty!
to make it appear as if the fields are flattened out. We have done this for composite model types, where the number of fields (component models) is variable, but it hardly seems worth your while here. Is there a reason for this?It would be nice to implement
clean!
methods to do sanity checks on the parameters.Otherwise, this looks good to go.
Next steps: