Skip to content

Conversation

@xjules
Copy link
Contributor

@xjules xjules commented Dec 19, 2025

Issue
Resolves #12427

Approach
Make sure that the formatting stays raw for integers.
Floats will use notation with :g to keep the current state.

(Screenshot of new behavior in GUI if applicable)

  • PR title captures the intent of the changes, and is fitting for release notes.
  • Added appropriate release note label
  • Commit history is consistent and clean, in line with the contribution guidelines.
  • Make sure unit tests pass locally after every commit (git rebase -i main --exec 'just rapid-tests')

When applicable

  • When there are user facing changes: Updated documentation
  • New behavior or changes to existing untested code: Ensured that unit tests are added (See Ground Rules).
  • Large PR: Prepare changes in small commits for more convenient review
  • Bug fix: Add regression test for the bug
  • Bug fix: Add backport label to latest release (format: 'backport release-branch-name')

@xjules xjules self-assigned this Dec 19, 2025
@codecov-commenter
Copy link

codecov-commenter commented Dec 22, 2025

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.55%. Comparing base (7bdb6d2) to head (0f23f43).
⚠️ Report is 23 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main   #12535      +/-   ##
==========================================
- Coverage   90.58%   90.55%   -0.03%     
==========================================
  Files         435      435              
  Lines       29931    29943      +12     
==========================================
+ Hits        27112    27116       +4     
- Misses       2819     2827       +8     
Flag Coverage Δ
cli-tests 37.36% <100.00%> (-0.01%) ⬇️
gui-tests 68.64% <66.66%> (-0.01%) ⬇️
performance-and-unit-tests 73.92% <91.66%> (-0.02%) ⬇️
test 38.09% <0.00%> (-0.02%) ⬇️

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.

@xjules xjules force-pushed the fix_formatting branch 2 times, most recently from 33ebc62 to 49d268f Compare December 22, 2025 15:41
@codspeed-hq
Copy link

codspeed-hq bot commented Dec 22, 2025

Merging this PR will not alter performance

Summary

✅ 22 untouched benchmarks


Comparing xjules:fix_formatting (0f23f43) with main (a29328d)

Open in CodSpeed

if isinstance(value, int):
value_str = str(value)
elif isinstance(value, float):
value_str = f"{value:.6g}"
Copy link
Contributor

Choose a reason for hiding this comment

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

Are we sure we want this at .6g formatting? What will happen if the value is 1234.567464646?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I thought about that and it might get flaky without a precision; ie. .6g means we get always a correct rounding of the number. There are many corner cases though. Extra large and extra small numbers - not sure how realistic they are.

Copy link
Contributor

Choose a reason for hiding this comment

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

I am not sure this will fix the issue, as the issue is the cornercase when the number is very large. I did some querying and one number submitted by the user was 257382775096236763020404641646935773111

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yes, but that is an integer (very likely from the design matrix), which should get a correct handling as integer.

@jonathan-eq
Copy link
Contributor

Can we add the test from #12480?

@xjules
Copy link
Contributor Author

xjules commented Dec 23, 2025

We need an extra pair of eyes on this one: @oyvindeide

@berland
Copy link
Contributor

berland commented Dec 23, 2025

We do not want to round as far down as .6g:

>>> aa = 4.2431319809873098109
>>> print(f"{aa:.6g}")
4.24313

I would expect Ert to let me work with double precision floats.

@xjules
Copy link
Contributor Author

xjules commented Jan 5, 2026

We do not want to round as far down as .6g:

>>> aa = 4.2431319809873098109
>>> print(f"{aa:.6g}")
4.24313

I would expect Ert to let me work with double precision floats.

We need to round it for some decimals though; ie. tests, snapshots, etc
So what is the suggestion then?

@berland
Copy link
Contributor

berland commented Jan 5, 2026

We need to round it for some decimals though; ie. tests, snapshots, etc

Rounding for that purpose should be put in the test code.

So what is the suggestion then?

repr(value) or f"{value:.17g}". This will give us round-trip accuracy when going back with float().

@xjules
Copy link
Contributor Author

xjules commented Jan 5, 2026

repr(value)

will not work:

>>> e = 0.000000000000001
>>> repr(e)
'1e-15'

@xjules
Copy link
Contributor Author

xjules commented Jan 6, 2026

Follow up issue with floating precision: #12581

Copy link
Collaborator

@oyvindeide oyvindeide left a comment

Choose a reason for hiding this comment

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

LGTM, one minor comment.

"REAL": list(range(num_realizations)),
"a": a_values,
"category": 5 * ["cat1"] + 5 * ["cat2"],
"big_numbers": [1e10 + i for i in range(num_realizations)],
Copy link
Collaborator

Choose a reason for hiding this comment

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

Perhaps rename this to big_integer for clarity?

This makes sure that we treat integers in raw format, while floats will
remain with the existing scientific notation.
@xjules xjules merged commit a45f33f into equinor:main Jan 7, 2026
35 checks passed
@scout-team-app
Copy link

scout-team-app bot commented Jan 7, 2026

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

backport version-18.0 release-notes:bug-fix Automatically categorise as bug fix in release notes

Projects

None yet

Development

Successfully merging this pull request may close these issues.

DESIGN_MATRIX: Fix large integers get exported in scientific notation

5 participants