Re: [WP 34S] New keyboard layout (poll)

[Walter B]

After discussing back and forth, it all boils down to whether (1) we keep the present layout but with changed EXIT and x<>y keys as shown in the picture below or (2) we turn to a layout as presented here (changed keys are marked):

MATRIX shall contain the new matrix commands, and L.R. all commands related to 2D data (curve fit modes, COV, etc.).

Your votes please :-)

Walter

[Cristian Arezzini]

I think I'd vote for 2. But is that layout fixed? I guess if it is we won't get same-shift "window change" keys...

Cristian

[fhub]

+1 for this new layout, looks really good! :-)

[Gene Wright]

?

[fhub]

Option (1) is the current layout (as in the release version) with only the 2 keys x<>y and EXIT changed as in the posted picture (which is option (2)).

[Walter B]

Exactly. Thanks, Franz :-)

[Eric Rechlin]

Rather than moving 4 keys around, why not just put MATRIX on [3] and pi on [EEX] and leave the [*] and [DownArrow] alone? Though if there is a good reason for moving X.FCN and STATUS I'm sure I could be convinced otherwise...

Eric

[M. Joury]

My thoughts exactly. What is the logic of moving X.FCN and Status?

Cheers,

-Marwan

[Walter B]

Some reasoning:

Starting point: MATRIX just looks right at *. STATUS is moved next to TEST for obvious reasons. Then X.FCN goes to 3 next to P.FCN, driving PI to EEX. Thus CLP - which became pretty "dangerous" since it deletes all programs - is no longer on the keyboard :-) (CLP was meant to clear just the current program when placed there as discussed here earlier.)

./, has a second use in alpha mode calling a catalogue of punctuation marks :-)

[Howard Owen]

I only see one layout here. It looks to me like option 2. If you have an option 1 mentioned in some other thread, could you please provide a link, or else post a picture here?

If option 1 doesn't change anything other than the unshifted key functions or the H shifted plane, then I vote for that. These changes aren't significant enough to justify the pain of replacing the whole base decal, in my opinion.

Thanks for asking. :)

[Walter B]

Please see above or read message #1 again.

[Kerem Kapkin (Silicon Valley, CA)]

I would vote for option (2) two which adds the valuable Matrix functions on the keyboard, and Pi seems to be in a better place in addition to other changes.
-K2

[Dominic Richens]

I've been meaning to ask this question, what does ./, do that it deserves to be on the keyboard? Doesn't ON-. do the same thing? Isn't it on the MODE catalog? Isn't it a set once only thing?

I say do option 1 and make MATRIX the h-shifted function on the decimal key.

However, I like having that 123456 block of keys be for catalogues.

I'm not sure I "get" most of the other changes on option 2 (but that's nothing new :-)

[M. Joury]

Good point on ./,. That would be a perfect place for PI. Then place MATRIX where PI is currently.

[Eric Rechlin]

I agree. Something that you only need to set once should not be on a scarce key label on the keyboard.

Eric

[Walter B]

Please see my post above. Thanks :-)

[Dominic Richens]

But that key is still the "." key. So even if we make MATRIX (or something else) the h-shifted function it is still no less logical place for the punctuation alpha-catalogue.

[Morten Nygaard Åsnes]

Option 2

[Gerson W. Barbosa]

2

[Alexander Oestert]

I vote for option 0: leave everything as it is. The proposed changes are far to insignificant in my opinion to warrant all the hassle.

[Marcus von Cube, Germany]

Option 0 is essentially option 1 with just replacing the rarely used xtoa/atox with the more useful (and brand new) y<> and z<> commands and swapping OFF and SHOW. You can certainly live with your old overlay then.

[Alexander Oestert]

My old overlay is really not my concern: I will just stick to the firmware version that supports it.

But from my perspective no change in the overlay is necessary at all, the gain seems too minor to me, as that I would want to render prior overlays partly obsolete. I'd rather change only inside the catalogs, but not the interface.

Again, this is only my very, very limited "curious user" perspective which should not at all influence the poll of more professional users who really need a calculator for their productive work. BTW how many of these are here amongst WP-34s users?

[Paul Dale]

Quote:

---

My old overlay is really not my concern: I will just stick to the firmware version that supports it.

---

You'll miss out on bug fixes if so & I'm sure there are plenty of bugs lurking still :-(

- Pauli

[Alexander Oestert]

Even if that were the case, I could easily live with that. I'm not working but only playing with the WP34s. It's a wonderful toy, though! :)

[Dominic Richens]

Quote:

---

You'll miss out on bug fixes if so & I'm sure there are plenty of bugs lurking still :-(

---

Time to investigate branching. I would suggest branching instead of tagging, since it implies we can still propagate bugfixes. Options:

branch off of the last 2.1 version, or last known stable version. I have been using 2.1 1664 for a while - I took that because it was the version where FIX would get me out of integer mode.

branch now, just before the keyboard layout changes. May not be as stable, but it has the HP-41 press-and-hold behaviour, the matrix routines plus other small enhancements and bugfixes.

Or we could also do both. But I would only volunteer to maintain one of them :-)

[Paul Dale]

If (and it is by no means certain) we do a major change to the keyboard, there will be subversion branches involved.

We've not decided what form they will take, first we need to decide if a branch is necessary. For option 1, it isn't.

- Pauli

[Jeff O.]

Can someone remind me of the need to swap OFF and SHOW? Is it just a preference to press h-EXIT to turn the calculator off instead of g-EXIT?

Edited: 14 Oct 2011, 9:29 a.m.

[fhub]

Quote:

---

Can someone remind me of the need to swap OFF and SHOW? Is it just a preference to press h-EXIT to turn the calculator off instead of g-EXIT?

---

Yes, it's just a preference of one (or very few) user, but with the difference that THIS preference seems to be made whereas many others are not.

[Cristian Arezzini]

I seem to recall that it's a preference of *many* users - people eventually got used to the way it is, but the "other" way is perceived as more intuitive, and I agree.

Oh, and this change, unlike others, comes at zero cost, as they are already going to change the layout anyway.

Cristian

[fhub]

Quote:

---

I seem to recall that it's a preference of *many* users

---

And switching the calculator OFF is indeed a *very* useful and *often used* feature - I am indeed using this OFF many times during my calculations! ;-)

[Dominic Richens]

I tend to turn my calculator on and off a lot so I would like it to be the h-shift function. However, I can see why people who use SHOW a lot would find this a downgrade.

On the WP-34s, to be an "h-shift" function is coveted due to the proximity of the h key to the edge of the calculator.

Overall I find the postilion of the shift keys annoying, but I think that is just because I never used anything prior to the HP15C. After that the shift keys were always a "left-thumb" keys. It was the main reason for starting the WP-32sII modifications (which, at this rate, will be done in 2015).

[John Abbott (S. Africa)]

I vote for #2. If Eric can provide a "keyboard patch kit" as suggested, then this makes the change easier to manage.
BTW, thanks for the overlays Eric - really professional.
John

[Marcus von Cube, Germany]

There seem to be some votes for Walter's new layout. If we go this route we should go a little further:

1. Move C/Py,x to the right and drop Phi and its inverse.
   
2. Move STATUS to PSE (I know Walter will object to this.)
   
3. Move ! to to the f-shifted position of the same key (UP)
   
4. Move <( and )> to h-shifted UP and DOWN
   
5. Now we have room for SF, CF and FS? on the vacant positions of UP and DOWN. :-)
   

Should look like this:



This is from an older design and lacks FS? but you see the point.

Edited: 14 Oct 2011, 5:06 a.m.

[fhub]

Quote:

---

Should look like this:



This is from an older design and lacks FS? but you see the point.

---

I don't like this splitting of "!" and "C P(y x)" to different keys at all - these 3 functions belong together and should stay as they are currenty.

Dropping Phi and its inverse is ok, it's really not used so often.

Removing PSE is also ok, that's definitely a programming function which should go the catalog - I would prefer having DROP on the keyboard instead (of course on an other position).

Franz

[Marcus von Cube, Germany]

Quote:

---

I don't like this splitting of "!" and "C P(y x)" to different keys at all - these 3 functions belong together and should stay as they are currenty.

---

The 15C has them on 0 and +, so a bit more apart, and no-one complains. In my design they are side by side.

[fhub]

Quote:

---

The 15C has them on 0 and +, so a bit more apart, and no-one complains. In my design they are side by side.

---

Well, then which 'partner' would you like to give this "[g]!"?

IOW what you put on the [f]-part of this key?

Otherwise the "!" would be quite 'lonesome' ... ;-)

[Marcus von Cube, Germany]

Besides FS? (grouped with SF and CF on DOWN), ln Gamma comes into my mind.

[Gene Wright]

Speak for yourself about the normal distribution and inverse. I use it quite a bit! :-)

[fhub]

Quote:

---

Speak for yourself about the normal distribution and inverse. I use it quite a bit! :-)

---

Well, does not everybody here only speak for himself? ;-)

Edited: 14 Oct 2011, 7:58 a.m.

[Dominic Richens]

If true, then use the following wording: "I don't use it so often"
:-)

[fhub]

Quote:

---

If true, then use the following wording: "I don't use it so often"
:-)

---

Well, I think I'm old enough to choose my wording myself. ;-)

[Alexander Oestert]

Quote:

---

Well, I think I'm old enough to choose my wording myself. ;-)

---

... and old enough to suffer from the so caused misunderstandings ... ;-)

[Dieter]

So do I. I consider these two functions absolutely essential in many different sciences. At least more essential than the || function for the EE department. ;-)

I sometimes have the impression that "science" here is usually considered something that is generally done not more than 3 meters (or 10 feet) away from a workbench. But there's more science out there. ;-) In finance, economics, econometrics, statistics and many, if not most other social sciences (sic!) the normal distribution (and others) is at least as essential as P<>R in engineering. Please don't let us forget this.

Dieter

Edited: 14 Oct 2011, 9:01 a.m.

[Walter B]

Quote:

---

There seem to be some votes for Walter's new layout.

---

;-) What's the opposite of euphemism?

Quote:

---

If we go this route we should go a little further:

---

If you can't beat an idea try exaggerating it ;-)

[svisvanatha]

My Vote is for Option 2.

I did like the idea of PI on the [3] though!

Can we also get a white 'reminder' label above EEX for LastX. There is space ;)

[fhub]

Quote:

---

Can we also get a white 'reminder' label above EEX for LastX. There is space ;)

---

There is even more space over the keys left and right of EEX, so why not even write the following 'reminder': "do not forget: LastX = RCL L" ;-)

[Dieter]

I see I am not the only one who prefers a dedicated LastX key. ;-)  Please see my other message in this thread with a suggestion that I think is useful and consistent. What do you two think about that?

Dieter

Edited: 14 Oct 2011, 8:14 a.m.

[fhub]

Quote:

---

I see I am not the only one who prefers a dedicated LastX key. ;-)

---

I guess you did misunderstand my posting, Dieter.

In fact I don't need this LastX at all, in the meantime I've really got used to RCL L. :-)

Franz

[Egan Ford]

Quote:

---

I see I am not the only one who prefers a dedicated LastX key.

---

I do as well. RCL L works, and I am not suggesting removing it. But if WP, et al really want to creating something that would be broadly accepted by RPN users then LASTx should be present.

If you create something that meets the needs of a small market, then only a small market will use it.

I guess the question is, if HP were to build the 34S, would they do it without LASTx?

Edited: 14 Oct 2011, 11:38 a.m.

[Eric Rechlin]

Think about the 50g.

SWAP (or X<>Y or whatever your preferred nomenclature) is one of the most important keys in RPN, yet it isn't labeled on the 50g at all. You just have to know that it is on the right arrow key!

Eric

[Dieter]

Quote:

---

Think about the 50g.

---

That's RPL - and therefore doesn't count in the world of pure RPN. ;-)

Dieter

[Egan Ford]

50g is RPL. 50g also had to make compromises to support ALG. For a pure RPN calculator, why compromise on LASTx?

If the audience for the 34S is only this community, then apparently most do not want LASTx. So don't have it. But if you all really want to push this to a larger audience, then think about what the average RPN user would expect.

Lastly, what if WP, et al had put LASTx on the keyboard, and you put it on the overlay, and 100s of overlays have shipped. Do you think we would be having this discussion? Dumping LASTx to save a label space? Probably not. Because there are lower priority functions such as || that would be considered first.

[Dieter]

Please take a look at my suggestion in the message below. Now imagine LSTX on h [0]. A truly classic solution, just as Pi on h [ . ] ;-) It may actually do a simple RCL L but it is easier to type (both keys on the edge of the keyboard) and more intuitive for most RPN users out there.

Dieter

Edited: 14 Oct 2011, 12:18 p.m.

[svisvanatha]

The reminder label was actually Pauli's suggestion a few days ago ;)

[Dieter]

I prefer the layout shown in the picture (that's option 2, if I get it right). Not only because it leaves the normal distribution on the keyboard - an essential function not only in mathematics and statistics but also for everyday use in the social sciences. The arrangement of the menus on the six digit keys is nice as well.

But there still is room for improvement. ;-)  I really like the idea of the two new functions Y<> and Z<>. But if there is sufficient RAM and even keyboard space for these two, why has as dedicated LastX been rejected for the same reasons (no RAM, valuable keyboard space wasted)?

I already mentioned that the f-shifted exponential functions and the g-shifted logs feel strange to me, maybe even "wrong". The reason for this may be the fact that all earlier HP calculators with different shift keys for these functions did it exactly the other way round: Take a look at classics like the HP-25, the 65, the 67 or the 34C - they all use f ln and g e^x as well as f log and g 10^x. Maybe this is more intuitive since - just like sqrt and x² - the f-shifted function usually returns a result smaller than the input while g-shift returns a larger one. I think we should do it this way as well and swap f and g here. Walter, what do you think?

As others already suggested, Pi should better go to h [ . ] while the decimal marker can be set using the respective command. Which usually is only done once by the user anyway, or even by the SETEUR etc. commands. Also, SHOW is a command that should be accessible as conveniently as possible. There is a reason why it has an exposed position on most HPs. So a h prefix is the obvious choice.

Suggestion for a useful and consistent layout:

h [ENTER] = SHOW

h [EEX] = CONST (yes, it will fit)

h [ . ] = Pi

This would also free g [EXIT] for LastX, maybe only as a shortcut for RCL L so that virtually no RAM is required.

What do you think?

Also take a look at the good old 34C. ;-)

Dieter

Edited: 14 Oct 2011, 8:27 a.m.

[Paul Dale]

Quote:

---

I really like the idea of the two new functions Y<> and Z<>. But if there is sufficient RAM and even keyboard space for these two, why has as dedicated LastX been rejected for the same reasons (no RAM, valuable keyboard space wasted)?

---

The keyboard space these occupy wasn't well utilised (ATOX and XTOA under different names) and we'd passed around many suggestions for existing commands to put there, none of which fitted in well. These are the best we came up with without leaving the slots empty.

The way I implemented these commands actually saved a little flash. There is one common routine for all of these exchanges and now it adds the opcode to a base address to decide the source register instead of always taking the X register. This did cost some additional bytes of course and more in function table overheads. However, I took this chance to remove the x<>y and complex x<>y dedicated functions -- they, like LastX, aren't necessary as separate standalone commands -- this saved about a hundred bytes which offset the extra I used.

The nett result is the x<>y command doesn't display as nicely as before, we have saved a few bytes, the two difficult to fill keyboard slots are occupied consistently and we've gained some potentially useful commands.

I think this is a worthwhile exchange and others seem to agree.

The 34S is at the point of everything being a compromise :-(

- Pauli

[Dominic Richens]

Quote:

---

The 34S is at the point of everything being a compromise :-(

---

Pretty damn good for a compromise :-) I prefer to think of it as a "negotiated design".

[Dieter]

Thank you for the explanation re. X<> and Z<>. But...

Quote:

---

The 34S is at the point of everything being a compromise :-(

---

I do not see a reason for a sad smiley here. In such a project where the user community is heavily involved, the best possible result is something that most users may agree to. This usually is called a compromise. :-)

Dieter

Edited: 14 Oct 2011, 12:09 p.m.

[Dieter]

In other words, my proposal would look like this:

If [ ./, ] has to be saved, simply leave it on h [ . ] and move Pi to h [0]. PSE may go to a catalog since it is used for programming only.

In the picture g [EXIT] is not used. This space may be taken by PSE or another useful command. For instance, let's say... LSTX. :-D

Dieter

Edited: 14 Oct 2011, 11:52 a.m.

[Alexander Oestert]

Why "for programming ONLY"? Programming is one of the main reasons I use the WP34s - and fast (and dirty) programming that is. As PSE is a very important function for this kind of programs to have for me, I'm absolutely happy with having it well in reach on the keyboard.

[Dieter]

Quote:

---

Why "for programming ONLY"?

---

Because PSE does not make much sense in Run mode, does it? It's useful only (in the sense of "exclusively") in Program mode.

But look, in the picture PSE still is there. ;-) The layout even has an unassigned position at g EXIT. So at least three out of four possible commands (Pi, LastX, PSE and . / ,) can be realized.

Dieter

[Walter B]

Please also note PSE has a second use as indicator where to find Greek PSI in alpha mode.

[Dieter]

Well, the proposed layout shows just some humble improvements of your option 2 of course. ;-)

What do you think about it? I feel the swapped positions of the logarithmic and exponential functions make some sense. For me, it looks much more ..."natural" and intuitive this way.

Concerning the number of letters in key labels: if six letters like MATRIX fit on a key in a row that is five keys wide, probably five letters like CONST will fit as well in a row that's six keys wide. And if everything else fails it can also be done with four or even three letters: CONS or CNST resp. CON or CST.

Leaving PSE on the keyboard is no problem as well. Here's another option for the last row:

It even includes another function whose name shall not be mentioned here. ;-)

Dieter

Edited: 14 Oct 2011, 5:47 p.m.

[Walter B]

Quote:

---

if six letters like MATRIX fit on a key in a row that is five keys wide, probably five letters like CONST will fit as well in a row that's six keys wide.

---

Where <20% increase may be tolerable, 25% may be just too much. That's the difference between "probably" and "sure" ;-) It will not fit. And BTW, I don't see any relation of CONST to EEX.

Regarding PSE, I prefer it remaining on 0 for reasons stated in the manual.

Walter

[Dieter]

Walter -

you mentioned two reasons why CONST should remain on [ENTER] and Pi on [EEX]. I would like to convice you that there are other, IMHO even better reasons for the solution I suggested.

1. "CONST is too wide for the [EEX] key"

   I do not have a 30B here, but I assume its keys are roughly (if not
   exactly) the same size as those on my 35s. Here, the delete key (back arrow) has CLEAR (in capitals) printed on it. Other keys in the same row show ABS(space)N and RND(space)O. So I do not see why CONST will not fit just as well. We can even gain some space with a slightly (virtually imperceptible) condensed font.

   If there really was not enough space, four letters would do just as well (CONS or CNST). HP themselves did so when neccessary, even in models as similar as the 67 and 97: On the latter it's LASTX, FRAC, MERGE and PAUSE while on the 67 it says LSTX, FRC, MRG and PSE. That's perfectly okay - I do not see any problem with this either.

2. "There is no relation between [EEX] and CONST, so Pi should stay there"

   First of all, there is no relation between [EEX] and Pi either. ;-)

   Second, Pi is a constant, like e or Phi, the golden ratio. That's why it appears in the CONST catalog. So currently [EEX] holds the mathematical constant Pi, while I simply suggest putting all constants there. The constants menu on [EEX] is neither more nor less intuitive or logic than its placement on the [ENTER] key. Just as [EEX] means "enter exponent", the shifted function is "enter constant".

   Finally, Pi is a constant that is frequently used in manual calculations. So it seems natural that it should be close to the digit keys. The designers of the original 35A knew that and placed this key next to the decimal point. On most classic HPs it's a shifted function of a digit key as well, and so it is in the original 34S layout (h [3]). That's why I think it should go to h [ . ] or h [0].

   The latter two keys are wider than those in the upper rows, so there is another option: Use one of these for CONST. This is even very intuitive: a constant is entered with one of the digit keys,
   just like any other number.

3. "PSE must stay on [0] because in alpha mode the Greek Psi is entered [g] [0] with PSE printed below as a reminder"

   There is no reason why this should not work with another key just as well. In my last proposal the user presses [g] [EXIT] with PSE printed below. Even if for some other reason PSE has to stay on h [0] there is no problem either:

   h [0] = PSE
   
   h [ . ] = CONST
   
   h [EEX] = Pi
   
   h [ENTER] = SHOW

   Which leaves some space for
   
   g {EXIT] = LastX
   

Walter, you did not comment on the swapped log/exp functions. So I assume you like it just as I do. I hope I also could give some good reasons for the other changes I suggested.

Dieter

[Walter B]

Dieter,

Thanks for supplying a complete proposal :-) But take care: you can put more letters in that bitmap than you can read on the real calculator. No way putting CONST on one of those small keys IMHO. So PI is - again IMHO - a far better inhabitant there. Continue trying ;-)

Walter

[Eddie W. Shore]

Quote:

---

...
Suggestion for a useful and consistent layout:

h [ENTER] = SHOW

h [EEX] = CONST (yes, it will fit)

h [ . ] = Pi

This would also free g [EXIT] for LastX, maybe only as a shortcut for RCL L so that virtually no RAM is required.

What do you think?

Also take a look at the good old 34C. ;-)

Dieter

---

I like this idea.

Eddie

[Alexander Oestert]

If suggestions are still welcome: put ALL, FIX, SCI and ENG in an h-shifted catalog on the D-key and thus free up three h-shifted locations.

[Walter B]

Quote:

---

put ALL, FIX, SCI and ENG in an h-shifted catalog on the D-key and thus free up three h-shifted locations.

---

OK, if I'd do this we'll gain three empty h-shifted locations. So what do you want to put there (a) fitting in that environment (b) better than the removed functions do? If you suggest something, please do it completely instead of only half ;-)

[Mike Mancini]

Hi all, long time lurker, first time poster and recent WP 34s user.

I'd strongly recommend rethinking the colors selected, especially for the f and h labels. They don't appear to provide nearly enough contrast for a anyone with moderate to severe dichromacy (e.g. red-green or blue-yellow). Going darker with the f key (to more of an burnt orange) and lighter with the h key (to more of a mint) would be one fix. Granted, I'm going off the picture and not the overlay and things change on paper vs. screen, but I think it's important to bring up the accessibility concerns now since there's talk of changing the layout.

[Walter B]

Please check the colors on the overlay. It's significantly less brilliant than the emulator skin. If the problem persists, please return. TIA

Walter

[Gene Wright]

are only in X.FCN ?

[Walter B]

No, Sir. They are distributed to X.FCN, P.FCN, and TEST. You can check this most easily employing the emulator 8-)

[Gene Wright]

Ah, I had found M-DET and M-INV in X.FCN, but I guess my concern is that they are in one or three :-) menus, rather than in a MATRIX menu itself. They are also out of the internal menu, it appears.

Hmm... think I'm leaning for option 2.

Another thought... although it would not be needed for stack exchange operations, T<> _ _ would be a useful function to put into the X.FCN catalog.

T exchange with X, Y or Z can be effected by doing the reverse exchange, but T exchange with a data memory cannot.

How about that as an addition to the X.FCN catalog? T<> ?

[Walter B]

Quote:

---

How about that as an addition to the X.FCN catalog? T<> ?

---

That can be done easily :-) though I doubt this function will see much use (z<> and even y<> as well). YMMV

Edited: 14 Oct 2011, 5:19 p.m.

[Marcus von Cube, Germany]

It's in P.FCN. :-)

[Gene Wright]

Rats!

[Dieter]

Quote:

---

I doubt this function will see much use (z<> and even y<> as well

---

That's my impression either. But it's very useful for programming. Just like any other advanced stack manipulation command. So the f- and g-shifted [X<>Y] key is free for two other commands that are more useful for manual calculations. I am sure we will find some. ;-)

Please don't let us get trapped by the idea that the primary target is a layout that looks nice, and therefore Y<> and Z<> should get assigned to the X<>Y key since all these go so well with each other and all these exchange functions on the same key look so nice. We are talking about a tool here, and it should support the user with a well balanced set of keyboard functions. The question whether a function should be accessible on the keyboard or by browsing a menu should not be answered by design aspects but by usefulness instead.

Dieter

[Paul Dale]

Quote:

---

Ah, I had found M-DET and M-INV in X.FCN, but I guess my concern is that they are in one or three :-) menus, rather than in a MATRIX menu itself. They are also out of the internal menu, it appears.

---

Something that hasn't been mentioned about the MATRIX catalogue. All the matrix commands start M-, so navigating this catalogue will require you to enter these two before the first possible distinguishing character. i.e. a standalone MATRIX catalogue will be more difficult to navigate to commands in than it currently is.

Quote:

---

Another thought... although it would not be needed for stack exchange operations, T<> _ _ would be a useful function to put into the X.FCN catalog.

---

:-) Way ahead here. I can add A<> B<> C<> and D<> for forty more bytes. I think we at the point of diminishing returns by then so I didn't bother.

From much of the discussions here, it seems most people are stuck on the four level stack.

- Pauli

[Walter B]

Quote:

---

it seems most people are stuck on the four level stack.

---

As expected, it takes a conservative audience a long time to get accustomed to innovations ;-/ But I'm happy (and content) we did this step towards eight stack levels. Now let time go by ... :-)

Edited: 15 Oct 2011, 2:30 a.m.

[Marcus von Cube, Germany]

Do we have the chance of a generic register exchange and/or register move command? It would need some tuning in the input logic to input two addresses. To squeeze it into a single op-code is another treat. Maybe not worth the hassle...

[Paul Dale]

It cannott be squeezed into a single opcode.
We might be able to do one in a double length op-code -- actually there would be plenty of space for it.

The input logic would be a problem. Especially given the zero free bytes.

There are a whole suite of double register commands that could be useful. Arithmetic STO, conditional tests .... Sadly, no space in the 34S for these.

- Pauli

[fhub]

Quote:

---

From much of the discussions here, it seems most people are stuck on the four level stack.

---

And just because of this the STOS/RCLS A would have been quite useful commands.

I really don't understand why you've removed them again and again, when OTOH you've put in lots of other stack commands (like all those new swaps). :-(

Franz

Edited: 15 Oct 2011, 5:31 a.m.

[Marcus von Cube, Germany]

At the moment they would not fit. I have to find some more flash space before I can start with my next idea, a return stack only limited by memory. :-)

[Paul Dale]

Which we've not yet agreed to :-)

- Pauli

[Walter B]

At the bottom line so far, it's nine in favour of option 2, zero for option 1, one for an unchanged layout. Votes of ourselves are not counted. Meanwhile, however, two new stack commands were placed below of x<>y, so there is a layout change anyway now.

[Cristian Arezzini]

Quote:

---

Votes of ourselves are not counted.

---

If you mean that your preferences don't count, I can't see why. If anything, I think your opinions would be more qualified and "educated", given your involvement, than those of regular users...

Cristian

[Paul Dale]

We had a split decision on these changes.

Our opinion still count of course :-)

- Pauli

[Marcus von Cube, Germany]

The sample size is very small compared to the population size. The latter should best be known to Eric who can tell to how many different people he has sold overlays. We might assume that only people which are interested in an updated layout post here. "Never believe in a statistic which you haven't forged yourself!".

[Eric Rechlin]

I've sold about 230 of them, and the average person bought 2 of them, so there are probably around 110-120 people in the population.

Eric

[Marcus von Cube, Germany]

Thanks for the numbers. Now how to weigh their silent votes?

[Gene Wright]

;-) lol

[Egan Ford]

Quote:

---

Thanks for the numbers. Now how to weigh their silent votes?

---

That's easy. No change.

[Walter B]

Too late. That train is gone ;-)

And BTW, who doesn't vote must not complain about the results.

[Egan Ford]

Quote:

---

And BTW, who doesn't vote must not complain about the results.

---

Must not?

Given the volume of discussion, objections, and complaints in this thread regarding the current proposals, I surmise that your must not directive will be undoubtedly ignored.

I predict that most that didn't vote will keep their current layout and firmware, or perhaps upgrade to the latest firmware that supports the old layout. And less than half will actually get a new 30b for a new overlay or get patches from Eric.

IMHO, there are a lot of great suggestions, even from the 34S development team, that are getting ignored. Expect objections, suggestions, criticisms, and yes complaints.

[Walter B]

That was a translation of a German saying "Wer nicht zur Wahl geht, darf sich hinterher nicht über das Ergebnis beschweren." Nevertheless, I know people will complain always for any reason whatsoever. But the receiver of such complaints may think (and say): "Well, folks, you didn't vote, so ..."

[Ángel Martin]

I'm sure I'm not the best qualified to comment on German-to-English translations, but in my experience DÜRFEN and MÜSSEN are widely misused by non-native speakers when moving between both languanges.

For me it works better to associate DÜRFEN to "being allowed to", and MÜSSEN to "can" - in contexts like the one used here. Not only it's more polite, but also it doesn't sound so harsh and regimented, I mean saying you "musn't" do something has lots of connotations beyond not being allowed to.

Cheers,
ÁM.

[Jeff O.]

Okay, I vote for no change beyond the already implemented y<> and z<> commands on the x<>y key.

[Gene Wright]

My reason for voting for #2 was to put the MATRIX catalog on the keyboard.

[Marcus von Cube, Germany]

This looks nicer than it actually is. If you put all matrix command in one catalog, tests and all, it's harder to find a function therein. All commands start with M- (or M., we are in a discussion about the nomenclature). To navigate, say to M-DET, you have to press 7 (for M), f, ., and finally D, to get there. This is true for the current arrangement, too, but the number of matrix commands in each catalog is smaller because they are distributed over TEST, X.FCN and P.FCN.

[Walter B]

It's just a matter of proper naming :-)

[fhub]

Quote:

---

It's just a matter of proper naming :-)

---

Or of having other ideas, like the following: ;-)

What if you would fill the input/keyboard buffer automatically with the 2 codes for "M" and "-" (or "." if it's changed again) when the user calls the MATRIX catalog?

Then his first 'real' keypress would bring him already to the desired function.

Franz

[Eric Rechlin]

What if you change the search algorithm?

In other words, if you press a letter, but no command starts with that letter, instead jump to the first command with that letter at the earliest position in its name.

Eric

[Marcus von Cube, Germany]

What if you press the next character then? Jump to the next command or to the next better match?

[Eric Rechlin]

You could do it like the 50g and have a timeout. If the next character is typed soon (1-2 seconds or so) after the last one, it will use that. Otherwise, treat the next character as starting over.

Eric

[Marcus von Cube, Germany]

That's already there but what will happen upon a timeout? Back to square one or to square three? As long as I can't reliably mark the already selected characters I'll refrain from such an automatism.

It we had a value stored with each command to indicate the first character position to search for we might have a chance to implement such behavior consistently and globally for all catalogs, but I doubt we find the space in our tables. Pauli? Walter?

[Walter B]

KISS. As written above already. But I'm abroad right now.

[Marcus von Cube, Germany]

I was thinking about this but we have no way of telling the user that we have already done part of the navigation for him. This seems a bit too surprising. We cannot properly underline the characters already selected and inverting them is too ugly. (There are more problems to solve here which are of pure technical nature but very hard to overcome: The timeout resetting the pointer to the beginning occurs while the processor is off and is only detected when the next key is pressed. This makes it impossible to reset the navigation cursor at the right time.)

[Paul Dale]

Underline is definitely out. So is inverse. We've tired both and the dot matrix portion of the screen isn't up to it.

Pre-loading the M- like we do for the complex catalogue would be possible but I doubt we've got enough code space left for this.

The old caveat applies: be care what you ask for, you just might get it :-)

- Pauli