WP-32S in 2016?

[walter b]

(01-08-2016 09:36 PM)Dieter Wrote:  Let me add just two remarks:

(01-08-2016 10:01 AM)emece67 Wrote:  Trigs with direct access from the keyboard (for me this is a must)

I would extend this to all major math functions, i.e. logs, exponentiation, roots, powers, 1/x, ... All this should be available directly from the keyboard, if possible even unshifted. Take a look at the 35s and the key row above ENTER. Remember: after all, it's a calculator, a tool for doing calculations.

After Christmas is before Christmas, isn't it? But here, wishing is not enough: you may - and should - make an alternative layout proposal based on the 39 keys given. Else it won't be a challenge, will it? And no challenge - no fun.

Looking forward to your presentation,

d:-)

Edit: One important point I forgot mentioning: In my layout proposal, the last menu view will stay displayed and valid until EXITed explicitly. So, if you want trigonometric functions unshifted, for instance, call TRIGS and you'll get HYP SIN COS TAN as long as you want them (and press [^] or [v] to get AHYP ASIN ACOS ATAN then).

[emece67]

(01-08-2016 09:36 PM)Dieter Wrote:  

(01-08-2016 10:01 AM)emece67 Wrote:  Operators like DSE & ISG that only increment/decrement the counter & do not perform the test (yes, I know I can write DSE NOP...)

This is already available on the 34s. It's called INC and DEC.
And no, DSE NOP is no substitute – think of non-integer arguments and the way the loop control number is defined. Simply try Pi followed by ISG X. ;-)

Dieter

But INC/DEC always add/substract 1, they do not obey the "step" information in the fractional part. What I ask for is, precisely: 3.14159 => 62.14159.

[emece67]

(01-08-2016 09:09 PM)Dieter Wrote:  ...
Then some functions that are now placed in XROM deserve a speed-up. Think of the quantile functions that sometimes require 5...10 seconds. Compare this with the design goal of the world's very first scientific calculator, the HP35: it was supposed to return any result within a second.

I'm curious here. I knew of the WP34s when the software was on its 3.3 incarnation, so I do not know how faster are commands in C vs. those in XROM. How many time needed the quartile functions when they were written in C?

[Dieter]

(01-09-2016 09:41 AM)walter b Wrote:  After Christmas is before Christmas, isn't it? But here, wishing is not enough: you may - and should - make an alternative layout proposal based on the 39 keys given.

No, I won't. Because I think that 37 (30b) or 39 keys simply are not enough for what I think is a better calculator with more or less direct access of the essential math functions.

Take a look at the 35s. It offers 43 keys while, compared to the 34s, the function set is much less comprehensive and there are no special keys like A–D or "→". This frees up a whole row of keys – the one with the essential math functions. That's why for most practlcal calculations I prefer the 35s to the 34s. I think I can say this as I use both almost every day.

So all in all what we need are more keys. The 30b/20b already is a compromise, and the SM platform is not much better for this purpose.

Dieter

[walter b]

This means we'll have to wait for the 43S. Back to start ...!

d:-/

CETERVM CENSEO: ...

[Paul Dale]

(01-09-2016 10:03 AM)emece67 Wrote:  I'm curious here. I knew of the WP34s when the software was on its 3.3 incarnation, so I do not know how faster are commands in C vs. those in XROM. How many time needed the quartile functions when they were written in C?

The C versions of the quantile functions used less efficient algorithms than the XROM ones so there is no proper comparison. The initial conversion to XROM used the same algorithms, so comparing the last C version to the first XROM version would give an idea.

I don't know the difference and it varies by function.


- Pauli

[walter b]

It took my starving design team quite some effort - and they even had to cover due to unfriendly crossfire in addition (who said we should focus on calculators?) - but I know I can rely on them even under fire. Here we go:

   

Some of our customers should be more content than before, at least.

d:-)

CETERVM CENSEO: ...

[Dieter]

(01-10-2016 12:50 PM)walter b Wrote:  Here we go:

I fear this is (close to...) the best that can be done with the limited number of keys available on the SM platform. Now the most important math functions are accessible with two keystrokes. Fine. That's not "direct access", but I think that's what can be done with 37 keys.

However, this or that still can be improved:

• Where is x²? Yes, [ENTER] [x] requires the same two keystrokes, but the highest stack register is lost. No, [STO][x][X] is not an option. ;-)
• As already mentioned by emece67, the two x=? and x≠? tests should be removed from the keyboard. Like all other tests (which require menus anyway) they are only used in programs so that direct access is not required. This frees up two keys that can now be assigned to more useful functions. For instance, if you think that y-hat deserves its own key, so does the correlation coefficent r.
• Is there a special reason for the sequence RAD DEG D.MS GRAD? I think DEG RAD GRAD D.MS would be more logical.
• Instead of "Blank" I would suggest labelling this key with the usual "open box" character (U+2423). Or, more '41-style, a simple "SPACE". ;-)
  

My suggestion: move the P-R conversions to g[0] and g[.], set the six first g-shifted functions of the second row to DEG RAD GRAD x² D.MS r.

Dieter

[Luigi Vampa]

@Walter
Thanks 'noch einmal' for the new layout design.

I don't know how to ask this without being somewhat blunt... now that WP43s project unfortunately seems to be going through a bumpy road, what is the likelihood of getting Swissmicros involved in this DM36L? Is there any word from Michael about it?

MfG 2 x
Don Luigi

[emece67]

(01-10-2016 12:50 PM)walter b Wrote:  It took my starving design team quite some effort - and they even had to cover due to unfriendly crossfire in addition (who said we should focus on calculators?) - but I know I can rely on them even under fire. Here we go:

Thanks Walter. I like it much more. 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.

Dieter proposals seem also quite appropriate to me.

I'm slightly concerned about some menus having too few items on them. What will be inside LOOPS (only ISE, ISG, ISZ, DSE, DSL & DSZ)? And in BOOLE (only AND, NAND, OR, NOR, XOR; XNOR & NOT)? What in STACK (only y<>, z<>, t<>, <> & DROP)? I think that, perhaps, some menus can be combined allowing other functions to be directly accesible.

I also think that the e^x, 10^x, 2^x seems more "natural" than 2^x, 10^x, e^x. Simply a matter of taste, although I use much more the binary than the decimal/natural variants.

[walter b]

I'm pretty sure Michael reads this forum - though I've no idea how closely he follows our posts. Anyway, I didn't receive anything from him since I purchased a DM16L.

d:-?

[rprosperi]

(01-10-2016 02:02 PM)Dieter Wrote:  My suggestion: move the P-R conversions to g[0] and g[.], set the six first g-shifted functions of the second row to DEG RAD GRAD x² D.MS r.

I generally concur with Dieter's comments, however is there evidence that changing between DEG/RAD/GRAD occurs frequently enough for a lot of users to warrant using valuable shifted keys (vs. in a menu such as X.FCN). To me, it does not seem to be a frequent setting, I think most users change this rarely. Especially true for GRAD.

(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.

[Dieter]

(01-10-2016 04:39 PM)rprosperi Wrote:  I generally concur with Dieter's comments, however is there evidence that changing between DEG/RAD/GRAD occurs frequently enough for a lot of users to warrant using valuable shifted keys (vs. in a menu such as X.FCN). To me, it does not seem to be a frequent setting, I think most users change this rarely. Especially true for GRAD.

There is a simple and straightforward solution: What about a D·R·G key that toggles between degrees, radians and grads? It isn't neccessarily bad just because Casio does it this way. ;-)

This way two more keys are gained. So the P-R conversions may move back to the second row and g[0] resp. g[.] can be used for CF and SF.
Great!

Dieter

[emece67]

(01-10-2016 07:54 PM)Dieter Wrote:  There is a simple and straightforward solution: What about a D·R·G key that toggles between degrees, radians and grads? It isn't neccessarily bad just because Casio does it this way. ;-)

This way two more keys are gained. So the P-R conversions may move back to the second row and g[0] resp. g[.] can be used for CF and SF.

But DEG, RAD, GRAD are still needed for - >DEG, - >RAD, - >GRAD.

[walter b]

(01-10-2016 02:02 PM)Dieter Wrote:  I fear this is (close to...) the best that can be done with the limited number of keys available on the SM platform.

Thanks for your kind words, coming from a diligent person.

Quote:However, this or that still can be improved:

Certainly.

Quote:Where is x²? Yes, [ENTER] [x] requires the same two keystrokes, but the highest stack register is lost.

Well, we'll offer 8 stack registers. Thus, who will care for one lost register?

Quote:As already mentioned by emece67, the two x=? and x≠? tests should be removed from the keyboard. Like all other tests (which require menus anyway) they are only used in programs so that direct access is not required. This frees up two keys that can now be assigned to more useful functions. For instance, if you think that y-hat deserves its own key, so does the correlation coefficent r.

Could be done. Please see below.

Quote:Is there a special reason for the sequence RAD DEG D.MS GRAD? I think DEG RAD GRAD D.MS would be more logical.

Some reasons: a) RAD shares its key with π for obvious reasons, as π shares it with CONST. b)DEG and D.MS are next to each other since both deal with degrees. c) D.MS shares its key with CLOCK for obvious reasons. d) RAD is located closer to [>] since it's used more frequently than GRAD. Thus, GRAD is placed on the far side.

Quote:Instead of "Blank" I would suggest labelling this key with the usual "open box" character (U+2423).

The "open box" will come.

Quote:My suggestion: move the P-R conversions to g[0] and g[.], set the six first g-shifted functions of the second row to DEG RAD GRAD x² D.MS r.

Thanks. Though not optimal since >DEG will require pressing the same key twice which I tried to avoid.

d:-)

[walter b]

(01-10-2016 07:54 PM)Dieter Wrote:  ... g[0] resp. g[.] can be used for CF and SF.
Great!

May I ask why you prefer them over the two tests located there now? I remember "they are only used in programs so that direct access is not required."

d:-?

[Dieter]

(01-10-2016 08:15 PM)emece67 Wrote:  But DEG, RAD, GRAD are still needed for - >DEG, - >RAD, - >GRAD.

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

[Dieter]

(01-10-2016 08:30 PM)walter b Wrote:  May I ask why you prefer them [CF and SF] over the two tests located there now? I remember "they are only used in programs so that direct access is not required."

You forgot the first words of that quote. I said "like all other tests they are only used in programs." ;-)

Flags are often used to set modes. Think of a TVM program where a flag toggles between begin and end mode. Or, Pauli and I have been discussing whether flag J may be used to control the discrete distributions' quantile returned as integers or fractional values. My statistical distributions package for the 35s uses a flag to toggle between CDF and quantile mode. In another program flag 2 can be set if results for two-sided tests (Normal/Student) are desired.

BTW that's why I miss a flag annunciator as featured by the 41-series or the 35s.

We had this discussion years ago regarding the 34s on the 20b/30b platform. And finally CF and SF made it to the keyboard.

Dieter

[walter b]

As mentioned earlier, I had SF and CF on the keyboard already (and I wrote why I removed them). Just wanted to understand your reasoning. SF and CF may show up again.

d:-)

[rprosperi]

(01-10-2016 02:02 PM)Dieter Wrote:  

(01-10-2016 08:15 PM)emece67 Wrote:  But DEG, RAD, GRAD are still needed for - >DEG, - >RAD, - >GRAD.

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.