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 5 hours ago
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 5 hours ago
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
5 hours ago
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
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
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 5 hours ago
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 5 hours ago
Jerry GuernJerry Guern
1,995933
asked 5 hours ago
Jerry GuernJerry Guern
1,995933
asked 5 hours ago
Jerry GuernJerry Guern
1,995933
asked 5 hours ago
Jerry GuernJerry Guern
1,995933
asked 5 hours ago
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
5 hours ago
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
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
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
5 hours ago
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
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
5 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
5 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
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 5 hours ago
RomanRoman
833511
$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 5 hours ago
b3m2a1b3m2a1
27.6k257161
$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 5 hours ago
RomanRoman
833511
$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 5 hours ago
RomanRoman
833511
$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 5 hours ago
RomanRoman
833511
$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 5 hours ago
RomanRoman
833511
edited 5 hours ago
answered 5 hours ago
RomanRoman
833511
answered 5 hours ago
RomanRoman
833511
answered 5 hours ago
RomanRoman
833511
833511
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 5 hours ago
b3m2a1b3m2a1
27.6k257161
$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 5 hours ago
b3m2a1b3m2a1
27.6k257161
$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 5 hours ago
b3m2a1b3m2a1
27.6k257161
$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 5 hours ago
b3m2a1b3m2a1
27.6k257161
answered 5 hours ago
b3m2a1b3m2a1
27.6k257161
answered 5 hours ago
b3m2a1b3m2a1
27.6k257161
answered 5 hours ago
b3m2a1b3m2a1
27.6k257161
27.6k257161
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
5 hours ago
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
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