I am trying to compute the roots of a 3rd order polynomial utilizing the Modelica.Math.Vectors.Utilities.roots function.
The polynomial 0 = -pi/3h^3+pir*h^2-V translates into the coefficient vector p={-Modelica.Constants.pi/3,Modelica.Constants.pi*r,0,-V} with r=0.5 and V=0.251327.
Wolfram alpha returns the following three roots: -0.35928; 0.486663; 1.37262
When computing the roots in Modelica with the given function, I get the following result: -1.37262; -0.486663; 0.35928
So the absolute values of the results are equal but the signs in Modelica are not correct.
Maybe I am missing something, but I can't figure out what the problem is.
That seems like an issue with a specific outdated version of MSL (Modelica Standard Library) or possibly some unspecified tool.
In Dymola 2018 FD01 I get the same roots as in Wolfram; using MSL 3.2.2 (but in reverse order).
In Dymola 2022 the function is called Modelica.Math.Polynomials.roots (due to MSL 4.0.0) but also give the same result.
I would report it to the tool; or update.
Related
I am trying to understand the process of solving DAEs in Dymola. According to Chapter 13.8 of Dymola's help document, Dymola would first use an index reduction algorithm to transform the original DAE into ODE, then get a BLT form after partitioning and tearing, so Dymola could solve ODE with BDF method like DASSL.
Here is the screenshot of Dymola's help document.
I also found some material about how to solve DAE from Wolfram mathematica, as shown in the following screenshot, there could be different strategies in different phases, I marked the method I think adopted in Dymola. My question is:
Does Dymola just adopt the method as I marked?
Or Dymola also adopt the method as Wolfram Mathematica, which is using different methods in different phases? If so, how does Dymola determine using which method?
Dymola does something resembling that red line, and ignoring many of the choices in that flow-chart as they are not relevant and there many equally important choices hidden.
E.g.,
The index reduction algorithm will work even if the index is 1 or 0 - it will just not do anything.
The dummy derivatives method can be seen as a projection method. (I did my master's thesis on implementing it a long time ago.)
IDAS is one of the solvers in the sundials suite. Dymola can use sundials solvers for integration, as well as a number of other solvers; and both have the model as ODE or as index 1 DAE for suitable solvers - but that's handled in the generated C-code, and doesn't influence other parts.
If I build a model in Dymola, but in translation, there is a warning about incompatible units of equations, but just according to the warning message, I can't find which components that the wrong equations belong to. So how could I find it in Dymola?
I agree that Dymola should include more information about equations in unit-checking.
However, we can see that:
It doesn't seem to be in a function, as it is an equation for a derivative.
It doesn't seem to be in heatExchangerFixedTemperature as all variables do not start with that prefix (unless T_amb is a package constant). It would thus seem that the equation is directly in the current model, or in one of its base-classes.
I am studying Stochastic calculus, and occasionally we need to compute an integral (from -infinity to +infinity) for some complex distribution. In this case, it was
with the answer on the right. This is the code I put into Matlab (and I have the symbolic math toolbox), which Matlab simply cannot process:
>> syms x t
>> f = exp(1+2*x)*(1/((2*pi*t)^0.5))*exp(-(x^2)/(2*t))
>> int(f,-inf,inf)
ans =
-((2^(1/2)*pi^(1/2)*exp(2*t + 1)*limit(erf((2^(1/2)*((x*1i)/t - 2i))/(2*(-1/t)^(1/2))), x, -Inf)*1i)/(2*(-1/t)^(1/2)) - (2^(1/2)*pi^(1/2)*exp(2*t + 1)*limit(erf((2^(1/2)*((x*1i)/t - 2i))/(2*(-1/t)^(1/2))), x, Inf)*1i)/(2*(-1/t)^(1/2)))/(2*pi*t)^(1/2)
This answer at the end looks like nonsense, while Wolfram (via their free tool), gives me the answer that the picture above has. Am I missing something fundamental about doing such integrations in Matlab that the basic Mathworks pages don't cover? Where am I proceeding incorrectly?
In order to explain what is happening, we need some theory:
Symbolic systems such as Matlab or Mathematica calculate integrals symbolically by the Risch algorithm (yes, there is a method to mechanically calculate integrals, just like derivatives).
However, the Risch algorithms works differently than using derivation rules. Strictly spoken, it is not an algorithm but a semi-algorithm. This is, it is not deterministic one (as algorithms are).
This (semi) algorithm makes a series of transformations on the input expression (the one to be integrated), and in a specific point, it requires to ask if the transformed expression is equals to zero, because if it were zero, it cannot continue (the input is not integrable using a finite set of terms).
The problem (and the reason of the "semi-algoritmicity") is that, the (apparently simple) equation:
E = 0
Is indecidable (it is also called the constant problem). It means that there cannot exist a formal method to solve the constant problem, for any expression E. Of course, we know to solve the constant problem for specific forms of the expression E (i.e. polynomials), but it is impossible to solve the problem for the general case.
It also means that the Risch algorithm cannot be perfect (being able to solve any integral -integrable in finite terms-). In other words, the Risch algorithm will be as powerful as our ability to solve the constant problem for as many forms of the expression E as we can, but losing any hope of solving for the general case.
Different symbolic systems have similar, but different methods to try to solve equations (and therefore the constant problem), it explains why some of them can "solve" different sets of integrals than others.
And generalizing, because no symbolic system will never be able to solve the constant problem for the general case, it will neither be able to solve any integral (integrable in finite terms).
The second parameter of int() needs to be the variable you're integrating over (which looks like t in this case):
syms x t
f = exp(1+2*x)*(1/((2*pi*t)^0.5))*exp(-(x^2)/(2*t))
int(f,'t',-inf,inf) % <- integrate over t
Recently I have encountered the following paradox (in my mind at least).
I tried to evaluate the rank of a symbolic matrix in Matlab (not really sure if rank() works as intended in the symbolic case, but anyway), but in order to simplify the coefficients resulting from the calculations, I used vpa() in the matrix.
What I noticed is that, after using vpa command, the matrix suddenly became a full rank matrix.
Has anyone had any previous experience with something similar to what I described? Which one should I trust?
I am trying to compute the accuracy of the HMAX model. First, I used a simple nearest Neighbor Classifier, secondly the Support Vector Machine (SVM) classifier.
In my laptop, I have the 7.6.0(R2008a) MATLAB version, and I obtained great values of accuracy by using either the nearest neighbor or svm classifer. When I moved to work on my friend's laptop in which the R2013b matlab version is installed instead of 7.6.0(R2008a), I always got the same error by using the svm classifer.
Error in mexSVMTrain (line 1)
function [AlphaY, SVs, Bias, Parameters, nSV, nLabel] = mexSVMTrain(Samples, Labels, Parameters, Weight, Verbose)
Output argument "AlphaY" (and maybe others) not assigned during call to
"C:\Users\xxxx\Documents\MATLAB\aub matlab\osu-svm\mexSVMTrain.m>mexSVMTrain".
Please I need your help in order to resolve this problem. Any help will be very appreciated.
It's not a solution to your problem. Seems like the existed mexSVMTrain.dll in the old version Matlab needs to be recompiled to work in the new released version, but it is unclear how it is recompiled without any C source code for mexSVMTrain from OSU_SVM.
I would suggest you use libsvm for the SVM part instead.