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
Currently rail_lephare produces several intermediate files as part of the Inform stage. These files are saved to disk and read in during the Evaluation stage using environmental variables that define their parent directory locations.
This isn't typical in RAIL - usually the model file would contain all of the information (with the exception of input data) that is required for redshift estimation. Often running the inform stage for other algorithms is computationally intensive and thus, it is convenient to be able to share the resulting single model file easily.
However, rail_lephare's inform stage is relatively lightweight, so the benefit of packaging everything into the model file (as well as writing and maintaining the output/input code to support that) isn't as clear.
It probably makes sense to wait a bit to better understand the way that users will typically interact with rail_lephare to determine if this is work would be helpful. If users don't mind running the inform stage prior to each estimate stage, then doing this work probably isn't as useful. Alternatively if repeatedly running the inform stage becomes a burden, then some way of packaging all intermediate data for portability will become more important.
The text was updated successfully, but these errors were encountered:
Currently rail_lephare produces several intermediate files as part of the
Inform
stage. These files are saved to disk and read in during theEvaluation
stage using environmental variables that define their parent directory locations.This isn't typical in RAIL - usually the model file would contain all of the information (with the exception of input data) that is required for redshift estimation. Often running the inform stage for other algorithms is computationally intensive and thus, it is convenient to be able to share the resulting single model file easily.
However, rail_lephare's inform stage is relatively lightweight, so the benefit of packaging everything into the model file (as well as writing and maintaining the output/input code to support that) isn't as clear.
It probably makes sense to wait a bit to better understand the way that users will typically interact with rail_lephare to determine if this is work would be helpful. If users don't mind running the inform stage prior to each estimate stage, then doing this work probably isn't as useful. Alternatively if repeatedly running the inform stage becomes a burden, then some way of packaging all intermediate data for portability will become more important.
The text was updated successfully, but these errors were encountered: