WP32S in 2016?

01102016, 09:45 PM
Post: #61




RE: WP32S in 2016?
(01102016 09:21 PM)rprosperi Wrote:(01102016 02:02 PM)Dieter Wrote: Of course you are right here. I also think it is acceptable. César  Information must flow. 

01112016, 12:08 AM
(This post was last modified: 01112016 11:51 AM by matthiaspaul.)
Post: #62




RE: WP32S in 2016?
(01102016 09:21 PM)rprosperi Wrote: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.(01102016 02:02 PM)Dieter Wrote: Of course you are right here.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 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/thread449...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 prepreviously selected mode [g]+[DRGT][DRGT][DRGT] would switch to the preprepreviously selected mode [→]+[DRGT] would switch&convert to the previously selected mode [→]+[DRGT][DRGT] would switch&convert to the prepreviously selected mode [→]+[DRGT][DRGT][DRGT] would switch&convert to the preprepreviously 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] semitoggle 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  "Programs are poems for computers." 

01112016, 07:34 AM
Post: #63




RE: WP32S in 2016?
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:) 

01112016, 08:02 AM
Post: #64




RE: WP32S in 2016?
(01102016 04:39 PM)rprosperi Wrote:(01102016 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. Please remember the stack will be XYZTABCD. d:) 

01112016, 08:05 AM
Post: #65




RE: WP32S in 2016?
(01112016 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 ndivisions 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 

01112016, 08:30 AM
Post: #66




RE: WP32S in 2016?
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:) 

01112016, 01:40 PM
(This post was last modified: 01112016 01:44 PM by Dieter.)
Post: #67




RE: WP32S in 2016?
(01112016 08:30 AM)walter b Wrote: It wasn't my intention to allow all 36 conversions. 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 This way any combination of "frommode" and "tomode" 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 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 

01112016, 02:07 PM
Post: #68




RE: WP32S in 2016?
Nice ideas for sure. Though, do we really need all those conversions??
d:? 

01122016, 12:08 AM
(This post was last modified: 01142016 12:21 AM by matthiaspaul.)
Post: #69




RE: WP32S in 2016?
(01082016 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
Secant and inverse:
http://www.hpmuseum.org/forum/thread475...l#pid42413 (01112016 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 floatingpoint standards also recommend new variants of trigonometric functions related to factors of pi (@ recommended by IEEE, the others are supported by Oracle).
Matthias  "Programs are poems for computers." 

01122016, 12:27 AM
Post: #70




RE: WP32S in 2016?
(01122016 12:08 AM)matthiaspaul Wrote: Regarding 1cos(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. (01122016 12:08 AM)matthiaspaul Wrote: By the way, the above mentioned floatingpoint 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 base2 nor base10 representation – 0,3333333333*pi is not pi/3. Dieter 

01122016, 03:07 AM
Post: #71




RE: WP32S in 2016?
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 

01122016, 04:13 PM
Post: #72




RE: WP32S in 2016?
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 twostep 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:? 

01122016, 07:47 PM
(This post was last modified: 01122016 08:05 PM by emece67.)
Post: #73




RE: WP32S in 2016?
(01122016 04:13 PM)walter b Wrote: Conversions from another mode would require a twostep 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. César  Information must flow. 

01122016, 08:29 PM
Post: #74




RE: WP32S in 2016?
(01122016 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 threedigit 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. (01122016 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. ;) (01122016 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. (01122016 04:13 PM)walter b Wrote: Conversions from another mode would require a twostep 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 selfexplaning. Dieter 

01122016, 11:35 PM
Post: #75




RE: WP32S in 2016?
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. (01122016 08:29 PM)Dieter Wrote:(01122016 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 . Example (continued): [→] [DRG] [ENTER] would execute 100 DEG→RAD and return 1.745. [UNDO] would return 100 again. (Sorry for the typo above) d:) 

01132016, 10:02 AM
(This post was last modified: 01132016 10:04 AM by walter b.)
Post: #76




RE: WP32S in 2016?
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:) 

01132016, 11:41 AM
Post: #77




RE: WP32S in 2016?
(01132016 10:02 AM)walter b Wrote: Let me try to simplify this a bit: Seems perfect for me. For the reverse conversions I still prefer the [>] [>] [DRG] approach. Thanks. César  Information must flow. 

01132016, 12:04 PM
Post: #78




RE: WP32S in 2016?  
01132016, 03:57 PM
Post: #79




RE: WP32S in 2016?
(01132016 10:02 AM)walter b Wrote: Let me try to simplify this a bit.. I do like this. It's simple, clear and intuitive. The multitier menu, controlled by up/down arrows is also a clear extension for larger sets of options. Bob Prosperi 

01152016, 09:05 PM
(This post was last modified: 01182016 06:28 PM by matthiaspaul.)
Post: #80




RE: WP32S in 2016?
(01122016 12:08 AM)matthiaspaul Wrote: some while back I learnt that the IEEE754: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"):FWIW, Intel x86 floatingpoint processors since the 80387 support machine instructions named FYL2XP1 and F2XM1 for:
http://mathworld.wolfram.com/FloatingPo...metic.html uses a similar notation log10(x) = lg(x), exp10(x) = 10^x log10p1 = lg(1+x), exp10m1 = 10^x1 log2(x) = ld(x), exp2(x) = 2^x log2p1(x) = ld(1+x), exp2m1(x) = 2^x1 William Kahan, however, uses the following odd notation in "PseudoDivision Algorithms for FloatingPoint Logarithms and Exponentials" (20020520), 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^x1 Greetings, Matthias  "Programs are poems for computers." 

« Next Oldest  Next Newest »

User(s) browsing this thread: