Why are these numbers not equal?












243















The following code is obviously wrong. What's the problem?



i <- 0.1
i <- i + 0.05
i
## [1] 0.15
if(i==0.15) cat("i equals 0.15") else cat("i does not equal 0.15")
## i does not equal 0.15









share|improve this question




















  • 5





    See also stackoverflow.com/q/6874867 and stackoverflow.com/q/2769510. The R Inferno is also another great read.

    – Aaron
    Mar 1 '12 at 2:10








  • 1





    A site-wide language-agnostic Q and A: Is floating point math broken?

    – Gregor
    Mar 21 at 20:30
















243















The following code is obviously wrong. What's the problem?



i <- 0.1
i <- i + 0.05
i
## [1] 0.15
if(i==0.15) cat("i equals 0.15") else cat("i does not equal 0.15")
## i does not equal 0.15









share|improve this question




















  • 5





    See also stackoverflow.com/q/6874867 and stackoverflow.com/q/2769510. The R Inferno is also another great read.

    – Aaron
    Mar 1 '12 at 2:10








  • 1





    A site-wide language-agnostic Q and A: Is floating point math broken?

    – Gregor
    Mar 21 at 20:30














243












243








243


90






The following code is obviously wrong. What's the problem?



i <- 0.1
i <- i + 0.05
i
## [1] 0.15
if(i==0.15) cat("i equals 0.15") else cat("i does not equal 0.15")
## i does not equal 0.15









share|improve this question
















The following code is obviously wrong. What's the problem?



i <- 0.1
i <- i + 0.05
i
## [1] 0.15
if(i==0.15) cat("i equals 0.15") else cat("i does not equal 0.15")
## i does not equal 0.15






r floating-point floating-accuracy r-faq






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited May 30 '18 at 19:56









Jaap

57.4k21124137




57.4k21124137










asked Feb 29 '12 at 23:46









dplanetdplanet

2,11082240




2,11082240








  • 5





    See also stackoverflow.com/q/6874867 and stackoverflow.com/q/2769510. The R Inferno is also another great read.

    – Aaron
    Mar 1 '12 at 2:10








  • 1





    A site-wide language-agnostic Q and A: Is floating point math broken?

    – Gregor
    Mar 21 at 20:30














  • 5





    See also stackoverflow.com/q/6874867 and stackoverflow.com/q/2769510. The R Inferno is also another great read.

    – Aaron
    Mar 1 '12 at 2:10








  • 1





    A site-wide language-agnostic Q and A: Is floating point math broken?

    – Gregor
    Mar 21 at 20:30








5




5





See also stackoverflow.com/q/6874867 and stackoverflow.com/q/2769510. The R Inferno is also another great read.

– Aaron
Mar 1 '12 at 2:10







See also stackoverflow.com/q/6874867 and stackoverflow.com/q/2769510. The R Inferno is also another great read.

– Aaron
Mar 1 '12 at 2:10






1




1





A site-wide language-agnostic Q and A: Is floating point math broken?

– Gregor
Mar 21 at 20:30





A site-wide language-agnostic Q and A: Is floating point math broken?

– Gregor
Mar 21 at 20:30












5 Answers
5






active

oldest

votes


















319














General (language agnostic) reason



Since not all numbers can be represented exactly in IEEE floating point arithmetic (the standard that almost all computers use to represent decimal numbers and do math with them), you will not always get what you expected. This is especially true because some values which are simple, finite decimals (such as 0.1 and 0.05) are not represented exactly in the computer and so the results of arithmetic on them may not give a result that is identical to a direct representation of the "known" answer.



This is a well known limitation of computer arithmetic and is discussed in several places:




  • The R FAQ has question devoted to it: R FAQ 7.31


  • The R Inferno by Patrick Burns devotes the first "Circle" to this problem (starting on page 9)

  • David Goldberg, "What Every Computer Scientist Should Know About Floating-point Arithmetic," ACM Computing Surveys 23, 1 (1991-03), 5-48 doi>10.1145/103162.103163 (revision also available)

  • The Floating-Point Guide - What Every Programmer Should Know About Floating-Point Arithmetic


  • 0.30000000000000004.com compares floating point arithmetic across programming languages

  • Several Stack Overflow questions including


    • Why Are Floating Point Numbers Inaccurate?

    • Why can't decimal numbers be represented exactly in binary?

    • Is floating point math broken?


    • Canonical duplicate for "floating point is inaccurate" (a meta discussion about a canonical answer for this issue)




Comparing scalars



The standard solution to this in R is not to use ==, but rather the all.equal function. Or rather, since all.equal gives lots of detail about the differences if there are any, isTRUE(all.equal(...)).



if(isTRUE(all.equal(i,0.15))) cat("i equals 0.15") else cat("i does not equal 0.15")


yields



i equals 0.15


Some more examples of using all.equal instead of == (the last example is supposed to show that this will correctly show differences).



0.1+0.05==0.15
#[1] FALSE
isTRUE(all.equal(0.1+0.05, 0.15))
#[1] TRUE
1-0.1-0.1-0.1==0.7
#[1] FALSE
isTRUE(all.equal(1-0.1-0.1-0.1, 0.7))
#[1] TRUE
0.3/0.1 == 3
#[1] FALSE
isTRUE(all.equal(0.3/0.1, 3))
#[1] TRUE
0.1+0.1==0.15
#[1] FALSE
isTRUE(all.equal(0.1+0.1, 0.15))
#[1] FALSE


Some more detail, directly copied from an answer to a similar question:



The problem you have encountered is that floating point cannot represent decimal fractions exactly in most cases, which means you will frequently find that exact matches fail.



while R lies slightly when you say:



1.1-0.2
#[1] 0.9
0.9
#[1] 0.9


You can find out what it really thinks in decimal:



sprintf("%.54f",1.1-0.2)
#[1] "0.900000000000000133226762955018784850835800170898437500"
sprintf("%.54f",0.9)
#[1] "0.900000000000000022204460492503130808472633361816406250"


You can see these numbers are different, but the representation is a bit unwieldy. If we look at them in binary (well, hex, which is equivalent) we get a clearer picture:



sprintf("%a",0.9)
#[1] "0x1.ccccccccccccdp-1"
sprintf("%a",1.1-0.2)
#[1] "0x1.ccccccccccccep-1"
sprintf("%a",1.1-0.2-0.9)
#[1] "0x1p-53"


You can see that they differ by 2^-53, which is important because this number is the smallest representable difference between two numbers whose value is close to 1, as this is.



We can find out for any given computer what this smallest representable number is by looking in R's machine field:



 ?.Machine
#....
#double.eps the smallest positive floating-point number x
#such that 1 + x != 1. It equals base^ulp.digits if either
#base is 2 or rounding is 0; otherwise, it is
#(base^ulp.digits) / 2. Normally 2.220446e-16.
#....
.Machine$double.eps
#[1] 2.220446e-16
sprintf("%a",.Machine$double.eps)
#[1] "0x1p-52"


You can use this fact to create a 'nearly equals' function which checks that the difference is close to the smallest representable number in floating point. In fact this already exists: all.equal.



?all.equal
#....
#all.equal(x,y) is a utility to compare R objects x and y testing ‘near equality’.
#....
#all.equal(target, current,
# tolerance = .Machine$double.eps ^ 0.5,
# scale = NULL, check.attributes = TRUE, ...)
#....


So the all.equal function is actually checking that the difference between the numbers is the square root of the smallest difference between two mantissas.



This algorithm goes a bit funny near extremely small numbers called denormals, but you don't need to worry about that.



Comparing vectors



The above discussion assumed a comparison of two single values. In R, there are no scalars, just vectors and implicit vectorization is a strength of the language. For comparing the value of vectors element-wise, the previous principles hold, but the implementation is slightly different. == is vectorized (does an element-wise comparison) while all.equal compares the whole vectors as a single entity.



Using the previous examples



a <- c(0.1+0.05, 1-0.1-0.1-0.1, 0.3/0.1, 0.1+0.1)
b <- c(0.15, 0.7, 3, 0.15)


== does not give the "expected" result and all.equal does not perform element-wise



a==b
#[1] FALSE FALSE FALSE FALSE
all.equal(a,b)
#[1] "Mean relative difference: 0.01234568"
isTRUE(all.equal(a,b))
#[1] FALSE


Rather, a version which loops over the two vectors must be used



mapply(function(x, y) {isTRUE(all.equal(x, y))}, a, b)
#[1] TRUE TRUE TRUE FALSE


If a functional version of this is desired, it can be written



elementwise.all.equal <- Vectorize(function(x, y) {isTRUE(all.equal(x, y))})


which can be called as just



elementwise.all.equal(a, b)
#[1] TRUE TRUE TRUE FALSE


Alternatively, instead of wrapping all.equal in even more function calls, you can just replicate the relevant internals of all.equal.numeric and use implicit vectorization:



tolerance = .Machine$double.eps^0.5
# this is the default tolerance used in all.equal,
# but you can pick a different tolerance to match your needs

abs(a - b) < tolerance
#[1] TRUE TRUE TRUE FALSE





share|improve this answer

































    37














    Adding to Brian's comment (which is the reason) you can over come this by using all.equal instead:



    # i <- 0.1
    # i <- i + 0.05
    # i
    #if(all.equal(i, .15)) cat("i equals 0.15n") else cat("i does not equal 0.15n")
    #i equals 0.15


    Per Joshua's warning here is the updated code (Thanks Joshua):



     i <- 0.1
    i <- i + 0.05
    i
    if(isTRUE(all.equal(i, .15))) { #code was getting sloppy &went to multiple lines
    cat("i equals 0.15n")
    } else {
    cat("i does not equal 0.15n")
    }
    #i equals 0.15





    share|improve this answer


























    • I missed Brian's link which explains my response succinctly.

      – Tyler Rinker
      Feb 29 '12 at 23:57






    • 15





      all.equal doesn't return FALSE when there are differences, so you need to wrap it with isTRUE when using it in an if statement.

      – Joshua Ulrich
      Mar 1 '12 at 0:49





















    9














    This is hackish, but quick:



    if(round(i, 10)==0.15) cat("i equals 0.15") else cat("i does not equal 0.15")





    share|improve this answer



















    • 2





      But you can use the all.equal(... tolerance) parameter. all.equal(0.147, 0.15, tolerance=0.05) is TRUE.

      – smci
      May 28 '18 at 11:25



















    3














    dplyr::near() is an option for testing if two vectors of floating point numbers are equal. This is the example from the docs:



    sqrt(2) ^ 2 == 2
    #> [1] FALSE
    library(dplyr)
    near(sqrt(2) ^ 2, 2)
    #> [1] TRUE


    The function has a built in tolerance parameter: tol = .Machine$double.eps^0.5 that can be adjusted. The default parameter is the same as the default for all.equal().






    share|improve this answer































      0














      I had a similar problem. I used the following solution.




      @ I found this work around solution about unequal cut intervals. @ I
      used the round function in R. By setting the option to 2 digits, did
      not solved the problem.




      options(digits = 2)
      cbind(
      seq( from = 1, to = 9, by = 1 ),
      cut( seq( from = 1, to = 9, by = 1), c( 0, 3, 6, 9 ) ),
      seq( from = 0.1, to = 0.9, by = 0.1 ),
      cut( seq( from = 0.1, to = 0.9, by = 0.1), c( 0, 0.3, 0.6, 0.9 )),
      seq( from = 0.01, to = 0.09, by = 0.01 ),
      cut( seq( from = 0.01, to = 0.09, by = 0.01), c( 0, 0.03, 0.06, 0.09 ))
      )


      output of unequal cut intervals based on options(digits = 2):



        [,1] [,2] [,3] [,4] [,5] [,6]
      [1,] 1 1 0.1 1 0.01 1
      [2,] 2 1 0.2 1 0.02 1
      [3,] 3 1 0.3 2 0.03 1
      [4,] 4 2 0.4 2 0.04 2
      [5,] 5 2 0.5 2 0.05 2
      [6,] 6 2 0.6 2 0.06 3
      [7,] 7 3 0.7 3 0.07 3
      [8,] 8 3 0.8 3 0.08 3
      [9,] 9 3 0.9 3 0.09 3


      options(digits = 200)
      cbind(
      seq( from = 1, to = 9, by = 1 ),
      cut( round(seq( from = 1, to = 9, by = 1), 2), c( 0, 3, 6, 9 ) ),
      seq( from = 0.1, to = 0.9, by = 0.1 ),
      cut( round(seq( from = 0.1, to = 0.9, by = 0.1), 2), c( 0, 0.3, 0.6, 0.9 )),
      seq( from = 0.01, to = 0.09, by = 0.01 ),
      cut( round(seq( from = 0.01, to = 0.09, by = 0.01), 2), c( 0, 0.03, 0.06, 0.09 ))
      )


      output of equal cut intervals based on round function:



            [,1] [,2] [,3] [,4] [,5] [,6]
      [1,] 1 1 0.1 1 0.01 1
      [2,] 2 1 0.2 1 0.02 1
      [3,] 3 1 0.3 1 0.03 1
      [4,] 4 2 0.4 2 0.04 2
      [5,] 5 2 0.5 2 0.05 2
      [6,] 6 2 0.6 2 0.06 2
      [7,] 7 3 0.7 3 0.07 3
      [8,] 8 3 0.8 3 0.08 3
      [9,] 9 3 0.9 3 0.09 3





      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%2f9508518%2fwhy-are-these-numbers-not-equal%23new-answer', 'question_page');
        }
        );

        Post as a guest















        Required, but never shown

























        5 Answers
        5






        active

        oldest

        votes








        5 Answers
        5






        active

        oldest

        votes









        active

        oldest

        votes






        active

        oldest

        votes









        319














        General (language agnostic) reason



        Since not all numbers can be represented exactly in IEEE floating point arithmetic (the standard that almost all computers use to represent decimal numbers and do math with them), you will not always get what you expected. This is especially true because some values which are simple, finite decimals (such as 0.1 and 0.05) are not represented exactly in the computer and so the results of arithmetic on them may not give a result that is identical to a direct representation of the "known" answer.



        This is a well known limitation of computer arithmetic and is discussed in several places:




        • The R FAQ has question devoted to it: R FAQ 7.31


        • The R Inferno by Patrick Burns devotes the first "Circle" to this problem (starting on page 9)

        • David Goldberg, "What Every Computer Scientist Should Know About Floating-point Arithmetic," ACM Computing Surveys 23, 1 (1991-03), 5-48 doi>10.1145/103162.103163 (revision also available)

        • The Floating-Point Guide - What Every Programmer Should Know About Floating-Point Arithmetic


        • 0.30000000000000004.com compares floating point arithmetic across programming languages

        • Several Stack Overflow questions including


          • Why Are Floating Point Numbers Inaccurate?

          • Why can't decimal numbers be represented exactly in binary?

          • Is floating point math broken?


          • Canonical duplicate for "floating point is inaccurate" (a meta discussion about a canonical answer for this issue)




        Comparing scalars



        The standard solution to this in R is not to use ==, but rather the all.equal function. Or rather, since all.equal gives lots of detail about the differences if there are any, isTRUE(all.equal(...)).



        if(isTRUE(all.equal(i,0.15))) cat("i equals 0.15") else cat("i does not equal 0.15")


        yields



        i equals 0.15


        Some more examples of using all.equal instead of == (the last example is supposed to show that this will correctly show differences).



        0.1+0.05==0.15
        #[1] FALSE
        isTRUE(all.equal(0.1+0.05, 0.15))
        #[1] TRUE
        1-0.1-0.1-0.1==0.7
        #[1] FALSE
        isTRUE(all.equal(1-0.1-0.1-0.1, 0.7))
        #[1] TRUE
        0.3/0.1 == 3
        #[1] FALSE
        isTRUE(all.equal(0.3/0.1, 3))
        #[1] TRUE
        0.1+0.1==0.15
        #[1] FALSE
        isTRUE(all.equal(0.1+0.1, 0.15))
        #[1] FALSE


        Some more detail, directly copied from an answer to a similar question:



        The problem you have encountered is that floating point cannot represent decimal fractions exactly in most cases, which means you will frequently find that exact matches fail.



        while R lies slightly when you say:



        1.1-0.2
        #[1] 0.9
        0.9
        #[1] 0.9


        You can find out what it really thinks in decimal:



        sprintf("%.54f",1.1-0.2)
        #[1] "0.900000000000000133226762955018784850835800170898437500"
        sprintf("%.54f",0.9)
        #[1] "0.900000000000000022204460492503130808472633361816406250"


        You can see these numbers are different, but the representation is a bit unwieldy. If we look at them in binary (well, hex, which is equivalent) we get a clearer picture:



        sprintf("%a",0.9)
        #[1] "0x1.ccccccccccccdp-1"
        sprintf("%a",1.1-0.2)
        #[1] "0x1.ccccccccccccep-1"
        sprintf("%a",1.1-0.2-0.9)
        #[1] "0x1p-53"


        You can see that they differ by 2^-53, which is important because this number is the smallest representable difference between two numbers whose value is close to 1, as this is.



        We can find out for any given computer what this smallest representable number is by looking in R's machine field:



         ?.Machine
        #....
        #double.eps the smallest positive floating-point number x
        #such that 1 + x != 1. It equals base^ulp.digits if either
        #base is 2 or rounding is 0; otherwise, it is
        #(base^ulp.digits) / 2. Normally 2.220446e-16.
        #....
        .Machine$double.eps
        #[1] 2.220446e-16
        sprintf("%a",.Machine$double.eps)
        #[1] "0x1p-52"


        You can use this fact to create a 'nearly equals' function which checks that the difference is close to the smallest representable number in floating point. In fact this already exists: all.equal.



        ?all.equal
        #....
        #all.equal(x,y) is a utility to compare R objects x and y testing ‘near equality’.
        #....
        #all.equal(target, current,
        # tolerance = .Machine$double.eps ^ 0.5,
        # scale = NULL, check.attributes = TRUE, ...)
        #....


        So the all.equal function is actually checking that the difference between the numbers is the square root of the smallest difference between two mantissas.



        This algorithm goes a bit funny near extremely small numbers called denormals, but you don't need to worry about that.



        Comparing vectors



        The above discussion assumed a comparison of two single values. In R, there are no scalars, just vectors and implicit vectorization is a strength of the language. For comparing the value of vectors element-wise, the previous principles hold, but the implementation is slightly different. == is vectorized (does an element-wise comparison) while all.equal compares the whole vectors as a single entity.



        Using the previous examples



        a <- c(0.1+0.05, 1-0.1-0.1-0.1, 0.3/0.1, 0.1+0.1)
        b <- c(0.15, 0.7, 3, 0.15)


        == does not give the "expected" result and all.equal does not perform element-wise



        a==b
        #[1] FALSE FALSE FALSE FALSE
        all.equal(a,b)
        #[1] "Mean relative difference: 0.01234568"
        isTRUE(all.equal(a,b))
        #[1] FALSE


        Rather, a version which loops over the two vectors must be used



        mapply(function(x, y) {isTRUE(all.equal(x, y))}, a, b)
        #[1] TRUE TRUE TRUE FALSE


        If a functional version of this is desired, it can be written



        elementwise.all.equal <- Vectorize(function(x, y) {isTRUE(all.equal(x, y))})


        which can be called as just



        elementwise.all.equal(a, b)
        #[1] TRUE TRUE TRUE FALSE


        Alternatively, instead of wrapping all.equal in even more function calls, you can just replicate the relevant internals of all.equal.numeric and use implicit vectorization:



        tolerance = .Machine$double.eps^0.5
        # this is the default tolerance used in all.equal,
        # but you can pick a different tolerance to match your needs

        abs(a - b) < tolerance
        #[1] TRUE TRUE TRUE FALSE





        share|improve this answer






























          319














          General (language agnostic) reason



          Since not all numbers can be represented exactly in IEEE floating point arithmetic (the standard that almost all computers use to represent decimal numbers and do math with them), you will not always get what you expected. This is especially true because some values which are simple, finite decimals (such as 0.1 and 0.05) are not represented exactly in the computer and so the results of arithmetic on them may not give a result that is identical to a direct representation of the "known" answer.



          This is a well known limitation of computer arithmetic and is discussed in several places:




          • The R FAQ has question devoted to it: R FAQ 7.31


          • The R Inferno by Patrick Burns devotes the first "Circle" to this problem (starting on page 9)

          • David Goldberg, "What Every Computer Scientist Should Know About Floating-point Arithmetic," ACM Computing Surveys 23, 1 (1991-03), 5-48 doi>10.1145/103162.103163 (revision also available)

          • The Floating-Point Guide - What Every Programmer Should Know About Floating-Point Arithmetic


          • 0.30000000000000004.com compares floating point arithmetic across programming languages

          • Several Stack Overflow questions including


            • Why Are Floating Point Numbers Inaccurate?

            • Why can't decimal numbers be represented exactly in binary?

            • Is floating point math broken?


            • Canonical duplicate for "floating point is inaccurate" (a meta discussion about a canonical answer for this issue)




          Comparing scalars



          The standard solution to this in R is not to use ==, but rather the all.equal function. Or rather, since all.equal gives lots of detail about the differences if there are any, isTRUE(all.equal(...)).



          if(isTRUE(all.equal(i,0.15))) cat("i equals 0.15") else cat("i does not equal 0.15")


          yields



          i equals 0.15


          Some more examples of using all.equal instead of == (the last example is supposed to show that this will correctly show differences).



          0.1+0.05==0.15
          #[1] FALSE
          isTRUE(all.equal(0.1+0.05, 0.15))
          #[1] TRUE
          1-0.1-0.1-0.1==0.7
          #[1] FALSE
          isTRUE(all.equal(1-0.1-0.1-0.1, 0.7))
          #[1] TRUE
          0.3/0.1 == 3
          #[1] FALSE
          isTRUE(all.equal(0.3/0.1, 3))
          #[1] TRUE
          0.1+0.1==0.15
          #[1] FALSE
          isTRUE(all.equal(0.1+0.1, 0.15))
          #[1] FALSE


          Some more detail, directly copied from an answer to a similar question:



          The problem you have encountered is that floating point cannot represent decimal fractions exactly in most cases, which means you will frequently find that exact matches fail.



          while R lies slightly when you say:



          1.1-0.2
          #[1] 0.9
          0.9
          #[1] 0.9


          You can find out what it really thinks in decimal:



          sprintf("%.54f",1.1-0.2)
          #[1] "0.900000000000000133226762955018784850835800170898437500"
          sprintf("%.54f",0.9)
          #[1] "0.900000000000000022204460492503130808472633361816406250"


          You can see these numbers are different, but the representation is a bit unwieldy. If we look at them in binary (well, hex, which is equivalent) we get a clearer picture:



          sprintf("%a",0.9)
          #[1] "0x1.ccccccccccccdp-1"
          sprintf("%a",1.1-0.2)
          #[1] "0x1.ccccccccccccep-1"
          sprintf("%a",1.1-0.2-0.9)
          #[1] "0x1p-53"


          You can see that they differ by 2^-53, which is important because this number is the smallest representable difference between two numbers whose value is close to 1, as this is.



          We can find out for any given computer what this smallest representable number is by looking in R's machine field:



           ?.Machine
          #....
          #double.eps the smallest positive floating-point number x
          #such that 1 + x != 1. It equals base^ulp.digits if either
          #base is 2 or rounding is 0; otherwise, it is
          #(base^ulp.digits) / 2. Normally 2.220446e-16.
          #....
          .Machine$double.eps
          #[1] 2.220446e-16
          sprintf("%a",.Machine$double.eps)
          #[1] "0x1p-52"


          You can use this fact to create a 'nearly equals' function which checks that the difference is close to the smallest representable number in floating point. In fact this already exists: all.equal.



          ?all.equal
          #....
          #all.equal(x,y) is a utility to compare R objects x and y testing ‘near equality’.
          #....
          #all.equal(target, current,
          # tolerance = .Machine$double.eps ^ 0.5,
          # scale = NULL, check.attributes = TRUE, ...)
          #....


          So the all.equal function is actually checking that the difference between the numbers is the square root of the smallest difference between two mantissas.



          This algorithm goes a bit funny near extremely small numbers called denormals, but you don't need to worry about that.



          Comparing vectors



          The above discussion assumed a comparison of two single values. In R, there are no scalars, just vectors and implicit vectorization is a strength of the language. For comparing the value of vectors element-wise, the previous principles hold, but the implementation is slightly different. == is vectorized (does an element-wise comparison) while all.equal compares the whole vectors as a single entity.



          Using the previous examples



          a <- c(0.1+0.05, 1-0.1-0.1-0.1, 0.3/0.1, 0.1+0.1)
          b <- c(0.15, 0.7, 3, 0.15)


          == does not give the "expected" result and all.equal does not perform element-wise



          a==b
          #[1] FALSE FALSE FALSE FALSE
          all.equal(a,b)
          #[1] "Mean relative difference: 0.01234568"
          isTRUE(all.equal(a,b))
          #[1] FALSE


          Rather, a version which loops over the two vectors must be used



          mapply(function(x, y) {isTRUE(all.equal(x, y))}, a, b)
          #[1] TRUE TRUE TRUE FALSE


          If a functional version of this is desired, it can be written



          elementwise.all.equal <- Vectorize(function(x, y) {isTRUE(all.equal(x, y))})


          which can be called as just



          elementwise.all.equal(a, b)
          #[1] TRUE TRUE TRUE FALSE


          Alternatively, instead of wrapping all.equal in even more function calls, you can just replicate the relevant internals of all.equal.numeric and use implicit vectorization:



          tolerance = .Machine$double.eps^0.5
          # this is the default tolerance used in all.equal,
          # but you can pick a different tolerance to match your needs

          abs(a - b) < tolerance
          #[1] TRUE TRUE TRUE FALSE





          share|improve this answer




























            319












            319








            319







            General (language agnostic) reason



            Since not all numbers can be represented exactly in IEEE floating point arithmetic (the standard that almost all computers use to represent decimal numbers and do math with them), you will not always get what you expected. This is especially true because some values which are simple, finite decimals (such as 0.1 and 0.05) are not represented exactly in the computer and so the results of arithmetic on them may not give a result that is identical to a direct representation of the "known" answer.



            This is a well known limitation of computer arithmetic and is discussed in several places:




            • The R FAQ has question devoted to it: R FAQ 7.31


            • The R Inferno by Patrick Burns devotes the first "Circle" to this problem (starting on page 9)

            • David Goldberg, "What Every Computer Scientist Should Know About Floating-point Arithmetic," ACM Computing Surveys 23, 1 (1991-03), 5-48 doi>10.1145/103162.103163 (revision also available)

            • The Floating-Point Guide - What Every Programmer Should Know About Floating-Point Arithmetic


            • 0.30000000000000004.com compares floating point arithmetic across programming languages

            • Several Stack Overflow questions including


              • Why Are Floating Point Numbers Inaccurate?

              • Why can't decimal numbers be represented exactly in binary?

              • Is floating point math broken?


              • Canonical duplicate for "floating point is inaccurate" (a meta discussion about a canonical answer for this issue)




            Comparing scalars



            The standard solution to this in R is not to use ==, but rather the all.equal function. Or rather, since all.equal gives lots of detail about the differences if there are any, isTRUE(all.equal(...)).



            if(isTRUE(all.equal(i,0.15))) cat("i equals 0.15") else cat("i does not equal 0.15")


            yields



            i equals 0.15


            Some more examples of using all.equal instead of == (the last example is supposed to show that this will correctly show differences).



            0.1+0.05==0.15
            #[1] FALSE
            isTRUE(all.equal(0.1+0.05, 0.15))
            #[1] TRUE
            1-0.1-0.1-0.1==0.7
            #[1] FALSE
            isTRUE(all.equal(1-0.1-0.1-0.1, 0.7))
            #[1] TRUE
            0.3/0.1 == 3
            #[1] FALSE
            isTRUE(all.equal(0.3/0.1, 3))
            #[1] TRUE
            0.1+0.1==0.15
            #[1] FALSE
            isTRUE(all.equal(0.1+0.1, 0.15))
            #[1] FALSE


            Some more detail, directly copied from an answer to a similar question:



            The problem you have encountered is that floating point cannot represent decimal fractions exactly in most cases, which means you will frequently find that exact matches fail.



            while R lies slightly when you say:



            1.1-0.2
            #[1] 0.9
            0.9
            #[1] 0.9


            You can find out what it really thinks in decimal:



            sprintf("%.54f",1.1-0.2)
            #[1] "0.900000000000000133226762955018784850835800170898437500"
            sprintf("%.54f",0.9)
            #[1] "0.900000000000000022204460492503130808472633361816406250"


            You can see these numbers are different, but the representation is a bit unwieldy. If we look at them in binary (well, hex, which is equivalent) we get a clearer picture:



            sprintf("%a",0.9)
            #[1] "0x1.ccccccccccccdp-1"
            sprintf("%a",1.1-0.2)
            #[1] "0x1.ccccccccccccep-1"
            sprintf("%a",1.1-0.2-0.9)
            #[1] "0x1p-53"


            You can see that they differ by 2^-53, which is important because this number is the smallest representable difference between two numbers whose value is close to 1, as this is.



            We can find out for any given computer what this smallest representable number is by looking in R's machine field:



             ?.Machine
            #....
            #double.eps the smallest positive floating-point number x
            #such that 1 + x != 1. It equals base^ulp.digits if either
            #base is 2 or rounding is 0; otherwise, it is
            #(base^ulp.digits) / 2. Normally 2.220446e-16.
            #....
            .Machine$double.eps
            #[1] 2.220446e-16
            sprintf("%a",.Machine$double.eps)
            #[1] "0x1p-52"


            You can use this fact to create a 'nearly equals' function which checks that the difference is close to the smallest representable number in floating point. In fact this already exists: all.equal.



            ?all.equal
            #....
            #all.equal(x,y) is a utility to compare R objects x and y testing ‘near equality’.
            #....
            #all.equal(target, current,
            # tolerance = .Machine$double.eps ^ 0.5,
            # scale = NULL, check.attributes = TRUE, ...)
            #....


            So the all.equal function is actually checking that the difference between the numbers is the square root of the smallest difference between two mantissas.



            This algorithm goes a bit funny near extremely small numbers called denormals, but you don't need to worry about that.



            Comparing vectors



            The above discussion assumed a comparison of two single values. In R, there are no scalars, just vectors and implicit vectorization is a strength of the language. For comparing the value of vectors element-wise, the previous principles hold, but the implementation is slightly different. == is vectorized (does an element-wise comparison) while all.equal compares the whole vectors as a single entity.



            Using the previous examples



            a <- c(0.1+0.05, 1-0.1-0.1-0.1, 0.3/0.1, 0.1+0.1)
            b <- c(0.15, 0.7, 3, 0.15)


            == does not give the "expected" result and all.equal does not perform element-wise



            a==b
            #[1] FALSE FALSE FALSE FALSE
            all.equal(a,b)
            #[1] "Mean relative difference: 0.01234568"
            isTRUE(all.equal(a,b))
            #[1] FALSE


            Rather, a version which loops over the two vectors must be used



            mapply(function(x, y) {isTRUE(all.equal(x, y))}, a, b)
            #[1] TRUE TRUE TRUE FALSE


            If a functional version of this is desired, it can be written



            elementwise.all.equal <- Vectorize(function(x, y) {isTRUE(all.equal(x, y))})


            which can be called as just



            elementwise.all.equal(a, b)
            #[1] TRUE TRUE TRUE FALSE


            Alternatively, instead of wrapping all.equal in even more function calls, you can just replicate the relevant internals of all.equal.numeric and use implicit vectorization:



            tolerance = .Machine$double.eps^0.5
            # this is the default tolerance used in all.equal,
            # but you can pick a different tolerance to match your needs

            abs(a - b) < tolerance
            #[1] TRUE TRUE TRUE FALSE





            share|improve this answer















            General (language agnostic) reason



            Since not all numbers can be represented exactly in IEEE floating point arithmetic (the standard that almost all computers use to represent decimal numbers and do math with them), you will not always get what you expected. This is especially true because some values which are simple, finite decimals (such as 0.1 and 0.05) are not represented exactly in the computer and so the results of arithmetic on them may not give a result that is identical to a direct representation of the "known" answer.



            This is a well known limitation of computer arithmetic and is discussed in several places:




            • The R FAQ has question devoted to it: R FAQ 7.31


            • The R Inferno by Patrick Burns devotes the first "Circle" to this problem (starting on page 9)

            • David Goldberg, "What Every Computer Scientist Should Know About Floating-point Arithmetic," ACM Computing Surveys 23, 1 (1991-03), 5-48 doi>10.1145/103162.103163 (revision also available)

            • The Floating-Point Guide - What Every Programmer Should Know About Floating-Point Arithmetic


            • 0.30000000000000004.com compares floating point arithmetic across programming languages

            • Several Stack Overflow questions including


              • Why Are Floating Point Numbers Inaccurate?

              • Why can't decimal numbers be represented exactly in binary?

              • Is floating point math broken?


              • Canonical duplicate for "floating point is inaccurate" (a meta discussion about a canonical answer for this issue)




            Comparing scalars



            The standard solution to this in R is not to use ==, but rather the all.equal function. Or rather, since all.equal gives lots of detail about the differences if there are any, isTRUE(all.equal(...)).



            if(isTRUE(all.equal(i,0.15))) cat("i equals 0.15") else cat("i does not equal 0.15")


            yields



            i equals 0.15


            Some more examples of using all.equal instead of == (the last example is supposed to show that this will correctly show differences).



            0.1+0.05==0.15
            #[1] FALSE
            isTRUE(all.equal(0.1+0.05, 0.15))
            #[1] TRUE
            1-0.1-0.1-0.1==0.7
            #[1] FALSE
            isTRUE(all.equal(1-0.1-0.1-0.1, 0.7))
            #[1] TRUE
            0.3/0.1 == 3
            #[1] FALSE
            isTRUE(all.equal(0.3/0.1, 3))
            #[1] TRUE
            0.1+0.1==0.15
            #[1] FALSE
            isTRUE(all.equal(0.1+0.1, 0.15))
            #[1] FALSE


            Some more detail, directly copied from an answer to a similar question:



            The problem you have encountered is that floating point cannot represent decimal fractions exactly in most cases, which means you will frequently find that exact matches fail.



            while R lies slightly when you say:



            1.1-0.2
            #[1] 0.9
            0.9
            #[1] 0.9


            You can find out what it really thinks in decimal:



            sprintf("%.54f",1.1-0.2)
            #[1] "0.900000000000000133226762955018784850835800170898437500"
            sprintf("%.54f",0.9)
            #[1] "0.900000000000000022204460492503130808472633361816406250"


            You can see these numbers are different, but the representation is a bit unwieldy. If we look at them in binary (well, hex, which is equivalent) we get a clearer picture:



            sprintf("%a",0.9)
            #[1] "0x1.ccccccccccccdp-1"
            sprintf("%a",1.1-0.2)
            #[1] "0x1.ccccccccccccep-1"
            sprintf("%a",1.1-0.2-0.9)
            #[1] "0x1p-53"


            You can see that they differ by 2^-53, which is important because this number is the smallest representable difference between two numbers whose value is close to 1, as this is.



            We can find out for any given computer what this smallest representable number is by looking in R's machine field:



             ?.Machine
            #....
            #double.eps the smallest positive floating-point number x
            #such that 1 + x != 1. It equals base^ulp.digits if either
            #base is 2 or rounding is 0; otherwise, it is
            #(base^ulp.digits) / 2. Normally 2.220446e-16.
            #....
            .Machine$double.eps
            #[1] 2.220446e-16
            sprintf("%a",.Machine$double.eps)
            #[1] "0x1p-52"


            You can use this fact to create a 'nearly equals' function which checks that the difference is close to the smallest representable number in floating point. In fact this already exists: all.equal.



            ?all.equal
            #....
            #all.equal(x,y) is a utility to compare R objects x and y testing ‘near equality’.
            #....
            #all.equal(target, current,
            # tolerance = .Machine$double.eps ^ 0.5,
            # scale = NULL, check.attributes = TRUE, ...)
            #....


            So the all.equal function is actually checking that the difference between the numbers is the square root of the smallest difference between two mantissas.



            This algorithm goes a bit funny near extremely small numbers called denormals, but you don't need to worry about that.



            Comparing vectors



            The above discussion assumed a comparison of two single values. In R, there are no scalars, just vectors and implicit vectorization is a strength of the language. For comparing the value of vectors element-wise, the previous principles hold, but the implementation is slightly different. == is vectorized (does an element-wise comparison) while all.equal compares the whole vectors as a single entity.



            Using the previous examples



            a <- c(0.1+0.05, 1-0.1-0.1-0.1, 0.3/0.1, 0.1+0.1)
            b <- c(0.15, 0.7, 3, 0.15)


            == does not give the "expected" result and all.equal does not perform element-wise



            a==b
            #[1] FALSE FALSE FALSE FALSE
            all.equal(a,b)
            #[1] "Mean relative difference: 0.01234568"
            isTRUE(all.equal(a,b))
            #[1] FALSE


            Rather, a version which loops over the two vectors must be used



            mapply(function(x, y) {isTRUE(all.equal(x, y))}, a, b)
            #[1] TRUE TRUE TRUE FALSE


            If a functional version of this is desired, it can be written



            elementwise.all.equal <- Vectorize(function(x, y) {isTRUE(all.equal(x, y))})


            which can be called as just



            elementwise.all.equal(a, b)
            #[1] TRUE TRUE TRUE FALSE


            Alternatively, instead of wrapping all.equal in even more function calls, you can just replicate the relevant internals of all.equal.numeric and use implicit vectorization:



            tolerance = .Machine$double.eps^0.5
            # this is the default tolerance used in all.equal,
            # but you can pick a different tolerance to match your needs

            abs(a - b) < tolerance
            #[1] TRUE TRUE TRUE FALSE






            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Jan 26 '18 at 23:14


























            community wiki





            13 revs, 5 users 66%
            Brian Diggs


























                37














                Adding to Brian's comment (which is the reason) you can over come this by using all.equal instead:



                # i <- 0.1
                # i <- i + 0.05
                # i
                #if(all.equal(i, .15)) cat("i equals 0.15n") else cat("i does not equal 0.15n")
                #i equals 0.15


                Per Joshua's warning here is the updated code (Thanks Joshua):



                 i <- 0.1
                i <- i + 0.05
                i
                if(isTRUE(all.equal(i, .15))) { #code was getting sloppy &went to multiple lines
                cat("i equals 0.15n")
                } else {
                cat("i does not equal 0.15n")
                }
                #i equals 0.15





                share|improve this answer


























                • I missed Brian's link which explains my response succinctly.

                  – Tyler Rinker
                  Feb 29 '12 at 23:57






                • 15





                  all.equal doesn't return FALSE when there are differences, so you need to wrap it with isTRUE when using it in an if statement.

                  – Joshua Ulrich
                  Mar 1 '12 at 0:49


















                37














                Adding to Brian's comment (which is the reason) you can over come this by using all.equal instead:



                # i <- 0.1
                # i <- i + 0.05
                # i
                #if(all.equal(i, .15)) cat("i equals 0.15n") else cat("i does not equal 0.15n")
                #i equals 0.15


                Per Joshua's warning here is the updated code (Thanks Joshua):



                 i <- 0.1
                i <- i + 0.05
                i
                if(isTRUE(all.equal(i, .15))) { #code was getting sloppy &went to multiple lines
                cat("i equals 0.15n")
                } else {
                cat("i does not equal 0.15n")
                }
                #i equals 0.15





                share|improve this answer


























                • I missed Brian's link which explains my response succinctly.

                  – Tyler Rinker
                  Feb 29 '12 at 23:57






                • 15





                  all.equal doesn't return FALSE when there are differences, so you need to wrap it with isTRUE when using it in an if statement.

                  – Joshua Ulrich
                  Mar 1 '12 at 0:49
















                37












                37








                37







                Adding to Brian's comment (which is the reason) you can over come this by using all.equal instead:



                # i <- 0.1
                # i <- i + 0.05
                # i
                #if(all.equal(i, .15)) cat("i equals 0.15n") else cat("i does not equal 0.15n")
                #i equals 0.15


                Per Joshua's warning here is the updated code (Thanks Joshua):



                 i <- 0.1
                i <- i + 0.05
                i
                if(isTRUE(all.equal(i, .15))) { #code was getting sloppy &went to multiple lines
                cat("i equals 0.15n")
                } else {
                cat("i does not equal 0.15n")
                }
                #i equals 0.15





                share|improve this answer















                Adding to Brian's comment (which is the reason) you can over come this by using all.equal instead:



                # i <- 0.1
                # i <- i + 0.05
                # i
                #if(all.equal(i, .15)) cat("i equals 0.15n") else cat("i does not equal 0.15n")
                #i equals 0.15


                Per Joshua's warning here is the updated code (Thanks Joshua):



                 i <- 0.1
                i <- i + 0.05
                i
                if(isTRUE(all.equal(i, .15))) { #code was getting sloppy &went to multiple lines
                cat("i equals 0.15n")
                } else {
                cat("i does not equal 0.15n")
                }
                #i equals 0.15






                share|improve this answer














                share|improve this answer



                share|improve this answer








                edited Mar 1 '12 at 0:59

























                answered Feb 29 '12 at 23:56









                Tyler RinkerTyler Rinker

                65.3k42234413




                65.3k42234413













                • I missed Brian's link which explains my response succinctly.

                  – Tyler Rinker
                  Feb 29 '12 at 23:57






                • 15





                  all.equal doesn't return FALSE when there are differences, so you need to wrap it with isTRUE when using it in an if statement.

                  – Joshua Ulrich
                  Mar 1 '12 at 0:49





















                • I missed Brian's link which explains my response succinctly.

                  – Tyler Rinker
                  Feb 29 '12 at 23:57






                • 15





                  all.equal doesn't return FALSE when there are differences, so you need to wrap it with isTRUE when using it in an if statement.

                  – Joshua Ulrich
                  Mar 1 '12 at 0:49



















                I missed Brian's link which explains my response succinctly.

                – Tyler Rinker
                Feb 29 '12 at 23:57





                I missed Brian's link which explains my response succinctly.

                – Tyler Rinker
                Feb 29 '12 at 23:57




                15




                15





                all.equal doesn't return FALSE when there are differences, so you need to wrap it with isTRUE when using it in an if statement.

                – Joshua Ulrich
                Mar 1 '12 at 0:49







                all.equal doesn't return FALSE when there are differences, so you need to wrap it with isTRUE when using it in an if statement.

                – Joshua Ulrich
                Mar 1 '12 at 0:49













                9














                This is hackish, but quick:



                if(round(i, 10)==0.15) cat("i equals 0.15") else cat("i does not equal 0.15")





                share|improve this answer



















                • 2





                  But you can use the all.equal(... tolerance) parameter. all.equal(0.147, 0.15, tolerance=0.05) is TRUE.

                  – smci
                  May 28 '18 at 11:25
















                9














                This is hackish, but quick:



                if(round(i, 10)==0.15) cat("i equals 0.15") else cat("i does not equal 0.15")





                share|improve this answer



















                • 2





                  But you can use the all.equal(... tolerance) parameter. all.equal(0.147, 0.15, tolerance=0.05) is TRUE.

                  – smci
                  May 28 '18 at 11:25














                9












                9








                9







                This is hackish, but quick:



                if(round(i, 10)==0.15) cat("i equals 0.15") else cat("i does not equal 0.15")





                share|improve this answer













                This is hackish, but quick:



                if(round(i, 10)==0.15) cat("i equals 0.15") else cat("i does not equal 0.15")






                share|improve this answer












                share|improve this answer



                share|improve this answer










                answered Sep 7 '13 at 1:09









                Hillary SandersHillary Sanders

                2,14732039




                2,14732039








                • 2





                  But you can use the all.equal(... tolerance) parameter. all.equal(0.147, 0.15, tolerance=0.05) is TRUE.

                  – smci
                  May 28 '18 at 11:25














                • 2





                  But you can use the all.equal(... tolerance) parameter. all.equal(0.147, 0.15, tolerance=0.05) is TRUE.

                  – smci
                  May 28 '18 at 11:25








                2




                2





                But you can use the all.equal(... tolerance) parameter. all.equal(0.147, 0.15, tolerance=0.05) is TRUE.

                – smci
                May 28 '18 at 11:25





                But you can use the all.equal(... tolerance) parameter. all.equal(0.147, 0.15, tolerance=0.05) is TRUE.

                – smci
                May 28 '18 at 11:25











                3














                dplyr::near() is an option for testing if two vectors of floating point numbers are equal. This is the example from the docs:



                sqrt(2) ^ 2 == 2
                #> [1] FALSE
                library(dplyr)
                near(sqrt(2) ^ 2, 2)
                #> [1] TRUE


                The function has a built in tolerance parameter: tol = .Machine$double.eps^0.5 that can be adjusted. The default parameter is the same as the default for all.equal().






                share|improve this answer




























                  3














                  dplyr::near() is an option for testing if two vectors of floating point numbers are equal. This is the example from the docs:



                  sqrt(2) ^ 2 == 2
                  #> [1] FALSE
                  library(dplyr)
                  near(sqrt(2) ^ 2, 2)
                  #> [1] TRUE


                  The function has a built in tolerance parameter: tol = .Machine$double.eps^0.5 that can be adjusted. The default parameter is the same as the default for all.equal().






                  share|improve this answer


























                    3












                    3








                    3







                    dplyr::near() is an option for testing if two vectors of floating point numbers are equal. This is the example from the docs:



                    sqrt(2) ^ 2 == 2
                    #> [1] FALSE
                    library(dplyr)
                    near(sqrt(2) ^ 2, 2)
                    #> [1] TRUE


                    The function has a built in tolerance parameter: tol = .Machine$double.eps^0.5 that can be adjusted. The default parameter is the same as the default for all.equal().






                    share|improve this answer













                    dplyr::near() is an option for testing if two vectors of floating point numbers are equal. This is the example from the docs:



                    sqrt(2) ^ 2 == 2
                    #> [1] FALSE
                    library(dplyr)
                    near(sqrt(2) ^ 2, 2)
                    #> [1] TRUE


                    The function has a built in tolerance parameter: tol = .Machine$double.eps^0.5 that can be adjusted. The default parameter is the same as the default for all.equal().







                    share|improve this answer












                    share|improve this answer



                    share|improve this answer










                    answered Nov 9 '18 at 3:31









                    sbhasbha

                    2,57822226




                    2,57822226























                        0














                        I had a similar problem. I used the following solution.




                        @ I found this work around solution about unequal cut intervals. @ I
                        used the round function in R. By setting the option to 2 digits, did
                        not solved the problem.




                        options(digits = 2)
                        cbind(
                        seq( from = 1, to = 9, by = 1 ),
                        cut( seq( from = 1, to = 9, by = 1), c( 0, 3, 6, 9 ) ),
                        seq( from = 0.1, to = 0.9, by = 0.1 ),
                        cut( seq( from = 0.1, to = 0.9, by = 0.1), c( 0, 0.3, 0.6, 0.9 )),
                        seq( from = 0.01, to = 0.09, by = 0.01 ),
                        cut( seq( from = 0.01, to = 0.09, by = 0.01), c( 0, 0.03, 0.06, 0.09 ))
                        )


                        output of unequal cut intervals based on options(digits = 2):



                          [,1] [,2] [,3] [,4] [,5] [,6]
                        [1,] 1 1 0.1 1 0.01 1
                        [2,] 2 1 0.2 1 0.02 1
                        [3,] 3 1 0.3 2 0.03 1
                        [4,] 4 2 0.4 2 0.04 2
                        [5,] 5 2 0.5 2 0.05 2
                        [6,] 6 2 0.6 2 0.06 3
                        [7,] 7 3 0.7 3 0.07 3
                        [8,] 8 3 0.8 3 0.08 3
                        [9,] 9 3 0.9 3 0.09 3


                        options(digits = 200)
                        cbind(
                        seq( from = 1, to = 9, by = 1 ),
                        cut( round(seq( from = 1, to = 9, by = 1), 2), c( 0, 3, 6, 9 ) ),
                        seq( from = 0.1, to = 0.9, by = 0.1 ),
                        cut( round(seq( from = 0.1, to = 0.9, by = 0.1), 2), c( 0, 0.3, 0.6, 0.9 )),
                        seq( from = 0.01, to = 0.09, by = 0.01 ),
                        cut( round(seq( from = 0.01, to = 0.09, by = 0.01), 2), c( 0, 0.03, 0.06, 0.09 ))
                        )


                        output of equal cut intervals based on round function:



                              [,1] [,2] [,3] [,4] [,5] [,6]
                        [1,] 1 1 0.1 1 0.01 1
                        [2,] 2 1 0.2 1 0.02 1
                        [3,] 3 1 0.3 1 0.03 1
                        [4,] 4 2 0.4 2 0.04 2
                        [5,] 5 2 0.5 2 0.05 2
                        [6,] 6 2 0.6 2 0.06 2
                        [7,] 7 3 0.7 3 0.07 3
                        [8,] 8 3 0.8 3 0.08 3
                        [9,] 9 3 0.9 3 0.09 3





                        share|improve this answer




























                          0














                          I had a similar problem. I used the following solution.




                          @ I found this work around solution about unequal cut intervals. @ I
                          used the round function in R. By setting the option to 2 digits, did
                          not solved the problem.




                          options(digits = 2)
                          cbind(
                          seq( from = 1, to = 9, by = 1 ),
                          cut( seq( from = 1, to = 9, by = 1), c( 0, 3, 6, 9 ) ),
                          seq( from = 0.1, to = 0.9, by = 0.1 ),
                          cut( seq( from = 0.1, to = 0.9, by = 0.1), c( 0, 0.3, 0.6, 0.9 )),
                          seq( from = 0.01, to = 0.09, by = 0.01 ),
                          cut( seq( from = 0.01, to = 0.09, by = 0.01), c( 0, 0.03, 0.06, 0.09 ))
                          )


                          output of unequal cut intervals based on options(digits = 2):



                            [,1] [,2] [,3] [,4] [,5] [,6]
                          [1,] 1 1 0.1 1 0.01 1
                          [2,] 2 1 0.2 1 0.02 1
                          [3,] 3 1 0.3 2 0.03 1
                          [4,] 4 2 0.4 2 0.04 2
                          [5,] 5 2 0.5 2 0.05 2
                          [6,] 6 2 0.6 2 0.06 3
                          [7,] 7 3 0.7 3 0.07 3
                          [8,] 8 3 0.8 3 0.08 3
                          [9,] 9 3 0.9 3 0.09 3


                          options(digits = 200)
                          cbind(
                          seq( from = 1, to = 9, by = 1 ),
                          cut( round(seq( from = 1, to = 9, by = 1), 2), c( 0, 3, 6, 9 ) ),
                          seq( from = 0.1, to = 0.9, by = 0.1 ),
                          cut( round(seq( from = 0.1, to = 0.9, by = 0.1), 2), c( 0, 0.3, 0.6, 0.9 )),
                          seq( from = 0.01, to = 0.09, by = 0.01 ),
                          cut( round(seq( from = 0.01, to = 0.09, by = 0.01), 2), c( 0, 0.03, 0.06, 0.09 ))
                          )


                          output of equal cut intervals based on round function:



                                [,1] [,2] [,3] [,4] [,5] [,6]
                          [1,] 1 1 0.1 1 0.01 1
                          [2,] 2 1 0.2 1 0.02 1
                          [3,] 3 1 0.3 1 0.03 1
                          [4,] 4 2 0.4 2 0.04 2
                          [5,] 5 2 0.5 2 0.05 2
                          [6,] 6 2 0.6 2 0.06 2
                          [7,] 7 3 0.7 3 0.07 3
                          [8,] 8 3 0.8 3 0.08 3
                          [9,] 9 3 0.9 3 0.09 3





                          share|improve this answer


























                            0












                            0








                            0







                            I had a similar problem. I used the following solution.




                            @ I found this work around solution about unequal cut intervals. @ I
                            used the round function in R. By setting the option to 2 digits, did
                            not solved the problem.




                            options(digits = 2)
                            cbind(
                            seq( from = 1, to = 9, by = 1 ),
                            cut( seq( from = 1, to = 9, by = 1), c( 0, 3, 6, 9 ) ),
                            seq( from = 0.1, to = 0.9, by = 0.1 ),
                            cut( seq( from = 0.1, to = 0.9, by = 0.1), c( 0, 0.3, 0.6, 0.9 )),
                            seq( from = 0.01, to = 0.09, by = 0.01 ),
                            cut( seq( from = 0.01, to = 0.09, by = 0.01), c( 0, 0.03, 0.06, 0.09 ))
                            )


                            output of unequal cut intervals based on options(digits = 2):



                              [,1] [,2] [,3] [,4] [,5] [,6]
                            [1,] 1 1 0.1 1 0.01 1
                            [2,] 2 1 0.2 1 0.02 1
                            [3,] 3 1 0.3 2 0.03 1
                            [4,] 4 2 0.4 2 0.04 2
                            [5,] 5 2 0.5 2 0.05 2
                            [6,] 6 2 0.6 2 0.06 3
                            [7,] 7 3 0.7 3 0.07 3
                            [8,] 8 3 0.8 3 0.08 3
                            [9,] 9 3 0.9 3 0.09 3


                            options(digits = 200)
                            cbind(
                            seq( from = 1, to = 9, by = 1 ),
                            cut( round(seq( from = 1, to = 9, by = 1), 2), c( 0, 3, 6, 9 ) ),
                            seq( from = 0.1, to = 0.9, by = 0.1 ),
                            cut( round(seq( from = 0.1, to = 0.9, by = 0.1), 2), c( 0, 0.3, 0.6, 0.9 )),
                            seq( from = 0.01, to = 0.09, by = 0.01 ),
                            cut( round(seq( from = 0.01, to = 0.09, by = 0.01), 2), c( 0, 0.03, 0.06, 0.09 ))
                            )


                            output of equal cut intervals based on round function:



                                  [,1] [,2] [,3] [,4] [,5] [,6]
                            [1,] 1 1 0.1 1 0.01 1
                            [2,] 2 1 0.2 1 0.02 1
                            [3,] 3 1 0.3 1 0.03 1
                            [4,] 4 2 0.4 2 0.04 2
                            [5,] 5 2 0.5 2 0.05 2
                            [6,] 6 2 0.6 2 0.06 2
                            [7,] 7 3 0.7 3 0.07 3
                            [8,] 8 3 0.8 3 0.08 3
                            [9,] 9 3 0.9 3 0.09 3





                            share|improve this answer













                            I had a similar problem. I used the following solution.




                            @ I found this work around solution about unequal cut intervals. @ I
                            used the round function in R. By setting the option to 2 digits, did
                            not solved the problem.




                            options(digits = 2)
                            cbind(
                            seq( from = 1, to = 9, by = 1 ),
                            cut( seq( from = 1, to = 9, by = 1), c( 0, 3, 6, 9 ) ),
                            seq( from = 0.1, to = 0.9, by = 0.1 ),
                            cut( seq( from = 0.1, to = 0.9, by = 0.1), c( 0, 0.3, 0.6, 0.9 )),
                            seq( from = 0.01, to = 0.09, by = 0.01 ),
                            cut( seq( from = 0.01, to = 0.09, by = 0.01), c( 0, 0.03, 0.06, 0.09 ))
                            )


                            output of unequal cut intervals based on options(digits = 2):



                              [,1] [,2] [,3] [,4] [,5] [,6]
                            [1,] 1 1 0.1 1 0.01 1
                            [2,] 2 1 0.2 1 0.02 1
                            [3,] 3 1 0.3 2 0.03 1
                            [4,] 4 2 0.4 2 0.04 2
                            [5,] 5 2 0.5 2 0.05 2
                            [6,] 6 2 0.6 2 0.06 3
                            [7,] 7 3 0.7 3 0.07 3
                            [8,] 8 3 0.8 3 0.08 3
                            [9,] 9 3 0.9 3 0.09 3


                            options(digits = 200)
                            cbind(
                            seq( from = 1, to = 9, by = 1 ),
                            cut( round(seq( from = 1, to = 9, by = 1), 2), c( 0, 3, 6, 9 ) ),
                            seq( from = 0.1, to = 0.9, by = 0.1 ),
                            cut( round(seq( from = 0.1, to = 0.9, by = 0.1), 2), c( 0, 0.3, 0.6, 0.9 )),
                            seq( from = 0.01, to = 0.09, by = 0.01 ),
                            cut( round(seq( from = 0.01, to = 0.09, by = 0.01), 2), c( 0, 0.03, 0.06, 0.09 ))
                            )


                            output of equal cut intervals based on round function:



                                  [,1] [,2] [,3] [,4] [,5] [,6]
                            [1,] 1 1 0.1 1 0.01 1
                            [2,] 2 1 0.2 1 0.02 1
                            [3,] 3 1 0.3 1 0.03 1
                            [4,] 4 2 0.4 2 0.04 2
                            [5,] 5 2 0.5 2 0.05 2
                            [6,] 6 2 0.6 2 0.06 2
                            [7,] 7 3 0.7 3 0.07 3
                            [8,] 8 3 0.8 3 0.08 3
                            [9,] 9 3 0.9 3 0.09 3






                            share|improve this answer












                            share|improve this answer



                            share|improve this answer










                            answered Feb 22 at 16:46









                            Elias EstatisticsEUElias EstatisticsEU

                            183212




                            183212






























                                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%2f9508518%2fwhy-are-these-numbers-not-equal%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







                                這個網誌中的熱門文章

                                Xamarin.form Move up view when keyboard appear

                                Post-Redirect-Get with Spring WebFlux and Thymeleaf

                                Anylogic : not able to use stopDelay()