Repository navigation
Table Uncertainty Reporting #377
Description
It appears that process_table, and functions dependent on it, report estimate and uncertainty but not the the upper and lower estimates. These are usually more informative than the raw uncertainty values. I think that estimate_lower and estimate_upper should be output by process_table by default rather than uncertainty.
Allowing users to optionally report uncertainty in addition to, or instead of, estimate_lower/estimate_upper, would probably be valid.
I think this is a fairly simple fix.
Activity
Schiano-NOAA commentedon Sep 28, 2026
How do you think it would be best displayed? Couldn't the users easily calculate the upper and lower bounds using the uncertainty from the model?
We face issues where tables can become quite clunky when too many columns are present because headers get repeated to meet accessibility requirements. I think an example of what you are thinking would be helpful!
JZahner1 commentedon Sep 28, 2026
Sure, the user could calculate them themselves; but its a calculation that's already built into the data provided to
process_table. Seems like something that should be provided for convenience (also to ensure mistakes dont get made in calculating the upper/lower values).Large tables being clunky is a universal problem. When you refer to "repeating headers" you're referring to using the full "stddev_spawning_potential_ratio_ratio" style names correct? If so, is there a reason that has become the accepted way to meet accessibility requirements? It seems to me like assessment authors would always change those header names to something more human readable before they became part of a report.
I would be expecting to see a table that styled something like below (data is very fake):
Obviously if there are tons of grouping variables (fleets, sexes, regions, etc.) this starts to get more complicated.
This table could potentially be simplified as something like:
Just a thought.
Schiano-NOAA commentedon Sep 28, 2026
I am going to convert this to a discussion to get more input from people. This would require an overhaul of the current tables, but if it's something other regions would want, we can determine the best path forward.
Note: Many tables do need groupings which can be difficult and become hard to read.