You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
no, as a function with the EFD as an input (one thing I eventually want to play with is direct numerical encoding (as opposed to one-hot bins) and for that we'll need to be able to do things like normalize values for model input)
If having different encoding schemes for an ElementFeatureDescriptor object is an idea, should we also consider bringing back encode_f and decode_f fields?
Yeah, I guess we might need to do that, since otherwise a lot of the fields (nbins, logspaced, etc.) would become irrelevant...so maybe the encoding functions would just get automatically built via arguments to the constructor that specify the encoding?
there is appeal to always having them attached in terms of dispatching the encoding on just the abstract FD type rather than having to define it for each subtype
The text was updated successfully, but these errors were encountered: