rocky
commented
2 years ago I will only speak for myself, but this is too long and complex to figure out whether or not this is a bug or whether you are doing something wrong.
Right now there are dozens of known bugs and problems with the code base where I know are what needs to be done, but just haven't gotten around to it. And all of the current maintainers are doing this as volunteer work. (A few people have sponsored me to in a generic level - not specific to Mathics - but the combined amount per month is about what I make there is less than two hours of paid full-time work.)
So again, speaking personally, it doesn't make sense for me to spend time to try to figure out whether this is a bug or you are doing something wrong.
Of course, this is open-source and this is an open forum so maybe someone else has the time, patience, and interest at studying this.
However if you don't find help forthcoming, or would like to increase the chances of someone else looking at this and volunteering their time, my suggestion is for you to make the first stab at narrowing the problem...
Maybe the expressions can be simplified and shortened. Instead of defining 37 variables, just substitute those values into the Solve[] call. If after substituting you find that you can simplify the expression passed to Solve[] do it. And if there still is a problem then, great, you've narrowed things and this is simpler. If not, we have found a boundary between what works and what doesn't.
Once we have the boundary between what works and wat doesn't, or a simple and short example, the next step would be to understand whether this is a problem in Mathics' translation to Sympy, which is what handles the Solve, or whether the problem is in Sympy itself. Or maybe the answer is valid.
So try converting the simple expression into Sympy. (Or if you are so disposed , try converting the above into Sympy).
Good luck!
P.S. Development has moved over to https://github.com/Mathics3/mathics-core , So any bug fixes will appear there, not here. I understand though that it will take a while before folks get used to the move.
BugsDanny
Hi, I saw wrong values while calculating a flight dynamics problem. Here is the code:
A=7.17; e=0.9; Clw=0.71; Xcg=0.591; Xca=0.50075; N0=0.94141; at=4.15; aw=4.02; St=4.06; Sw=21.3; w=2200; Lt=6; cam=2.003; nt=0.9; Kyy=1.75; deda=0.355568; Cdf=0.048; dh=0.065; ce=1.05; ct=0.85; Vc=400/3.6; Se=4.06; me=42/2; xe=(0.65-.0.65-0.3); ke=0.7; ro=0.00162214.54/0.0283/9.81; CTiempo = w/(9.81roVcSw) Clalfa=aw Cd=Cdf+(ClwClw)/(PiAe) Cdalfa = 2ClwClalfa/(PiAe) Cmalfa = Clalfa(Xcg-N0) Xa =Xcg - Xca mu = (w/9.81)/(roSwcam) Vred=(Lt-Xa)St/(camSw) Cmdalfa=-atVrednt1/mu(Lt-Xa)deda/cam CmdTita = -1.1atVrednt(Lt-Xa)/(cammu)
This is the system:
DL={{Cd+lambda, (Cdalfa-Clw)/2, Clw/2},{Clw, Clalfa/2+lambda, -lambda},{0,Cmalfa+Cmdalfalambda,CmdTitalambda-2lambda^2Kyy^2/(cam^2*mu)}};
Here resolution:
DLec=-Det[DL]==0 Raices = Solve[DLec, lambda]
The eigenvalues representation
l4=lambda/.Raices[[1]] l3=lambda/.Raices[[2]] l2=lambda/.Raices[[3]] l1=lambda/.Raices[[4]]
and the result is:
-3.9646−7.097 I -3.9646−7.097 I -0.0312515−0.465597 I -0.0312515+0.465597 I
You know, I expected two pair of complex roots and as you see the first one is not real +/- imaginary. Is this a bug or am I doing something wrong?
Thank you in advance.