Floating-point numbers cannot generally be represented exactly, so it is usually inappropriate to test for 'equality' between two floating-point numbers. Rather, it is generally appropriate to check whether the difference between the two numbers is sufficiently small that they can be considered practically equal. (In other words, so close in value that any differences could be explained by inherent limitations of computations using floating-point numbers.)
Based on two scalar inputs of type double, namely A and B, you must return a scalar logical output set to true if the difference in magnitude between the single-precision representations of A and B is 'small', or otherwise set to false.
For this problem "small" shall mean no more than Δ, which is defined as the larger of δ and ten times ε. In turn, δ has a fixed value of 1×10⁻¹⁰ and ε is the larger of ε₁ & ε₂, where ε₁ is the floating-point precision with which A is represented, and ε₂ is the precision with which B is represented.
EXAMPLE:
% Input
A = 0
B = 1E-20
% Output
practicallyEqual = true
Explanation: When represented as single values, A is represented with a precision of ε₁ = 2⁻¹⁴⁹, whereas B is represented with a precision of ε₂ = 2⁻⁹⁰. Thus ε = 2⁻⁹⁰; however the threshold Δ is 1×10⁻¹⁰ for this situation, because 1×10⁻¹⁰ > 10×2⁻⁹⁰. The difference between A and B is 1×10⁻²⁰, and this difference does not exceed the threshold. Thus A and B are practically equal in this example.
RELATED PROBLEMS:
Solution Stats
Problem Comments
3 Comments
Solution Comments
Show comments
Loading...
Problem Recent Solvers9
Suggested Problems
-
Replace NaNs with the number that appears to its left in the row.
3059 Solvers
-
Back to basics 21 - Matrix replicating
1788 Solvers
-
524 Solvers
-
Sum the 'edge' values of a matrix
397 Solvers
-
166 Solvers
More from this Author32
Problem Tags
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!
Oops. I just noticed that I forgot to rename the function from "compareDoubles" (used in Problem 44690) to "compareSingles". Unfortunately I cannot make the fix now without breaking the two successful submissions. Sorry about any confusion. —DIV
Good problem, but it would be better if base-10 or base-2 was adopted as a standard at the description. It is confusing to keep changing them. And the function name should probably be compareSingles and not compareDoubles. You can fix the test suite by using try and catch while accepting both names for the function.
Hello, Rafael.
Thank-you for the tip about using try & catch. I have modified the Test Suite accordingly, so it should be possible now for Cody players to call their function either "compareSingles" or "compareDoubles". When formatted neatly this workaround code distracted from the core content of the Test Suite, so I have crammed it onto one individual line in each separate Test.
Regarding the problem statement, I think this is like real life, and Cody players can figure it out. Some Cody players will find the conversion obvious, so it won't be a hassle for them; other Cody players might find the conversion less obvious, so it's a small extra challenge and learning opportunity for them. (See also Problem 44690.)