make core algorithm a self.variable. #818
Comments
|
customizing the algorithm is nice but i don't see why it should be stored as a mutable field of |
|
@lostanlen so then I could do without having to redefine scattering function. |
saved you one line |
|
Is there a big software no no against storing the algorithm as a mutable field? |
Actually, Im not quite sure this is the solution i want. you need to redefine some logic present in the scattering function. |
|
Hm, i don't know. Then yes, a field for the algorithm is needed: (just like for Maybe refactor def scattering(self, input, sc_algorithm):
self.check_input(input)
phi, psi = self.load_filters()
x = self.pad(input)
S = sc_algorithm(x, self.pad, self.unpad, self.backend ... )
return self.format(S) in this way, we'd be exposing new utility functions (check_input, pad, format ...) to potential future core modules (wavelets, phase harmonics ...) |
|
Are you saying we store a function as an attribute (a sort of callback)? I'm not convinced this is a good idea. The way we currently extend the classes is using inheritance. Adding another way of modifying the core behavior of the classes would just cause confusion, I think. |
Currently in each specific deep learning framework's frontend we import from core the
ScatteringnDalgorithm and call it.It would be a nice change for power users if we instead imported the algorithm in the base frontend and defined a variable to contain the call i.e.
self.scatteringalgo = scatteringnd. then in each specific frontend, the call to the algorithm would be given byself.scatteringalgo. This would allow power users to define a breadth first search algorithm #798 , or define their own scattering implementation where they can retrieve coefficients #445 (tho, these futures should be one day in our code base, please see #735).The text was updated successfully, but these errors were encountered: