Why is 24.0000 not equal to 24.0000 in MATLAB?












57















I am writing a program where I need to delete duplicate points stored in a matrix. The problem is that when it comes to check whether those points are in the matrix, MATLAB can't recognize them in the matrix although they exist.



In the following code, intersections function gets the intersection points:



[points(:,1), points(:,2)] = intersections(...
obj.modifiedVGVertices(1,:), obj.modifiedVGVertices(2,:), ...
[vertex1(1) vertex2(1)], [vertex1(2) vertex2(2)]);


The result:



>> points
points =
12.0000 15.0000
33.0000 24.0000
33.0000 24.0000

>> vertex1
vertex1 =
12
15

>> vertex2
vertex2 =
33
24


Two points (vertex1 and vertex2) should be eliminated from the result. It should be done by the below commands:



points = points((points(:,1) ~= vertex1(1)) | (points(:,2) ~= vertex1(2)), :);
points = points((points(:,1) ~= vertex2(1)) | (points(:,2) ~= vertex2(2)), :);


After doing that, we have this unexpected outcome:



>> points
points =
33.0000 24.0000


The outcome should be an empty matrix. As you can see, the first (or second?) pair of [33.0000 24.0000] has been eliminated, but not the second one.



Then I checked these two expressions:



>> points(1) ~= vertex2(1)
ans =
0
>> points(2) ~= vertex2(2)
ans =
1 % <-- It means 24.0000 is not equal to 24.0000?


What is the problem?





More surprisingly, I made a new script that has only these commands:



points = [12.0000   15.0000
33.0000 24.0000
33.0000 24.0000];

vertex1 = [12 ; 15];
vertex2 = [33 ; 24];

points = points((points(:,1) ~= vertex1(1)) | (points(:,2) ~= vertex1(2)), :);
points = points((points(:,1) ~= vertex2(1)) | (points(:,2) ~= vertex2(2)), :);


The result as expected:



>> points
points =
Empty matrix: 0-by-2









share|improve this question




















  • 1





    This has also been addressed here

    – ChrisF
    Mar 26 '09 at 16:28






  • 2





    @Kamran: Sorry I didn't point out the perils of floating point comparison when you asked about comparing values in your other question. It didn't immediately occur to me you might run into that problem.

    – gnovice
    Mar 26 '09 at 16:43






  • 2





    As a side note, compare 1.2 - 0.2 - 1 == 0 and 1.2 - 1 - 0.2 == 0. Surprising, isn't it? When you're dealing with floating-point numbers, the order of operations matters.

    – jubobs
    Oct 12 '14 at 12:51








  • 1





    @Tick Tock: As the author of the question, I could not even understand the title you chose for my question. Also it did not reflect the fact that MATLAB does not show the entire floating point part of the number when you print out the variable.

    – Kamran Bigdely
    Aug 18 '16 at 22:34






  • 1





    @m7913d, I see. but usually they put the 'duplicate' label on the newer question. Please read the rules for duplicate label: meta.stackexchange.com/questions/10841/…

    – Kamran Bigdely
    May 4 '17 at 17:28


















57















I am writing a program where I need to delete duplicate points stored in a matrix. The problem is that when it comes to check whether those points are in the matrix, MATLAB can't recognize them in the matrix although they exist.



In the following code, intersections function gets the intersection points:



[points(:,1), points(:,2)] = intersections(...
obj.modifiedVGVertices(1,:), obj.modifiedVGVertices(2,:), ...
[vertex1(1) vertex2(1)], [vertex1(2) vertex2(2)]);


The result:



>> points
points =
12.0000 15.0000
33.0000 24.0000
33.0000 24.0000

>> vertex1
vertex1 =
12
15

>> vertex2
vertex2 =
33
24


Two points (vertex1 and vertex2) should be eliminated from the result. It should be done by the below commands:



points = points((points(:,1) ~= vertex1(1)) | (points(:,2) ~= vertex1(2)), :);
points = points((points(:,1) ~= vertex2(1)) | (points(:,2) ~= vertex2(2)), :);


After doing that, we have this unexpected outcome:



>> points
points =
33.0000 24.0000


The outcome should be an empty matrix. As you can see, the first (or second?) pair of [33.0000 24.0000] has been eliminated, but not the second one.



Then I checked these two expressions:



>> points(1) ~= vertex2(1)
ans =
0
>> points(2) ~= vertex2(2)
ans =
1 % <-- It means 24.0000 is not equal to 24.0000?


What is the problem?





More surprisingly, I made a new script that has only these commands:



points = [12.0000   15.0000
33.0000 24.0000
33.0000 24.0000];

vertex1 = [12 ; 15];
vertex2 = [33 ; 24];

points = points((points(:,1) ~= vertex1(1)) | (points(:,2) ~= vertex1(2)), :);
points = points((points(:,1) ~= vertex2(1)) | (points(:,2) ~= vertex2(2)), :);


The result as expected:



>> points
points =
Empty matrix: 0-by-2









share|improve this question




















  • 1





    This has also been addressed here

    – ChrisF
    Mar 26 '09 at 16:28






  • 2





    @Kamran: Sorry I didn't point out the perils of floating point comparison when you asked about comparing values in your other question. It didn't immediately occur to me you might run into that problem.

    – gnovice
    Mar 26 '09 at 16:43






  • 2





    As a side note, compare 1.2 - 0.2 - 1 == 0 and 1.2 - 1 - 0.2 == 0. Surprising, isn't it? When you're dealing with floating-point numbers, the order of operations matters.

    – jubobs
    Oct 12 '14 at 12:51








  • 1





    @Tick Tock: As the author of the question, I could not even understand the title you chose for my question. Also it did not reflect the fact that MATLAB does not show the entire floating point part of the number when you print out the variable.

    – Kamran Bigdely
    Aug 18 '16 at 22:34






  • 1





    @m7913d, I see. but usually they put the 'duplicate' label on the newer question. Please read the rules for duplicate label: meta.stackexchange.com/questions/10841/…

    – Kamran Bigdely
    May 4 '17 at 17:28
















57












57








57


21






I am writing a program where I need to delete duplicate points stored in a matrix. The problem is that when it comes to check whether those points are in the matrix, MATLAB can't recognize them in the matrix although they exist.



In the following code, intersections function gets the intersection points:



[points(:,1), points(:,2)] = intersections(...
obj.modifiedVGVertices(1,:), obj.modifiedVGVertices(2,:), ...
[vertex1(1) vertex2(1)], [vertex1(2) vertex2(2)]);


The result:



>> points
points =
12.0000 15.0000
33.0000 24.0000
33.0000 24.0000

>> vertex1
vertex1 =
12
15

>> vertex2
vertex2 =
33
24


Two points (vertex1 and vertex2) should be eliminated from the result. It should be done by the below commands:



points = points((points(:,1) ~= vertex1(1)) | (points(:,2) ~= vertex1(2)), :);
points = points((points(:,1) ~= vertex2(1)) | (points(:,2) ~= vertex2(2)), :);


After doing that, we have this unexpected outcome:



>> points
points =
33.0000 24.0000


The outcome should be an empty matrix. As you can see, the first (or second?) pair of [33.0000 24.0000] has been eliminated, but not the second one.



Then I checked these two expressions:



>> points(1) ~= vertex2(1)
ans =
0
>> points(2) ~= vertex2(2)
ans =
1 % <-- It means 24.0000 is not equal to 24.0000?


What is the problem?





More surprisingly, I made a new script that has only these commands:



points = [12.0000   15.0000
33.0000 24.0000
33.0000 24.0000];

vertex1 = [12 ; 15];
vertex2 = [33 ; 24];

points = points((points(:,1) ~= vertex1(1)) | (points(:,2) ~= vertex1(2)), :);
points = points((points(:,1) ~= vertex2(1)) | (points(:,2) ~= vertex2(2)), :);


The result as expected:



>> points
points =
Empty matrix: 0-by-2









share|improve this question
















I am writing a program where I need to delete duplicate points stored in a matrix. The problem is that when it comes to check whether those points are in the matrix, MATLAB can't recognize them in the matrix although they exist.



In the following code, intersections function gets the intersection points:



[points(:,1), points(:,2)] = intersections(...
obj.modifiedVGVertices(1,:), obj.modifiedVGVertices(2,:), ...
[vertex1(1) vertex2(1)], [vertex1(2) vertex2(2)]);


The result:



>> points
points =
12.0000 15.0000
33.0000 24.0000
33.0000 24.0000

>> vertex1
vertex1 =
12
15

>> vertex2
vertex2 =
33
24


Two points (vertex1 and vertex2) should be eliminated from the result. It should be done by the below commands:



points = points((points(:,1) ~= vertex1(1)) | (points(:,2) ~= vertex1(2)), :);
points = points((points(:,1) ~= vertex2(1)) | (points(:,2) ~= vertex2(2)), :);


After doing that, we have this unexpected outcome:



>> points
points =
33.0000 24.0000


The outcome should be an empty matrix. As you can see, the first (or second?) pair of [33.0000 24.0000] has been eliminated, but not the second one.



Then I checked these two expressions:



>> points(1) ~= vertex2(1)
ans =
0
>> points(2) ~= vertex2(2)
ans =
1 % <-- It means 24.0000 is not equal to 24.0000?


What is the problem?





More surprisingly, I made a new script that has only these commands:



points = [12.0000   15.0000
33.0000 24.0000
33.0000 24.0000];

vertex1 = [12 ; 15];
vertex2 = [33 ; 24];

points = points((points(:,1) ~= vertex1(1)) | (points(:,2) ~= vertex1(2)), :);
points = points((points(:,1) ~= vertex2(1)) | (points(:,2) ~= vertex2(2)), :);


The result as expected:



>> points
points =
Empty matrix: 0-by-2






matlab floating-point precision






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Aug 18 '16 at 7:21









rayryeng

83.4k17116142




83.4k17116142










asked Mar 26 '09 at 16:10









Kamran BigdelyKamran Bigdely

3,275114465




3,275114465








  • 1





    This has also been addressed here

    – ChrisF
    Mar 26 '09 at 16:28






  • 2





    @Kamran: Sorry I didn't point out the perils of floating point comparison when you asked about comparing values in your other question. It didn't immediately occur to me you might run into that problem.

    – gnovice
    Mar 26 '09 at 16:43






  • 2





    As a side note, compare 1.2 - 0.2 - 1 == 0 and 1.2 - 1 - 0.2 == 0. Surprising, isn't it? When you're dealing with floating-point numbers, the order of operations matters.

    – jubobs
    Oct 12 '14 at 12:51








  • 1





    @Tick Tock: As the author of the question, I could not even understand the title you chose for my question. Also it did not reflect the fact that MATLAB does not show the entire floating point part of the number when you print out the variable.

    – Kamran Bigdely
    Aug 18 '16 at 22:34






  • 1





    @m7913d, I see. but usually they put the 'duplicate' label on the newer question. Please read the rules for duplicate label: meta.stackexchange.com/questions/10841/…

    – Kamran Bigdely
    May 4 '17 at 17:28
















  • 1





    This has also been addressed here

    – ChrisF
    Mar 26 '09 at 16:28






  • 2





    @Kamran: Sorry I didn't point out the perils of floating point comparison when you asked about comparing values in your other question. It didn't immediately occur to me you might run into that problem.

    – gnovice
    Mar 26 '09 at 16:43






  • 2





    As a side note, compare 1.2 - 0.2 - 1 == 0 and 1.2 - 1 - 0.2 == 0. Surprising, isn't it? When you're dealing with floating-point numbers, the order of operations matters.

    – jubobs
    Oct 12 '14 at 12:51








  • 1





    @Tick Tock: As the author of the question, I could not even understand the title you chose for my question. Also it did not reflect the fact that MATLAB does not show the entire floating point part of the number when you print out the variable.

    – Kamran Bigdely
    Aug 18 '16 at 22:34






  • 1





    @m7913d, I see. but usually they put the 'duplicate' label on the newer question. Please read the rules for duplicate label: meta.stackexchange.com/questions/10841/…

    – Kamran Bigdely
    May 4 '17 at 17:28










1




1





This has also been addressed here

– ChrisF
Mar 26 '09 at 16:28





This has also been addressed here

– ChrisF
Mar 26 '09 at 16:28




2




2





@Kamran: Sorry I didn't point out the perils of floating point comparison when you asked about comparing values in your other question. It didn't immediately occur to me you might run into that problem.

– gnovice
Mar 26 '09 at 16:43





@Kamran: Sorry I didn't point out the perils of floating point comparison when you asked about comparing values in your other question. It didn't immediately occur to me you might run into that problem.

– gnovice
Mar 26 '09 at 16:43




2




2





As a side note, compare 1.2 - 0.2 - 1 == 0 and 1.2 - 1 - 0.2 == 0. Surprising, isn't it? When you're dealing with floating-point numbers, the order of operations matters.

– jubobs
Oct 12 '14 at 12:51







As a side note, compare 1.2 - 0.2 - 1 == 0 and 1.2 - 1 - 0.2 == 0. Surprising, isn't it? When you're dealing with floating-point numbers, the order of operations matters.

– jubobs
Oct 12 '14 at 12:51






1




1





@Tick Tock: As the author of the question, I could not even understand the title you chose for my question. Also it did not reflect the fact that MATLAB does not show the entire floating point part of the number when you print out the variable.

– Kamran Bigdely
Aug 18 '16 at 22:34





@Tick Tock: As the author of the question, I could not even understand the title you chose for my question. Also it did not reflect the fact that MATLAB does not show the entire floating point part of the number when you print out the variable.

– Kamran Bigdely
Aug 18 '16 at 22:34




1




1





@m7913d, I see. but usually they put the 'duplicate' label on the newer question. Please read the rules for duplicate label: meta.stackexchange.com/questions/10841/…

– Kamran Bigdely
May 4 '17 at 17:28







@m7913d, I see. but usually they put the 'duplicate' label on the newer question. Please read the rules for duplicate label: meta.stackexchange.com/questions/10841/…

– Kamran Bigdely
May 4 '17 at 17:28














6 Answers
6






active

oldest

votes


















84














The problem you're having relates to how floating-point numbers are represented on a computer. A more detailed discussion of floating-point representations appears towards the end of my answer (The "Floating-point representation" section). The TL;DR version: because computers have finite amounts of memory, numbers can only be represented with finite precision. Thus, the accuracy of floating-point numbers is limited to a certain number of decimal places (about 16 significant digits for double-precision values, the default used in MATLAB).



Actual vs. displayed precision



Now to address the specific example in the question... while 24.0000 and 24.0000 are displayed in the same manner, it turns out that they actually differ by very small decimal amounts in this case. You don't see it because MATLAB only displays 4 significant digits by default, keeping the overall display neat and tidy. If you want to see the full precision, you should either issue the format long command or view a hexadecimal representation of the number:



>> pi
ans =
3.1416
>> format long
>> pi
ans =
3.141592653589793
>> num2hex(pi)
ans =
400921fb54442d18


Initialized values vs. computed values



Since there are only a finite number of values that can be represented for a floating-point number, it's possible for a computation to result in a value that falls between two of these representations. In such a case, the result has to be rounded off to one of them. This introduces a small machine-precision error. This also means that initializing a value directly or by some computation can give slightly different results. For example, the value 0.1 doesn't have an exact floating-point representation (i.e. it gets slightly rounded off), and so you end up with counter-intuitive results like this due to the way round-off errors accumulate:



>> a=sum([0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.1]);  % Sum 10 0.1s
>> b=1; % Initialize to 1
>> a == b
ans =
logical
0 % They are unequal!
>> num2hex(a) % Let's check their hex representation to confirm
ans =
3fefffffffffffff
>> num2hex(b)
ans =
3ff0000000000000


How to correctly handle floating-point comparisons



Since floating-point values can differ by very small amounts, any comparisons should be done by checking that the values are within some range (i.e. tolerance) of one another, as opposed to exactly equal to each other. For example:



a = 24;
b = 24.000001;
tolerance = 0.001;
if abs(a-b) < tolerance, disp('Equal!'); end


will display "Equal!".



You could then change your code to something like:



points = points((abs(points(:,1)-vertex1(1)) > tolerance) | ...
(abs(points(:,2)-vertex1(2)) > tolerance),:)




Floating-point representation



A good overview of floating-point numbers (and specifically the IEEE 754 standard for floating-point arithmetic) is What Every Computer Scientist Should Know About Floating-Point Arithmetic by David Goldberg.



A binary floating-point number is actually represented by three integers: a sign bit s, a significand (or coefficient/fraction) b, and an exponent e. For double-precision floating-point format, each number is represented by 64 bits laid out in memory as follows:



enter image description here



The real value can then be found with the following formula:



enter image description here



This format allows for number representations in the range 10^-308 to 10^308. For MATLAB you can get these limits from realmin and realmax:



>> realmin
ans =
2.225073858507201e-308
>> realmax
ans =
1.797693134862316e+308


Since there are a finite number of bits used to represent a floating-point number, there are only so many finite numbers that can be represented within the above given range. Computations will often result in a value that doesn't exactly match one of these finite representations, so the values must be rounded off. These machine-precision errors make themselves evident in different ways, as discussed in the above examples.



In order to better understand these round-off errors it's useful to look at the relative floating-point accuracy provided by the function eps, which quantifies the distance from a given number to the next largest floating-point representation:



>> eps(1)
ans =
2.220446049250313e-16
>> eps(1000)
ans =
1.136868377216160e-13


Notice that the precision is relative to the size of a given number being represented; larger numbers will have larger distances between floating-point representations, and will thus have fewer digits of precision following the decimal point. This can be an important consideration with some calculations. Consider the following example:



>> format long              % Display full precision
>> x = rand(1, 10); % Get 10 random values between 0 and 1
>> a = mean(x) % Take the mean
a =
0.587307428244141
>> b = mean(x+10000)-10000 % Take the mean at a different scale, then shift back
b =
0.587307428244458


Note that when we shift the values of x from the range [0 1] to the range [10000 10001], compute a mean, then subtract the mean offset for comparison, we get a value that differs for the last 3 significant digits. This illustrates how an offset or scaling of data can change the accuracy of calculations performed on it, which is something that has to be accounted for with certain problems.






share|improve this answer


























  • why can't I see that small decimal amount?

    – Kamran Bigdely
    Mar 26 '09 at 16:18






  • 2





    you can see it if you view the variable in the matrix view. Right click on variable -> "View selection" or something? I don't have MATLAB here, so I can't check.

    – atsjoo
    Mar 26 '09 at 16:20






  • 4





    You can also see small differences by typing "format long" at the command prompt.

    – gnovice
    Mar 26 '09 at 16:23






  • 2





    you are right: format long points = 12.000000000000000 15.000000000000000 33.000000000000000 23.999999999999996 33.000000000000000 24.000000000000000

    – Kamran Bigdely
    Mar 26 '09 at 20:02






  • 6





    "format hex" can sometimes help even more than format long here.

    – Sam Roberts
    Oct 5 '09 at 15:25



















21














Look at this article: The Perils of Floating Point. Though its examples are in FORTRAN it has sense for virtually any modern programming language, including MATLAB. Your problem (and solution for it) is described in "Safe Comparisons" section.






share|improve this answer



















  • 1





    I discovered it some time ago and was very impressed with it =) Now I always recommend it in similar situations.

    – Rorick
    Mar 27 '09 at 8:26











  • Archived version of this excellent resource!

    – wizclown
    Jul 12 '18 at 12:37



















12














type



format long g


This command will show the FULL value of the number. It's likely to be something like 24.00000021321 != 24.00000123124






share|improve this answer































    7














    Try writing




    0.1 + 0.1 + 0.1 == 0.3.




    Warning: You might be surprised about the result!






    share|improve this answer
























    • I tried it and it returns 0. But I don't see what it has to do, with the problem above. Can you pls explain it to me?

      – Max
      Sep 16 '15 at 8:46






    • 6





      This is because 0.1 comes with some floating point error, and when you add three such terms together, the errors do not necessarily add up to 0. The same issue is causing (floating) 24 to not be exactly equal to (another floating) 24.

      – Derek
      Mar 4 '16 at 11:14



















    2














    Maybe the two numbers are really 24.0 and 24.000000001 but you're not seeing all the decimal places.






    share|improve this answer































      1














      Check out the Matlab EPS function.



      Matlab uses floating point math up to 16 digits of precision (only 5 are displayed).






      share|improve this answer

























        Your Answer






        StackExchange.ifUsing("editor", function () {
        StackExchange.using("externalEditor", function () {
        StackExchange.using("snippets", function () {
        StackExchange.snippets.init();
        });
        });
        }, "code-snippets");

        StackExchange.ready(function() {
        var channelOptions = {
        tags: "".split(" "),
        id: "1"
        };
        initTagRenderer("".split(" "), "".split(" "), channelOptions);

        StackExchange.using("externalEditor", function() {
        // Have to fire editor after snippets, if snippets enabled
        if (StackExchange.settings.snippets.snippetsEnabled) {
        StackExchange.using("snippets", function() {
        createEditor();
        });
        }
        else {
        createEditor();
        }
        });

        function createEditor() {
        StackExchange.prepareEditor({
        heartbeatType: 'answer',
        autoActivateHeartbeat: false,
        convertImagesToLinks: true,
        noModals: true,
        showLowRepImageUploadWarning: true,
        reputationToPostImages: 10,
        bindNavPrevention: true,
        postfix: "",
        imageUploader: {
        brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
        contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
        allowUrls: true
        },
        onDemand: true,
        discardSelector: ".discard-answer"
        ,immediatelyShowMarkdownHelp:true
        });


        }
        });














        draft saved

        draft discarded


















        StackExchange.ready(
        function () {
        StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f686439%2fwhy-is-24-0000-not-equal-to-24-0000-in-matlab%23new-answer', 'question_page');
        }
        );

        Post as a guest















        Required, but never shown

























        6 Answers
        6






        active

        oldest

        votes








        6 Answers
        6






        active

        oldest

        votes









        active

        oldest

        votes






        active

        oldest

        votes









        84














        The problem you're having relates to how floating-point numbers are represented on a computer. A more detailed discussion of floating-point representations appears towards the end of my answer (The "Floating-point representation" section). The TL;DR version: because computers have finite amounts of memory, numbers can only be represented with finite precision. Thus, the accuracy of floating-point numbers is limited to a certain number of decimal places (about 16 significant digits for double-precision values, the default used in MATLAB).



        Actual vs. displayed precision



        Now to address the specific example in the question... while 24.0000 and 24.0000 are displayed in the same manner, it turns out that they actually differ by very small decimal amounts in this case. You don't see it because MATLAB only displays 4 significant digits by default, keeping the overall display neat and tidy. If you want to see the full precision, you should either issue the format long command or view a hexadecimal representation of the number:



        >> pi
        ans =
        3.1416
        >> format long
        >> pi
        ans =
        3.141592653589793
        >> num2hex(pi)
        ans =
        400921fb54442d18


        Initialized values vs. computed values



        Since there are only a finite number of values that can be represented for a floating-point number, it's possible for a computation to result in a value that falls between two of these representations. In such a case, the result has to be rounded off to one of them. This introduces a small machine-precision error. This also means that initializing a value directly or by some computation can give slightly different results. For example, the value 0.1 doesn't have an exact floating-point representation (i.e. it gets slightly rounded off), and so you end up with counter-intuitive results like this due to the way round-off errors accumulate:



        >> a=sum([0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.1]);  % Sum 10 0.1s
        >> b=1; % Initialize to 1
        >> a == b
        ans =
        logical
        0 % They are unequal!
        >> num2hex(a) % Let's check their hex representation to confirm
        ans =
        3fefffffffffffff
        >> num2hex(b)
        ans =
        3ff0000000000000


        How to correctly handle floating-point comparisons



        Since floating-point values can differ by very small amounts, any comparisons should be done by checking that the values are within some range (i.e. tolerance) of one another, as opposed to exactly equal to each other. For example:



        a = 24;
        b = 24.000001;
        tolerance = 0.001;
        if abs(a-b) < tolerance, disp('Equal!'); end


        will display "Equal!".



        You could then change your code to something like:



        points = points((abs(points(:,1)-vertex1(1)) > tolerance) | ...
        (abs(points(:,2)-vertex1(2)) > tolerance),:)




        Floating-point representation



        A good overview of floating-point numbers (and specifically the IEEE 754 standard for floating-point arithmetic) is What Every Computer Scientist Should Know About Floating-Point Arithmetic by David Goldberg.



        A binary floating-point number is actually represented by three integers: a sign bit s, a significand (or coefficient/fraction) b, and an exponent e. For double-precision floating-point format, each number is represented by 64 bits laid out in memory as follows:



        enter image description here



        The real value can then be found with the following formula:



        enter image description here



        This format allows for number representations in the range 10^-308 to 10^308. For MATLAB you can get these limits from realmin and realmax:



        >> realmin
        ans =
        2.225073858507201e-308
        >> realmax
        ans =
        1.797693134862316e+308


        Since there are a finite number of bits used to represent a floating-point number, there are only so many finite numbers that can be represented within the above given range. Computations will often result in a value that doesn't exactly match one of these finite representations, so the values must be rounded off. These machine-precision errors make themselves evident in different ways, as discussed in the above examples.



        In order to better understand these round-off errors it's useful to look at the relative floating-point accuracy provided by the function eps, which quantifies the distance from a given number to the next largest floating-point representation:



        >> eps(1)
        ans =
        2.220446049250313e-16
        >> eps(1000)
        ans =
        1.136868377216160e-13


        Notice that the precision is relative to the size of a given number being represented; larger numbers will have larger distances between floating-point representations, and will thus have fewer digits of precision following the decimal point. This can be an important consideration with some calculations. Consider the following example:



        >> format long              % Display full precision
        >> x = rand(1, 10); % Get 10 random values between 0 and 1
        >> a = mean(x) % Take the mean
        a =
        0.587307428244141
        >> b = mean(x+10000)-10000 % Take the mean at a different scale, then shift back
        b =
        0.587307428244458


        Note that when we shift the values of x from the range [0 1] to the range [10000 10001], compute a mean, then subtract the mean offset for comparison, we get a value that differs for the last 3 significant digits. This illustrates how an offset or scaling of data can change the accuracy of calculations performed on it, which is something that has to be accounted for with certain problems.






        share|improve this answer


























        • why can't I see that small decimal amount?

          – Kamran Bigdely
          Mar 26 '09 at 16:18






        • 2





          you can see it if you view the variable in the matrix view. Right click on variable -> "View selection" or something? I don't have MATLAB here, so I can't check.

          – atsjoo
          Mar 26 '09 at 16:20






        • 4





          You can also see small differences by typing "format long" at the command prompt.

          – gnovice
          Mar 26 '09 at 16:23






        • 2





          you are right: format long points = 12.000000000000000 15.000000000000000 33.000000000000000 23.999999999999996 33.000000000000000 24.000000000000000

          – Kamran Bigdely
          Mar 26 '09 at 20:02






        • 6





          "format hex" can sometimes help even more than format long here.

          – Sam Roberts
          Oct 5 '09 at 15:25
















        84














        The problem you're having relates to how floating-point numbers are represented on a computer. A more detailed discussion of floating-point representations appears towards the end of my answer (The "Floating-point representation" section). The TL;DR version: because computers have finite amounts of memory, numbers can only be represented with finite precision. Thus, the accuracy of floating-point numbers is limited to a certain number of decimal places (about 16 significant digits for double-precision values, the default used in MATLAB).



        Actual vs. displayed precision



        Now to address the specific example in the question... while 24.0000 and 24.0000 are displayed in the same manner, it turns out that they actually differ by very small decimal amounts in this case. You don't see it because MATLAB only displays 4 significant digits by default, keeping the overall display neat and tidy. If you want to see the full precision, you should either issue the format long command or view a hexadecimal representation of the number:



        >> pi
        ans =
        3.1416
        >> format long
        >> pi
        ans =
        3.141592653589793
        >> num2hex(pi)
        ans =
        400921fb54442d18


        Initialized values vs. computed values



        Since there are only a finite number of values that can be represented for a floating-point number, it's possible for a computation to result in a value that falls between two of these representations. In such a case, the result has to be rounded off to one of them. This introduces a small machine-precision error. This also means that initializing a value directly or by some computation can give slightly different results. For example, the value 0.1 doesn't have an exact floating-point representation (i.e. it gets slightly rounded off), and so you end up with counter-intuitive results like this due to the way round-off errors accumulate:



        >> a=sum([0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.1]);  % Sum 10 0.1s
        >> b=1; % Initialize to 1
        >> a == b
        ans =
        logical
        0 % They are unequal!
        >> num2hex(a) % Let's check their hex representation to confirm
        ans =
        3fefffffffffffff
        >> num2hex(b)
        ans =
        3ff0000000000000


        How to correctly handle floating-point comparisons



        Since floating-point values can differ by very small amounts, any comparisons should be done by checking that the values are within some range (i.e. tolerance) of one another, as opposed to exactly equal to each other. For example:



        a = 24;
        b = 24.000001;
        tolerance = 0.001;
        if abs(a-b) < tolerance, disp('Equal!'); end


        will display "Equal!".



        You could then change your code to something like:



        points = points((abs(points(:,1)-vertex1(1)) > tolerance) | ...
        (abs(points(:,2)-vertex1(2)) > tolerance),:)




        Floating-point representation



        A good overview of floating-point numbers (and specifically the IEEE 754 standard for floating-point arithmetic) is What Every Computer Scientist Should Know About Floating-Point Arithmetic by David Goldberg.



        A binary floating-point number is actually represented by three integers: a sign bit s, a significand (or coefficient/fraction) b, and an exponent e. For double-precision floating-point format, each number is represented by 64 bits laid out in memory as follows:



        enter image description here



        The real value can then be found with the following formula:



        enter image description here



        This format allows for number representations in the range 10^-308 to 10^308. For MATLAB you can get these limits from realmin and realmax:



        >> realmin
        ans =
        2.225073858507201e-308
        >> realmax
        ans =
        1.797693134862316e+308


        Since there are a finite number of bits used to represent a floating-point number, there are only so many finite numbers that can be represented within the above given range. Computations will often result in a value that doesn't exactly match one of these finite representations, so the values must be rounded off. These machine-precision errors make themselves evident in different ways, as discussed in the above examples.



        In order to better understand these round-off errors it's useful to look at the relative floating-point accuracy provided by the function eps, which quantifies the distance from a given number to the next largest floating-point representation:



        >> eps(1)
        ans =
        2.220446049250313e-16
        >> eps(1000)
        ans =
        1.136868377216160e-13


        Notice that the precision is relative to the size of a given number being represented; larger numbers will have larger distances between floating-point representations, and will thus have fewer digits of precision following the decimal point. This can be an important consideration with some calculations. Consider the following example:



        >> format long              % Display full precision
        >> x = rand(1, 10); % Get 10 random values between 0 and 1
        >> a = mean(x) % Take the mean
        a =
        0.587307428244141
        >> b = mean(x+10000)-10000 % Take the mean at a different scale, then shift back
        b =
        0.587307428244458


        Note that when we shift the values of x from the range [0 1] to the range [10000 10001], compute a mean, then subtract the mean offset for comparison, we get a value that differs for the last 3 significant digits. This illustrates how an offset or scaling of data can change the accuracy of calculations performed on it, which is something that has to be accounted for with certain problems.






        share|improve this answer


























        • why can't I see that small decimal amount?

          – Kamran Bigdely
          Mar 26 '09 at 16:18






        • 2





          you can see it if you view the variable in the matrix view. Right click on variable -> "View selection" or something? I don't have MATLAB here, so I can't check.

          – atsjoo
          Mar 26 '09 at 16:20






        • 4





          You can also see small differences by typing "format long" at the command prompt.

          – gnovice
          Mar 26 '09 at 16:23






        • 2





          you are right: format long points = 12.000000000000000 15.000000000000000 33.000000000000000 23.999999999999996 33.000000000000000 24.000000000000000

          – Kamran Bigdely
          Mar 26 '09 at 20:02






        • 6





          "format hex" can sometimes help even more than format long here.

          – Sam Roberts
          Oct 5 '09 at 15:25














        84












        84








        84







        The problem you're having relates to how floating-point numbers are represented on a computer. A more detailed discussion of floating-point representations appears towards the end of my answer (The "Floating-point representation" section). The TL;DR version: because computers have finite amounts of memory, numbers can only be represented with finite precision. Thus, the accuracy of floating-point numbers is limited to a certain number of decimal places (about 16 significant digits for double-precision values, the default used in MATLAB).



        Actual vs. displayed precision



        Now to address the specific example in the question... while 24.0000 and 24.0000 are displayed in the same manner, it turns out that they actually differ by very small decimal amounts in this case. You don't see it because MATLAB only displays 4 significant digits by default, keeping the overall display neat and tidy. If you want to see the full precision, you should either issue the format long command or view a hexadecimal representation of the number:



        >> pi
        ans =
        3.1416
        >> format long
        >> pi
        ans =
        3.141592653589793
        >> num2hex(pi)
        ans =
        400921fb54442d18


        Initialized values vs. computed values



        Since there are only a finite number of values that can be represented for a floating-point number, it's possible for a computation to result in a value that falls between two of these representations. In such a case, the result has to be rounded off to one of them. This introduces a small machine-precision error. This also means that initializing a value directly or by some computation can give slightly different results. For example, the value 0.1 doesn't have an exact floating-point representation (i.e. it gets slightly rounded off), and so you end up with counter-intuitive results like this due to the way round-off errors accumulate:



        >> a=sum([0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.1]);  % Sum 10 0.1s
        >> b=1; % Initialize to 1
        >> a == b
        ans =
        logical
        0 % They are unequal!
        >> num2hex(a) % Let's check their hex representation to confirm
        ans =
        3fefffffffffffff
        >> num2hex(b)
        ans =
        3ff0000000000000


        How to correctly handle floating-point comparisons



        Since floating-point values can differ by very small amounts, any comparisons should be done by checking that the values are within some range (i.e. tolerance) of one another, as opposed to exactly equal to each other. For example:



        a = 24;
        b = 24.000001;
        tolerance = 0.001;
        if abs(a-b) < tolerance, disp('Equal!'); end


        will display "Equal!".



        You could then change your code to something like:



        points = points((abs(points(:,1)-vertex1(1)) > tolerance) | ...
        (abs(points(:,2)-vertex1(2)) > tolerance),:)




        Floating-point representation



        A good overview of floating-point numbers (and specifically the IEEE 754 standard for floating-point arithmetic) is What Every Computer Scientist Should Know About Floating-Point Arithmetic by David Goldberg.



        A binary floating-point number is actually represented by three integers: a sign bit s, a significand (or coefficient/fraction) b, and an exponent e. For double-precision floating-point format, each number is represented by 64 bits laid out in memory as follows:



        enter image description here



        The real value can then be found with the following formula:



        enter image description here



        This format allows for number representations in the range 10^-308 to 10^308. For MATLAB you can get these limits from realmin and realmax:



        >> realmin
        ans =
        2.225073858507201e-308
        >> realmax
        ans =
        1.797693134862316e+308


        Since there are a finite number of bits used to represent a floating-point number, there are only so many finite numbers that can be represented within the above given range. Computations will often result in a value that doesn't exactly match one of these finite representations, so the values must be rounded off. These machine-precision errors make themselves evident in different ways, as discussed in the above examples.



        In order to better understand these round-off errors it's useful to look at the relative floating-point accuracy provided by the function eps, which quantifies the distance from a given number to the next largest floating-point representation:



        >> eps(1)
        ans =
        2.220446049250313e-16
        >> eps(1000)
        ans =
        1.136868377216160e-13


        Notice that the precision is relative to the size of a given number being represented; larger numbers will have larger distances between floating-point representations, and will thus have fewer digits of precision following the decimal point. This can be an important consideration with some calculations. Consider the following example:



        >> format long              % Display full precision
        >> x = rand(1, 10); % Get 10 random values between 0 and 1
        >> a = mean(x) % Take the mean
        a =
        0.587307428244141
        >> b = mean(x+10000)-10000 % Take the mean at a different scale, then shift back
        b =
        0.587307428244458


        Note that when we shift the values of x from the range [0 1] to the range [10000 10001], compute a mean, then subtract the mean offset for comparison, we get a value that differs for the last 3 significant digits. This illustrates how an offset or scaling of data can change the accuracy of calculations performed on it, which is something that has to be accounted for with certain problems.






        share|improve this answer















        The problem you're having relates to how floating-point numbers are represented on a computer. A more detailed discussion of floating-point representations appears towards the end of my answer (The "Floating-point representation" section). The TL;DR version: because computers have finite amounts of memory, numbers can only be represented with finite precision. Thus, the accuracy of floating-point numbers is limited to a certain number of decimal places (about 16 significant digits for double-precision values, the default used in MATLAB).



        Actual vs. displayed precision



        Now to address the specific example in the question... while 24.0000 and 24.0000 are displayed in the same manner, it turns out that they actually differ by very small decimal amounts in this case. You don't see it because MATLAB only displays 4 significant digits by default, keeping the overall display neat and tidy. If you want to see the full precision, you should either issue the format long command or view a hexadecimal representation of the number:



        >> pi
        ans =
        3.1416
        >> format long
        >> pi
        ans =
        3.141592653589793
        >> num2hex(pi)
        ans =
        400921fb54442d18


        Initialized values vs. computed values



        Since there are only a finite number of values that can be represented for a floating-point number, it's possible for a computation to result in a value that falls between two of these representations. In such a case, the result has to be rounded off to one of them. This introduces a small machine-precision error. This also means that initializing a value directly or by some computation can give slightly different results. For example, the value 0.1 doesn't have an exact floating-point representation (i.e. it gets slightly rounded off), and so you end up with counter-intuitive results like this due to the way round-off errors accumulate:



        >> a=sum([0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.1]);  % Sum 10 0.1s
        >> b=1; % Initialize to 1
        >> a == b
        ans =
        logical
        0 % They are unequal!
        >> num2hex(a) % Let's check their hex representation to confirm
        ans =
        3fefffffffffffff
        >> num2hex(b)
        ans =
        3ff0000000000000


        How to correctly handle floating-point comparisons



        Since floating-point values can differ by very small amounts, any comparisons should be done by checking that the values are within some range (i.e. tolerance) of one another, as opposed to exactly equal to each other. For example:



        a = 24;
        b = 24.000001;
        tolerance = 0.001;
        if abs(a-b) < tolerance, disp('Equal!'); end


        will display "Equal!".



        You could then change your code to something like:



        points = points((abs(points(:,1)-vertex1(1)) > tolerance) | ...
        (abs(points(:,2)-vertex1(2)) > tolerance),:)




        Floating-point representation



        A good overview of floating-point numbers (and specifically the IEEE 754 standard for floating-point arithmetic) is What Every Computer Scientist Should Know About Floating-Point Arithmetic by David Goldberg.



        A binary floating-point number is actually represented by three integers: a sign bit s, a significand (or coefficient/fraction) b, and an exponent e. For double-precision floating-point format, each number is represented by 64 bits laid out in memory as follows:



        enter image description here



        The real value can then be found with the following formula:



        enter image description here



        This format allows for number representations in the range 10^-308 to 10^308. For MATLAB you can get these limits from realmin and realmax:



        >> realmin
        ans =
        2.225073858507201e-308
        >> realmax
        ans =
        1.797693134862316e+308


        Since there are a finite number of bits used to represent a floating-point number, there are only so many finite numbers that can be represented within the above given range. Computations will often result in a value that doesn't exactly match one of these finite representations, so the values must be rounded off. These machine-precision errors make themselves evident in different ways, as discussed in the above examples.



        In order to better understand these round-off errors it's useful to look at the relative floating-point accuracy provided by the function eps, which quantifies the distance from a given number to the next largest floating-point representation:



        >> eps(1)
        ans =
        2.220446049250313e-16
        >> eps(1000)
        ans =
        1.136868377216160e-13


        Notice that the precision is relative to the size of a given number being represented; larger numbers will have larger distances between floating-point representations, and will thus have fewer digits of precision following the decimal point. This can be an important consideration with some calculations. Consider the following example:



        >> format long              % Display full precision
        >> x = rand(1, 10); % Get 10 random values between 0 and 1
        >> a = mean(x) % Take the mean
        a =
        0.587307428244141
        >> b = mean(x+10000)-10000 % Take the mean at a different scale, then shift back
        b =
        0.587307428244458


        Note that when we shift the values of x from the range [0 1] to the range [10000 10001], compute a mean, then subtract the mean offset for comparison, we get a value that differs for the last 3 significant digits. This illustrates how an offset or scaling of data can change the accuracy of calculations performed on it, which is something that has to be accounted for with certain problems.







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited Feb 23 '17 at 18:09









        Kamran Bigdely

        3,275114465




        3,275114465










        answered Mar 26 '09 at 16:14









        gnovicegnovice

        116k13231335




        116k13231335













        • why can't I see that small decimal amount?

          – Kamran Bigdely
          Mar 26 '09 at 16:18






        • 2





          you can see it if you view the variable in the matrix view. Right click on variable -> "View selection" or something? I don't have MATLAB here, so I can't check.

          – atsjoo
          Mar 26 '09 at 16:20






        • 4





          You can also see small differences by typing "format long" at the command prompt.

          – gnovice
          Mar 26 '09 at 16:23






        • 2





          you are right: format long points = 12.000000000000000 15.000000000000000 33.000000000000000 23.999999999999996 33.000000000000000 24.000000000000000

          – Kamran Bigdely
          Mar 26 '09 at 20:02






        • 6





          "format hex" can sometimes help even more than format long here.

          – Sam Roberts
          Oct 5 '09 at 15:25



















        • why can't I see that small decimal amount?

          – Kamran Bigdely
          Mar 26 '09 at 16:18






        • 2





          you can see it if you view the variable in the matrix view. Right click on variable -> "View selection" or something? I don't have MATLAB here, so I can't check.

          – atsjoo
          Mar 26 '09 at 16:20






        • 4





          You can also see small differences by typing "format long" at the command prompt.

          – gnovice
          Mar 26 '09 at 16:23






        • 2





          you are right: format long points = 12.000000000000000 15.000000000000000 33.000000000000000 23.999999999999996 33.000000000000000 24.000000000000000

          – Kamran Bigdely
          Mar 26 '09 at 20:02






        • 6





          "format hex" can sometimes help even more than format long here.

          – Sam Roberts
          Oct 5 '09 at 15:25

















        why can't I see that small decimal amount?

        – Kamran Bigdely
        Mar 26 '09 at 16:18





        why can't I see that small decimal amount?

        – Kamran Bigdely
        Mar 26 '09 at 16:18




        2




        2





        you can see it if you view the variable in the matrix view. Right click on variable -> "View selection" or something? I don't have MATLAB here, so I can't check.

        – atsjoo
        Mar 26 '09 at 16:20





        you can see it if you view the variable in the matrix view. Right click on variable -> "View selection" or something? I don't have MATLAB here, so I can't check.

        – atsjoo
        Mar 26 '09 at 16:20




        4




        4





        You can also see small differences by typing "format long" at the command prompt.

        – gnovice
        Mar 26 '09 at 16:23





        You can also see small differences by typing "format long" at the command prompt.

        – gnovice
        Mar 26 '09 at 16:23




        2




        2





        you are right: format long points = 12.000000000000000 15.000000000000000 33.000000000000000 23.999999999999996 33.000000000000000 24.000000000000000

        – Kamran Bigdely
        Mar 26 '09 at 20:02





        you are right: format long points = 12.000000000000000 15.000000000000000 33.000000000000000 23.999999999999996 33.000000000000000 24.000000000000000

        – Kamran Bigdely
        Mar 26 '09 at 20:02




        6




        6





        "format hex" can sometimes help even more than format long here.

        – Sam Roberts
        Oct 5 '09 at 15:25





        "format hex" can sometimes help even more than format long here.

        – Sam Roberts
        Oct 5 '09 at 15:25













        21














        Look at this article: The Perils of Floating Point. Though its examples are in FORTRAN it has sense for virtually any modern programming language, including MATLAB. Your problem (and solution for it) is described in "Safe Comparisons" section.






        share|improve this answer



















        • 1





          I discovered it some time ago and was very impressed with it =) Now I always recommend it in similar situations.

          – Rorick
          Mar 27 '09 at 8:26











        • Archived version of this excellent resource!

          – wizclown
          Jul 12 '18 at 12:37
















        21














        Look at this article: The Perils of Floating Point. Though its examples are in FORTRAN it has sense for virtually any modern programming language, including MATLAB. Your problem (and solution for it) is described in "Safe Comparisons" section.






        share|improve this answer



















        • 1





          I discovered it some time ago and was very impressed with it =) Now I always recommend it in similar situations.

          – Rorick
          Mar 27 '09 at 8:26











        • Archived version of this excellent resource!

          – wizclown
          Jul 12 '18 at 12:37














        21












        21








        21







        Look at this article: The Perils of Floating Point. Though its examples are in FORTRAN it has sense for virtually any modern programming language, including MATLAB. Your problem (and solution for it) is described in "Safe Comparisons" section.






        share|improve this answer













        Look at this article: The Perils of Floating Point. Though its examples are in FORTRAN it has sense for virtually any modern programming language, including MATLAB. Your problem (and solution for it) is described in "Safe Comparisons" section.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Mar 26 '09 at 16:18









        RorickRorick

        7,28332836




        7,28332836








        • 1





          I discovered it some time ago and was very impressed with it =) Now I always recommend it in similar situations.

          – Rorick
          Mar 27 '09 at 8:26











        • Archived version of this excellent resource!

          – wizclown
          Jul 12 '18 at 12:37














        • 1





          I discovered it some time ago and was very impressed with it =) Now I always recommend it in similar situations.

          – Rorick
          Mar 27 '09 at 8:26











        • Archived version of this excellent resource!

          – wizclown
          Jul 12 '18 at 12:37








        1




        1





        I discovered it some time ago and was very impressed with it =) Now I always recommend it in similar situations.

        – Rorick
        Mar 27 '09 at 8:26





        I discovered it some time ago and was very impressed with it =) Now I always recommend it in similar situations.

        – Rorick
        Mar 27 '09 at 8:26













        Archived version of this excellent resource!

        – wizclown
        Jul 12 '18 at 12:37





        Archived version of this excellent resource!

        – wizclown
        Jul 12 '18 at 12:37











        12














        type



        format long g


        This command will show the FULL value of the number. It's likely to be something like 24.00000021321 != 24.00000123124






        share|improve this answer




























          12














          type



          format long g


          This command will show the FULL value of the number. It's likely to be something like 24.00000021321 != 24.00000123124






          share|improve this answer


























            12












            12








            12







            type



            format long g


            This command will show the FULL value of the number. It's likely to be something like 24.00000021321 != 24.00000123124






            share|improve this answer













            type



            format long g


            This command will show the FULL value of the number. It's likely to be something like 24.00000021321 != 24.00000123124







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered Mar 26 '09 at 21:14









            KitsuneYMGKitsuneYMG

            10.8k33252




            10.8k33252























                7














                Try writing




                0.1 + 0.1 + 0.1 == 0.3.




                Warning: You might be surprised about the result!






                share|improve this answer
























                • I tried it and it returns 0. But I don't see what it has to do, with the problem above. Can you pls explain it to me?

                  – Max
                  Sep 16 '15 at 8:46






                • 6





                  This is because 0.1 comes with some floating point error, and when you add three such terms together, the errors do not necessarily add up to 0. The same issue is causing (floating) 24 to not be exactly equal to (another floating) 24.

                  – Derek
                  Mar 4 '16 at 11:14
















                7














                Try writing




                0.1 + 0.1 + 0.1 == 0.3.




                Warning: You might be surprised about the result!






                share|improve this answer
























                • I tried it and it returns 0. But I don't see what it has to do, with the problem above. Can you pls explain it to me?

                  – Max
                  Sep 16 '15 at 8:46






                • 6





                  This is because 0.1 comes with some floating point error, and when you add three such terms together, the errors do not necessarily add up to 0. The same issue is causing (floating) 24 to not be exactly equal to (another floating) 24.

                  – Derek
                  Mar 4 '16 at 11:14














                7












                7








                7







                Try writing




                0.1 + 0.1 + 0.1 == 0.3.




                Warning: You might be surprised about the result!






                share|improve this answer













                Try writing




                0.1 + 0.1 + 0.1 == 0.3.




                Warning: You might be surprised about the result!







                share|improve this answer












                share|improve this answer



                share|improve this answer










                answered Dec 14 '11 at 18:55









                Andrey RubshteinAndrey Rubshtein

                18.4k85497




                18.4k85497













                • I tried it and it returns 0. But I don't see what it has to do, with the problem above. Can you pls explain it to me?

                  – Max
                  Sep 16 '15 at 8:46






                • 6





                  This is because 0.1 comes with some floating point error, and when you add three such terms together, the errors do not necessarily add up to 0. The same issue is causing (floating) 24 to not be exactly equal to (another floating) 24.

                  – Derek
                  Mar 4 '16 at 11:14



















                • I tried it and it returns 0. But I don't see what it has to do, with the problem above. Can you pls explain it to me?

                  – Max
                  Sep 16 '15 at 8:46






                • 6





                  This is because 0.1 comes with some floating point error, and when you add three such terms together, the errors do not necessarily add up to 0. The same issue is causing (floating) 24 to not be exactly equal to (another floating) 24.

                  – Derek
                  Mar 4 '16 at 11:14

















                I tried it and it returns 0. But I don't see what it has to do, with the problem above. Can you pls explain it to me?

                – Max
                Sep 16 '15 at 8:46





                I tried it and it returns 0. But I don't see what it has to do, with the problem above. Can you pls explain it to me?

                – Max
                Sep 16 '15 at 8:46




                6




                6





                This is because 0.1 comes with some floating point error, and when you add three such terms together, the errors do not necessarily add up to 0. The same issue is causing (floating) 24 to not be exactly equal to (another floating) 24.

                – Derek
                Mar 4 '16 at 11:14





                This is because 0.1 comes with some floating point error, and when you add three such terms together, the errors do not necessarily add up to 0. The same issue is causing (floating) 24 to not be exactly equal to (another floating) 24.

                – Derek
                Mar 4 '16 at 11:14











                2














                Maybe the two numbers are really 24.0 and 24.000000001 but you're not seeing all the decimal places.






                share|improve this answer




























                  2














                  Maybe the two numbers are really 24.0 and 24.000000001 but you're not seeing all the decimal places.






                  share|improve this answer


























                    2












                    2








                    2







                    Maybe the two numbers are really 24.0 and 24.000000001 but you're not seeing all the decimal places.






                    share|improve this answer













                    Maybe the two numbers are really 24.0 and 24.000000001 but you're not seeing all the decimal places.







                    share|improve this answer












                    share|improve this answer



                    share|improve this answer










                    answered Mar 26 '09 at 16:17









                    Jimmy JJimmy J

                    1,51811019




                    1,51811019























                        1














                        Check out the Matlab EPS function.



                        Matlab uses floating point math up to 16 digits of precision (only 5 are displayed).






                        share|improve this answer






























                          1














                          Check out the Matlab EPS function.



                          Matlab uses floating point math up to 16 digits of precision (only 5 are displayed).






                          share|improve this answer




























                            1












                            1








                            1







                            Check out the Matlab EPS function.



                            Matlab uses floating point math up to 16 digits of precision (only 5 are displayed).






                            share|improve this answer















                            Check out the Matlab EPS function.



                            Matlab uses floating point math up to 16 digits of precision (only 5 are displayed).







                            share|improve this answer














                            share|improve this answer



                            share|improve this answer








                            edited Dec 9 '17 at 17:28









                            Dmitri Chubarov

                            11.1k22454




                            11.1k22454










                            answered Mar 26 '09 at 16:25









                            jlejle

                            7,04523963




                            7,04523963






























                                draft saved

                                draft discarded




















































                                Thanks for contributing an answer to Stack Overflow!


                                • Please be sure to answer the question. Provide details and share your research!

                                But avoid



                                • Asking for help, clarification, or responding to other answers.

                                • Making statements based on opinion; back them up with references or personal experience.


                                To learn more, see our tips on writing great answers.




                                draft saved


                                draft discarded














                                StackExchange.ready(
                                function () {
                                StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f686439%2fwhy-is-24-0000-not-equal-to-24-0000-in-matlab%23new-answer', 'question_page');
                                }
                                );

                                Post as a guest















                                Required, but never shown





















































                                Required, but never shown














                                Required, but never shown












                                Required, but never shown







                                Required, but never shown

































                                Required, but never shown














                                Required, but never shown












                                Required, but never shown







                                Required, but never shown







                                Popular posts from this blog

                                Guess what letter conforming each word

                                Port of Spain

                                Run scheduled task as local user group (not BUILTIN)