Mixing
Gauss-Seidel Method, differences from key in Python
$begingroup$
Here is the problem
equation 2: x1 = 1/7(6 + y0)
equation 3: y1 = 1/5(x1 + 4)
Define a function, called gs1_iteration, which accepts as input values for
x and y (which we think of as being xn-1 and yn-1 respectively), and returns a list
[new_x,new_y], where new_x is the updated value x_n and new_y is the updated value y_n
using the Gauss-Seidel method and equations (2) and (3).
In other words, gs1_iteration(x,y) should return the results of performing one iteration of the Gauss-Seidel method for system (1) on the inputs x, y.
To test your function, note that gs1_iteration(3,5) should return
[1.5714285714285714, 1.1142857142857143].
So I know I have this first iteration right as
def gs1_iteration(x,y):
new_x=0
new_y=0
new_x = 1/7*(6+y)
new_y = 1/5*(new_x+4)
y = new_y
return [new_x,new_y]
gs1_iteration(3,5)
returns [1.5714285714285714, 1.1142857142857143]
However, the next problem states:
Define a function, called gs1_method, which accepts as input a single non-
negative integer n, and returns a list [x_n,y_n], where x_n and y_n are the values of x_n and y_n respectively for the Gauss-Seidel method when applied to system (1) above. Use
(x0, y0) = (0, 0) as your starting approximation.
To test your function, note that gs1_method(2) should return the list
[0.9959183673469388, 0.9991836734693879].
But my code returns a different value
def gs1_method(n):
x_n=0
y_n=0
for i in range(n):
[x_n, y_n] = gs1_iteration(x_n,y_n)
return [x_n,y_n]
gs1_method(2)
returns [0.9959183673469387, 0.9991836734693877], which is different in the last decimal place than the key shows
From what I understand, my equation should work, as according to the Gauss-Seidel method, I'm using the new value of x and y for the iterations. Because I'm getting a different value, I think there must be some error in my equation. What equation should I use for my Gauss-Seidel program, or what can I fix in my current equation to get the values provided in the key?
I wasn't sure if this would have been more appropriate on stack overflow, but I think my actual problem is with my math, which is why I posted it here.
linear-algebra python
asked Jan 30 at 18:14
Joe-You-KnowJoe-You-Know
1185
$endgroup$
|
show 3 more comments
$begingroup$
Here is the problem
equation 2: x1 = 1/7(6 + y0)
equation 3: y1 = 1/5(x1 + 4)
Define a function, called gs1_iteration, which accepts as input values for
x and y (which we think of as being xn-1 and yn-1 respectively), and returns a list
[new_x,new_y], where new_x is the updated value x_n and new_y is the updated value y_n
using the Gauss-Seidel method and equations (2) and (3).
In other words, gs1_iteration(x,y) should return the results of performing one iteration of the Gauss-Seidel method for system (1) on the inputs x, y.
To test your function, note that gs1_iteration(3,5) should return
[1.5714285714285714, 1.1142857142857143].
So I know I have this first iteration right as
def gs1_iteration(x,y):
new_x=0
new_y=0
new_x = 1/7*(6+y)
new_y = 1/5*(new_x+4)
y = new_y
return [new_x,new_y]
gs1_iteration(3,5)
returns [1.5714285714285714, 1.1142857142857143]
However, the next problem states:
Define a function, called gs1_method, which accepts as input a single non-
negative integer n, and returns a list [x_n,y_n], where x_n and y_n are the values of x_n and y_n respectively for the Gauss-Seidel method when applied to system (1) above. Use
(x0, y0) = (0, 0) as your starting approximation.
To test your function, note that gs1_method(2) should return the list
[0.9959183673469388, 0.9991836734693879].
But my code returns a different value
def gs1_method(n):
x_n=0
y_n=0
for i in range(n):
[x_n, y_n] = gs1_iteration(x_n,y_n)
return [x_n,y_n]
gs1_method(2)
returns [0.9959183673469387, 0.9991836734693877], which is different in the last decimal place than the key shows
From what I understand, my equation should work, as according to the Gauss-Seidel method, I'm using the new value of x and y for the iterations. Because I'm getting a different value, I think there must be some error in my equation. What equation should I use for my Gauss-Seidel program, or what can I fix in my current equation to get the values provided in the key?
I wasn't sure if this would have been more appropriate on stack overflow, but I think my actual problem is with my math, which is why I posted it here.
linear-algebra python
asked Jan 30 at 18:14
Joe-You-KnowJoe-You-Know
1185
$endgroup$
$begingroup$
Are you sure you are supposed to be precise in the last digit? You would have to make exactly the same rounding errors, which would mean at least using the same order of operations, probably on the same ALU. Generally last digit is absolutely OK if you are not specifically working on rounding error problems.
$endgroup$
– Lukáš Mrazík
Jan 30 at 18:23
$begingroup$
The problem arises when I use my error function after this, which has the last 4 decimal places off after it iterates 3 times (and I know my error function is calculated correctly, because it's just the distance between two points). I'll talk to a TA about it, but I'm pretty sure it's supposed to be precise, but I couldn't find anything wrong with my equation.
$endgroup$
– Joe-You-Know
Jan 30 at 18:28
$begingroup$
You might try to rewrite eqs as (6+y)/7 and (new_x+4)/5. 4 digits of after 50 iterations seems fine to me, if the math was wrong, you would be way off even with the first iteration.
$endgroup$
– Lukáš Mrazík
Jan 30 at 18:34
$begingroup$
@Joe-You-Know Python stores these numbers as what are called floats, but you can manually change to another, more precise format to address this. Options are discussed here.
$endgroup$
– J.G.
Jan 30 at 18:36
1
$begingroup$
@Joe-You-Know You might also want to try changing5to5.0etc (in fact just5.will do). Failing that, I suspect your TA's approach used floats but got different result for hardware-specific or stochastic reasons, or because of a different Python "interpretation" running locally. I'm not an expert on what happens under the hood, but interpreted languages can be susceptible to that.
$endgroup$
– J.G.
Jan 30 at 19:00
|
show 3 more comments
$begingroup$
Here is the problem
equation 2: x1 = 1/7(6 + y0)
equation 3: y1 = 1/5(x1 + 4)
Define a function, called gs1_iteration, which accepts as input values for
x and y (which we think of as being xn-1 and yn-1 respectively), and returns a list
[new_x,new_y], where new_x is the updated value x_n and new_y is the updated value y_n
using the Gauss-Seidel method and equations (2) and (3).
In other words, gs1_iteration(x,y) should return the results of performing one iteration of the Gauss-Seidel method for system (1) on the inputs x, y.
To test your function, note that gs1_iteration(3,5) should return
[1.5714285714285714, 1.1142857142857143].
So I know I have this first iteration right as
def gs1_iteration(x,y):
new_x=0
new_y=0
new_x = 1/7*(6+y)
new_y = 1/5*(new_x+4)
y = new_y
return [new_x,new_y]
gs1_iteration(3,5)
returns [1.5714285714285714, 1.1142857142857143]
However, the next problem states:
Define a function, called gs1_method, which accepts as input a single non-
negative integer n, and returns a list [x_n,y_n], where x_n and y_n are the values of x_n and y_n respectively for the Gauss-Seidel method when applied to system (1) above. Use
(x0, y0) = (0, 0) as your starting approximation.
To test your function, note that gs1_method(2) should return the list
[0.9959183673469388, 0.9991836734693879].
But my code returns a different value
def gs1_method(n):
x_n=0
y_n=0
for i in range(n):
[x_n, y_n] = gs1_iteration(x_n,y_n)
return [x_n,y_n]
gs1_method(2)
returns [0.9959183673469387, 0.9991836734693877], which is different in the last decimal place than the key shows
From what I understand, my equation should work, as according to the Gauss-Seidel method, I'm using the new value of x and y for the iterations. Because I'm getting a different value, I think there must be some error in my equation. What equation should I use for my Gauss-Seidel program, or what can I fix in my current equation to get the values provided in the key?
I wasn't sure if this would have been more appropriate on stack overflow, but I think my actual problem is with my math, which is why I posted it here.
linear-algebra python
asked Jan 30 at 18:14
Joe-You-KnowJoe-You-Know
1185
$endgroup$
Here is the problem
equation 2: x1 = 1/7(6 + y0)
equation 3: y1 = 1/5(x1 + 4)
Define a function, called gs1_iteration, which accepts as input values for
x and y (which we think of as being xn-1 and yn-1 respectively), and returns a list
[new_x,new_y], where new_x is the updated value x_n and new_y is the updated value y_n
using the Gauss-Seidel method and equations (2) and (3).
In other words, gs1_iteration(x,y) should return the results of performing one iteration of the Gauss-Seidel method for system (1) on the inputs x, y.
To test your function, note that gs1_iteration(3,5) should return
[1.5714285714285714, 1.1142857142857143].
So I know I have this first iteration right as
def gs1_iteration(x,y):
new_x=0
new_y=0
new_x = 1/7*(6+y)
new_y = 1/5*(new_x+4)
y = new_y
return [new_x,new_y]
gs1_iteration(3,5)
returns [1.5714285714285714, 1.1142857142857143]
However, the next problem states:
Define a function, called gs1_method, which accepts as input a single non-
negative integer n, and returns a list [x_n,y_n], where x_n and y_n are the values of x_n and y_n respectively for the Gauss-Seidel method when applied to system (1) above. Use
(x0, y0) = (0, 0) as your starting approximation.
To test your function, note that gs1_method(2) should return the list
[0.9959183673469388, 0.9991836734693879].
But my code returns a different value
def gs1_method(n):
x_n=0
y_n=0
for i in range(n):
[x_n, y_n] = gs1_iteration(x_n,y_n)
return [x_n,y_n]
gs1_method(2)
returns [0.9959183673469387, 0.9991836734693877], which is different in the last decimal place than the key shows
From what I understand, my equation should work, as according to the Gauss-Seidel method, I'm using the new value of x and y for the iterations. Because I'm getting a different value, I think there must be some error in my equation. What equation should I use for my Gauss-Seidel program, or what can I fix in my current equation to get the values provided in the key?
I wasn't sure if this would have been more appropriate on stack overflow, but I think my actual problem is with my math, which is why I posted it here.
linear-algebra python
linear-algebra python
asked Jan 30 at 18:14
Joe-You-KnowJoe-You-Know
1185
asked Jan 30 at 18:14
Joe-You-KnowJoe-You-Know
1185
edited Jan 30 at 18:22
Joe-You-Know
asked Jan 30 at 18:14
Joe-You-KnowJoe-You-Know
1185
asked Jan 30 at 18:14
Joe-You-KnowJoe-You-Know
1185
asked Jan 30 at 18:14
Joe-You-KnowJoe-You-Know
1185
1185
$begingroup$
Are you sure you are supposed to be precise in the last digit? You would have to make exactly the same rounding errors, which would mean at least using the same order of operations, probably on the same ALU. Generally last digit is absolutely OK if you are not specifically working on rounding error problems.
$endgroup$
– Lukáš Mrazík
Jan 30 at 18:23
$begingroup$
The problem arises when I use my error function after this, which has the last 4 decimal places off after it iterates 3 times (and I know my error function is calculated correctly, because it's just the distance between two points). I'll talk to a TA about it, but I'm pretty sure it's supposed to be precise, but I couldn't find anything wrong with my equation.
$endgroup$
– Joe-You-Know
Jan 30 at 18:28
$begingroup$
You might try to rewrite eqs as (6+y)/7 and (new_x+4)/5. 4 digits of after 50 iterations seems fine to me, if the math was wrong, you would be way off even with the first iteration.
$endgroup$
– Lukáš Mrazík
Jan 30 at 18:34
$begingroup$
@Joe-You-Know Python stores these numbers as what are called floats, but you can manually change to another, more precise format to address this. Options are discussed here.
$endgroup$
– J.G.
Jan 30 at 18:36
1
$begingroup$
@Joe-You-Know You might also want to try changing5to5.0etc (in fact just5.will do). Failing that, I suspect your TA's approach used floats but got different result for hardware-specific or stochastic reasons, or because of a different Python "interpretation" running locally. I'm not an expert on what happens under the hood, but interpreted languages can be susceptible to that.
$endgroup$
– J.G.
Jan 30 at 19:00
|
show 3 more comments
$begingroup$
Are you sure you are supposed to be precise in the last digit? You would have to make exactly the same rounding errors, which would mean at least using the same order of operations, probably on the same ALU. Generally last digit is absolutely OK if you are not specifically working on rounding error problems.
$endgroup$
– Lukáš Mrazík
Jan 30 at 18:23
$begingroup$
The problem arises when I use my error function after this, which has the last 4 decimal places off after it iterates 3 times (and I know my error function is calculated correctly, because it's just the distance between two points). I'll talk to a TA about it, but I'm pretty sure it's supposed to be precise, but I couldn't find anything wrong with my equation.
$endgroup$
– Joe-You-Know
Jan 30 at 18:28
$begingroup$
You might try to rewrite eqs as (6+y)/7 and (new_x+4)/5. 4 digits of after 50 iterations seems fine to me, if the math was wrong, you would be way off even with the first iteration.
$endgroup$
– Lukáš Mrazík
Jan 30 at 18:34
$begingroup$
@Joe-You-Know Python stores these numbers as what are called floats, but you can manually change to another, more precise format to address this. Options are discussed here.
$endgroup$
– J.G.
Jan 30 at 18:36
1
$begingroup$
@Joe-You-Know You might also want to try changing5to5.0etc (in fact just5.will do). Failing that, I suspect your TA's approach used floats but got different result for hardware-specific or stochastic reasons, or because of a different Python "interpretation" running locally. I'm not an expert on what happens under the hood, but interpreted languages can be susceptible to that.
$endgroup$
– J.G.
Jan 30 at 19:00
$begingroup$
Are you sure you are supposed to be precise in the last digit? You would have to make exactly the same rounding errors, which would mean at least using the same order of operations, probably on the same ALU. Generally last digit is absolutely OK if you are not specifically working on rounding error problems.
$endgroup$
– Lukáš Mrazík
Jan 30 at 18:23
$begingroup$
Are you sure you are supposed to be precise in the last digit? You would have to make exactly the same rounding errors, which would mean at least using the same order of operations, probably on the same ALU. Generally last digit is absolutely OK if you are not specifically working on rounding error problems.
$endgroup$
– Lukáš Mrazík
Jan 30 at 18:23
$begingroup$
The problem arises when I use my error function after this, which has the last 4 decimal places off after it iterates 3 times (and I know my error function is calculated correctly, because it's just the distance between two points). I'll talk to a TA about it, but I'm pretty sure it's supposed to be precise, but I couldn't find anything wrong with my equation.
$endgroup$
– Joe-You-Know
Jan 30 at 18:28
$begingroup$
The problem arises when I use my error function after this, which has the last 4 decimal places off after it iterates 3 times (and I know my error function is calculated correctly, because it's just the distance between two points). I'll talk to a TA about it, but I'm pretty sure it's supposed to be precise, but I couldn't find anything wrong with my equation.
$endgroup$
– Joe-You-Know
Jan 30 at 18:28
$begingroup$
You might try to rewrite eqs as (6+y)/7 and (new_x+4)/5. 4 digits of after 50 iterations seems fine to me, if the math was wrong, you would be way off even with the first iteration.
$endgroup$
– Lukáš Mrazík
Jan 30 at 18:34
$begingroup$
You might try to rewrite eqs as (6+y)/7 and (new_x+4)/5. 4 digits of after 50 iterations seems fine to me, if the math was wrong, you would be way off even with the first iteration.
$endgroup$
– Lukáš Mrazík
Jan 30 at 18:34
$begingroup$
@Joe-You-Know Python stores these numbers as what are called floats, but you can manually change to another, more precise format to address this. Options are discussed here.
$endgroup$
– J.G.
Jan 30 at 18:36
$begingroup$
@Joe-You-Know Python stores these numbers as what are called floats, but you can manually change to another, more precise format to address this. Options are discussed here.
$endgroup$
– J.G.
Jan 30 at 18:36
1
1
$begingroup$
@Joe-You-Know You might also want to try changing
5 to 5.0 etc (in fact just 5. will do). Failing that, I suspect your TA's approach used floats but got different result for hardware-specific or stochastic reasons, or because of a different Python "interpretation" running locally. I'm not an expert on what happens under the hood, but interpreted languages can be susceptible to that.$endgroup$
– J.G.
Jan 30 at 19:00
$begingroup$
@Joe-You-Know You might also want to try changing
5 to 5.0 etc (in fact just 5. will do). Failing that, I suspect your TA's approach used floats but got different result for hardware-specific or stochastic reasons, or because of a different Python "interpretation" running locally. I'm not an expert on what happens under the hood, but interpreted languages can be susceptible to that.$endgroup$
– J.G.
Jan 30 at 19:00
|
show 3 more comments
0
active
oldest
votes
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: "69"
};
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
},
noCode: 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%2fmath.stackexchange.com%2fquestions%2f3093900%2fgauss-seidel-method-differences-from-key-in-python%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
0
active
oldest
votes
0
active
oldest
votes
active
oldest
votes
active
oldest
votes
Thanks for contributing an answer to Mathematics 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%2fmath.stackexchange.com%2fquestions%2f3093900%2fgauss-seidel-method-differences-from-key-in-python%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
$begingroup$
Are you sure you are supposed to be precise in the last digit? You would have to make exactly the same rounding errors, which would mean at least using the same order of operations, probably on the same ALU. Generally last digit is absolutely OK if you are not specifically working on rounding error problems.
$endgroup$
– Lukáš Mrazík
Jan 30 at 18:23
$begingroup$
The problem arises when I use my error function after this, which has the last 4 decimal places off after it iterates 3 times (and I know my error function is calculated correctly, because it's just the distance between two points). I'll talk to a TA about it, but I'm pretty sure it's supposed to be precise, but I couldn't find anything wrong with my equation.
$endgroup$
– Joe-You-Know
Jan 30 at 18:28
$begingroup$
You might try to rewrite eqs as (6+y)/7 and (new_x+4)/5. 4 digits of after 50 iterations seems fine to me, if the math was wrong, you would be way off even with the first iteration.
$endgroup$
– Lukáš Mrazík
Jan 30 at 18:34
$begingroup$
@Joe-You-Know Python stores these numbers as what are called floats, but you can manually change to another, more precise format to address this. Options are discussed here.
$endgroup$
– J.G.
Jan 30 at 18:36
1
$begingroup$
@Joe-You-Know You might also want to try changing
5to5.0etc (in fact just5.will do). Failing that, I suspect your TA's approach used floats but got different result for hardware-specific or stochastic reasons, or because of a different Python "interpretation" running locally. I'm not an expert on what happens under the hood, but interpreted languages can be susceptible to that.$endgroup$
– J.G.
Jan 30 at 19:00