34s - stack lift with PI compared to 15c - difference - anyone else able to repeat this?



#2

Try this:

4 ENTER 3 ENTER 2 ENTER PI

On the 15c, you can press Roll Down and see 2, 3, 4, then PI again.

On the 34s, when I press roll down at this point, I see 2, 2, 3, then PI.

Should this keystroke sequence load the stack in the same way?

Or, what have I missed here? :-)

Edited: 14 July 2011, 11:22 a.m. after one or more responses were posted


#3

I don't have a machine handy at the moment (or the emulator) but if it is acting as described I personally think that this is a bug. ENTER should disable stack lift. This should act the same as entering: 4 E^ 3 E^ 2 E^ 3.14159...

Cheers

#4

I just loaded the emulator on my laptop and was able to reproduce this. I see exactly the same thing as Gene.

Cheers.


#5

Pauli has to look into this.

#6

It is the same when you insert constants from the constants menu instead of PI.

A short test with on the 35S works like the 15C, even with constants.

Hubert


#7

I agree that it's a bug. We have to wait until Pauli is back. He's in the middle of the night at the moment.

EDIT: It should be fixed now.


Edited: 14 July 2011, 3:36 p.m.

#8

Quote:
It is the same when you insert constants from the constants menu instead of PI.

And not only with constants - also recalling a value from any register with RCL xx behaves the same way.

Franz

#9

Entering the same as you, Gene, on my 30b I get 2, 2, 3, 4, 0, 0, 0, pi ;-) Same story with constants. It's definitively a bug. Thanks for reporting d:-)

Walter


#10

I had a look at it and it's hopefully fixed now. I changed both the constants and the RCL cases. I hope I got it without breaking anything.


#11

Quote:
I had a look at it and it's hopefully fixed now. I changed both the constants and the RCL cases. I hope I got it without breaking anything.

Unfortunately nothing has changed with the new SVN 1214, neither constants nor RCL work different than in the previous version.

#12

You're right, my testing was incomplete.

Can you try again, please?


#13

Quote:
Can you try again, please?

Yes, now it's ok - at least all conditions that I've tested! ;-)

#14

The problem with my latest fix is that now some functions which are supposed to enable stack lift will no longer do it. Pauli will have to investigate this.


#15

Quote:
The problem with my latest fix is that now some functions which are supposed to enable stack lift will no longer do it. Pauli will have to investigate this.

Nun, war sowieso "zu früh gefreut" as we say in German. :-(

Constants (from the menu with [h][CONST]) are still making a stack lift - I've overlooked to test this because I've not needed any constants so far (except PI, but this one works).
#16

I think I've fixed this one but due to the pervasiveness of the stack lift, it is going to need a lot of testing.

PS: nobody mentioned that complex RCL and complex constants caused problems as well. Do folks even know these commands exist?


- Pauli


#17

Maybe it turned out already real is so complex nobody dares using complex ;-)

#18

Quote:
PS: nobody mentioned that complex RCL and complex constants caused problems as well. Do folks even know these commands exist?

Complex contants? Are there any in the catalog? ;-)

But why worry about such useless things when I can't even get to work usual things: :-(

No matter what I try, the functions Cx,y and Px,y always return "Domain error"!?

Of course I'm not in any special integer mode (so it should be DECM I guess), but I don't get it ...


#19

Bug introduced as part of the y-hat fix. Will be fixed soon.

- Pauli

#20

The stack lift again - it's amazing how we take certain things for granted, and how detailed our code must be to play along them. I also had a few glitches with the 41Z in this department, so I can understand this dilemma.


#21

Things would be simplier without being able to disable stack lift. We've got a separate command line so it ought to be possible to do without it. That wouldn't be old calculator friendly however.


- Pauli


#22

Hi,
I know we're up to version 1228 now, but last night I loaded version 1220 and now every time I press the multiply key, I get a "Domain Error". Also, I may have missed something a couple of weeks ago, but single-stepping a program seems to have changed. In the past, I would press down arrow and see the step just executed along with the result in X; and now I see the step about to be executed but in X is the result of the last step. This is very misleading to me and was much more intuitive before (and I would say the original way was much more like our other HP machines).

Thanks,
Jake


#23

Quote:
...and now every time I press the multiply key, I get a "Domain Error".

Yes, the 4 basic operations +-*/ have been removed, because they can easily be done in the head! ;-)

But seriously again, duadic ops were broken for a few SVN versions, but are now working again.

The SVN is currently changing faster than you can download: today suddenly Zeta and Bernoulli were removed, then I went outdoor smoking 2 cigarettes and when I returned they have come back again. But now STOM/RCLM suddenly disappeared (2 quite useful function IMHO).

Franz


Edited: 15 July 2011, 9:37 a.m. after one or more responses were posted


#24

Quote:
The SVN is currently changing faster than you can download...

I think if the trinity are willing to let us peek in at the SVN development stage, we should be patient when things go adrift for a day or two.

Doing engieering for a living, I certainly wouldn't want my customer to have the kind of access that these guys have granted us!

You can always look at the SVN logs and back off a few revisions if you want. That is what this tool is designed for.

How about we report problems and then give them a wee bit of space to crack them. The thinnly veiled sniping is not a positive feedback for anyone.

Then again, maybe I have misiunderstood you. If so, I apologize.


#25

Quote:
Doing engieering for a living,...

Yeah, I do engineering for a living, too (since 1976). But when there is a posting that something has been addressed, that usually means we should take a crack at it to see how it is (which is what I did).

I am still puzzled about the single-stepping programs issue. Does anyone remember whether this change was supposedly a "feature"? It is counter-intuitive for me.

Jake


#26

Quote:
Yeah, I do engineering for a living, too (since 1976).

Do I get to call you an old timer if I *only* started in '80? :-)

Quote:
But when there is a posting that something has been addressed, that usually means we should take a crack at it to see how it is (which is what I did).

I didn't actually think I was quote you. I saw nothing untoward in your entry. Others however....

But I was not whining about the feedback -- far from it. The feedback is essential to assisting in the verification effort. These guys are overloaded as it is.

I am asking that the unhelpful, negative comments be toned back. We can point out issues without tearing at them -- I am thinking of "death by a thousand paper cuts"...

I guess I have said my piece (or is the "peace" pun more approprite in this case :-).

#27

You are very good at detecting what we are currently discussing internally. The main issue is flash space. Both STOM/RCLM and Zeta/Bernoulli are large functions in terms of code space. I just need some headroom to debug the serial I/O stuff. If that's done, we'll be putting back what will fit.

STOM/RCLM are useful, I agree, but the implementation is not at a level we want it to be. They will probably reappear in new clothes soon.


#28

Quote:
The main issue is flash space. Both STOM/RCLM and Zeta/Bernoulli are large functions in terms of code space.

Well, from earlier experience(s) I know that MY ideas have never been very welcome here, but nevertheless I dare to suggest one further idea:

I'm really curious who would ever need (or use) this 'strange' STATUS display (of flags and labels)!? Maybe I just don't get it, but I see no useful purpose for flags at all in manual calculator mode. For programming flags are of course very useful, but what would I need them for when I do manual calculations?

And so I'm wondering what this "flags display" with STATUS is in fact good for (it's a nice 'Gimmick' but not more).

Now I'm sure this 'feature' need a lot of programming bytes too, so maybe you should think about removing THIS feature instead of storing and recalling a complete calculator status (or mode). And furthermore this would also free one key which could be used for any other purpose.

Just my 2 (Euro) cents, ;-)

Franz

#29

STOM/RCLM use about 600 bytes which is way too large for what they do. In addition, they only returned a fraction of the calculator's user settable state so they weren't fulfilling their defined purpose. Things that aren't included (in no particular order and I've likely missed some):

  • Fraction maximum denominator
  • Fraction denominator mode
  • Proper or improper fractions?
  • Fractions mode
  • Integer or real mode?
  • Integer base
  • Leading zeros in integer mode
  • Integer word size
  • Thousands separator?
  • Julian to Gregorian calendar change over date

There are about as many settings that weren't included as were. The choice as to what was included seems rather odd to me. We included the radix mark but not the thousands separator. Integer sign mode but not word size or base. Basically, this is a mess.

Some history: these two commands were originally introduced to allow the trig mode to be saved, changed and restored from a program. We no longer need this functionality with the suite of conversions based on the current trig mode. Want a right angle in the current mode "90 DEG->". Want to display your result in radians "->RAD". There is no pressing need for a program to change the trig mode now.


The extras sort of crept in. We are thinking about these two and how to implement them using a lot less space and more fully. As usual suggestions are welcome. However, any suggestion to go back to what was there is a waste of everyone's time...what was there is broken and needs to be fixed.


A question, has anybody actually used these commands in a program? I tried a couple of times and they were more pain than they were worth. I do admit that I was coding for XROM which has special requirements and limitations. Has anyone else used them or tried to use them for something serious? Trying them to see the result doesn't count :-)


- Pauli


#30

I can imagine it's quite useful to be able to format a number for display or Alpha append without overwriting the users preferences for the main numeric display. So saving and restoring the display settings seems worthwhile.


#31

And nowhere have I said that these two commands aren't coming back. Just that they are too big for what they do and they don't actually do what they ought.

- Pauli


Edited: 16 July 2011, 4:27 a.m.

#32

Quote:
This is very misleading to me and was much more intuitive before (and I would say the original way was much more like our other HP machines).

I can't win. I was given a hard time over the "dubious" SST behaviour of showing the step just executed. I changed to what was asked for which was to show the next step to execute. Now I'm getting a hard time over the new behaviour.

Either way is easy to implement, neither takes noticeably more space than the other. What should we do here? I prefer the old.


- Pauli


#33

Showing the next step that will be executed AND the result of the step just finished but not shown seems to be a recipe for all sorts of confusion, IMO. :-)


#34

SST is a key where "show what will happen" and "NULL" makes perfect sense but then I'll have to implement key up detection.

Edit: This will break the autorepeat feature. :-(

Edited: 16 July 2011, 3:16 a.m.


#35

I wouldn't bother NULLing out SST. If you don't have a clue what your program is going to do next then you should switch to program mode and look and if you are too lazy to do that you probably shouldn't be programming.


Like I said, I'm happy to implement this either way. So far 100% of the votes are to show what was executed rather than what will be. Where have those vocal few who wanted the change I wonder?


- Pauli

#36

Quote:
I can't win. I was given a hard time over the "dubious" SST behaviour of showing the step just executed.

Hi Pauli,

First, let me say that you have been doing a fantastic job with this completely voluntary endeavor....your commitment to the project has been amazing.

Secondly, the SST function showing the step just executed in conjunction with the resulting X register shouldn't be considered "dubious", since that is how every HP RPN calculator works up to this point. Please hear me out as to why it should be this way.

First off, it has been made clear that the flash space is just about exhausted and adding things in at this point means possibly sacrificing existing things in return, which is probably a bad thing. The way it is now (with it showing the step not-yet-executed) has a serious problem when the step (call it step "n") just executed has been either GTO, XEQ or a test function (like "x=y?"). In these cases, the machine displays program step "n+1", which in the case of GTO or XEQ is the incorrect program step shown - it should be the destination label of the branch. In the case of a test instruction, the display always shows step n+1, which is only executed if the test evaluates to true. If the test fails, the step displayed is skipped.....again, very misleading. If it was returned back to the original way of displaying the step just executed, you would see the GTO, XEQ or test correctly, followed by the correct next step, whatever that is. I would bet that changing the logic with the existing situation so it showed the correct next step on GTO or XEQ would be fairly complex and would require eating up more precious flash space which isn't available. Plus, I don't think there is a logical solution at all for test instructions, in that the machine might not yet know what the next step will be, especially if the user moved the program counter (via GTO while out of program mode) to the test instruction and pressed the down-arrow in order to do an "SST" from there.

I hope this all makes sense and will justify returning to the "HP way".

Thanks for reading,
Jake


#37

Very well pointed out. Even if Pauli has taken account of some of the points you mention, chances are high he has missed some so it's much better to return to the way it was before the change.


#38

I hope so. The behavior desired would probably be best to be the same as previous HP calculators.

Press SST, see the step about to be executed, and then see the result.

On the 34s, it will be:

Press SST, top line shows the step just executed, and the result is shown on the bottom line.

#39

I hadn't considered these cases, they would be easy to handle -- display to step after it executes when the program counter is updated.

It looks like we'll be heading back to the old way since nobody has voiced any support for the current method even though some people requested the change!


- Pauli


#40

The SST display has been reverted.

It will be available next build (post 1231).

- Pauli

Edited: 16 July 2011, 9:17 p.m.


#41

Quote:
The SST display has been reverted.

Thank you very much....it is greatly appreciated.

Jake


Possibly Related Threads…
Thread Author Replies Views Last Post
  HP35s Program Four Slings Lift Calculation Jean-Marc Biram (Australia) 2 2,295 12-16-2013, 07:21 PM
Last Post: Jean-Marc Biram (Australia)
  [OT] Mathematica free for Raspberry PI BruceH 32 8,527 11-23-2013, 05:24 AM
Last Post: Nick_S
  HP 50g - select characters on the stack, copy/paste Sean Freeman 7 2,800 11-20-2013, 07:11 AM
Last Post: Sean Freeman
  Prime: Placing more than 1 item on the RPN stack in a single program? John Colvin 4 2,336 11-19-2013, 08:59 AM
Last Post: Miguel Toro
  Computing pi with the PC-1300S Kiyoshi Akima 0 1,151 11-17-2013, 12:24 AM
Last Post: Kiyoshi Akima
  emu48 - copy stack doesn't work (as expected) Thomas Radtke 2 2,020 11-11-2013, 02:19 PM
Last Post: Thomas Radtke
  HP Prime Stack operations from within a program John Colvin 1 1,435 11-08-2013, 09:45 PM
Last Post: Helge Gabert
  HP Prime Programming Tutorial #3: WHILE, INPUT, KILL, REPEAT, GETKEY Eddie W. Shore 5 2,509 11-07-2013, 12:25 AM
Last Post: Han
  HP Prime Collect/Factor difference bluesun08 3 1,571 10-29-2013, 09:36 AM
Last Post: Eddie W. Shore
  Prime: Anyway to refresh stack? kris223 5 2,213 10-16-2013, 05:09 PM
Last Post: kris223

Forum Jump: