HP Forum Archive 20

[ Return to Index | Top of Index ]

Angular modes (another poll) Message #1 Posted by Walter B on 17 Apr 2011, 12:33 p.m. Hi all, So far, we have the traditional three DEG, RAD, GRAD implemented in the WP 34S. All trigonometric functions will sense the mode set and operate within the respective mode. There are also five conversion commands as follow: Assumed input Operation Output -------------------------------+-----------+------------------------------ decimal value in degrees D>R radians, ang. mode as before decimal value in radians R>D degrees, ang. mode as before decimal value in any ang. mode >DEG degrees, ang. mode set to DEG decimal value in any ang. mode >GRAD grads, ang. mode set to GRAD decimal value in any ang. mode >RAD radians, ang. mode set to RAD That said, is there anything missing? Or any suggestions for a better set of operations? Walter

Re: Angular modes (another poll) Message #2 Posted by Marcus von Cube, Germany on 17 Apr 2011, 1:12 p.m., in response to message #1 by Walter B I wasn't aware of the different sets of operations with and without change of mode. This makes obsolete my former idea of a user flag which decides whether with the conversion the mode shall be updated. I prefer the set of operations as pictured above. In fact, we have 4 possible modes (not completely implemented): RAD, GRAD, DEG and HMS. HMS only exists as a display option. We should investigate the possibility of tagging register content with the associated mode, at least concerning HMS or decimal. OK, I know that Pauli believes we cannot find the necessary bits for this. But I already have an idea. :)

Re: Angular modes (another poll) Message #3 Posted by Paul Dale on 17 Apr 2011, 5:50 p.m., in response to message #2 by Marcus von Cube, Germany Quote: We should investigate the possibility of tagging register content with the associated mode, at least concerning HMS or decimal. OK, I know that Pauli believes we cannot find the necessary bits for this. But I already have an idea. :) Far more important than tagging a value as being H.MS is tagging it as being an integer or alpha data. So after you've found two bits for each of our 112 registers then go looking for space for a H.MS tag :-) Actually, I know how to get some tag bits for reals. Reduce the accuracy of reals to 12 digits plus exponent and use the saved space to tag values. We could then mark angular mode (all four not just one), fraction, whatever. - Pauli

Re: Angular modes (another poll) Message #4 Posted by Marcus von Cube, Germany on 18 Apr 2011, 1:55 a.m., in response to message #3 by Paul Dale I was thinking of a single decimal digit for the purpose. For H.MS we could even stick to subnormal numbers.

Re: Angular modes (another poll) Message #5 Posted by Dieter on 18 Apr 2011, 1:45 p.m., in response to message #4 by Marcus von Cube, Germany One single digit should do - that's four bits, as far as I can see, so 16 different tags are possible. This could mean that there are some additional options - for instance calendar dates. They could be handled as integers, representing their Julian day number, this way allowing simple addition and subtraction instead of special commands. In a similar way, values tagged as h°m's" could be handled without special commands as well. Okay, all this needs some coding... ;-) In a way it's similar to the Excel approach: every value is stored in a number that can stand for a real number, a date, a percentage, whatever. If all this can be done with one single digit less I think the advantages outweigh the minimal loss of precision. 15 digits (or 12 displayed plus three "guard digits") are fine for me. BTW - in earlier HP machines like the HP-41 these tags were simply coded in four mantissa sign bits. I assume this is not an option here? Dieter

Re: Angular modes (another poll) Message #6 Posted by Marcus von Cube, Germany on 18 Apr 2011, 3:10 p.m., in response to message #5 by Dieter The decimal64 is described in detail in Wikipedia. It's not as easy as it seems. 3 digits are packed in ten bits. You cannot simply take a digit and hope it's four bits worth. In fact, 10 different tags would be possible this way. I had anther idea: If we can live without subnormal numbers (numbers which start with one or more zero digits) we could use a limited range of numbers with tags without losing precision on normal reals. Edited: 18 Apr 2011, 3:11 p.m.

Re: Angular modes (another poll) Message #7 Posted by Paul Dale on 18 Apr 2011, 8:58 p.m., in response to message #5 by Dieter This won't work as is. Integers are separate and use all 64 bits available. Likewise, alpha data probably needs a separate bit -- a 64 bit integer holds 64 bits worth of alpha data. I think we're better defining our own numeric format (which is what this suggestion is doing anyway) and using that. I'm not sure how we'll go on the code size front. Tagging values will require extra code. And the first digit in a decimal64 only has 10 states we could use but it would be possible to use I guess. Things are BCD and tightly packed. - Pauli

Re: Angular modes (another poll) Message #8 Posted by Dieter on 17 Apr 2011, 1:39 p.m., in response to message #1 by Walter B First I would suggest a complete set of conversions without any change of the current angular mode. Second, I like the idea of conversions with a simultaneous switch to the target angular mode as well. In other words: command command angular mode name description after execution --------------------------------------------------- D->R degrees to radians unchanged R->D radians to degrees unchanged D->G degrees to grads unchanged G->D grads to degrees unchanged R->G radians to grads unchanged G->R grads to radians unchanged ->R current to radians Radians ->D current to degrees Degrees ->G current to grads Grads By the way: for programming purposes I always liked the idea to get certain key values (like a full or half or quarter circle) in the current angular mode. This usually is done with an inverse trig function: for instance, arccos(-1) returns 180 degrees or Pi or 200 grads. I wonder if this can be done more elegantly with the 34s command set. Dieter

Re: Angular modes (another poll) Message #9 Posted by Paul Dale on 17 Apr 2011, 5:45 p.m., in response to message #8 by Dieter Dieter missed three options: R-> radians to current unchanged D-> degrees to current unchanged G-> grads to current unchanged Making the full suite: command command angular mode name description after execution --------------------------------------------------- D->R degrees to radians unchanged R->D radians to degrees unchanged D->G degrees to grads unchanged G->D grads to degrees unchanged R->G radians to grads unchanged G->R grads to radians unchanged ->R current to radians Radians ->D current to degrees Degrees ->G current to grads Grads R-> radians to current unchanged D-> degrees to current unchanged G-> grads to current unchanged Ask what people want and they come back everything and then some :-) - Pauli

Re: Angular modes (another poll) Message #10 Posted by Dieter on 18 Apr 2011, 1:06 p.m., in response to message #9 by Paul Dale Quote: Dieter missed three options: R-> radians to current unchanged D-> degrees to current unchanged G-> grads to current unchanged Well, I was not sure if these three make sense. But now I see these three additions will solve exactly the problem I mentioned in my last sentence: Pi R-> returns the equivalent of a half circle 180 D-> dto. 90 D-> returns the equivalent of a right angle 400 G-> returns the equivalent of a full circle   ...in units of the current angular mode. Great! I like it! :-) Dieter Edited: 18 Apr 2011, 1:07 p.m.

Re: Angular modes (another poll) Message #11 Posted by Gerson W. Barbosa on 17 Apr 2011, 2:33 p.m., in response to message #1 by Walter B However the most useful conversions (that is, keeping the current mode) one would like to do from the keyboard , D>R and R>D, require at least five keystrokes each: D->R: h X.FCN -> ^ ENTER R->D: h X.FCN 6 ^ ENTER Why not define shortcuts for them? D->R: -> 5 R->D: -> D Furthermore, since simultaneous conversions and changes of mode is not a concern to you, why not save two positions by using cyclic angle mode switching as Pauli has suggested? The blue GRAD under Rv could be replaced with DRG so our table now would be: Assumed input Operation Output Shortcut -------------------------------+-----------+------------------------------+------------------ decimal value in any ang. mode D>R radians, ang. mode as before -> 5 decimal value in any ang. mode R>D degrees, ang. mode as before -> D decimal value in any ang. mode DRG unchanged, angle mode annunciators changed cyclically from ...360 to RAD to G... . \ . | decimal value in degrees >DRG radians, ang. mode set to RAD -> Rv | >DRG grads, ang. mode set to GRAD -> Rv | cyclically >DRG degree, ang. mode set to DEG -> Rv | . | . / Of course DRG and ->DRG could not be programmable commands. The drawback would be another poll for choosing the functions that should occupy the free positions. Regards, Gerson.

Re: Angular modes (another poll) Message #12 Posted by Paul Dale on 17 Apr 2011, 5:46 p.m., in response to message #11 by Gerson W. Barbosa Quote: Furthermore, since simultaneous conversions and changes of mode is not a concern to you, why not save two positions by using cyclic angle mode switching as Pauli has suggested? The blue GRAD under Rv could be replaced with DRG so our table now would be: A single mode switch command is badness. It doesn't save any commands for programming purposes. - Pauli

Re: Angular modes (another poll) Message #13 Posted by Gerson W. Barbosa on 17 Apr 2011, 7:09 p.m., in response to message #12 by Paul Dale I meant saving positions on the keyboard for the functions that are now missing due to the A label and Sigma+ latest changes. Anyway, I'd be pleased with the shortcuts for D>R and R>D only, if possible. Gerson.

Re: Angular modes (another poll) Message #14 Posted by Paul Dale on 17 Apr 2011, 7:20 p.m., in response to message #13 by Gerson W. Barbosa The only commands we lost putting in the A button were %+ and %- and nobody seemed to want either of those. As for the short cuts, Walter is usually the final authority on keyboard design. - Pauli

Re: Angular modes (another poll) Message #15 Posted by Eddie W. Shore on 17 Apr 2011, 3:08 p.m., in response to message #1 by Walter B That looks good - however conversions to gradients would be cool. >DEG >RAD >GRAD or D-G, R-G, G-D, G-R

Re: Angular modes (another poll) Message #16 Posted by Walter B on 17 Apr 2011, 3:17 p.m., in response to message #15 by Eddie W. Shore Hi Eddie, Quote: conversions to gradients would be cool. a "gradient" is something different d:-)

Re: Angular modes (another poll) Message #17 Posted by David Hayden on 17 Apr 2011, 5:52 p.m., in response to message #1 by Walter B You're missing another set of conversions: going *to* the current angle mode: DEG> Degrees to current angle mode RAD> Radians to current angle mode GRAD> Grads to current angle mode. Rather than doing a full set of conversions, I'd consider converting to/from radians only. So a conversion from degrees to grads would be done in two steps (D>R, R->G). This would cut down on the number of commands needed and might make it more feasible to add HMS a fully supported mode. HMS would be useful for navigation and surveying, which seem to be applications that these machines are commonly used for. Dave

Re: Angular modes (another poll) Message #18 Posted by Paul Dale on 17 Apr 2011, 6:06 p.m., in response to message #17 by David Hayden Quote: Rather than doing a full set of conversions, I'd consider converting to/from radians only. So a conversion from degrees to grads would be done in two steps (D>R, R->G). This would cut down on the number of commands needed and might make it more feasible to add HMS a fully supported mode. HMS would be useful for navigation and surveying, which seem to be applications that these machines are commonly used for. One small problem here, conversion to and from radians implies a rounding step and an accuracy loss. I can convert degrees directly to gradians exactly e.g. Does it matter in real life? Probably not. - Pauli

Re: Angular modes (another poll) Message #19 Posted by Marcus von Cube, Germany on 18 Apr 2011, 2:01 a.m., in response to message #18 by Paul Dale Just a thought: Why not have an "exact radians" mode where the numbers are multiples of PI? In this mode, 1.5 SIN would return -1.

Re: Angular modes (another poll) Message #20 Posted by Paul Dale on 18 Apr 2011, 5:57 a.m., in response to message #1 by Walter B Since they seem to be wanted, I've added commands for D->G, R->G, G->D and G->R. To reiterate the big open question, does anyone really want ->DEG, ->RAD and ->GRAD to change the trig mode or just convert the number? Those who've commented about this above don't need to comment again. - Pauli

Re: Angular modes (another poll) Message #21 Posted by Walter B on 18 Apr 2011, 1:47 p.m., in response to message #20 by Paul Dale Quote: Since they seem to be wanted, I've added commands for D->G, R->G, G->D and G->R. We're going to have a flooding if we continue this way: remember we've included R>D and D>R for backward compatibility only. So I vote for keeping these two with their traditional names in X.FCN or P.FCN for exactly that reason, and for putting all 6 conversions possible between DEG, RAD and GRAD into CONV, operating without a mode change. Additionally, we have 3 conversions "current" to DEG/RAD/GRAD. We get them for free as long as we keep DEG, RAD, and GRAD on the keyboard. And there was the desire introducing DEG/RAD/GRAD to "current", FWIW. Quote: To reiterate the big open question, does anyone really want ->DEG, ->RAD and ->GRAD to change the trig mode or just convert the number? Those who've commented about this above don't need to comment again. To change or not to change (modes in these conversions), that's the question. Walter

Re: Angular modes (another poll) Message #22 Posted by David Hayden on 18 Apr 2011, 2:32 p.m., in response to message #20 by Paul Dale Quote: To reiterate the big open question, does anyone really want ->DEG, ->RAD and ->GRAD to change the trig mode or just convert the number? I would just convert the number, without changing the trig mode. In general I've found that commands that do too much usually hurt more than they help. It's easy to forget about the side effect (where the "side effect" is "the thing that the command does in addition to the thing that I want it to do") and this can easily lead to programming bugs. Also, if a command is going to change the way future commands work, I think it needs to be very explicit. There's my 2 cents worth. :) Dave

Re: Angular modes (another poll) Message #23 Posted by Jeff O. on 18 Apr 2011, 8:04 p.m., in response to message #22 by David Hayden I will vote with David, so we are up to 4 cents. Jeff

Re: Angular modes (another poll) Message #24 Posted by htom trites jr on 19 Apr 2011, 3:00 p.m., in response to message #23 by Jeff O. I'd like degrees minutes seconds.fractionalseconds too, please. Abbreviation DMS. Navigation and old-fashioned surveying. Four modes, five if we allow real*PI, which would be handy sometimes. There are going to be few exact conversions from one to another, other than some special values.

[ Return to Index | Top of Index ]

Go back to the main exhibit hall