-
Notifications
You must be signed in to change notification settings - Fork 63
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Uses rtol instead of places in tests #148
Comments
I am not sure I understand, could you please elaborate a bit more? What exactly is the problem with current version? |
The use of relative tolerance (rtol) instead of absolute tolerance (places) in unit tests, especially for floating-point comparisons, is often preferred for several reasons:
rtol is scale-independent, meaning it works well across a wide range of magnitudes.
Floating-point arithmetic can introduce small errors due to how computers represent and operate on decimal numbers.
For very large or very small numbers, an absolute tolerance might be too strict or too lenient, respectively.
When dealing with calculations involving different units or scales, rtol provides a more consistent way to compare results.
In scientific and engineering applications, relative error is often more important than absolute error.
rtol allows for setting a percentage difference that's acceptable, which can be more intuitive in many cases. Example: With places=6 (absolute tolerance), this would fail. Now compare 1,000,000 and 1,000,001: With places=6, this would pass, which might not be desirable for such large numbers. In practice, a combination of both relative (rtol) and absolute (atol) tolerance is often used for robust comparisons, especially in libraries like NumPy's isclose() function or pytest's approx(). (claude.ai answer) |
Hello,
Test with
assertAlmostEqual
uses places which is close to absolute tolerance (atol) 10**-places is atolrelative tolerance (rtol) would probably be a better idea.
See
https://github.com/nardew/talipp/pull/147/files#diff-356e9ecd00b59db50b3531a4b1143455b87bc4d213b491b642d19db6bff50ec9R51
Kind regards
The text was updated successfully, but these errors were encountered: