Open adam2392 opened 1 month ago
Notes:
To fix 2., we need to decouple the assumptions of the design with that of the oblique splitter, where storing all this stuff and iterating more than once has negligible cost.
Instead for MORF, we may want to instantiate a separate subclass that isn't an extension of oblique. Here, we want to store the "parameters" of the projection matrix per split since we need some way of indexing what was the "best split" and then getting all the relevant information needed in order to apply it. The current way of doing it leverages the fact that one can simultaneously iterate over projection_weights and projection_indices to obtain the feature value during predict
. So we should maybe piggyback that method, but we only store the final projection_indices and weights once we've selected the "best split".
To parameterize a split indices, we need the top left point and the corresponding patch dims. To parameters a split weight, we need the relevant kernel. In the naive case, this is just all values of "1". In the case of a gaussian kernel for instance, The # of non-zeros would correspond to the number of split indices. So we can either i) store the parameters of the gaussian kernel (mu, sigma, shape), ii) the full set of weights, or iii) the index of kernel in the pre-generated kernel dictionary (passed in by the user). Obviously we don't want to store the full sets of weights, so that's not viable. So i) and iii) seem most viable, where i) requires then one to write a function to generate the full kernel given the parameters, and iii) just requires keeping a reference to the original kernel dictionary generated by the user.
Reference Issues/PRs
Towards: #20 Closes: https://github.com/neurodata/treeple/pull/269
What does this implement/fix? Explain your changes.
Any other comments?