1AUG2019 SolveSys  Equation Library and Nonlinear Systems Solver

02152017, 12:16 AM
(This post was last modified: 02152017 07:20 PM by Han.)
Post: #19




RE: SolveSys  Equation Library and Multiple Equations Solver
(02142017 11:21 PM)akmon Wrote: Downloaded equation library. I have choosen an easy example: I am not quite sure what you mean by not being able to solve it. If you want it to solve for P and I while fixing the values of V and R, then you will need to tell the solver that the values of V and R are constant. To the far right of the variables are check boxes to set them to be constants (when checked) or variables (when unchecked). If you leave them as variables, then you are actually solving an underdetermined system (4 variables with only 2 equations  there are an infinite number of solutions). On the other hand, setting V and R to be constants gives me the solution P=5377.7778 and I=24.4444 (2 variables, 2 equations  if a solution exists, it will be unique). I used a guess of 100, 100. I changed my tolerances because the values supplied (220 and 9) suggest we only need to be within 5 or so decimal places for a reasonable answer (unlike the other problem where the solution itself was in the order of 10^10 or 10^11). Please keep in mind that the conclusion from the app is all based on your tolerances. It stops the iterations if the x_i's are within the tolerance you specify (it's actually not a tolerance, but a check on whether the digits up to a certain order have stopped changing). Then it checks to see if the output values are also within (another) tolerance, concluding a zero if yes. And if not it checks to see if perhaps a minimum (or extremum in general) may have been found. These last two are the only possible, valid conclusions since a "tiny" (or no) change in the x_i's suggests that the gradient is nearly 0 (which occurs at extrema). Here, "tiny" is relative to the tolerance you set. But again, these conclusions are based on your tolerances. So if you set them too large, then it may conclude incorrectly. Set them too small, and you may never see convergence in some situations (not enough precisions to meet the desired tolerance) despite the values actually converging. That said, I have been considering implementing a hybrid solver just as described by the HP patent. Since the Prime has access to a CAS, it should not be too hard to implement a secondary solver (or maybe this could be the primary solver) in which a formula having only one parameter that is unknown is used to determine the remaining parameter, repeating as much as necessary while cycling through the remaining formulas. EDIT: Ahh, ok. I downloaded the version listed in the first post, and am seeing the misbehavior. There's a single line in the function ssEvalF that was modified and somehow did not make it into this revision (this is what I get for not using a CVS and developing on multiple copies over multiple machines). In the meantime, change the line ssCAS(ssCurSys(4,j) + ":=" + vec(j)); to become ssCAS(ssCurSys(4,ssSolveVars(j)) + ":=" + vec(j)); within the function ssEvalF(vec) I found a few more bugs that I need to iron out in the pinv() routine (for degenerate cases like m x 1 or 1 x n matrices) but I should have an update up soon. EDIT 2: 0.652 should take care of this, now. SVD was also updated. Graph 3D  QPI  SolveSys 

« Next Oldest  Next Newest »

User(s) browsing this thread: 1 Guest(s)