You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The concept of column mappings was an early component of TAPE design, with the idea being that an Ensemble will know which columns map to known timeseries quantities. The benefits of this being that any (internal) operation that leverages these can use these columns without the user needing to specify a column name. We use these most heavily in Ensemble.batch, when using TAPE analysis functions where the difference is showcased here:
def tape_analysis_function(time, flux, error, band):
return result
ensemble.batch(tape_analysis_function)
Of course, the above only applies to TAPE analysis functions, and not any externally defined user functions. And a further downside is that ColumnMapping requires users to set up the mapping manually up front, before any data is loaded. And it's probably the most cumbersome component of setting up a new Ensemble workflow, with code looking like this:
This ticket is really just asking whether this is adding value to TAPE or not. @nevencaplar has had issues with it from a usability perspective. Do we think users would prefer to just deal with what operations are using what columns manually in all cases? In the future, we have had plans to build out the suite of default mappings for the major surveys. Where users of ZTF, LSST, PS1 data would only need to specify:
From LINCC-UP, the decision was made to deprecate column mapping, @dougbrn will investigate the scope of work needed in the internals to move away from it. Edit: It's possible we may actually keep this...
The concept of column mappings was an early component of TAPE design, with the idea being that an Ensemble will know which columns map to known timeseries quantities. The benefits of this being that any (internal) operation that leverages these can use these columns without the user needing to specify a column name. We use these most heavily in Ensemble.batch, when using TAPE analysis functions where the difference is showcased here:
Without Column Mapping:
With Column Mapping:
Of course, the above only applies to TAPE analysis functions, and not any externally defined user functions. And a further downside is that ColumnMapping requires users to set up the mapping manually up front, before any data is loaded. And it's probably the most cumbersome component of setting up a new Ensemble workflow, with code looking like this:
This ticket is really just asking whether this is adding value to TAPE or not. @nevencaplar has had issues with it from a usability perspective. Do we think users would prefer to just deal with what operations are using what columns manually in all cases? In the future, we have had plans to build out the suite of default mappings for the major surveys. Where users of ZTF, LSST, PS1 data would only need to specify:
In this case, we would still only be choosing some column set, and it's possible that users will want to choose different columns to map.
The text was updated successfully, but these errors were encountered: