WP 34S: Another poll about single letter labels



#2

We've had a recent discussion about the single letter labels available in the 34S firmware. The original set of labels included only the four letters A to D. We recently expanded this set to a somewhat random looking set of A, B, C, D, G, H, I, J, K, L, P, T, W, Y, Z. The restrictions are mainly forced by how the keyboard works for alpha entry. Letters on keys which have a meaning when answering a label prompt are missing from the list. X is missing because it conflicts with GTO.nnn, a direct command to navigate program memory.

We have three options:

1.) Go back to A to D for the sake of a clean interface. Remove the other labels.

2.) Leave it as it is now. Not very consistent but working and of some use as long as we don't have a user keyboard.

3.) Expand it to all letters of the alphabet. This would be a consistent approach. It's easy to implement on the external assembler tool but it would need a redesign of the handling of the input on a label prompt. I would vote for giving GTO.nnn a new home and using LBL .X (X being any letter) in cases where the key in question would otherwise be interpreted as a digit or ->. The dot would be optional in the unambiguous cases.

My own favorite is option three. We'd like to hear your opinions.


#3

We need to fill in the context here about the cleanness and consistency of the layout and loss thereof with the extras.

There was also a fourth option that Walter suggested which hasn't got a mention.

And my suggestion of arithmetic labels for the four operator keys which was only commented on by one person outside the development team.

I'm not going to comment on the third since that is elsewhere in the forums and it doesn't seem all that sensible. I'll let Walter comment on the first two.


- Pauli


#4

Quote:
And my suggestion of arithmetic labels for the four operator keys which was only commented on by one person outside the development team.

Well, that was me! ;-)

And my main point was: why display "LBL +" instead of "LBL Z" in program mode, when the keystrokes are exactly the same?

This "LBL +" is looking really ugly (something like redefining the addition operator), and what would be the next consistent step? Labels with names like "LBL x<>y", "LBL +/-" or "LBL Rv"?

Now to Marcus' poll: I also prefer his 3rd solution.

Maybe the GTO.nnn could be changed to GTO[^]nnn and GTO[v]nnn where [^] and [v] are the up/down-arrowkeys (if they don't already have any other meaning after GTO).

Franz

#5

Please understand this as a complete layman's viewpoint ;)

Couldn't this problem

Quote:
Letters on keys which have a meaning when answering a label prompt are missing from the list.

be overcome by preceding the letter key with any combination of f, g and h (that is different from any otherwise meaningful combination) if it's meant to be a single letter label and thereby making the whole alphabet available?


#6

Quote:
Couldn't this problem

...

be overcome by preceding the letter key with any combination of f, g and h (that is different from any otherwise meaningful combination) if it's meant to be a single letter label and thereby making the whole alphabet available?


Well, that would need at least 2 additional keystrokes (e.g. [f][g]X) preceding the letter key, so there's no difference to just enter the alpha-mode (with [ENTER]X[ENTER]).

And it would make it a bit complicated in other situations when you've pressed the wrong prefix for a function: then you couldn't just fix this by pressing the other (correct) prefix.

Franz

Edited: 4 Aug 2011, 5:51 a.m.

#7

Quote:
Couldn't this problem ... be overcome by preceding the letter key with any combination of f, g and h (that is different from any otherwise meaningful combination) if it's meant to be a single letter label and thereby making the whole alphabet available?

At the moment these keys do nothing in label entry mode so they are free.

As for GTO.nnn and GTO..: The current implementation needs two key strokes for GTO (h+XEQ) plus the dot plus the address while h+dot do nothing while not in alpha mode. We could either make the prefix h redundant for GTO. (XEQ. does nothing now) or the key GTO so just h+. does the trick. We will lose quick jumps in alpha mode but these are a bad idea anyway because alpha mode would still be active at the new position. The h+. solution would free the dot as a prefix for short labels.

#8

I also prefer the third proposal, but when I started to use the 34S I was pleased to find that the GTO.nnn and GTO.. are supported and work as on vintage HP calculators, so I would be disappointed to loose them.

What about using the up arrow [^] (or down arrow [v]) as suggested by Franz, but to access the single letter labels? Such as [GTO][^][X] for GTO X.

Edited: 4 Aug 2011, 6:14 a.m.

#9

There isn't much point voting at the moment. There is information explaining the situation that hasn't been given.

Any votes at the moment are made from a position of ignorance.

Patience.


- Pauli

#10

I really don't like option 3. It breaks consistency of the layout and doesn't really save much. LBL . X vs LBL ENTER X ENTER. The latter keeping consistency, allowing shifted characters (more labels) and extra characters (many more labels). The former confusingly allowing the . to be omitted for some keys but not others -- most people would end up always putting the . in I suspect.

The second and third options break our layout consistency in several ways which haven't been mentioned publicly. Walter can and likely will put this better than I will but I'll try...


Currently, all commands with a single alpha argument are special.

Alpha flag operations change how the device operates (or turn an annunicator on or off). They are not freely changeable like the numeric flags, they have side effects. Thus, these are special.

Alpha registers all have system defined purposes that make them not general purpose registers. Thus, these too are special. That we let users use the ones they don't otherwise require as general purpose registers is simply a bonus.

Alpha labels are our hot keys. In this way they are different to and distinct from numeric labels. Thus, these are also special.

See the trend here? Introducing these shortcut alpha labels completely breaks this internal consistency. Some labels are now general purpose, some aren't. Both Walter and myself dislike this and I'm usually the one pushing for weird and wonderful extra features and getting beaten down.

The keyboard and entry engines are very consistent currently and this makes them easy to use. I believe that this is the main reason why people are finding that the 34S is nice and easy after the initial shock of the very cluttered keyboard. Once you get the hang of things, everything is where you expect and logically arranged. I really would like to maintain this.


Adding the extra labels leaves new (and even experienced) users in a bind. Is this one special or not? Do I need the . prefix or not. We've already had one query about why no X label and that from somebody who is quite familiar with the device. Marcus thought this important enough to explicitly spell out in the description above. None of this is good.


There is another far more minor issue to do with indirect access. The numeric positions of the lettered registers vs the flags and labels don't match up currently and these proposals make things much worse. This is quite minor however.


Even Walter's alternative suggestion (which is for some of the additional letters to be usable as labels) grates with me. I'll let Walter put this forward if he so desires.


- Pauli


#11

Would it be possible to add another error message "No solution", or isn't there any space for it anymore?

Would be nice for the SLV command when it fails ... :-)


#12

Quote:
Would be nice for the SLV command when it fails ... :-)

BTW, I just found that the SLV command in manual mode (i.e. not running in a program!) just returns a nonsense result when the equation has no solution (I've tried it with x^2+1).

So if you use SLV manually in calculator mode you don't see if the returned value is in fact a solution, or just a temporary value of the solving process when it fails.

That's not really nice - maybe any error message (like my "no solution" above, or at least a "false") could be displayed in this case!?

Edited: 4 Aug 2011, 11:56 a.m.

#13

Yeah, this is worthwhile...

The solver does return the function evaluation so you can check easily but a message would be better.


- Pauli


#14

Quote:
The solver does return the function evaluation so you can check easily but a message would be better.

Hi Pauli,

I see in the SVN that you're working on error messages - I hope you don't forget to implement also one for SLV.

At least a "false" if it fails (as all other tests display,too) ...

Franz


#15

Error or step jump from solve is a lot harder than it looks :-(

I'm not really working on error messages, just streamlining things.


- Pauli


#16

Quote:
Error or step jump from solve is a lot harder than it looks :-(

Hmmm? I don't understand!?

I had a short look at the SLV routine in xrom.c and I see there a few EXITp1. Aren't these exactly the places where the solver fails and thus makes a RTN+1?

So why not just add here a command to display "false" (only in manual mode, not for a running program)?

Or do you want to say that SLV isn't working correctly (i.e. skipping the next instruction on fail) in program mode, too?

Franz


#17

Of course those are the places. The problem isn't where to put the change but what the change needs to be.

The suggestion of a command that displays false if not run from a program isn't the answer -- the solver code is a running program. It is indistinguishable from a user program.

The problem boils down to solve doesn't know where it came from.


I've no idea what you're getting at with your last question. Solve must skip a step in the calling program if it doesn't converge. This is not negotiable.


Displaying "false" on failure in run mode isn't ideal either although it matches other conditional tests. An error is more appropriate and matches older devices' solver better.


I'm still thinking about this one, it hasn't been forgotten.


- Pauli


#18

Quote:
The problem boils down to solve doesn't know where it came from.

Ok, not knowing one's origin is of course always bad. ;-)

I just don't understand this problem in comparision with all other test functions (like SF?, x=0? etc.). Why do these functions 'know' if they have been called from within a program or directly from a user input, but SLV does _not_?


Edited: 8 Aug 2011, 6:22 a.m. after one or more responses were posted


#19

Solve is ***not*** a conditional test from the firmware's point of view. It is a user program. This should be clear enough from looking at the xrom dump.

The RTN+1 command is faking a conditional test. No more no less.


- Pauli


#20

Quote:
Solve is ***not*** a conditional test from the firmware's point of view. It is a user program.

Ok, but: although I don't know the complete 34s structure, but shouldn't there at least be a 'higher-level' routine (the parser) which would (or should) know whether the state is "program running" or "user mode" when it 'sees' a SLV command? And so this 'parser' could set any internal flag (running yes/no) before it calls the SLV routine?

But maybe I'm completely wrong with my understanding of this internal flow ...


#21

That would require some RAM to store the flag.

RAM is full.

Completely full.

Doing it this way would work but it would also mean losing something else.


That said, I think I've got a solution which I'm in the process of testing.


- Pauli


#22

Quote:
That would require some RAM to store the flag.

RAM is full.

Completely full.


Oh my god, not even a few bytes left? Poor WP34s! :-(

Maybe you should work on a RAM extender ... ;-)


#23

Nope, not a byte of battery backed RAM left (which is where this must live).

I think there is one bit left in the user mode settings word which isn't useable here.

There are a few bits free in the LCD bitmap memory but they don't survive the lower power modes and thus can't be used in the solver.


We've really pushed the hardware to the limit :-)

- Pauli

#24

Quote:
That said, I think I've got a solution which I'm in the process of testing.

Well, looking at your recent changes (TST_TOP, TOP? and isTop) - isn't this exactly the way I've suggested?

Of course I don't have your internal knowledge of your code, so I can't say exactly what to put in where and which commands have to be added in detail, but what you have done know is just what I meant: testing whether SLV is called from within a program or by the user (TOP).

So not everything someone else suggests is just nonsense - but it seems to be hard to admit this ... for some people ... ;-)


#25

No it isn't anything like any of your suggestions.

Your suggestions in order were:

  • So why not just add here a command to display "false" -- there is no command to display false. The new error message isn't sufficient by itself.

  • I just don't understand this problem in comparision with all other test functions (like SF?, x=0? etc.). -- solve still isn't a conditional test and cannot be made into a real one.

  • And so this 'parser' could set any internal flag (running yes/no) before it calls the SLV routine? -- no such flag exists.

You did get the location of the changes correct and I'd already said they were the spots.


Quote:
testing whether SLV is called from within a program or by the user (TOP).

You never wrote this anywhere.

I can't read minds here let along halfway around the world.

That said, this is the obvious path to the solution, the difficulty is detecting this state. Checking for an empty return stack hasn't been mentioned before this.

Quote:
So not everything someone else suggests is just nonsense - but it seems to be hard to admit this ... for some people ... ;-)

I think you need a chip removed from your shoulder.

- Pauli

Edited: 8 Aug 2011, 7:46 a.m.


#26

Quote:
No it isn't anything like any of your suggestions.

Your suggestions in order were:
...


bla bla bla ...

All that has nothing to do with the problem and its solution in principle.
Quote:
Quote: testing whether SLV is called from within a program or by the user (TOP).

You never wrote this anywhere.


Well, then look at message #19 above.

But I give up, it's just useless to discuss with a stubborn and complacent guy like you.

Cheers,

Franz

Edited: 8 Aug 2011, 8:09 a.m.


#27

Franz, don't give up!

We are working on a solution. When we're done, SLV will behave like a conditional test, hopefully. :-)

BTW, I've worked hard on the keyboard handler. This saves us space in flash but needs thorough testing. The latest version in SVN contains the changes. Please report back any findings! Try the catalogues and all keyboard commands.


#28

Quote:
Franz, don't give up!

Well Marcus, I don't give up the WP34s project (zumindest NOCH nicht), but I give up talking to and discussing with Pauli because his arrogance is just annoying me!

I made a suggestion for this SLV problem, he answered "impossible!" and then, just a few minutes later, he implemented it almost the same way as I had described it. And finally he even denies that my idea had anything to do with 'his' solution - that's simply incredible!

But ok, let's forget it and talk about your latest changes to 34s:

Although for the user there's no difference now in accessing these additional XEQ shortcuts, in my opinion this internal change from e.g. LBL G to LBL 21 is no good idea.

Why? Well, I would say that these number labels LBL 00-99 are mostly used for subroutines but it's usually not indended that a user calls such a subroutine directly with XEQ 00-99.

But as it is now the chance is quite high that a user might press any of these 'shortcut' keys after XEQ by mistake, and so this would run the corresponding subroutine.

My consequence from this new 'feature'(?) is, that it's the best to avoid using in programs any of these labels with keycode-numbers(with the exception of course that exactly this key would be wanted as a shortcut key).

Well, just my opinion of course, but this change is probably a source of confusions and mistakes in future programs.

Franz

#29

Franz,

mal unabhängig von dem gegenwärtigen Fall, den man offensichtlich unterschiedlich wahrnehmen kann: Deine dauernden Ankündigungen erscheinen mir langsam etwas albern. Könnte es vielleicht sein, dass du *auch* etwas schwierig bist? Ich bin übrigens ebenfalls nicht ganz einfach, versuche aber nicht jedes Mal jemanden in die Pfanne zu hauen (nur manchmal) ;-)

(For our unilingual friends: I took the opportunity to talk German to Franz - in the good ol' meaning of "mit dem hab' ich mal deutsch gered't". No idea whether Google is able to translate this correctly.)

Back on topic: I think the task is clear to everyone, and any suggestion may foster the progress of the project. Often innovations are triggered by dialogues though its different participants may not always understand each other correctly - the abilities in clairvoyance are simply not equally distributed on this planet ;-)

FWIW

Walter

#30

Pauli has explained most of the reasons already why we prefer option 1 over 2 and 3. The only thing I want to add is: Perhaps the easiest way to get an idea what's the point is looking to the manual, page 18. And remember you are using a calculator which will not change its physical surface entering temporary alpha mode (see page 9 showing only a virtual change).

So I'd recommend reading at least page 18 thoroughly. Thereafter (!), if there will be anything you'll be missing still, please tell me.

Walter


#31

Quote:
So I'd recommend reading at least page 18 thoroughly. Thereafter (!), if there will be anything you'll be missing still, please tell me.

Well Walter, I still don't understand what's the (or your) problem with option 2 (keeping the current state).

Ok, it may be a bit inconsistent, but that happens with other things too (think of STO/RCL with Z and T, which also is handled differently than e.g. X and Y).

The current use of extended labels (option 2) is working already (so it needs no additional programming), it definitely requires less keystrokes for those additional label than having to use them with [ENTER], and if someone doesn't like this - well, nobody is forced to use this shorter way.

Franz


#32

Well Franz, the current state is option 1 8-)


#33

It's just a conditional compile and I'm not happy with Pauli's decision to silently disable it. I'm still more with Franz then with Walter and Pauli. Option two is a pragmatic approach. I'm a pragmatic person.

The problem with *not* having one of option 2 or 3 or a variant thereof is that we just lose functionality which cannot be replicated with the remaining features. Let me explain. If we tell users to stick to pure alpha labels instead at the expense of having to press one or two additional keys, they will still lose an important aspect of the short labels, their locality. If you want to have more than one application making use of let's say a variable named I or a function to add two objects, this will not be possible without distinctive names for the operations because alpha labels are global and the search order is independent of the current state of the program counter.


Possibly Related Threads…
Thread Author Replies Views Last Post
  [WP-34S] Unfortunate key damage with update to V3 :( svisvanatha 5 3,296 12-10-2013, 11:37 PM
Last Post: Les Bell
  WP-34S (Emulator Program Load/Save) Barry Mead 1 1,869 12-09-2013, 05:29 PM
Last Post: Marcus von Cube, Germany
  DIY HP 30b WP 34s serial flash/programming cable Richard Wahl 2 2,603 12-04-2013, 11:14 AM
Last Post: Barry Mead
  Prime: Placing more than 1 item on the RPN stack in a single program? John Colvin 4 2,331 11-19-2013, 08:59 AM
Last Post: Miguel Toro
  WP 34S/43 ?'s Richard Berler 3 2,126 11-10-2013, 02:27 AM
Last Post: Walter B
  My FrankenCulator (wp-34s) FORTIN Pascal 4 2,246 11-09-2013, 06:18 PM
Last Post: FORTIN Pascal
  WP 34S Owner's Handbook Walter B 5 2,752 11-09-2013, 05:34 PM
Last Post: Harald
  wp 34s overlay and programming. FORTIN Pascal 6 2,985 11-08-2013, 01:28 PM
Last Post: Nick_S
  m.dy in display of WP-34S Harold A Climer 3 2,001 11-05-2013, 11:28 AM
Last Post: Andrew Nikitin
  WP 34s : An old problem coming back Miguel Toro 2 1,800 11-05-2013, 03:00 AM
Last Post: Marcus von Cube, Germany

Forum Jump: