Angular modes (another poll)



#25

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


#26

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. :)


#27

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


#28

I was thinking of a single decimal digit for the purpose. For H.MS we could even stick to subnormal numbers.


#29

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


#30

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.

#31

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

#32

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


#33

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


#34

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.

#35

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.


#36

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


#37

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.


#38

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

#39

That looks good - however conversions to gradients would be cool.

>DEG
>RAD
>GRAD

or D-G, R-G, G-D, G-R


#40

Hi Eddie,

Quote:
conversions to gradients would be cool.

a "gradient" is something different d:-)
#41

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


#42

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


#43

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.

#44

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


#45

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

#46

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


#47

I will vote with David, so we are up to 4 cents.

Jeff


#48

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.


Possibly Related Threads...
Thread Author Replies Views Last Post
  Back to School/Work/Other Calculator Poll Eddie W. Shore 63 11,542 09-12-2013, 06:03 AM
Last Post: bhtooefr
  Poll: SandMath and 41Z Overlays anyone? Ángel Martin 20 3,484 05-20-2013, 04:13 PM
Last Post: aurelio
  [43S]Top row poll (until Monday, 4.2.13, 13:13 UTC) Walter B 175 23,843 02-04-2013, 09:38 AM
Last Post: Andrés C. Rodríguez (Argentina)
  What are the most popular functions? (Poll until 18.12.) Walter B 62 8,392 12-18-2012, 08:18 AM
Last Post: Walter B
  Here is a poll again Walter B 80 10,407 12-03-2012, 03:59 AM
Last Post: Walter B
  Alternate poll Paul Dale 14 2,465 11-29-2012, 01:29 PM
Last Post: Eddie W. Shore
  Formulae or formulas, that's the question (poll) Walter B 56 9,742 06-16-2012, 11:16 AM
Last Post: William L. Drylie
  USB-41 82143A simulation update: MAN-TRACE modes Diego Diaz 0 777 06-09-2012, 08:46 PM
Last Post: Diego Diaz.
  [WP 34S] Backside label contents (>> poll <<) Walter B 11 2,324 05-18-2012, 10:01 PM
Last Post: Walter B
  [WP 34S] Complex calculations (poll) Walter B 41 6,546 04-08-2012, 01:44 AM
Last Post: Paul Dale

Forum Jump: