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
While I see the motivation for the min_redshift/max_redshift/delta_redshift approach, after thinking about it a bit I think I favor instead having the user pass in a single redshifts keyword. My reasoning is that I know there are times I want to pass in a custom grid - e.g. logarithmic, or if I know I want a particular area of redshift to focus on but also have a broad grid. E.g. to capture "it's probably in a particular redshift where I think it is based on some other external dataset, but maybe it's an outlier and actually at a very different redshift". So given that requirement, I'd say just have a single redshifts keyword, but leave the min/max/delta in the documentation by doing np.arange(min_redshift, max_redshift, delta_redshift) and pass the result of that in as the redshift grid. That has the added advantage that if we later want to add a redshift fitting techinique (instead of this brute-force grid approach), we can pass that in via this keyword.
Also, I think it would be useful if these functions return the chi-squared of the other templates at their best-fit redshift, not just the best one. The reason why is that in the science cases I know for this you often have several templates, and sometimes it's not that clear which is the best one. So it's useful to see if there are several templates with roughly similar chi-squared, indicating that several are possible matches, or rather instead it's that there's one that's clearly better.
The text was updated successfully, but these errors were encountered:
Erik's points from PR #527 :
While I see the motivation for the min_redshift/max_redshift/delta_redshift approach, after thinking about it a bit I think I favor instead having the user pass in a single redshifts keyword. My reasoning is that I know there are times I want to pass in a custom grid - e.g. logarithmic, or if I know I want a particular area of redshift to focus on but also have a broad grid. E.g. to capture "it's probably in a particular redshift where I think it is based on some other external dataset, but maybe it's an outlier and actually at a very different redshift". So given that requirement, I'd say just have a single redshifts keyword, but leave the min/max/delta in the documentation by doing np.arange(min_redshift, max_redshift, delta_redshift) and pass the result of that in as the redshift grid. That has the added advantage that if we later want to add a redshift fitting techinique (instead of this brute-force grid approach), we can pass that in via this keyword.
Also, I think it would be useful if these functions return the chi-squared of the other templates at their best-fit redshift, not just the best one. The reason why is that in the science cases I know for this you often have several templates, and sometimes it's not that clear which is the best one. So it's useful to see if there are several templates with roughly similar chi-squared, indicating that several are possible matches, or rather instead it's that there's one that's clearly better.
The text was updated successfully, but these errors were encountered: