Centralize floating-point conversion and implement isapprox#59
Merged
Centralize floating-point conversion and implement isapprox#59
Conversation
By default it asks whether two FixedPoints are within eps of each other. Handy in testing.
Collaborator
|
This looks good thank you for tackling this. |
Contributor
|
Guess nobody has complained for almost a year, but this supported 0.4 and has been giving ambiguity warnings there. |
Member
Author
|
Is there anything we need to do? The current FPN requires Julia 0.5. |
Contributor
|
Right but the last 0.4-supporting versions was after this. If it's a one liner to fix, might be worth backporting to a branch off that last 0.4-supporting version and doing one last tag in that old minor series. |
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This tries to be a little more consistent about which floating-point type (☹️ , but I personally think it's worth it. I'll give others a chance to chime in before merging.
Float32orFloat64) we use for conversions. As a consequence, this has the possibility of being breakingAlso implemented
isapproxsox ≈ yworks nicely in tests (by default, allowing a 1-eps difference).