Skip to content

Conversation

jakobjakobson13
Copy link
Contributor

@jakobjakobson13 jakobjakobson13 commented Dec 11, 2022

Reference issue

Closes gh-11341, closes gh-11345 and closes gh-14467.

What does this implement/fix?

Exact values of the CODATA constant set are calculated for bigger precision

Additional information

This is just a follow up on the abandoned gh-11345 and credits for the working parts go to @pv (The broken bits are my mistake.)

@jakobjakobson13 jakobjakobson13 changed the title MAINT: Recalculation of exact values MAINT: Recalculation of exact constants Dec 11, 2022
@tupui tupui added enhancement A new feature or improvement scipy.constants labels Dec 11, 2022
@tupui tupui added this to the 1.11.0 milestone Dec 11, 2022
@jakobjakobson13 jakobjakobson13 marked this pull request as ready for review December 12, 2022 22:19
Copy link
Member

@tupui tupui 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 the work! It's in good shape now, just some minor things with the linter.

@jakobjakobson13
Copy link
Contributor Author

Thanks for the work! It's in good shape now, just some minor things with the linter.

@tupui Could you take a look at the linter/formatting issues? I don´t know how to handle them.

Copy link
Member

@tupui tupui left a comment

Choose a reason for hiding this comment

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

I did a few suggestions to fix the linter. For some lines too long in _codata it's ok to let it complain.

elif is_exact:
exact[name] = val
else:
assert not is_truncated
Copy link
Member

Choose a reason for hiding this comment

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

Here and elsewhere:
Is this for control flow? If yes, could you replace these with proper exceptions? The issue is that assertions are missing if someone use python -O

jakobjakobson13 and others added 6 commits December 13, 2022 18:55
Co-authored-by: Pamphile Roy <roy.pamphile@gmail.com>
Co-authored-by: Pamphile Roy <roy.pamphile@gmail.com>
Co-authored-by: Pamphile Roy <roy.pamphile@gmail.com>
Co-authored-by: Pamphile Roy <roy.pamphile@gmail.com>
Co-authored-by: Pamphile Roy <roy.pamphile@gmail.com>
Co-authored-by: Pamphile Roy <roy.pamphile@gmail.com>
Comment on lines 1642 to 1644
raise Exception("Parsing error")
except Warning as w:
raise Warning(f"{name} is truncated but not exact.") from w
Copy link
Member

@tupui tupui Dec 23, 2022

Choose a reason for hiding this comment

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

About the exceptions, we should try to raise informative types of exceptions for the users, instead of Warning, it's more something like a ValueError that we might need.

For internal exceptions, we should also be more specific and not use a bare Exception. This to help prevent catching something else.

Lastly and this is a bit more work, we should test any new exception which we add. Our current policy is to do the following in Pytest:

message = r"Message in the exception"
with pytest.raises(ValueError, match=message):
    ...  # code that will raise

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Okay, I'll try to get to it at some other day.

Copy link
Member

Choose a reason for hiding this comment

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

Thank you 🙇 No rush at all.

@jakobjakobson13
Copy link
Contributor Author

The tests show the intended error messages but I admit that the whole pull request became such a mess that I'm not sure if I made it better or worse. So, before you merge it, please perform a very, very thorough review.

@h-vetinari h-vetinari modified the milestones: 1.11.0, 1.12.0 May 20, 2023
@jakobjakobson13
Copy link
Contributor Author

@lucascolley
Regarding your latest post in #11345: Unfortunately I won´t have the time to check the pull requests thoroughly in the next weeks.

@lucascolley lucascolley modified the milestones: 1.12.0, 1.13.0 Nov 19, 2023
@lucascolley
Copy link
Member

Unfortunately I won´t have the time to check the pull requests thoroughly in the next weeks.

Thanks a lot for the quick response. I've bumped the milestone on the assumption that no maintainers are looking to give the "very, very thorough review" and finish this in the next few weeks.

@lucascolley lucascolley modified the milestones: 1.13.0, 1.14.0 Mar 12, 2024
@lucascolley lucascolley changed the title MAINT: Recalculation of exact constants MAINT: constants: recalculation of exact constants May 18, 2024
@tylerjereddy
Copy link
Contributor

no maintainers are looking to give the "very, very thorough review" and finish this in the next few weeks.

Probably not, and I'm hoping we don't have to wait weeks before I branch 1.14.0, so I'm going to bump the milestone again, apologies!

@tylerjereddy tylerjereddy modified the milestones: 1.14.0, 1.15.0 May 26, 2024
@jakobjakobson13
Copy link
Contributor Author

Probably not, and I'm hoping we don't have to wait weeks before I branch 1.14.0, so I'm going to bump the milestone again, apologies!

Don't worry, I'm currently occupied with other things with a higher priority for me.

Comment on lines 1 to 7
from numpy.testing import (
assert_equal,
assert_,
assert_almost_equal,
assert_raises,
)
from scipy.constants import _codata
Copy link
Contributor

Choose a reason for hiding this comment

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

Let's not make unnnecessary formatting changes.

elif is_exact:
exact[name] = val
elif is_truncated:
raise Warning("Parsing error")
Copy link
Contributor

@mdhaber mdhaber Sep 30, 2024

Choose a reason for hiding this comment

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

Why raisea Warning? Should this warn or raise an exception?


physical_constants: dict[str, tuple[float, str, float]] = {}
exact2022 = exact2018
Copy link
Contributor

Choose a reason for hiding this comment

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

I haven't checked whether this is true, but for now...

h = exact['Planck constant']
e = exact['elementary charge']
k = exact['Boltzmann constant']
N_A = exact['Avogadro constant']
Copy link
Contributor

Choose a reason for hiding this comment

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

The original PR defined some useful constants to reduce duplication. I'll add them back.

Comment on lines +1554 to +1555
alpha_W = (3 + lambertw(-3 * math.exp(-3))).real
x_W = (5 + lambertw(-5 * math.exp(-5))).real
Copy link
Contributor

Choose a reason for hiding this comment

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

The original PR defined numerical values. Fortunately, lambertw gives exactly the same result as mpmath, but it would probably be safer to pre-calculate these.

mdhaber added a commit to pv/scipy-work that referenced this pull request Sep 30, 2024
@mdhaber
Copy link
Contributor

mdhaber commented Sep 30, 2024

Thanks for working on this @jakobjakobson13.

After merging main into gh-11345 and this PR, I checked this against the original, gh-11345. I've decided to close this one in favor of gh-11345 for a few reasons:

  • It appears that this was a manual recreation and adjustment of MAINT: constants: revise way 'exact' values are recomputed #11345. The PR that gets merged should include the original commits.
  • The raise Warnings do not seem to be an improvement over the assertions in the original PR. Neither are ideal, but the intent of the original assertions was more clear to me.
  • There were unrelated formatting changes here; these make the diff harder to review.
  • There were some good ideas from the original PR that were left out of this one (e.g. definition of hbar and reuse)

There were also some good ideas from this one that I merged into gh-11345 in 4a91f45, so when that gets merged, we'll add you as a coauthor.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement A new feature or improvement scipy.constants
Projects
None yet
Development

Successfully merging this pull request may close these issues.

DOC: constants: explain 0.0 uncertainty MAINT: constants: disparate electric permittivity constants
6 participants