Skip to content

Conversation

@dwhswenson
Copy link
Member

Requested by @atravitz : more explanation of the need for the weird rounding we do in gather.

(Does this need a news entry? Can do if required.)

Checklist

  • Added a news entry

Developers certificate of origin

atravitz and others added 2 commits November 19, 2025 11:38
Co-authored-by: David W.H. Swenson <david.swenson@omsf.io>
@codecov
Copy link

codecov bot commented Nov 19, 2025

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.01%. Comparing base (f710d3c) to head (9b1e1ef).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1687      +/-   ##
==========================================
- Coverage   95.41%   93.01%   -2.41%     
==========================================
  Files         185      185              
  Lines       16045    16045              
==========================================
- Hits        15310    14924     -386     
- Misses        735     1121     +386     
Flag Coverage Δ
fast-tests 93.01% <ø> (?)
slow-tests ?

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

Co-authored-by: Alyssa Travitz <31974495+atravitz@users.noreply.github.com>
Copy link
Member

@IAlibay IAlibay left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for adding this @dwhswenson !

It has to be the uncertainty that determines the precision of the estimate, because if you said you had 3 significant figures in the estimate and used that to set the precision of the uncertainty, you'd have 12.3 +/- 0.0 -- no error at all!
We implement this by thinking of the decimal representation as "columns" centered on the decimal point.
We get the column index of the first non-zero number in the decimal representation of the uncertainty, and use the fact that ``np.round`` rounds to the number of decimal places you give it to report the estimate.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I might be misunderstanding what is being said here, but we only rely on np.round for cases where we go above decimal for rounding right? I.e. my understanding is that with negative columns we rely on string formatting, which is built-in round behaviour.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correct, we use string formatting to add trailing zeroes to the degree of precision we're reporting, which you can't do with floats and rounding.

@dwhswenson - correct?

@github-actions
Copy link

No API break detected ✅

@atravitz atravitz merged commit 20ae9f8 into main Nov 24, 2025
11 of 12 checks passed
@atravitz atravitz deleted the rounding-docstring branch November 24, 2025 15:16
@atravitz atravitz mentioned this pull request Dec 4, 2025
7 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants