some `ElementFeature` convenience functions about chemistryfeaturization.jl HOT 5 OPEN

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

from chemistryfeaturization.jl.

pull all possible values (categorical) or range (continuous) of encodable values

Without actually creating an ElementFeatureDescriptor object?

from chemistryfeaturization.jl.

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)

from chemistryfeaturization.jl.

If having different encoding schemes for an ElementFeatureDescriptor object is an idea, should we also consider bringing back encode_f and decode_f fields?

from chemistryfeaturization.jl.

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?

from chemistryfeaturization.jl.