Why is 0 vs 0.0 causing a precision problem?
$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?
machine-precision precision-and-accuracy
asked yesterday
Jerry GuernJerry Guern
1,995933
$endgroup$
add a comment |
$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?
machine-precision precision-and-accuracy
asked yesterday
Jerry GuernJerry Guern
1,995933
$endgroup$
1
$begingroup$
The presence of any machine precision number (including0.0) will result in the calculation being done with machine precision.
$endgroup$
– Bob Hanlon
yesterday
1
$begingroup$
By using an extended precision version of0you can get a small speedup from using numbers instead of full symbolic expressions but without sacrificing accuracy. Tryd=0``1.
$endgroup$
– b3m2a1
yesterday
2
$begingroup$
Also in terms of programming style this is probably faster:d + NestList[1/(# - Floor[# + d]) &, t, 200] // Floor // RepeatedTiming
$endgroup$
– b3m2a1
yesterday
add a comment |
$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?
machine-precision precision-and-accuracy
asked yesterday
Jerry GuernJerry Guern
1,995933
$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
machine-precision precision-and-accuracy
asked yesterday
Jerry GuernJerry Guern
1,995933
asked yesterday
Jerry GuernJerry Guern
1,995933
asked yesterday
Jerry GuernJerry Guern
1,995933
asked yesterday
Jerry GuernJerry Guern
1,995933
asked yesterday
Jerry GuernJerry Guern
1,995933
1,995933
1
$begingroup$
The presence of any machine precision number (including0.0) will result in the calculation being done with machine precision.
$endgroup$
– Bob Hanlon
yesterday
1
$begingroup$
By using an extended precision version of0you can get a small speedup from using numbers instead of full symbolic expressions but without sacrificing accuracy. Tryd=0``1.
$endgroup$
– b3m2a1
yesterday
2
$begingroup$
Also in terms of programming style this is probably faster:d + NestList[1/(# - Floor[# + d]) &, t, 200] // Floor // RepeatedTiming
$endgroup$
– b3m2a1
yesterday
add a comment |
1
$begingroup$
The presence of any machine precision number (including0.0) will result in the calculation being done with machine precision.
$endgroup$
– Bob Hanlon
yesterday
1
$begingroup$
By using an extended precision version of0you can get a small speedup from using numbers instead of full symbolic expressions but without sacrificing accuracy. Tryd=0``1.
$endgroup$
– b3m2a1
yesterday
2
$begingroup$
Also in terms of programming style this is probably faster:d + NestList[1/(# - Floor[# + d]) &, t, 200] // Floor // RepeatedTiming
$endgroup$
– b3m2a1
yesterday
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
yesterday
$begingroup$
The presence of any machine precision number (including
0.0) will result in the calculation being done with machine precision.$endgroup$
– Bob Hanlon
yesterday
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
yesterday
$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
yesterday
2
2
$begingroup$
Also in terms of programming style this is probably faster:
d + NestList[1/(# - Floor[# + d]) &, t, 200] // Floor // RepeatedTiming$endgroup$
– b3m2a1
yesterday
$begingroup$
Also in terms of programming style this is probably faster:
d + NestList[1/(# - Floor[# + d]) &, t, 200] // Floor // RepeatedTiming$endgroup$
– b3m2a1
yesterday
add a comment |
2 Answers
2
active
oldest
votes
$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.
answered yesterday
RomanRoman
842511
$endgroup$
add a comment |
$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}}
answered yesterday
b3m2a1b3m2a1
27.6k357161
$endgroup$
add a comment |
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
$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.
answered yesterday
RomanRoman
842511
$endgroup$
add a comment |
$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.
answered yesterday
RomanRoman
842511
$endgroup$
add a comment |
$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.
answered yesterday
RomanRoman
842511
$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.
answered yesterday
RomanRoman
842511
edited yesterday
answered yesterday
RomanRoman
842511
answered yesterday
RomanRoman
842511
answered yesterday
RomanRoman
842511
842511
add a comment |
add a comment |
$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}}
answered yesterday
b3m2a1b3m2a1
27.6k357161
$endgroup$
add a comment |
$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}}
answered yesterday
b3m2a1b3m2a1
27.6k357161
$endgroup$
add a comment |
$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}}
answered yesterday
b3m2a1b3m2a1
27.6k357161
$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}}
answered yesterday
b3m2a1b3m2a1
27.6k357161
answered yesterday
b3m2a1b3m2a1
27.6k357161
answered yesterday
b3m2a1b3m2a1
27.6k357161
answered yesterday
b3m2a1b3m2a1
27.6k357161
27.6k357161
add a comment |
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
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
yesterday
1
$begingroup$
By using an extended precision version of
0you can get a small speedup from using numbers instead of full symbolic expressions but without sacrificing accuracy. Tryd=0``1.$endgroup$
– b3m2a1
yesterday
2
$begingroup$
Also in terms of programming style this is probably faster:
d + NestList[1/(# - Floor[# + d]) &, t, 200] // Floor // RepeatedTiming$endgroup$
– b3m2a1
yesterday