Why is 0 vs 0.0 causing a precision problem?












2












$begingroup$


I wasn't sure what to title this Question.
I tried calculating different forms of a continued fraction, and I found that I get a correct result when I set d to 0 but a wrong result (in the final two terms) if I set d to 0.0



ClearAll["Global`*"];
t = Sqrt[17];
d = 0.0;
n = 11;
a = ConstantArray[0, n];
Do[a[[i]] = Floor[t + d]; t = 1/(t - Floor[t + d]), {i, 1, n}];
a

{4, 8, 8, 8, 8, 8, 8, 8, 8, 7, 4}


I only caught this because I happen to know that this series should end in infinite 8's.



When I try to calculate the form of continued fractions that allows negative terms, I get the correct series from d=1/2 but wrong terms if d=.5. So I gather that this problem has something to do with precision and using rational numbers instead of floats but why is this happening for zero? Is Mathematica adding 0.0 incorrectly?










share|improve this question









$endgroup$








  • 1




    $begingroup$
    The presence of any machine precision number (including 0.0) will result in the calculation being done with machine precision.
    $endgroup$
    – Bob Hanlon
    6 hours ago






  • 1




    $begingroup$
    By using an extended precision version of 0 you can get a small speedup from using numbers instead of full symbolic expressions but without sacrificing accuracy. Try d=0``1.
    $endgroup$
    – b3m2a1
    5 hours ago








  • 2




    $begingroup$
    Also in terms of programming style this is probably faster: d + NestList[1/(# - Floor[# + d]) &, t, 200] // Floor // RepeatedTiming
    $endgroup$
    – b3m2a1
    5 hours ago
















2












$begingroup$


I wasn't sure what to title this Question.
I tried calculating different forms of a continued fraction, and I found that I get a correct result when I set d to 0 but a wrong result (in the final two terms) if I set d to 0.0



ClearAll["Global`*"];
t = Sqrt[17];
d = 0.0;
n = 11;
a = ConstantArray[0, n];
Do[a[[i]] = Floor[t + d]; t = 1/(t - Floor[t + d]), {i, 1, n}];
a

{4, 8, 8, 8, 8, 8, 8, 8, 8, 7, 4}


I only caught this because I happen to know that this series should end in infinite 8's.



When I try to calculate the form of continued fractions that allows negative terms, I get the correct series from d=1/2 but wrong terms if d=.5. So I gather that this problem has something to do with precision and using rational numbers instead of floats but why is this happening for zero? Is Mathematica adding 0.0 incorrectly?










share|improve this question









$endgroup$








  • 1




    $begingroup$
    The presence of any machine precision number (including 0.0) will result in the calculation being done with machine precision.
    $endgroup$
    – Bob Hanlon
    6 hours ago






  • 1




    $begingroup$
    By using an extended precision version of 0 you can get a small speedup from using numbers instead of full symbolic expressions but without sacrificing accuracy. Try d=0``1.
    $endgroup$
    – b3m2a1
    5 hours ago








  • 2




    $begingroup$
    Also in terms of programming style this is probably faster: d + NestList[1/(# - Floor[# + d]) &, t, 200] // Floor // RepeatedTiming
    $endgroup$
    – b3m2a1
    5 hours ago














2












2








2





$begingroup$


I wasn't sure what to title this Question.
I tried calculating different forms of a continued fraction, and I found that I get a correct result when I set d to 0 but a wrong result (in the final two terms) if I set d to 0.0



ClearAll["Global`*"];
t = Sqrt[17];
d = 0.0;
n = 11;
a = ConstantArray[0, n];
Do[a[[i]] = Floor[t + d]; t = 1/(t - Floor[t + d]), {i, 1, n}];
a

{4, 8, 8, 8, 8, 8, 8, 8, 8, 7, 4}


I only caught this because I happen to know that this series should end in infinite 8's.



When I try to calculate the form of continued fractions that allows negative terms, I get the correct series from d=1/2 but wrong terms if d=.5. So I gather that this problem has something to do with precision and using rational numbers instead of floats but why is this happening for zero? Is Mathematica adding 0.0 incorrectly?










share|improve this question









$endgroup$




I wasn't sure what to title this Question.
I tried calculating different forms of a continued fraction, and I found that I get a correct result when I set d to 0 but a wrong result (in the final two terms) if I set d to 0.0



ClearAll["Global`*"];
t = Sqrt[17];
d = 0.0;
n = 11;
a = ConstantArray[0, n];
Do[a[[i]] = Floor[t + d]; t = 1/(t - Floor[t + d]), {i, 1, n}];
a

{4, 8, 8, 8, 8, 8, 8, 8, 8, 7, 4}


I only caught this because I happen to know that this series should end in infinite 8's.



When I try to calculate the form of continued fractions that allows negative terms, I get the correct series from d=1/2 but wrong terms if d=.5. So I gather that this problem has something to do with precision and using rational numbers instead of floats but why is this happening for zero? Is Mathematica adding 0.0 incorrectly?







machine-precision precision-and-accuracy






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked 6 hours ago









Jerry GuernJerry Guern

1,995933




1,995933








  • 1




    $begingroup$
    The presence of any machine precision number (including 0.0) will result in the calculation being done with machine precision.
    $endgroup$
    – Bob Hanlon
    6 hours ago






  • 1




    $begingroup$
    By using an extended precision version of 0 you can get a small speedup from using numbers instead of full symbolic expressions but without sacrificing accuracy. Try d=0``1.
    $endgroup$
    – b3m2a1
    5 hours ago








  • 2




    $begingroup$
    Also in terms of programming style this is probably faster: d + NestList[1/(# - Floor[# + d]) &, t, 200] // Floor // RepeatedTiming
    $endgroup$
    – b3m2a1
    5 hours ago














  • 1




    $begingroup$
    The presence of any machine precision number (including 0.0) will result in the calculation being done with machine precision.
    $endgroup$
    – Bob Hanlon
    6 hours ago






  • 1




    $begingroup$
    By using an extended precision version of 0 you can get a small speedup from using numbers instead of full symbolic expressions but without sacrificing accuracy. Try d=0``1.
    $endgroup$
    – b3m2a1
    5 hours ago








  • 2




    $begingroup$
    Also in terms of programming style this is probably faster: d + NestList[1/(# - Floor[# + d]) &, t, 200] // Floor // RepeatedTiming
    $endgroup$
    – b3m2a1
    5 hours ago








1




1




$begingroup$
The presence of any machine precision number (including 0.0) will result in the calculation being done with machine precision.
$endgroup$
– Bob Hanlon
6 hours ago




$begingroup$
The presence of any machine precision number (including 0.0) will result in the calculation being done with machine precision.
$endgroup$
– Bob Hanlon
6 hours ago




1




1




$begingroup$
By using an extended precision version of 0 you can get a small speedup from using numbers instead of full symbolic expressions but without sacrificing accuracy. Try d=0``1.
$endgroup$
– b3m2a1
5 hours ago






$begingroup$
By using an extended precision version of 0 you can get a small speedup from using numbers instead of full symbolic expressions but without sacrificing accuracy. Try d=0``1.
$endgroup$
– b3m2a1
5 hours ago






2




2




$begingroup$
Also in terms of programming style this is probably faster: d + NestList[1/(# - Floor[# + d]) &, t, 200] // Floor // RepeatedTiming
$endgroup$
– b3m2a1
5 hours ago




$begingroup$
Also in terms of programming style this is probably faster: d + NestList[1/(# - Floor[# + d]) &, t, 200] // Floor // RepeatedTiming
$endgroup$
– b3m2a1
5 hours ago










2 Answers
2






active

oldest

votes


















4












$begingroup$

Your algorithm is probing the limits of machine precision numbers.



When you add Sqrt[17]+0 you get $sqrt{17}$ with infinite precision:



Sqrt[17] + 0
(* Sqrt[17] *)


When you add Sqrt[17]+0.0 you get much less precision:



Sqrt[17] + 0.0 // FullForm
(* 4.123105625617661` *)


The number you're effectively dealing with in the d=0.0 case is not $t=sqrt{17}$ but



SetPrecision[Sqrt[17] + 0.0, ∞]
(* 4642204239785223/1125899906842624 *)


which is the closest available machine-precision number to $sqrt{17}$.



If you change your code to



t = 4642204239785223/1125899906842624;
d = 0;
n = 11;
a = ConstantArray[0, n];
Do[a[[i]] = Floor[t + d]; t = 1/(t - Floor[t + d]), {i, 1, n}];
a


you get a similar answer to the d=0.0 case:



(* {4, 8, 8, 8, 8, 8, 8, 8, 8, 7, 2} *)


Another way of seeing this is that you're doing a continued-fraction representation, which differs when you convert a number to its machine-precision representation:



ContinuedFraction[Sqrt[17]]
(* {4, {8}} *)
ContinuedFraction[Sqrt[17] // N]
(* {4, 8, 8, 8, 8, 8, 8, 8} *)


Notice that the builtin ContinuedFraction command stops before spitting out "wrong" digits due to machine-precision issues.






share|improve this answer











$endgroup$





















    0












    $begingroup$

    Two comments rolled into one.



    Try using extended precision numbers like:



    d = 0``1


    Also try a different programming style to get things cleaner and a bit faster:



    t = Sqrt[17];
    d = 0``1;
    d + NestList[1/(# - Floor[# + d]) &, t, 200] // Floor // RepeatedTiming

    {0.0055, {4, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8,
    8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8,
    8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8,
    8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8,
    8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8,
    8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8,
    8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8,
    8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8,
    8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8,
    8}}





    share|improve this answer









    $endgroup$













      Your Answer





      StackExchange.ifUsing("editor", function () {
      return StackExchange.using("mathjaxEditing", function () {
      StackExchange.MarkdownEditor.creationCallbacks.add(function (editor, postfix) {
      StackExchange.mathjaxEditing.prepareWmdForMathJax(editor, postfix, [["$", "$"], ["\\(","\\)"]]);
      });
      });
      }, "mathjax-editing");

      StackExchange.ready(function() {
      var channelOptions = {
      tags: "".split(" "),
      id: "387"
      };
      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: false,
      noModals: true,
      showLowRepImageUploadWarning: true,
      reputationToPostImages: null,
      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%2fmathematica.stackexchange.com%2fquestions%2f190863%2fwhy-is-0-vs-0-0-causing-a-precision-problem%23new-answer', 'question_page');
      }
      );

      Post as a guest















      Required, but never shown

























      2 Answers
      2






      active

      oldest

      votes








      2 Answers
      2






      active

      oldest

      votes









      active

      oldest

      votes






      active

      oldest

      votes









      4












      $begingroup$

      Your algorithm is probing the limits of machine precision numbers.



      When you add Sqrt[17]+0 you get $sqrt{17}$ with infinite precision:



      Sqrt[17] + 0
      (* Sqrt[17] *)


      When you add Sqrt[17]+0.0 you get much less precision:



      Sqrt[17] + 0.0 // FullForm
      (* 4.123105625617661` *)


      The number you're effectively dealing with in the d=0.0 case is not $t=sqrt{17}$ but



      SetPrecision[Sqrt[17] + 0.0, ∞]
      (* 4642204239785223/1125899906842624 *)


      which is the closest available machine-precision number to $sqrt{17}$.



      If you change your code to



      t = 4642204239785223/1125899906842624;
      d = 0;
      n = 11;
      a = ConstantArray[0, n];
      Do[a[[i]] = Floor[t + d]; t = 1/(t - Floor[t + d]), {i, 1, n}];
      a


      you get a similar answer to the d=0.0 case:



      (* {4, 8, 8, 8, 8, 8, 8, 8, 8, 7, 2} *)


      Another way of seeing this is that you're doing a continued-fraction representation, which differs when you convert a number to its machine-precision representation:



      ContinuedFraction[Sqrt[17]]
      (* {4, {8}} *)
      ContinuedFraction[Sqrt[17] // N]
      (* {4, 8, 8, 8, 8, 8, 8, 8} *)


      Notice that the builtin ContinuedFraction command stops before spitting out "wrong" digits due to machine-precision issues.






      share|improve this answer











      $endgroup$


















        4












        $begingroup$

        Your algorithm is probing the limits of machine precision numbers.



        When you add Sqrt[17]+0 you get $sqrt{17}$ with infinite precision:



        Sqrt[17] + 0
        (* Sqrt[17] *)


        When you add Sqrt[17]+0.0 you get much less precision:



        Sqrt[17] + 0.0 // FullForm
        (* 4.123105625617661` *)


        The number you're effectively dealing with in the d=0.0 case is not $t=sqrt{17}$ but



        SetPrecision[Sqrt[17] + 0.0, ∞]
        (* 4642204239785223/1125899906842624 *)


        which is the closest available machine-precision number to $sqrt{17}$.



        If you change your code to



        t = 4642204239785223/1125899906842624;
        d = 0;
        n = 11;
        a = ConstantArray[0, n];
        Do[a[[i]] = Floor[t + d]; t = 1/(t - Floor[t + d]), {i, 1, n}];
        a


        you get a similar answer to the d=0.0 case:



        (* {4, 8, 8, 8, 8, 8, 8, 8, 8, 7, 2} *)


        Another way of seeing this is that you're doing a continued-fraction representation, which differs when you convert a number to its machine-precision representation:



        ContinuedFraction[Sqrt[17]]
        (* {4, {8}} *)
        ContinuedFraction[Sqrt[17] // N]
        (* {4, 8, 8, 8, 8, 8, 8, 8} *)


        Notice that the builtin ContinuedFraction command stops before spitting out "wrong" digits due to machine-precision issues.






        share|improve this answer











        $endgroup$
















          4












          4








          4





          $begingroup$

          Your algorithm is probing the limits of machine precision numbers.



          When you add Sqrt[17]+0 you get $sqrt{17}$ with infinite precision:



          Sqrt[17] + 0
          (* Sqrt[17] *)


          When you add Sqrt[17]+0.0 you get much less precision:



          Sqrt[17] + 0.0 // FullForm
          (* 4.123105625617661` *)


          The number you're effectively dealing with in the d=0.0 case is not $t=sqrt{17}$ but



          SetPrecision[Sqrt[17] + 0.0, ∞]
          (* 4642204239785223/1125899906842624 *)


          which is the closest available machine-precision number to $sqrt{17}$.



          If you change your code to



          t = 4642204239785223/1125899906842624;
          d = 0;
          n = 11;
          a = ConstantArray[0, n];
          Do[a[[i]] = Floor[t + d]; t = 1/(t - Floor[t + d]), {i, 1, n}];
          a


          you get a similar answer to the d=0.0 case:



          (* {4, 8, 8, 8, 8, 8, 8, 8, 8, 7, 2} *)


          Another way of seeing this is that you're doing a continued-fraction representation, which differs when you convert a number to its machine-precision representation:



          ContinuedFraction[Sqrt[17]]
          (* {4, {8}} *)
          ContinuedFraction[Sqrt[17] // N]
          (* {4, 8, 8, 8, 8, 8, 8, 8} *)


          Notice that the builtin ContinuedFraction command stops before spitting out "wrong" digits due to machine-precision issues.






          share|improve this answer











          $endgroup$



          Your algorithm is probing the limits of machine precision numbers.



          When you add Sqrt[17]+0 you get $sqrt{17}$ with infinite precision:



          Sqrt[17] + 0
          (* Sqrt[17] *)


          When you add Sqrt[17]+0.0 you get much less precision:



          Sqrt[17] + 0.0 // FullForm
          (* 4.123105625617661` *)


          The number you're effectively dealing with in the d=0.0 case is not $t=sqrt{17}$ but



          SetPrecision[Sqrt[17] + 0.0, ∞]
          (* 4642204239785223/1125899906842624 *)


          which is the closest available machine-precision number to $sqrt{17}$.



          If you change your code to



          t = 4642204239785223/1125899906842624;
          d = 0;
          n = 11;
          a = ConstantArray[0, n];
          Do[a[[i]] = Floor[t + d]; t = 1/(t - Floor[t + d]), {i, 1, n}];
          a


          you get a similar answer to the d=0.0 case:



          (* {4, 8, 8, 8, 8, 8, 8, 8, 8, 7, 2} *)


          Another way of seeing this is that you're doing a continued-fraction representation, which differs when you convert a number to its machine-precision representation:



          ContinuedFraction[Sqrt[17]]
          (* {4, {8}} *)
          ContinuedFraction[Sqrt[17] // N]
          (* {4, 8, 8, 8, 8, 8, 8, 8} *)


          Notice that the builtin ContinuedFraction command stops before spitting out "wrong" digits due to machine-precision issues.







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited 6 hours ago

























          answered 6 hours ago









          RomanRoman

          833511




          833511























              0












              $begingroup$

              Two comments rolled into one.



              Try using extended precision numbers like:



              d = 0``1


              Also try a different programming style to get things cleaner and a bit faster:



              t = Sqrt[17];
              d = 0``1;
              d + NestList[1/(# - Floor[# + d]) &, t, 200] // Floor // RepeatedTiming

              {0.0055, {4, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8,
              8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8,
              8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8,
              8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8,
              8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8,
              8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8,
              8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8,
              8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8,
              8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8,
              8}}





              share|improve this answer









              $endgroup$


















                0












                $begingroup$

                Two comments rolled into one.



                Try using extended precision numbers like:



                d = 0``1


                Also try a different programming style to get things cleaner and a bit faster:



                t = Sqrt[17];
                d = 0``1;
                d + NestList[1/(# - Floor[# + d]) &, t, 200] // Floor // RepeatedTiming

                {0.0055, {4, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8,
                8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8,
                8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8,
                8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8,
                8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8,
                8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8,
                8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8,
                8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8,
                8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8,
                8}}





                share|improve this answer









                $endgroup$
















                  0












                  0








                  0





                  $begingroup$

                  Two comments rolled into one.



                  Try using extended precision numbers like:



                  d = 0``1


                  Also try a different programming style to get things cleaner and a bit faster:



                  t = Sqrt[17];
                  d = 0``1;
                  d + NestList[1/(# - Floor[# + d]) &, t, 200] // Floor // RepeatedTiming

                  {0.0055, {4, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8,
                  8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8,
                  8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8,
                  8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8,
                  8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8,
                  8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8,
                  8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8,
                  8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8,
                  8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8,
                  8}}





                  share|improve this answer









                  $endgroup$



                  Two comments rolled into one.



                  Try using extended precision numbers like:



                  d = 0``1


                  Also try a different programming style to get things cleaner and a bit faster:



                  t = Sqrt[17];
                  d = 0``1;
                  d + NestList[1/(# - Floor[# + d]) &, t, 200] // Floor // RepeatedTiming

                  {0.0055, {4, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8,
                  8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8,
                  8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8,
                  8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8,
                  8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8,
                  8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8,
                  8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8,
                  8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8,
                  8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8,
                  8}}






                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered 5 hours ago









                  b3m2a1b3m2a1

                  27.6k257161




                  27.6k257161






























                      draft saved

                      draft discarded




















































                      Thanks for contributing an answer to Mathematica Stack Exchange!


                      • 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.


                      Use MathJax to format equations. MathJax reference.


                      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%2fmathematica.stackexchange.com%2fquestions%2f190863%2fwhy-is-0-vs-0-0-causing-a-precision-problem%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

                      A CLEAN and SIMPLE way to add appendices to Table of Contents and bookmarks

                      Calculate evaluation metrics using cross_val_predict sklearn

                      Insert data from modal to MySQL (multiple modal on website)