Importing Results from Symbolic Toolbox to Matlab

2 vues (au cours des 30 derniers jours)
Tim Lewis
Tim Lewis le 2 Oct 2012
I recently updated my installation of Matlab from 2010a to 2012a. I have a fairly large program that I developed to calculate/plot the results of the research I am doing in tire modeling. Due to the precision needed to calculate the results, I have to do the majority of calculations in the Symbolic Toolbox and import the results to Matlab. When I run the program from MuPad, I get the following results:
thetaS = 0.2009477451
thetaL = 0.1745329252
lambda = 0.001609149705
delta = 0.004816291818
L = 0.1149593055
F = 820.2820398
However, when I run the same program with the same inputs from Matlab 2012a and import the results, I get the following results:
thetaS = 0
thetaL = 0.17453
lambda = 0.001381587043
delta = -0.00217123178
L = 0.1149747052
F = 172.866371
When I run the exact same program with the exact same input in Matlab 2010a, I get the same results that MuPad gives.
The value of the last four results above are calculated by solving a linear system of equations with input values of thetaL and thetaS. The value of thetaS is found by solving that system of equations with various values of thetaS until certain requirements are met. One of those requirements is that thetaS be between thetaL and some value greater than thetaL. Therefore, it seems as though Matlab 2012a is somehow setting thetaS equal to zero and solving the system of equations, disregarding the fact that the requirements are not being met. This seems quite illogical to me.
My question is what changed between release 2010a and 2012a that could be causing this? I have looked through the release notes published online and could not find anything that looked like it might have caused it. Is there other changes listed somewhere that might give me a clue to what happened? I am currently upgrading to 2012b to see if the problem has been fixed in that release.
If there is any other information I can provide I will do my best to provide it. Just let me know.
Thanks in advance!
_________________________________________________________________
Edit: I have just observed the same behavior noted in Matlab 2012a in Matlab 2012b. That is to say, the same results are produced.
  2 commentaires
Star Strider
Star Strider le 2 Oct 2012
You didn't post your code, so I'm wildly guessing that perhaps assume and its relatives could help.
Tim Lewis
Tim Lewis le 4 Oct 2012
Modifié(e) : Tim Lewis le 4 Oct 2012
Sorry I did not reply sooner.
I am not using assume or any of its relatives in my code.
I cannot post my entire code, since it is nearly 4,000 lines long and is the primary result of the last 2 years of research I have been doing.
In Matlab, I use the following code to run my MuPad program in the Symbolic Toolbox:
feval(symengine,'reset');
feval(symengine,'read','"TireProgram.mu"');
Results=feval(symengine,'float',evalin(symengine, ...
['TireProgram(',Inputs,')']));
where Inputs is a string containing user-selected numerical inputs to the mathematical model.
In my MuPad program, I have the following code to produce a table containing the output:
Results[thetaSout]:=thetaS:
Results[thetaLout]:=thetaL:
Results[Fout]:=F:
Results[Lout]:=L:
Results[deltaout]:=delta:
Results[lambdaout]:=lambda:
These results are then being imported into Matlab using the following code:
theta_S=double(evalin(symengine,[char(Results),'[thetaSout]']));
theta_L=double(evalin(symengine,[char(Results),'[thetaLout]']));
F=double(evalin(symengine,[char(Results),'[Fout]']));
L=double(evalin(symengine,[char(Results),'[Lout]']));
delta=double(evalin(symengine,[char(Results),'[deltaout]']));
lambda=double(evalin(symengine,[char(Results),'[lambdaout]']));
I believe the problem is somewhere in my MuPad code where the results are being calculated, but I am unsure of where.
I already know that using i as a variable instead of an imaginary number in MuPad code causes problems when the code runs from Matlab (though it runs fine when run from a MuPad notebook). I expect that there is something like this that is causing the problem.
I was hoping that someone on here might know of a change that occurred between release 2010a and 2012a that could have caused this behavior. If I can help by posting the code for how I accomplish something, I would be happy to. Just let me know what you want to see.
Thanks for your help!

Connectez-vous pour commenter.

Réponse acceptée

Tim Lewis
Tim Lewis le 12 Oct 2012
I just found the answer to my question. I had a line of code that said the following:
if thetaL~=0 then
thetaS=0:
else
% Calculate what thetaS should be
end_if:
In MuPad, the ~= operator means "approximately equal to," which is true when the difference between the two values is less than the environment variable DIGITS. However, in Matlab, the ~= operator obviously means "not equal to." Therefore, when my program was run in the MuPad environment, ~= was interpreted as the _approx function and resulted in what I expected. At some point between Matlab 2010a and Matlab 2012a, the Matlab editor becaome the default editor for MuPad program files. I believe this resulted in Matlab interpreting ~= as "not equal to" instead of "approximately equal to" as it had before. As I have already mentioned, Matlab was already interpreting i as the imaginary number, so I don't know why I wasn't having this problem before.
In any case, the solution to my problem was to use the _approx function directly instead of the ~= operator.
It seems like if MuPad is going to become more and more integrated into Matlab, the syntax of MuPad should be made as similar to Matlab's syntax as possible.

Plus de réponses (1)

Tim Lewis
Tim Lewis le 7 Oct 2012
Is there anyone out there that has any idea why this is happening? Any help you can provide would be greatly appreciated!
Thanks!

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!

Translated by