Yeap! SOLVE is not the way... by itself Message #11 Posted by Vieira, Luiz C. (Brazil) on 28 Aug 2004, 12:48 a.m., in response to message #6 by Tom White
Hi Tom, Richard, all;
First of all, thank you, guys. And let me admit that SOLVE is actually not the way to solve the case. But let me get acquainted with the HP27S way to deal with coordinate conversion; would you follow me and let me know where my reasonings and the actual HP27S conversion split?
The following lines contain my reasoning over the subject itself. This is a first-shot reasoning, and I am sure others will give other analysis. I'd like to read others and enhance my own reasoning, so, please, go ahead with yours.
There are many ways to relate Xcoord (X for shortening), Ycoord (Y for shortening), angle (Ø for shortening) and R. I think that one of them might be:
X/(RcosØ) = Y/(RsenØ) = 1
mostly because each side of the equation equals to 1. Anyone dealing with polar and rectangular coordinates knows that knowing any two variables allows the other two to be calculated. That was my main reason of suggesting the use of SOLVE. The problem is that for each unknown variable, three possible relations exist, given that any two of the other three variables are know. As a single example (for those who are following but did not get my point because of any reason), to calculate Ø we may have one of the following three possibilities:
Ø = cos-1(X/R) or
Ø = sen-1(Y/R) or
Ø = tan-1(Y/X).
The chosen one depends on which are the other two known variables. As a consequence, after finding Ø, the fourth unknown can also be calculated.
At first I thought about four menu labels and detecting number input by testing flag 22 in each of them. After each input data, pressing a key would cause the input data to be stored and the other two unknowns are computed (which ones is also a crytical issue, but using flags would be not too hard). If no data is entered, pressing the key shows the corresponding variable's current value. Of course, after the first single one there is no way to compute the other three, but the program would start with a standard (X,Y) = (1,1), leading to (R|_Ø) = (sqrt(2),45º). After that, keying in any new vlue would lead to compute others with existing values. To solve this, four routines (LBL 01, 02, 03 and 04) associated with KEY nn XEQ nn and MENU would give us a program with some generous byte count. I thought that SOLV would do that better, but I confess I did not find a practical way to implement my idea. IF to compute R or Ø it's expected to have X and Y and conversely, two PGMSLV "name" and SOLVE "var" are enough, but I think that the HP27S conversion application goes beyond this unjustified limitations, right?
Thoughts? Comments? Suggestions? CORRECTIONS? (this is too much more important!) All welcome, please!
My 1¢.
Luiz (Brazil)
Edited: 28 Aug 2004, 2:07 a.m.
|