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 compute_presence function allows users to pass whether they want the output as a ration or percent, but the SpectralTimeModel report from strings.py always prints the %, regardless of the output flag.
So we either need to change the report, or just pick one presence reporting style and stick with it.
I'm inclined to vote for the latter, since "80%" is less ambiguous than (0.80), people can divide by 100 if they really want, and fewer options to track is better if they're not critical for the method or understanding.
The text was updated successfully, but these errors were encountered:
Oops, good catch - the compute_presence has output settings, but the reports were inconsistent in defining which output they used, even though they were set up to take percents. The easy fix for the literal error is to male the SpectralTimeModel report set the presence output just like the Event model does - which is done in #341
I also agree on picking on presence reporting standard - though the string outputs are now consistent between model types, there's an inconsistency between the string report using % and the plot using ratio (see fe.report output here), which is no good in terms of consistency.
If we prefer the % then the quick fix is to update the event presence plot to use percent - does that sound good? We could also optionally also simplify the output types of compute_presence, but as a 'behind the scenes' function, I don't think it matters much if it defines 1 or 2 output types.
The
compute_presence
function allows users to pass whether they want the output as a ration or percent, but theSpectralTimeModel
report from strings.py always prints the %, regardless of theoutput
flag.So we either need to change the report, or just pick one presence reporting style and stick with it.
I'm inclined to vote for the latter, since "80%" is less ambiguous than (0.80), people can divide by 100 if they really want, and fewer options to track is better if they're not critical for the method or understanding.
The text was updated successfully, but these errors were encountered: