Vector giving weird multiplication

prompt = {'Mass 1','Mass 2','K1','K2','K3'};
dlg_title = 'Constants';
num_lines = 1;
defaultans = {'1','1','1','1','1'};
temp = inputdlg(prompt,dlg_title,num_lines,defaultans);
[m1,m2,k1,k2,k3] = temp{:};
A=[-(k1+k2)/(m1),k2/m1;k2/m2,-(k2+k3)/m2];
[v,d]=eig(A);
v1 = v(1:2,1);
v2 = v(1:2,2);
prompt = {'Starting x1','Starting x2'};
dlg_title = 'Start x relative to equalib.';
num_lines = 1;
defaultans = {'1','0'};
answer = inputdlg(prompt,dlg_title,num_lines,defaultans);
[x1,x2] = answer{:};
x = [x1;x2];
gamma=inv(v)*x;

So Im very new to Matlab and have been "tweaking" another code I found online that relates two masses attached to 3 springs and they have only a linear motion. My problem is in the output of gamma, where Im supposed to be getting an answer of x = [.7071;.7071], but Im getting x = [.7071,68.5894] which is really off. Also when I was trying to figure out where something went wrong, I noticed that if I set "e" as a 2x2 identity matrix and go e*x, I get the weird answer of [49;48]. Thedefault answers are what I used. Any help would be greatly appreciated

[Adam]

Your program is based on user inputs so it is impossible for us to know what values were input to produce these answers.

[M]

Sorry, just the default answers in the inputs is what I used.

[Stephen23]

You should read the inv documentation, which explicitly warns against doing the exact calculation that you are attempting: "A\b is computed differently than x = inv(A)*b and is recommended for solving systems of linear equations." and "Using A\b instead of inv(A)*b is two to three times faster, and produces residuals on the order of machine accuracy relative to the magnitude of the data."

Lets try the correct way of solving these equations then:

>> v\x
ans =
  0.70711
 68.58936

[M]

The original code was much simpler, where all the input values were just 1 anyway. It is the gamma Im trying to obtain.

A=[-2 1;1 -2];
[v,d]=eig(A)
x0=[1 0]'
gamma=inv(v)*x0

[M]

furthermore, Ive changed to gamma = v\x and i still have the same incorrect answer unfortunately.

[John D'Errico]

There are lots of reasons why I would avoid this code like the plague. Yes, you found this code online. NOT everything you find online is true, good, or safe for you. Certainly, not every piece of code you find is well written code. This is a case where the code was written by someone who actually knew little about numerical methods or good coding practices in MATLAB.

Several things catch my eye immediately. First you mention the variable gamma. Oops! Bad idea there, to define a variable named gamma. Why? Because gamma is the name of a useful function. One day, if you are using this script, you will find that you then wanted to use the function gamma. That will cause a conflict, and you will then ask a question online like why does my code fail?

Next is the use of inv. Inv (det is another bad thing to use) is one of those tools that really should almost never be used. There are better choices almost always. But students learn the idea of matrix inverses, and think they are fine to use, again, like det. But there are a lot of things you find in books that are not always the best way to write code.

For example, if you have a problem like A*x=b. In a book, you'll probably see the solution written as essentially

x = A^-1 * b

or as

x = inv(A)*b

or there may be some complex formula where an inverse was used, simply because that is the simple way to write the formula. Most of the time though, you will be better off if you use alternatives like

x = A\b

when you actually write the code in MATLAB.

Finally, another clue about seeing code written by a relative novice is when you see code laden with inputs as a way to bring in information. LEARN TO USE FUNCTIONS INSTEAD! Your capabilities in MATLAB will grow by leaps and bounds once you start to learn what a function is and how to use them effectively.

[M]

Yes Im sure I will understand how to code better as I take more engineering classes, but I haven't even taken a basic programming class yet either, coincidently, so Im sure the inefficiency shows haha. This did help clarify what I should be doing next though, thank you.

Answer 1

[Stephen23]

The problem is very simple: x has character class, it is not a numeric as you think it is.

inputdlg outputs a cell array of strings, which you then join into a character array using [x1,x2] = answer{:};. So the answers you are getting, e.g.

>> eye(2)*x
ans =
   49
   48

are completely correct: multiply the character code by the identity matrix, and this returns the character codes for '1' and '0' (49 and 48 respectively).

I suggest that you change the last two lines of code to this:

>> x = [str2double(x1);str2double(x2)];
>> gam = v\x;
gam =
   0.70711
   0.70711

Addendum

Note that it is actually very easy to tell the difference between a character digit and a numeric value, based on their column justification (char are left aligned):

>> '1' % character
ans =
1
>> 1 % numeric
ans =
     1

[M]

Thank you very much! With my inexperience at the moment, it would have taken forever for me to even think of that as a possibility.