-
Notifications
You must be signed in to change notification settings - Fork 184
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
Initial checkin for a module for tolerant comparison of reals #353
Conversation
The module is based on the idea to allow for a small margin when comparing reals. Such a margin can solve the problem that the finite precision of floating-point calculations make the results inaccurate. Two essentially equal real numbers may therefore appear to be different
This backup file (from an edit action) was not supposed to go into the repository
Certainly not - github desktop is all too keen on submitting all files
residing in the checkout directory.
Op za 20 mrt. 2021 om 12:42 schreef Sebastian Ehlert <
***@***.***>:
… ***@***.**** commented on this pull request.
------------------------------
In src/CMakeLists.bak
<#353 (comment)>:
> @@ -0,0 +1,73 @@
+### Pre-process: .fpp -> .f90 via Fypp
src/CMakeLists.bak is not supposed to be committed here, is it?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#353 (review)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAN6YRZNNYMKTSPCFL45KS3TESCZJANCNFSM4ZQLBXTQ>
.
|
Thanks @arjenmarkus, I think these will be useful. Is "tolerant" a commonly and uniquely used term? I wonder if most people would understand what it is just based on that word. What do you think about I guess my main gripe with the word "tolerant" is that it's an adjective and not a noun, i.e. it doesn't say what is in the module, but what something is like in the module. |
The original source code mentions "fuzzy Fortran operators", that may be
more apt, but then I fear people would expect fuzzy sets and the like. I am
not too happy with the term tolerant either, so I am open to suggestions.
Op ma 22 mrt. 2021 om 20:46 schreef Milan Curcic ***@***.***>:
… Thanks @arjenmarkus <https://github.com/arjenmarkus>, I think these will
be useful.
Is "tolerant" a commonly and uniquely used term? I wonder if most people
would understand what it is just based on that word.
What do you think about stdlib_comparisons? But then it misses the point
of the comparisons being tolerant. And stdlib_tolerant_comparisons is
unwieldy.
I guess my main gripe with the word "tolerant" is that it's an adjective
and not a noun, i.e. it doesn't say what is in the module, but what
something is like in the module.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#353 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAN6YR7YUGSMHHJXY77MEXDTE6NCXANCNFSM4ZQLBXTQ>
.
|
Currently |
The plural has my preference. As I will not be able to join today, I will
simply await the results.
Op di 23 mrt. 2021 om 23:35 schreef Milan Curcic ***@***.***>:
… Currently stdlib_comparison or stdlib_comparisons is my favorite. We can
request feedback on the call tomorrow.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#353 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAN6YR7REP2OB5A4FINV4V3TFEJSJANCNFSM4ZQLBXTQ>
.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank ypou @arjenmarkus for this PR. Here are some comments.
I agree with @milancurcic: stdlib_comparison
or stdlib_comparisons
would be better thatn stdlib_tolerant
. However, they don't cover tfloor
,,... What do you think about stdlib_operators
?
General comments:
- Some hyperlinks mst still be added in the code, but this could be done at the end of the PR
fypp
could be used to generated the code for the different kinds ofreal
.
|
||
Provide tolerant versions of the `floor`, `ceil` and `round` functions that take a small interval into account. | ||
While the actual interval can be set, the advised default is three times epsilon(). Note that the implementation | ||
is actually much more involved than would seem necessary. It is the result of extensive research. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is actually much more involved than would seem necessary. It is the result of extensive research. | |
is actually much more involved than would seem necessary. It is the result of extensive research. |
#### Description | ||
|
||
Provide tolerant versions of the `floor`, `ceil` and `round` functions that take a small interval into account. | ||
While the actual interval can be set, the advised default is three times epsilon(). Note that the implementation |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While the actual interval can be set, the advised default is three times epsilon(). Note that the implementation | |
While the actual interval can be set, the advised default is three times `epsilon()`. Note that the implementation |
|
||
`x`: The real number that is to be truncated or rounded | ||
|
||
`ct`: Tolearance for comparison (optional, defaults to 3*epsilon) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
`ct`: Tolearance for comparison (optional, defaults to 3*epsilon) | |
`ct`: Tolerance for comparison. It is an `intent(in)` and `optional` argument. The default is 3*`epsilon(). |
|
||
#### Arguments | ||
|
||
`x`: The real number that is to be truncated or rounded |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
`x`: The real number that is to be truncated or rounded | |
`x`: The real number that is to be truncated or rounded. It is an `intent(in)` argument. |
integer, parameter, private :: sp = kind(1.0) | ||
integer, parameter, private :: dp = kind(1.0d0) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it be possible to use the ones defined in stdlib_kinds
?
|
||
#### Arguments | ||
|
||
`x`, `y`: Two reals (of the same kind) to be compared |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are they scalar? Or are arrays also possible (and then the function should be elemental
?
logical function teq_sp( x, y ) result(cmp) | ||
real(kind=sp), intent(in) :: x, y | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All the functions for the different kinds could be generated with fypp.
|
||
implicit none | ||
|
||
integer, parameter :: dp = kind(1.0d0) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe using the ones defined by stdlib_kinds
?
real(kind=dp) :: x, y, z | ||
real(kind=dp) :: yfloor, yceil | ||
integer :: i | ||
|
||
real(kind=dp) :: eps3 = 3.0_dp * epsilon(eps3) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fypp could be used to generate the same tests for the other kinds.
The module is based on the idea to allow for a small margin when comparing reals. Such a margin can solve the problem that the finite precision of floating-point calculations make the results inaccurate. Two essentially equal real numbers may therefore appear to be different. This is in response to issue #327