>Complete vectorial setup for Given-Find<<br> ________________________
Not yet for both responders. The visiting collab does not have a usable project in hand. No export = no project done, ASAT [As Simple As That] !
jmG
Not yet for both responders. The visiting collab does not have a usable project in hand. No export = no project done, ASAT [As Simple As That] !
jmG
On 11/4/2009 9:47:57 PM, Tom_Gutman wrote:
>You have avoided the hole by accepting solutions that are not really solutions.
That happing every mornings. Try to tell to polyroots that 2.002 are not a really solution:
Symbolic calculus it's allways superior to numerical, but not applicable to all situations. And human resources are part of situations.
>Dividing through by d61 does not result in a real solution, it only allows find to consider a non-solution as a solution.
If makers of polyroots code can cosiderer bad solutions as procedures answers, I can too.
>The condition involving θ is such that at θ=180� the d61 segment must be precisely vertical (its total length equals Δz). But the remaining constraints do not allow it to be precisely vertical. Hence no solution for that θ.
Yes, that the reason for the punctual hole, but we have a range one. So, question is how to drive the size of the range (because allways go to be a range).
>If you are willing to accept non-solutions to avoid failures to find, you can get "solutions" for all values of θ by simply changing find to minerr. That is effectively what you have done with respect to that one constraint.
An very usual technique, if find not work, try with minerr, maybe there are some kind of answer.
>BTW, the hole is not just a point (as I had earlier supposed) but does cover a range. It errors when within about 1% of π. Changing CTOL may change the size of the hole.
Actually, I'm not only divide by d61. Also take square root over the squares sum, eliminate the square in d_hk, and change it's sign. This for have a better control over the calculus, estimating in the same scale as x,y,z the answers given by check() or sys() functions.
To have full control over each equation, one can equate the eqn to zero, and choose a factor. This factor could be function of TOL and CTOL. In a system which it is very sensible to one of they equations, like this, it isn't a bad idea, and do this for only this sensible equation.
Regards. Alvaro.
>You have avoided the hole by accepting solutions that are not really solutions.
That happing every mornings. Try to tell to polyroots that 2.002 are not a really solution:
Symbolic calculus it's allways superior to numerical, but not applicable to all situations. And human resources are part of situations.
>Dividing through by d61 does not result in a real solution, it only allows find to consider a non-solution as a solution.
If makers of polyroots code can cosiderer bad solutions as procedures answers, I can too.
>The condition involving θ is such that at θ=180� the d61 segment must be precisely vertical (its total length equals Δz). But the remaining constraints do not allow it to be precisely vertical. Hence no solution for that θ.
Yes, that the reason for the punctual hole, but we have a range one. So, question is how to drive the size of the range (because allways go to be a range).
>If you are willing to accept non-solutions to avoid failures to find, you can get "solutions" for all values of θ by simply changing find to minerr. That is effectively what you have done with respect to that one constraint.
An very usual technique, if find not work, try with minerr, maybe there are some kind of answer.
>BTW, the hole is not just a point (as I had earlier supposed) but does cover a range. It errors when within about 1% of π. Changing CTOL may change the size of the hole.
Actually, I'm not only divide by d61. Also take square root over the squares sum, eliminate the square in d_hk, and change it's sign. This for have a better control over the calculus, estimating in the same scale as x,y,z the answers given by check() or sys() functions.
To have full control over each equation, one can equate the eqn to zero, and choose a factor. This factor could be function of TOL and CTOL. In a system which it is very sensible to one of they equations, like this, it isn't a bad idea, and do this for only this sensible equation.
Regards. Alvaro.
>to this other. Teaching teach me that errors occurs any_where_any_time ... But the discussed file have not "errors". Was posted with the following text<<br> _______________________
Never mind the text, that's not what you put in a thesis or remit to the client o to a machine shop ... a red result and no explanation of the red.
Nobody said your work sheet had errors, only that it does not produce an export. Red result is not necessarily an error, it just tells you are not doing correct for the end purpose. You don't seem to understand what an export is as well as Tom Gutman. Can you give a table of the solution to the client if red, I bet no. In Tom Gutman work sheet, I have an export within the limit of the solver, which I haven't pushed further. You are mentioning root, root of what in a multiple solver. Given/Find does not seeds ... so, end of the story. TOL/CTOL of what ? try to squeeze the initials, but that is " un travail de moine" because there is no algebraic immediate inspection.
That would be a great feature you could suggest PTC, i.e: imagine/invent a way to seed Given/Find, inspired of the seeded root scanner that solves the function declared not solvable by Mathematica.
jmG
Never mind the text, that's not what you put in a thesis or remit to the client o to a machine shop ... a red result and no explanation of the red.
Nobody said your work sheet had errors, only that it does not produce an export. Red result is not necessarily an error, it just tells you are not doing correct for the end purpose. You don't seem to understand what an export is as well as Tom Gutman. Can you give a table of the solution to the client if red, I bet no. In Tom Gutman work sheet, I have an export within the limit of the solver, which I haven't pushed further. You are mentioning root, root of what in a multiple solver. Given/Find does not seeds ... so, end of the story. TOL/CTOL of what ? try to squeeze the initials, but that is " un travail de moine" because there is no algebraic immediate inspection.
That would be a great feature you could suggest PTC, i.e: imagine/invent a way to seed Given/Find, inspired of the seeded root scanner that solves the function declared not solvable by Mathematica.
jmG
.gif){kind=link}
