WP34s feature question



#2

Hi,

I can remember that the HP-41 had a special flag (22) which was set when the user had just input anything. This was quite useful in programs: entering a number and then pressing one of the upper-row label keys could e.g. just store this value, but pressing such a label without having entered anything before could calculate this value (almost all TVM calculators behave exactly like this for the usual 5 function keys N I PV PMT FV).

Is there something like this in the WP34s? I've read through the manual but couldn't find anything.

This could also be useful when a running program stops/prompts for an user input, so that it could decide after a R/S whether anything had in fact been entered or not.

Franz

Edited: 25 June 2011, 6:09 p.m.


#3

Yes there is. Look in the test catalogue for ENTRY?


- Pauli


#4

Yep, that's exactly what I meant, many thanks! :-)

There are soooo many functions that you almost overlook everything you're searching for ... ;-)

Maybe it would be nice if this ENTRY? condition could be manually reset via the EXIT key (e.g. if you enter something but then exit this input again), but it's not very important.

[Edit:] Ok, I've just tried it again and EXIT works except directly when entering a number - here you have to press EXIT twice to reset the ENTRY? condition. Not optimal but ok (if you know it). ;-)

Franz


Edited: 26 June 2011, 8:09 a.m.


#5

There are plenty of ramifications with the entry flag. For example, what if I'm entering two numbers and exit out of the second?

In fact, I might change it so that EXIT doesn't clear this flag.
I'm not sure what is correct or desirable here. This one was added late and hasn't really been thought through completely.


- Pauli


#6

Quote:
In fact, I might change it so that EXIT doesn't clear this flag.

Well, that would even be worse than it is now! :-(

How could you then reset this ENTRY? condition at all?

I guess it will be better to not report any found problem(s) anymore, if after this report you think about changing it in a way that would even worsen the situation ...

Franz


Edited: 27 June 2011, 5:30 a.m.


#7

The entry flag is reset when a program stops running. It is set by numeric or alpha entry. I'm happy with this part of its operation. I'm not sure about how it should behave on EXIT and this hasn't been thought through properly yet.


Please explain how & when you think it should be reset.

You will need to take into account all usage scenarios not just the one you've raised thus far. Things like multiple number entries and cancellations of some and possibly all of those entries. Also consider what happens if I enter a number, press enter to commit it to the stack and then press EXIT. What about entering stuff and performing some arithmetic and functions and then pressing exit and continuing the program. Currently these last two will not register as digit entry although they clearly are. This seems very wrong to me hence my suggestion to change exit to not clear the flag.

Now complicate everything with catalogues and exit.


Finally, we've only a small number of bits of RAM left, so we cannot add lots of state variables.


Anyway, I'm very much looking forward to suggestions here.


- Pauli


#8

Well, at the moment I'm not on the computer where WP43s is running, but IIRC from my yesterdays trials this ENTRY? flag is also reset by almost any other operations (e.g. +, -, *, etc....).

And I have no problem with that at all - the only thing I was wondering is that EXIT during a number input did NOT reset this flag and that I had to press EXIT twice!

I'm quite satisfied with this ENTRY? flag behaviour as it is now (except this need for a double press of EXIT when cancelling a number entry), so there's no need to completely change anything.

But I think there MUST be ANY way to reset this flag, and as long as there's no explicit flag number that can be used with CF, pressing EXIT is probably the best method!

Franz


#9

Quote:
Well, at the moment I'm not on the computer where WP43s is running, but IIRC from my yesterdays trials this ENTRY? flag is also reset by almost any other operations (e.g. +, -, *, etc....).

No it isn't. Almost all operations don't touch this flag. So if the program stops and you press + R/S the flag will be clear. If, however, you press 3 + R/S the flag will be set because you entered a digit.

Another way to clear the flag is to press the up arrow then R/S although this is less obvious.


Like I've said a couple of times now this flag hasn't been thought through properly. What we've got is mostly right most of the time.


- Pauli


#10

Yes, you're right with +, - and so on, I've tried it again now.

All I've tried yesterday was not with a program which prompted for an input (and was continued with R/S), but just with a program with LBL A, and the program should check if there has been an entry immediately before pressing the A button. It should then just store this entry and otherwise calculate something.

And as I already said it's quite ok as it is now: I know that I have to press EXIT twice to reset this ENTRY? flag again when I'm cancelling an input to make the program behave correctly, so there's no need to change anything.

I'm just wondering why e.g. after an input has been finished with ENTER a single EXIT is enough to reset this flag, but during the input you need 2 EXITs for that.

Franz

Edited: 27 June 2011, 7:01 a.m.


#11

Does anyone else have suggestions as to how the entry flag should behave?


Quote:
...but just with a program with LBL A, and the program should check if there has been an entry immediately before pressing the A button. It should then just store this entry and otherwise calculate something.

I don't think it will ever operate like this. When you do something it is impossible to tell that your next operation will be to execute a label. If I could tell this, I'd prefer use such accurate precognition to make a fortune on the stock market or lottery :-) Finish the LBL A subroutine with a R/S instead of a RTN to reset the flag. Pressing A again will have the flag set if the user entered something and cleared if not.


Quote:
I'm just wondering why e.g. after an input has been finished with ENTER a single EXIT is enough to reset this flag, but during the input you need 2 EXITs for that.

File keys.c lines 2077 - 2086. The first EXIT cancels the command line. The second does a warm start. It is the latter that resets this flag.

This is all documented on page 56 of the manual BTW. The 'does nothing' at the end should be 'does a soft reset'. Most of the time there is no noticeable difference however.


- Pauli


#12

Quote:
I don't think it will ever operate like this.

Well, but it DOES operate exactly like this on all financial keys (N,I,PV,PMT,FV) of HP calcs! ;-)

#13

No calculator financial or otherwise works the way you are suggesting. Case in point, my 12c treats any keystroke except one of the TVM keys as a data entry regardless of what it is. e.g. f PREFIX to look at all the digits of the result followed by one of the TVM keys enters a new value rather than calculating. Likewise, g MEM does the same. Neither of these are data entry operations and neither changes the stack nor any other registers. Also worthy of note is that there is no simple way to clear the data entry setting -- which is something you've been asking quite vocally for.

We could operate exactly this way on the 34s, but I'd need input from other people before committing to such a change. One opinion does not a change make (unless it's mine of course ;-)

Since there seems to be a fixation on financial calculators, I'll reiterate: this isn't a financial calculator and never will be. Leave your 20b/30b alone if you want a financial calculator. Better yet buy a spare and leave that alone so you've got both and HP has two sales :-)

- Pauli

Edited: 27 June 2011, 8:03 a.m.


#14

Quote:
One opinion does not a change make (unless it's mine of course ;-)

Yes, that's something I've already got! ;-)

I doubt you'll get much input because this is a rather special 'feature' almost nobody else would ever need. So I would say leave it as it is - I can clear this flag with a double-EXIT from any pending operation or with a single-EXIT when the calculator is in its 'normal' state and that's ok for me.

Since you say that such a (2nd) EXIT does a 'warm start' (???), I hope this won't do any other 'dangerous' (unexpected) things (like e.g. clear all my registers or delete my program) ... ;-)

Franz

Edited: 27 June 2011, 8:28 a.m.


#15

Hallo Franz,

Quote:
Since you say that such a (2nd) EXIT does a 'warm start' (???), I hope this won't do any other 'dangerous' (unexpected) things (like e.g. clear all my registers or delete my program) ... ;-)

As you (should) know, we're in beta test phase now. So feel free to check what's going to happen under whatever conditions you can think of - we did only check the conditions we could think of ;-) And we're pretty patient usually ...

Walter


#16

I've an idea how it should work: Any action that potentially changes the contents of X or Alpha sets the flag. EXIT, be it on digit entry (cancel the command line) or on its own while X is shown, resets the flag. So does CLP.


#17

Quote:
I've an idea how it should work: Any action that potentially changes the contents of X or Alpha sets the flag. EXIT, be it on digit entry (cancel the command line) or on its own while X is shown, resets the flag. So does CLP.

Yes, that's exactly as I would have expected it!

(and of course every STOP or RTN in a program)


Now we have already 2 opinions, so maybe that would make a change now ... ;-)

Edited: 27 June 2011, 12:31 p.m.

#18

I thought about this a fair bit last night while not sleeping.

EXIT to clear this flag is just asking for user error and confusion which we're trying to avoid. E.g. I input a number, go to the conversions catalogue, decide I don't need to change it, pressed EXIT and continue. Result is the flag is set. Change the last bit to press EXIT twice by accident and continue and the result is totally different and unexpected. This flies in the face of extra EXITs doing nothing as documented in the manual.

I'm going to change the behaviour to detect any digit entry as per the 41 series (which is what this flag setting is modeled off, not the financial calculators overloading of the TVM keys) and to only clear this flag on program stop. I think this is the only consistent option. This is far gentler than the financial calculators any key press kills the flag and it captures the meaning of the setting: did you the user press a digit key? Yes you did.

We can argue about whether it should be digit entry or any change in X. We can also argue is a clear entry flag command is required but this should be a manual step and never done automatically & this remains available via up-arrow then R/S.


- Pauli


#19

Quote:
I'm going to change the behaviour to detect any digit entry as per the 41 series and to only clear this flag on program stop.

Ok, do whatever you want! :-(

So this is definitely my last report wrt. the WP34s, if mentioning a little problem leads to a 'solution' (?) that is even worse than it has been before.

Franz


#20

As I asked last night and you pretty much completely ignored, make a consistent and intuitive suggestion as to how this should behave and we'll consider it. Make sure you cover at least the use cases I mentioned -- I know there are plenty more I missed in my haste that will become apparent as you do your analysis.

The current behaviour has major potential for confusion, I do not believe this is acceptable as it stands. Your only suggestion so far has been to make things worse from the confusing point of view.

After my recent change it is consistent and not confusing. Any digit entry sets the flag, program stop clears it. No exceptions and no avoiding it. You press a digit, the flag gets set. Using your baseline of financial calculators, we're already a lot softer in raising this than they are. Show me a financial model that lets you reset the "user pressed a key flag"? How about one that lets you unpress a shift key and not impact this flag? My latest suggestion is more in line with this behaviour, you should be overjoyed by it not condemning it.


Now, if somebody sits down and thinks this through and comes up with a better solution, I'm all ears. We've made quite a few changes based on the input here and I'm sure we will make some more in the future.


- Pauli

PS: It is possible to do the TVM functions without an entry flag, there is a 15c program that does just this by defining the hot key labels twice.

#21

I vote for a slight modification to your scheme. It shouldn't be the typing of a digit entry key but the commit of the input line to X that sets the flag. So you have the option to cancel the command line with EXIT or backspace which will return you to the unmodified stack. If this situation would set the entry flag you are asking for confusion.


#22

Quote:
If this situation would set the entry flag you are asking for confusion.

You typed a digit didn't you? No confusion :-)


You suggestion sounds good however. What should happen if the command line processing produces an error -- set the entry flag or do nothing?


Pauli


#23

The discussion about the command line rises another question that is not only interesting to WP 34S but to all newer RPN calculators that handle an input line.

In the good old days, there was no distinction between the input line and the X register. ENTER is always a DUP which disables stack lift. If you type 1 ENTER 2 + you get 3 because the 2 after ENTER replaces the 1 in X. Typing 1 ENTER + returns 2. We all know this behavior well.

Now to the newer generation. Let's talk about RPL first. There is no concept of disabled stack lift at all. ENTER isn't a DUP anymore, at least not after entry of some data on the input line. It just commits what is there. If it is a number or if it generates one through evaluation, this goes to the stack. ENTER duplicates as DUP if no command line entry is present. This is just a shortcut. Our examples from above now work slightly differently then before. If you type 1 ENTER 2 + you get 3 because + does an implicit evaluation of the input line before it executes. The result is the same as before. Typing 1 ENTER + returns the sum of 1 and whatever is on the next higher stack level. Here things behave differently.

What about more recent RPN (not RPL) calcs? Some testing revealed that most of them (27bii+, 32S, 33S, 35S, 42S) behave the old way. On the last three you have a visible feedback so the behavior is obvious to the user.

The 20b and 30b change the game. Here 1 INPUT + returns 1 if the stack has been cleared before and not 2 as one could expect from an RPN machine. INPUT just commits the input line to X but leaves stack lift enabled. 1 INPUT 1 + behaves as expected. It occurs to me that there is not concept of a disabled stack lift in these calculators at all. 1 INPUT INPUT 2 INPUT leaves 1 in Y, 1 in Z and 2 in X. This is exactly what RPL would do here.

What is your preferred behavior? I start liking the way the 20b and 30b work.


#24

I'm a conservative in this matter: 1 ENTER + equals 2. Period d:-)

Walter


#25

FWIW, I agree about keeping it the old way. People who like RPL style have had the choice of buying a 48 / 49 / 50 or so; but people who stood by years in a yet-unanswered prayer for an HP43S only has the WP34S as choice.

(Please disregard any idiomatic mistake)

#26

Marcus,

If only life were so simple ...

ENTER isn't the only command that plays games with stack lift. Sigma+ is another e.g.

Also, we've got backwards compatibility issues with existing programs, we've tried pretty hard to be able to run many old solution book programs and user library programs as is.


Anyway, I've not really used the 20b and 30b for computations so I don't really know if it is better or not.


- Pauli

#27

Marcus, having grown with the 48 and 50 calculators, I would have loved SO MUCH if the 34s worked the way you describe! Of course I didn't dare suggest it.
In my opinion, this whole "stack lift disabling" thing is confusing. It took me a long time to get used to it, and I think people are comfortable with that system only because they've used it for so long...! :)

Cristian

#28

This has been implemented and will be coming soon the build.

Entering a command line and having it accepted onto the stack sets the entry flag. The flag is only cleared when program execution stops.

The flag is also set if you enter any alpha character even if you backspace over it again or press exit. Can't easily change this one. So I guess we've a small inconsistency :-(

- Pauli

Edited: 28 June 2011, 4:50 a.m.


#29

Any ability to have an ENTRY? and an ENTRY?C command?

They both test for an entry, but the 2nd test also clears the flag. Similar to the FS? 22 and FS?C 22 flags on the HP 41.

?


#30

Quote:
Any ability to have an ENTRY? and an ENTRY?C command?

They both test for an entry, but the 2nd test also clears the flag. Similar to the FS? 22 and FS?C 22 flags on the HP 41.


We could make ?C the default behavior, i. e. clear the flag after it has been tested. If you need the status more than once, use a user flag: CF 1; ENTRY?; SF 1. This would offer a possibility to clear the flag manually by just executing ENTRY?. ENTRY?C will not happen because we have only six characters for the command name.

#31

That would probably work, as I believe a majority of times it will be used to detect input and then branch. Once you have branched, input has of course occurred.

I do think the FS?C behavior was the most common type in HP 41 style programs.

Thoughts from anyone else?

#32

There is no point having ENTRY?C as a command. First up the command name is too long but ignoring that for a moment...

The internal entry flag is cleared when a program stops execution (for whatever reason). The flag is set when a command line is accepted and processed successfully. Typically the user will continue with R/S and the program runs again.

Unless someone can find a use case where a second user entry is made without a program stopping execution a second time, I don't see a need for ENTRY? to clear the internal flag. Two entries at once doesn't count -- the flag doesn't count them only indicates that at least one has been made.

I believe getting a second command line entered is impossible without a program stopping execution a second time.

Does having ENTRY? clearing the flag hurt any use cases? One that I can think of:

    ENTRY?
XEQ ..
ENTRY?
GTO ..

Could be worked around easily enough of course so this doesn't really count in the grand scheme.

- Pauli

PS: and now I see Marcus said half of what I did already...

Edited: 28 June 2011, 5:50 p.m.


#33

Ok, I can buy that.

Kindly ignore my previous requests.

Edited: 28 June 2011, 5:55 p.m.

#34

Hi Pauli:

I don't completely follow this thread but it appears to me that you're saying ENTRY? sets the internal entry flag when the command line is processed successfully and clears when the program halts. Does that mean if a user writes a program with multiple data input requests (each on a separate line) that each time the program halts for data entry the internal entry flag is reset?

A little confused,
Gerry


#35

Yes.

- Pauli

#36

ENTRY? doesn't set a flag, it just checks for it. The flag is set during number entry, that is while the calculator is not executing a program (which is not totally correct if Pauli didn't build in a check for it. We can safely ignore the case because the next program halt will reset the flag.)

The intended logic is as follows:

Running program comes to a STOP -> flag is reset.

User does not enter any numbers or text.

User presses R/S, A~D or XEQ <label>.

ENTRY? will skip the next command because the flag is still reset.

Running program comes to a STOP -> flag is reset.

User does enter some numbers or text.

User presses R/S, A~D or XEQ <label>.

ENTRY? will execute the next command because the flag is set.

The only way to reset the flag is doing a BST and R/S to re-execute the instruction that made the program stop.

In a real world application one might code the following (given the stack is set to 4 levels):

LBL A
ENTRY?
GTO 01
<compute A>
LBL 01
STO A
RTN

This will allow the following use cases:

<number> A or <number> STO A ==> Store parameter A

RCL A ==> control or use the value of A

A ==> compute a new value for A


#37

I think it's fine the way it is, but just for the sake of curiosity... (these are cases of little practical value):

a) What happens if a program enters numeric data and then ENTRY? is tested before a R/S resets the flag?

b) It's clear that the "STOP" operation from a running program (or an interrupting R/S by the user) clears the flag, before the user can ever enter data. Is it the same when debugging a program using SST to run it step-by step?


#38

Try them and tell us the outcomes :-)

I'd guess for a, the flag will be set. For b I've no idea.


- Pauli


#39

Possibly in the weekend... I need to get the "last" version before. I'm some hundreds of revisions (10 days) late... As Walter once said, 34S is a moving target indeed! :-)


#40

I'll spill the beans then, both your queries work properly.

i.e. in a the flag is set by numeric entry inside a running program and in b the flag operates properly even though you are single stepping the code.

Anyway, the point of my response was more to highlight that it would be most helpful if folks checked these kind of "what if" or "waht about" questions out themselves rather than asking. While I don't mind checking these, I'd prefer a bug report. Even better I'd get no report when things already worked :-)


- Pauli

Edited: 30 June 2011, 5:50 p.m.

#41

Quote:
We can argue about whether it should be digit entry or any change in X.

I'd vote for the latter.

Walter

#42

How about a comparison to Flag 22 of the HP 41? The description below comes from A. Thimet's great HP-41CV Quick Reference found here:

HP 41 quick reference

Flag 22 Data Entry Flag. This flag detect keyboard input. The
calculator sets flag 22 when numeric data is entered from the
keyboard. The flag is cleared each time calculator is turned on.

Flag 22 is not automatically cleared, which is why you see many HP 41 programs that right after a PAUSE have a "FS?C 22" instruction.

The ENTRY? right now is more like a FS? 22 instruction, is that correct?

If so, perhaps an ENTRY?C instruction might be a useful addition?

Thanks...

#43

Hi Walter,

I hope you don't have overlooked my report about the 2 errors in the manual (wrong TVM formula and wrong description of STO- and STO/)?

These are in fact errors (not just a matter of taste ;-)), and should of course be fixed.

Franz


#44

Hallo Franz,

Those are fixed already but the update is not uploaded yet. I ask for your patience since I've to add some more items.

Walter


#45

Quote:
Those are fixed already but the update is not uploaded yet. I ask for your patience since I've to add some more items.

No problem Walter, take the time you need, I just wanted to be sure that you haven't overlooked it.

And you know: patience is one of the few good features in the elderly ... ;-)

Franz


Possibly Related Threads...
Thread Author Replies Views Last Post
  Prime feature request Stefan Dröge (Germany) 0 105 11-06-2013, 11:06 AM
Last Post: Stefan Dröge (Germany)
  HP Prime "Notes" feature request Charles Bennett 0 95 09-27-2013, 12:14 PM
Last Post: Charles Bennett
  WP-34s feature suggestion: "Follow jump" shortcut Andrew Nikitin 3 172 06-12-2013, 01:42 AM
Last Post: Walter B
  Simple? programming question [WP34S] Shawn Gibson 3 177 03-15-2013, 11:56 AM
Last Post: Didier Lachieze
  [wp34s] xtal question jerome ibanes 9 320 02-05-2013, 05:35 PM
Last Post: Massimo Gnerucci (Italy)
  [WP34s] Bug or feature? Dieter 25 663 01-03-2013, 06:20 PM
Last Post: Paul Dale
  [WP34S] WP34S firmware on the AT91SAM7L-STK dev kit? jerome ibanes 1 124 10-04-2012, 04:59 PM
Last Post: Paul Dale
  more question regarding complex operations using complex number on wp34s wildpig 22 521 09-02-2012, 12:54 PM
Last Post: Walter B
  Bug HP39GII....or feature? Bunuel66 14 389 08-11-2012, 02:59 PM
Last Post: Gilles Carpentier
  Request for a new WP34S Emulator feature Namir 2 116 08-06-2012, 07:07 AM
Last Post: Neil Hamilton (Ottawa)

Forum Jump: