The new DataGeometry objects allow users to apply the same sequences of operations (that were applied to old data) to new data. However, the parameters of those transformations are currently fit anew for the new data. Therefore it is still inelegant to map new data onto the same space as old data without refitting the model.
The fundamental challenge is that it is not always a straightforward process to fit the transformation parameters and then map new data onto a lower dimensional space. For example, the scikit learn dimensionality reduction functions (which hypertools.reduce wraps) don't have fully consistent APIs.
The two basic functions that would be useful to expose are:
model.transform: use a fitted model to map new data onto a lower dimensional spacemodel.inverse: take a low-dimensional representation and map it back onto the original high-dimensional feature space
In the long run, it would be nice to support both of these operations for all of the dimensionality reduction models we support in hypertools.reduce. However, as a compromise that might be relatively easy to implement, I suggest that we extend the DataGeometry object to include transform and inverse functions. We should (initially) only support the simplest cases where:
- No normalization is applied
- No alignment is applied
transform is set to either model.transform (if the transform function is supported for that model in scikit-learn) or a null "identity" function that just returns whatever data it's passed and outputs a warning message (if the transform function is unsupported for that model in scikit-learn, or if normalization or alignment have been applied to the data)inverse is set to either model.inverse_transform (if supported for that model in scikit-learn) or the null identity function (if the inverse_transform function is unsupported for that model in scikit-learn, or if normalization or alignment have been applied to the data)
I've compiled a list of which functions support the transform and inverse_transform methods: [LINK]
Eventually we can also support normalized data (by saving the normalization parameters) and aligned data (by saving the alignment parameters). Essentially we need to save enough so that we can invert those transformations. I don't think this would be fundamentally difficult, but we just need to think through the right way to implement it.
The new
DataGeometryobjects allow users to apply the same sequences of operations (that were applied to old data) to new data. However, the parameters of those transformations are currently fit anew for the new data. Therefore it is still inelegant to map new data onto the same space as old data without refitting the model.The fundamental challenge is that it is not always a straightforward process to fit the transformation parameters and then map new data onto a lower dimensional space. For example, the scikit learn dimensionality reduction functions (which
hypertools.reducewraps) don't have fully consistent APIs.The two basic functions that would be useful to expose are:
model.transform: use a fitted model to map new data onto a lower dimensional spacemodel.inverse: take a low-dimensional representation and map it back onto the original high-dimensional feature spaceIn the long run, it would be nice to support both of these operations for all of the dimensionality reduction models we support in
hypertools.reduce. However, as a compromise that might be relatively easy to implement, I suggest that we extend theDataGeometryobject to includetransformandinversefunctions. We should (initially) only support the simplest cases where:transformis set to eithermodel.transform(if thetransformfunction is supported for that model in scikit-learn) or a null "identity" function that just returns whatever data it's passed and outputs a warning message (if thetransformfunction is unsupported for that model in scikit-learn, or if normalization or alignment have been applied to the data)inverseis set to eithermodel.inverse_transform(if supported for that model in scikit-learn) or the null identity function (if theinverse_transformfunction is unsupported for that model in scikit-learn, or if normalization or alignment have been applied to the data)I've compiled a list of which functions support the
transformandinverse_transformmethods: [LINK]Eventually we can also support normalized data (by saving the normalization parameters) and aligned data (by saving the alignment parameters). Essentially we need to save enough so that we can invert those transformations. I don't think this would be fundamentally difficult, but we just need to think through the right way to implement it.