▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
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
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
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. :)
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
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
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
I was thinking of a single decimal digit for the purpose. For H.MS we could even stick to subnormal numbers.
▼
Posts: 653
Threads: 26
Joined: Aug 2010
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
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
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.
Posts: 3,229
Threads: 42
Joined: Jul 2006
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
Posts: 653
Threads: 26
Joined: Aug 2010
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
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
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
▼
Posts: 653
Threads: 26
Joined: Aug 2010
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.
Posts: 2,761
Threads: 100
Joined: Jul 2005
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.
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
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
▼
Posts: 2,761
Threads: 100
Joined: Jul 2005
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.
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
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
Posts: 764
Threads: 118
Joined: Aug 2007
That looks good - however conversions to gradients would be cool.
>DEG
>RAD
>GRAD
or D-G, R-G, G-D, G-R
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
Hi Eddie,
Quote:
conversions to gradients would be cool.
a "gradient" is something different d:-)
Posts: 528
Threads: 40
Joined: Dec 2008
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
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
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
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
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.
Posts: 3,229
Threads: 42
Joined: Jul 2006
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
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
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
Posts: 528
Threads: 40
Joined: Dec 2008
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
▼
Posts: 875
Threads: 37
Joined: Jul 2005
I will vote with David, so we are up to 4 cents.
Jeff
▼
Posts: 66
Threads: 2
Joined: Aug 2007
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.
|