WP-32S in 2016?

[emece67]

(01-10-2016 09:21 PM)rprosperi Wrote:  

(01-10-2016 02:02 PM)Dieter Wrote:  Of course you are right here.
But who says the conversions can't be done with a single key either?

Press [→] [D·R·G] and see →DEG in the display, press [D·R·G] once more and see →RAD, or a third time for →GRAD.
As usual, [XEQ] or [ENTER] executes the function.

Too cumbersome? Then avoid all kinds of menus. ;-)

Dieter

Very sensible and a good solution IMHO. I don't think needing [XEQ] or [ENTER] makes it cumbersome, as it is not frequently used, and this is consistent with other functions.

I also think it is acceptable.

[matthiaspaul]

(01-10-2016 09:21 PM)rprosperi Wrote:  

(01-10-2016 02:02 PM)Dieter Wrote:  Of course you are right here.
But who says the conversions can't be done with a single key either?

Press [→] [D·R·G] and see →DEG in the display, press [D·R·G] once more and see →RAD, or a third time for →GRAD.
As usual, [XEQ] or [ENTER] executes the function.

Too cumbersome? Then avoid all kinds of menus. ;-)

Very sensible and a good solution IMHO. I don't think needing [XEQ] or [ENTER] makes it cumbersome, as it is not frequently used, and this is consistent with other functions.

I'd like to see a TURN mode being implemented as well. TURN mode works exactly like DEG, RAD and GRAD (including having a full set of angle unit conversion functions like on the WP 34S), except for that a full circle doesn't equal 360 degree, 6.2831... rad or 400 gon, but 1 turn.
(I once implemented this in a software calculator long ago and found it to be really convenient in engineering/programming, where you often have to convert to/from other unit representations, anyway. But I think it can also be useful for educational purposes. I also started to implement this for the WP 34S, but haven't found the time to finish it.)

http://www.hpmuseum.org/forum/thread-449...l#pid40343

If only one key is available for the mode switch, sequences like [→][DRGT][DRGT][DRGT][DRGT][ENTER] might be too long to be useful, in particular when switching to TURN mode happens often. Therefore, I suggest to implement this in a ring (similar to the task switcher [ALT]+[TAB] under Windows), so that (with + indicating that the modifier must be pressed continuously)

[g]+[DRGT] would switch to the previously selected mode
[g]+[DRGT][DRGT] would switch to the pre-previously selected mode
[g]+[DRGT][DRGT][DRGT] would switch to the pre-pre-previously selected mode

[→]+[DRGT] would switch&convert to the previously selected mode
[→]+[DRGT][DRGT] would switch&convert to the pre-previously selected mode
[→]+[DRGT][DRGT][DRGT] would switch&convert to the pre-pre-previously selected mode

In most cases while working on a single problem, a user would frequently switch between two modes only, and perhaps three modes in total. This would reduce the mode switch to a [→]+[DRGT] semi-toggle and perhaps an occasional [→]+[DRGT][DRGT].

The same could be implemented using [ENTER] at the expense of an additional necessary keypress. Alternatively, it would be possible to implement:

[g][DRGT][ENTER] would switch to DEG mode
[g][DRGT][DRGT][ENTER] would switch to RAD mode
[g][DRGT][DRGT][DRGT][ENTER] would switch to GRAD mode
[g][DRGT][DRGT][DRGT][DRGT][ENTER] would switch to TURN mode

[→][DRGT][ENTER] would switch&convert to DEG mode
[→][DRGT][DRGT][ENTER] would switch&convert to RAD mode
[→][DRGT][DRGT][DRGT][ENTER] would switch&convert to GRAD mode
[→][DRGT][DRGT][DRGT][DRGT][ENTER] would switch&convert to TURN mode

(If [DRGT] would be an unshifted key, things could become easier, as we would no longer need [g] or [ENTER], as any key other than [DRGT] would exit the sequence.)

Greetings,

Matthias

[walter b]

While we're at it, it reminds me of an angular mode I wanted to see implemented in the 43S: multiples of π. We calculate them very precisely anyway, so this mode will come at no extra cost.

So we would have got six angular modes now: D.MS, DEG, RAD, GRAD, MOπ, and TURNS. If we'd need all of them, it would be a bit much for a single ring, though just about right for a menu. If we'd put the conversions in as well this would make [>] obsolete.

d:-)

[walter b]

(01-10-2016 04:39 PM)rprosperi Wrote:  

(01-10-2016 03:07 PM)emece67 Wrote:  Although the location of the XYZ letters may seem strange, I think it will not pose any problem in everyday use. I wonder if a top line XYZT and a bottom one UVWSpace may also be acceptable.

I agree that with experience, we can get used to this non-linear Alpha layout, though at first it seems awkward. I support emece67's clever suggestion of keeping the XYZT together as well, for stack manipulation functions.

Please remember the stack will be XYZTABCD.

d:-)

[Paul Dale]

(01-11-2016 07:34 AM)walter b Wrote:  So we would have got six angular modes now: D.MS, DEG, RAD, GRAD, MOπ, and TURNS. If we'd need all of them, it would be a bit much for a single ring, though just about right for a menu. If we'd put the conversions in as well this would make [>] obsolete.

There would be a lot of conversions (36) if all are allowed.

It might make more sense to have an n-divisions in a circle setting. That way DEG is 360 divisions, GRAD is 400, MOπ is 2 and TURNS is 1. This would support most of the modes Matthias mentioned in his link. RAD and D.MS require special handling -- RAD requires high precision modulo reduction which using 2π wouldn't achieve and D.MS requires special display.


- Pauli

[walter b]

It wasn't my intention to allow all 36 conversions. We may get along with only 6. E.g. >DEG would convert from current angular mode to degrees, >RAD to radians etc.

We may further allow for D.MS<->DEG and DEG<->RAD in both directions for sake of tradition, and maybe RAD<->MOπ and DEG<->MOπ, but that would do IMHO.

d:-)

[Dieter]

(01-11-2016 08:30 AM)walter b Wrote:  It wasn't my intention to allow all 36 conversions.
(...)
We may further allow for D.MS<->DEG and DEG<->RAD in both directions for sake of tradition, and maybe RAD<->MOπ and DEG<->MOπ, but that would do IMHO.

How about this one:

Edit: I just noticed that matthiaspaul made a similar suggestion. But since both ideas are not exactly the same I think I'll post this anyway.

Code:

 [g] [DRG]           DEG
     [DRG]           RAD
[->]                 RAD->DEG
     [DRG]           RAD->GRAD
     [ENTER]

This way any combination of "from-mode" and "to-mode" can be chosen easily without digging through endless menus.

Even the conversion from the current mode into another is possible. Assuming the current mode is radians:

Code:

[->] [DRG]           RAD->DEG
     [DRG]           RAD->GRAD
     [ENTER]

So pressing the initial [→] simply sets the "from mode" (left of arrow) to the current one. This way the user unambigously sees what conversion will be executed.

I'm sure there also is a convenient way to do this the other way round when an angle is converted to the current mode, like in [DEG→]. For instance pressing [x↔y] may swap both sides.

For use in programs the dedicated [→DEG], [RAD→] etc. commands can be left in menus.

Dieter

[walter b]

Nice ideas for sure. Though, do we really need all those conversions??

d:-?

[matthiaspaul]

(01-08-2016 09:09 PM)Dieter Wrote:  Finally, there are some not too sophisticated functions that can make the programmer's life much easier as they preserve accuracy that would be lost in a straightforward implementation. Think of a sqrt(1+x) – 1 or a general (1+x)^n – 1 function, especially for small x. Or y^x – 1, or 1 – cos x, or Lambert's W + 1. Or a sin(x*pi) function that returns exact results for integer fractions of Pi. Or... you get the idea. There is more than ln(1+x) and e^x–1.

Yes, I agree. I always wondered why these two functions

• lnp1(x) = ln(1+x)
• expm1(x) = e^x-1
  

were available for base e only, not for some other bases. However, some while back I learnt that the IEEE-754:2008 and ISO/IEC/IEEE 60559:2011 standards now recommend implementations also for base 10 and 2 (the following 4 function names are my own creations in lack of anything "official"):

• lgp1(x) = lg(1+x)
• exp10m1(x) = 10^x-1
  

• ldp1(x) = ld(1+x)
• exp2m1(x) = 2^x-1
  

Regarding 1-cos(x), I recommend to implement not just the versine but the whole set of missing trigonometric functions (with q=angle of full circle/4 depending on selected angle mode):

Secant and inverse:

• sec(x) = 1/cos(x)
• asec(x) = acos(1/x)
  

Cosecant and inverse:

• csc(x) = 1/sin(x)
• acsc(x) = asin(1/x)
  

Cotangent and inverse:

• cot(x) = 1/tan(x) = cos(x)/sin(x)
• acot(x) = atan(1/x)
  

Versine and inverse:

• ver(x) (or vsn(x)) = 2*(sin(x/2))^2 = 1-cos(x)
• aver(x) = acos(1-x)
  

Vercosine and inverse:

• vcs(x) = 2*(cos(x/2))^2 = 1+cos(x)
• avcs(x) = acos(1+x)
  

Coversine and inverse:

• cvs(x) = ver(q-x) = 1-sin(x)
• acvs(x) = asin(1-x)
  

Covercosine and inverse:

• cvc(x) = vcs(q-x) = 1+sin(x)
• acvc(x) = asin(1+x)
  

Haversine and inverse:

• hav(x) = ver(x)/2 = (sin(x/2))^2 = (1-cos(x))/2
• ahav(x) = 2*asin(sqrt(x))
  

Havercosine and inverse:

• hvc(x) = vcs(x)/2 = (cos(x/2))^2 = (1+cos(x))/2
• ahvc(x) = 2*acos(sqrt(x))
  

Hacoversine and inverse:

• hcv(x) = cvs(x)/2 = ver(q-x)/2 = hav(q-x) = (1-sin(x))/2
• ahcv(x) = ?
  

Hacovercosine and inverse:

• hcc(x) = cvc(x)/2 = vcs(q-x)/2 = hvc(q-x) = (1+sin(x))/2
• ahcc(x) = ?
  

Exsecant and inverse:

• exs(x) = sec(x)-1 = 1/cos(x)-1 = (1-cos(x))/cos(x) = ver(x)/cos(x) = ver(x)*sec(x) = 2*sec(x)*(sin(x/2))^2
• aexs(x) = asec(x+1) = acos(1/(1+x)) = atan(sqrt(x^2+2*x))
  

Excosecant and inverse:

• exc(x) = exs(q-x) = csc(x)-1 = 1/sin(x)-1 = (1-sin(x))/sin(x) = cvs(x)/sin(x) = cvs(x)*csc(x) = 2*csc(x)*(cos(x/2))^2
• aexc(x) = acsc(x+1) = asin(1/(1+x))
  

Chord and inverse:

• crd(x) = 2*sin(x/2)
• acrd(x) = 2*asin(x/2)
  

Sagitta and inverse:

• sag(x) = ver(x/2) = 1-cos(x/2)
• asag(x) = 2*acos(1-x)
  

Cosagitta and inverse:

• csg(x) = cvs(x/2) = 1-sin(x/2)
• acsg(x) = 2*asin(1-x)
  

See also:
http://www.hpmuseum.org/forum/thread-475...l#pid42413

(01-11-2016 07:34 AM)walter b Wrote:  While we're at it, it reminds me of an angular mode I wanted to see implemented in the 43S: multiples of π. We calculate them very precisely anyway, so this mode will come at no extra cost.

Yes, factors of pi definitely has utility value as well (some RPL calcs have a ->Qπ fraction of pi function in addition to the normal ->Q function to convert a number into a fraction), it's quite close to a turns mode.

Nevertheless, if I were forced to select only one of these modes, I would choose turns because it appears to be more universal and is already reasonably well established (although not implemented in calculators so far). Having the angle of a full circle normalized to 1 allows for easier conversions to/from a whole bunch of other angle units (including factors of pi, of course).

By the way, the above mentioned floating-point standards also recommend new variants of trigonometric functions related to factors of pi (@ recommended by IEEE, the others are supported by Oracle).

• sinpi(x) = sin(pi*x) @
• cospi(x) = cos(pi*x) @
• tanpi(x) = tan(pi*x)
  

• asinpi(x) = asin(x) / pi
• acospi(x) = acos(x) / pi
• atanpi(x) = atan(x) / pi @
  

• atan2pi(y,x) = atan2(x) / pi @
  

Greetings,

Matthias

[Dieter]

(01-12-2016 12:08 AM)matthiaspaul Wrote:  Regarding 1-cos(x), I recommend to implement not just the versine but the whole set of missing trigonometric functions

I'd say the first four (and ther inverses) are sufficient. ;-)
That's the versine, vercosine, coversine and covercosine.
This way 1±sin(x) and 1±cos(x) can be calculated exactly.

(01-12-2016 12:08 AM)matthiaspaul Wrote:  By the way, the above mentioned floating-point standards also recommend new variants of trigonometric functions related to factors of pi (@ recommended by IEEE, the others are supported by Oracle).

So do I ("..a sin(x*pi) function that returns exact results for integer fractions of Pi"). ;-) But a complete function set would include both trig(pi*x) and trig(pi/x) functions. Think of arguments like pi/3 or 2/3*pi which cannot be expressed exactly, neither in base-2 nor base-10 representation – 0,3333333333*pi is not pi/3.

Dieter

[Paul Dale]

The 34S already has one of these functions:

(-1)^x gives cos(pi x)


I've been tempted to fill out the trigonometric functions -- I did implement sec, cosec and cot (with inverses) at one point, but they didn't make it. The extra trigonometric functions were tempting too. The haversine rule is still used occasionally -- I saw it in production when I was playing with GPS guided tractors two or three years ago. Vincenty's formulæ is more accurate but more difficult to implement.

- Pauli

[walter b]

Dieter, let's assume something along your suggestions and look what will happen. For the time being, subsequent presses of [DRG] shall call DEG, RAD, GRAD, TURNS, DEG, etc. Let's further assume default startup agular mode is DEG. Setting current angular mode to TURNS, for example, will need 4 keystrokes then (plus a trailing pause of e.g. >0.5s to let the calculator know the [DRG] pressing has stopped now). Waiting a bit and pressing [DRG] once more will return to DEG.

For conversions from current mode, starting from default DEG, pressing [→] [DRG] [DRG] and waiting as above would execute DEG→GRAD. As long as the SW will be based on the 34S, note the output of this conversion may be labeled by a suitable indicator for gradians but this will only be temporary (since we don't have tagged values or variables yet). Thus calling [→] [DEG] once more will interprete the number displayed as an angle in degrees and convert it into radians. If you want to invert this last conversion, call UNDO .

Conversions from another mode would require a two-step process: first switch to the angular mode suiting the source value (e.g. to RAD by pressing [DRG] once); then convert to the target mode (e.g. to TURNS by pressing [→], [DRG], [DRG] then).

Did I understand your intentions correctly?

d:-?

[emece67]

(01-12-2016 04:13 PM)walter b Wrote:  Conversions from another mode would require a two-step process: first switch to the angular mode suiting the source value (e.g. to RAD by pressing [DRG] once); then convert to the target mode (e.g. to TURNS by pressing [→], [DRG], [DRG] then).

For these "inverse" conversions I think one of Bit's patches seems better. With it, pressing [->] twice shows [<-] in the status bar, then DEG, RAD, GRAD (here [DRG] one or more times) converts from such unit to the current angle mode.

In any case, this [DRG] approach with more than three (or even two) options may be cumbersome, specially if one takes into account the pause needed after the last [DRG] for the machine to recognize the sequence ending.

Regards.

EDIT: and two keys? One [D·G], the other [R·T]? Four angle modes, in just two keys with shorter sequences. The most (I think) usual conversions (DEG<>RAD) require only 2 keys, as R<>T and D<>G. Only conversions from D or G to T, and R or T to G need 3 keys. Inverse conversions one more key.

[Dieter]

(01-12-2016 04:13 PM)walter b Wrote:  Dieter, let's assume something along your suggestions and look what will happen. For the time being, subsequent presses of [DRG] shall call DEG, RAD, GRAD, TURNS, DEG, etc. Let's further assume default startup agular mode is DEG. Setting current angular mode to TURNS, for example, will need 4 keystrokes then (plus a trailing pause of e.g. >0.5s to let the calculator know the [DRG] pressing has stopped now). Waiting a bit and pressing [DRG] once more will return to DEG.

Waiting for the calculator to accept my entry? No way. #-)

Selecting menu items by timeout IMHO is the worst of all methods. If you want to tell the calculator (or any other device) what you chose, simply press ENTER (or a simliar key). Imagine your TV remote control expecting a three-digit program number while you just want to switch to program #7. Press the 7 and wait a few seconds? No way – 7 ENTER does it.

(01-12-2016 04:13 PM)walter b Wrote:  For conversions from current mode, starting from default DEG, pressing [→] [DRG] [DRG] and waiting as above would execute DEG→GRAD.

Yes – but without the "waiting" part. ;-)

(01-12-2016 04:13 PM)walter b Wrote:  As long as the SW will be based on the 34S, note the output of this conversion may be labeled by a suitable indicator for gradians but this will only be temporary (since we don't have tagged values or variables yet). Thus calling [→] [DEG] once more will interprete the number displayed as an angle in degrees and convert it into radians. If you want to invert this last conversion, call UNDO .

I admit I don't understand this point.

(01-12-2016 04:13 PM)walter b Wrote:  Conversions from another mode would require a two-step process: first switch to the angular mode suiting the source value (e.g. to RAD by pressing [DRG] once); then convert to the target mode (e.g. to TURNS by pressing [→], [DRG], [DRG] then).

Yes. I think this procedure is quite self-explaning.

Dieter

[walter b]

So switching from DEG to TURNS would need 5 keystrokes then. - And starting from default DEG again, pressing [→] [DRG] [DRG] [ENTER] would execute DEG→GRAD.

Example:
90 [→] [DRG] [DRG] [ENTER] would execute 90 DEG→GRAD and return 100.

(01-12-2016 08:29 PM)Dieter Wrote:  

(01-12-2016 04:13 PM)walter b Wrote:  As long as the SW will be based on the 34S, note the output of this conversion may be labeled by a suitable indicator for gradians but this will only be temporary (since we don't have tagged values or variables yet). Thus calling [→] [DRG] [ENTER] once more will interprete the number displayed as an angle in degrees and convert it into radians. If you want to invert this last conversion, call UNDO .

I admit I don't understand this point.

Example (continued):
[→] [DRG] [ENTER] would execute 100 DEG→RAD and return 1.745.
[UNDO] would return 100 again.
(Sorry for the typo above)

d:-)

[walter b]

Let me try to simplify this a bit:

Assume this part of the keyboard will look like this:

(Sorry, forgot underlining DRG.)

Then pressing [g][DRG] shall open a small menu [DEG][RAD][GRAD][TURNS]. Pressing the corresponding softkey ([A], [B], [C], or [D]) shall set the angular mode respectively.

OTOH, pressing [→][DRG] ([→] will go with [g] automatically like in WP 34S) shall open a similar menu [>DEG][>RAD][>GRAD][>TURN]. Pressing the corresponding softkey ([A], [B], [C], or [D]) shall convert from the current angular mode to the respective notation.

Should be easy enough. For hexagesimal degrees, [g][D.MS] and [→][D.MS] shall work in analogy.

How do you like this?

d:-)

[emece67]

(01-13-2016 10:02 AM)walter b Wrote:  Let me try to simplify this a bit:

Assume this part of the keyboard will look like this:

(Sorry, forgot underlining DRG.)

Then pressing [g][DRG] shall open a small menu [DEG][RAD][GRAD][TURNS]. Pressing the corresponding softkey ([A], [B], [C], or [D]) shall set the angular mode respectively.

OTOH, pressing [→][DRG] ([→] will go with [g] automatically like in WP 34S) shall open a similar menu [>DEG][>RAD][>GRAD][>TURN]. Pressing the corresponding softkey ([A], [B], [C], or [D]) shall convert from the current angular mode to the respective notation.

Should be easy enough. For hexagesimal degrees, [g][D.MS] and [→][D.MS] shall work in analogy.

How do you like this?

d:-)

Seems perfect for me. For the reverse conversions I still prefer the [->] [->] [DRG] approach.

Thanks.

[walter b]

(01-13-2016 11:41 AM)emece67 Wrote:  For the reverse conversions I still prefer the [->] [->] [DRG] approach.

I'd suggest a 3-row menu instead:

Code:

→DEG  →RAD  →GRAD →TURN
DEG→  RAD→  GRAD→ TURN→
D.MS→

You'd get to the next menu row by pressing [v] (i.e. arrow down).

d:-)

[rprosperi]

(01-13-2016 10:02 AM)walter b Wrote:  Let me try to simplify this a bit..

How do you like this?

I do like this. It's simple, clear and intuitive. The multi-tier menu, controlled by up/down arrows is also a clear extension for larger sets of options.

[matthiaspaul]

(01-12-2016 12:08 AM)matthiaspaul Wrote:  some while back I learnt that the IEEE-754:2008 and ISO/IEC/IEEE 60559:2011 standards now recommend implementations also for base 10 and 2 (the following 4 function names are my own creations in lack of anything "official"):

• lgp1(x) = lg(1+x)
• exp10m1(x) = 10^x-1
  

• ldp1(x) = ld(1+x)
• exp2m1(x) = 2^x-1
  

FWIW, Intel x86 floating-point processors since the 80387 support machine instructions named FYL2XP1 and F2XM1 for:

• l2xp1(x) = ld(1+x)
• 2xm1(x) = 2^x-1
  

This MathWorld article by Christopher Stover

http://mathworld.wolfram.com/Floating-Po...metic.html

uses a similar notation

log10(x) = lg(x), exp10(x) = 10^x
log10p1 = lg(1+x), exp10m1 = 10^x-1

log2(x) = ld(x), exp2(x) = 2^x
log2p1(x) = ld(1+x), exp2m1(x) = 2^x-1

William Kahan, however, uses the following odd notation in "Pseudo-Division Algorithms for Floating-Point Logarithms and Exponentials" (2002-05-20), http://www.cims.nyu.edu/~dbindel/class/cs279/logexp.pdf

lg(x) = ld(x), txp(x) = 2^x
lg1p(x) = ld(1+x), txpm1(x) =2^x-1

Greetings,

Matthias