scholar
                                
                                 scholar copied to clipboard
                                
                                    scholar copied to clipboard
                            
                            
                            
                        Shall we deprecate Scholar.Preprocessing?
Today the module only contain defdelegate to functions in other modules. Should we remove these delegations? Should we keep them?
@krstopro @msluszniak @polvalente
Given that each of these modules contains fit_transform/2, I think it is safe to deprecate/remove Scholar.Preprocessing. Only Binarizer module remains to be implemented.
Just my opinion, curious to see what the others think.
Yes, I agree that after moving the binarizer into a separate module we'll be able to delete Scholar.Preprocessing
There is another option here to remove the duplication:
- Remove the fit_transform functions from Scholar.Preprocesing.*modules
- Keep the current functions in Scholar.Preprocessingas thefit_transformvariant
But I don't like much because the documentation for supported options are all in the actual module. So we would either need a way to share the options or redirect users to a separate module, which is not the best user experience. I thought I'd mention it for completeness tho.
We might make a more general struct Preprocessing with two fields operation and data. For practical purposes, all functions will have fit and predict parts. Then using predict, based on the operation field, it will call the right function. However, this makes the fields like standard deviation in normalization less explicit.