wp34s INC s function



#20

I apologize in advance if this question has been asked and answered previously. I did read the fine manual, and attempted to search the archives, but could not find the answer. The question is, is it intentional behavior that register L is not updated when applying the INC function to the value in the stack X register. In other words, this happens:

Keystroke	X display
1 1
ENTER 1
2 2
+ 3
INC X 4
RCL L 2 (equals the “2” used in the plus operation above, which was not the last value in X)

Instead of this:

Keystroke	X display
1 1
ENTER 1
2 2
+ 3
INC X 4
RCL L 3 (equals the “3”, which was the last value in X prior to the INC X function)

Thanks.


...


#21

If I'd document it the way it works (i.e. not loading L), it would be a feature ;-) After all, LASTx is primarily for error recovery IMHO, so not loading L in INC doesn't hurt, it's just not documented. Or is there any *need* for loading L here?


#22

Well, I "needed" it when I determined that it did not operate that way :-)

LASTx’s primary use may be error recovery, but seeing as how functions like RCL+L, RCL-L, X<>L, etc. are allowed, it is also useful for general data manipulation. So should INC X, which is after all a function that could be called “X+1”, load L just like any* other function operating on X?

* - I did not do an exhaustive search to determine if there are any other situations where something is done to the value in X that does not load L.


...

#23

One of these days I intended to use INC X in a program, but I quit because it didn't update the L register. I shifted to the HP-42S instead and used NOT, even though this is equivalent to 1 + +/- (for integers in the valid range). I think both DEC and INC should update the L register, but only when they act on X, if this is not difficult to implement.


#24

What does the 41C/42S do with "STO+ ST X" and the LastX register?

This is the same case.


- Pauli


#25

I see your point. Fortunately on the HP-42S we have "RCL+ST X", which behaves differently regarding the LastX register :-)

Gerson.


#26

On the 34S RCL register arithmetic sets L appropriately too :-) This makes sense since X is always changes. For STO arithmetic (and INC and DEC), X isn't always changed so L is left alone. There is some logic here :-)


- Pauli


#27

I see your points. Probably a trivial issue, one that will never impact me again. I just wanted to make sure it was intentional.

In this case, I was to trying create x(x+1) without disturbing the stack by the following steps:

INC X

RCLxL

But the following does the job:

X^2

RCL+L


...

Edited: 3 Oct 2012, 7:40 a.m.

#28

To add to Pauli's comment, what about INC->nn where nn contains 100? Updating LastX would be dependent on the data, not only on the command alone. Looks like a Pandoara's box to me which should be better left unopened.

#29

This behaviour is intentional. Likewise for DEC. The only register it might make sense for is X and if we did it then, we'd have an exception which is bad. Better for these to just not touch L unless it is their argument.


- Pauli


#30

Quote:
This behaviour is intentional. Likewise for DEC...

Than it should be stated in section "last x behaviour" if one exists. Similar to stack lift/disable characteristic of different functions. Intuitively I would think DEC would load L with X.

#31

Quote:

Than it should be stated in section "last x behaviour" if one exists. Similar to stack lift/disable characteristic of different functions. Intuitively I would think DEC would load L with X.


There isn't such a section yet, but it may change ;-) OTOH, stack lift should be documented completely.

#32

We should also get sections for carry and overflow in integer mode like the 16c manual has.

- Pauli


#33

For carry please see p. 55 :-)


#34

That's seven of the carry altering functions. See the 16c manual page 98 for some more. That is still not a comprehensive list.


- Pauli


#35

Literally copying old manuals is little fun :-( So I may point to that manual instead ...


#36

I find 55 commands that change carry and/or overflow. The 16c manual only lists 16 commands.

      Command           Carry    Overflow            
+ X X
- X X
times X
/ X zero
LCM X
X^2 X
X^3 X
+/- X
ABS X
DBL[times] zero
DBL/ X zero
DBLmod zero
DBLrmdr zero
SL X
SR X
ASR X
RR X
RL X
RRC X
RLC X
SQRT X
y^x X X
LG2 X
2^x X X
LOG X
10^x X
(-1)^x X
FIB X
RECV1 X
LN X X
E^x X X
CUBERT X X
x! X X
GAMMA X X
LOGXY X X
COMB X X
PERM X X
XROOT X X
INC X X
DEC X X
ISZ X X
DSZ X X
ISG X X
DSE X X
ISE X X
DSL X X
STO+ X X
STO- X X
STO[times] X
STO/ X zero
RCL+ X X
RCL- X X
RCL[times] X
RCL/ X zero

- Pauli


Edited: 4 Oct 2012, 5:41 a.m.

#37

I certainly wouldn't argue about such a minor point but my SandMath's INCX and DECX functions do store X in L.

If you consider Inc() and Dec() to be -trivial- functions then x is their argument.

However DSE/ISG ST X do not save it, so that's supporting your approach.

Either way is good, a consistent implementation is better... but "consistency is in the eye of the beholder"

Cheers,
'AM


#38

Remember the 34S's INC and DEC take a register argument and increment or decrement that. In fact, the share code with DSE/ISG/DSZ/iSZ/DSL/ISE.

If we'd implemented an explicit INCX/DECX, it would have saved X into L.


Additionally, my experience with INC/DEC supports the don't touch L viewpoint. I've written plenty of programs where leaving L intact was a benefit. Of course, most programs really don't care either way.


- Pauli


Possibly Related Threads...
Thread Author Replies Views Last Post
  HP50g: Writing a function that returns a function Chris de Castro 2 711 12-10-2013, 06:49 PM
Last Post: Han
  [WP34s] RSD function Dieter 11 1,173 01-29-2013, 08:58 AM
Last Post: Walter B
  [WP34s] Parallel function Dieter 25 2,073 11-05-2012, 04:04 PM
Last Post: Marcus von Cube, Germany
  [WP34S] WP34S firmware on the AT91SAM7L-STK dev kit? jerome ibanes 1 426 10-04-2012, 04:59 PM
Last Post: Paul Dale
  WP34S Fibonacci function wildpig 3 499 09-02-2012, 02:25 AM
Last Post: Walter B
  [WP34S] LocRm allocation function missing? Chris Tvergard 10 1,017 05-14-2012, 10:14 AM
Last Post: Chris Tvergard
  [WP34S] Curious Bug in Inverse Normal Function Les Wright 61 3,300 05-01-2012, 02:44 AM
Last Post: Paul Dale
  [wp34s] Incomplete Gamma on the wp34s Les Wright 18 1,668 12-06-2011, 11:07 AM
Last Post: Namir
  [wp34s] Romberg Integration on the wp34s Les Wright 2 538 12-04-2011, 10:49 PM
Last Post: Les Wright
  Stopwatch function implemented on WP34s pascal_meheut 18 1,489 10-29-2011, 06:37 AM
Last Post: Marcus von Cube, Germany

Forum Jump: