# HP Forums

Full Version: HP-15C Bug with MATRIX 5
You're currently viewing a stripped down version of our content. View the full version with proper formatting.

So I was trying to use ATB to calculate the scalar product of a vector with itself:

## Definition of a 4x1 vector E

Set USER mode to enter the coordinates of the vector E = [1 2 3 4]T:

```4
ENTER
1
DIM E
MATRIX 1
1 STO E
2 STO E
3 STO E
4 STO E
```

## Calculate ETE

We'd expect that to be: 12 + 22 + 32 + 42 = 30.

```RCL MATRIX E
RESULT A
ENTER
MATRIX 5
MATRIX 1
RCL A
```

And we get indeed:
30.0000

## Running as a program

Use CLEAR PRGM to have all the programs removed. WARNING: you may not want to do that!

Now enter the few steps from above:

```001-42,26,11   RESULT A
002-      36   ENTER
003-42,16, 5   MATRIX 5
004-42,16, 1   MATRIX 1
005-u  45 11   RCL A
```

And run the program:

```RCL MATRIX E
RTN
R/S
```

I get an ERROR 11: Improper Matrix Argument. For MATRIX 5 the Appendix A: Error Conditions states as possible reasons:

• the input is a scalar;
• the dimensions are incompatible; or
• the result is one of the arguments.

The funny thing is that the result is there. The stack consists of the following values:

```T:
Z: A       1   1
Y: 30.0000
X: 30.0000
```

But the program stopped at this line:

```003-42,16, 5   MATRIX 5
```

## Workaround

A simple workaround is to add a RTN statement at the end of the program. Or you can single-step through the program as well.

Now is this a well known bug of the HP-15C? Could somebody verify this on a real calculator and possibly on the HP-15C LE? Unfortunately I can only test this with an emulator.

Kind regards

Thomas

PS: You think I should use MATRIX 8 followed by x2 instead?

Edited: 3 Feb 2012, 11:44 a.m.

1. Same thing on the LE.

2. But the problem is not with Matrix 5. It blows up on Matriz 5 simply because you're trying to use it with the number "30", and not with a matrix descriptor.

3. The problem is (and I don't understand what is going on) that the program tries to do a second loop (which is simultaneously why Matrix 5 is being fed the "30" - and thereby screaming for help with the Error 11 - , and why the RTN instruction solves the problem).

4. Why you would need an explicit return is what bothers me. Being the only program in memory, the RTN should be automatic; the program should return to address 000 and halt, not go for another ride at the merry-go-round.

:-(

Paulo

Edited: 3 Feb 2012, 12:36 p.m.

Thanks to your comment I understand better what's happening. But still I think it is somehow related the MATRIX operations. Because it never occurred to me in simple programs like:

```001-      36   ENTER
002-      40   +
```

I'm just leaving the above statement, but I guess the real problem is the RCL A command in USER mode.

Since the dimension of A is 1x1 it jumps over the next step. But this is missing so it starts from scratch at line 000. This is what I consider the bug. Or is it a feature?

With the following program you get an endless-loop:

```001-45,16,11   RCL MATRIX A
002-42,16, 1   MATRIX 1
003-u  45 11   RCL A
```

This appears to happen with ISG as well:

```001-42, 6,25   ISG I
```

Thomas

Edited: 3 Feb 2012, 2:06 p.m.

Yeah. It seems that, by some reason it stops the implicit RTN function.
When you plug in an explicit RTN instruction, everything works ok, right?
I have no clue as to the "why".

Quote:
Since the dimension of A is 1x1 it jumps over the next step

It makes no sense. You're being far too nice and/or forgiving. RCL A (after Matrix 1), is supposed to simply return the element 1,1 of A. Not jump, move, skip, or even think :-)

You may have found a bug on the original 15C firmware, and that would be something.
It seems to be either that, or that I'm just deeper into Alzheimer than I thought :-)

Cheers
Paulo

Quote:
RCL A (after Matrix 1), is supposed to simply return the element 1,1 of A. Not jump, move, skip, or even think :-)

There's a subtle difference between:

```003u   45 11   RCL A
```

and

```003-   45 11   RCL A
```

The first is entered in USER mode while the latter isn't. The first does some very cool magic:

• auto-increments registers R0 and R1
• skips the next instruction if the end of the matrix is reached

This makes looping through the elements of a matrix very easy. Say you want to square each element:

```MATRIX 1
LBL 0
RCL A
x2
u STO A
GTO 0
```

Thomas

Edited: 3 Feb 2012, 3:00 p.m.

Quote:
This appears to happen with ISG as well.

This seems to be a general issue with conditional jumps on the last line of the program. You may try this with MATRIX 7 (row norm) and MATRIX 8 (Fobenius norm) as well. Just make sure you have a number in the X-Register. And unsurprisingly it's the same with DSE, F?, x=0, ...

So this might be the shortest loop-test:

```001-      40   +
002-   43 20   x=0
```

Just fill the stack with 1s and hit the R/S key.

Thomas

Edited: 3 Feb 2012, 3:20 p.m.

In user mode, the increment of R0/R1, thus pointing to the next element is supposed to happen (when reaching the end of a matrix, R0/R1 return to 1,1, in readiness for the next matrix). But the mentioned skipping of the next instruction when the end of a matrix is reached and the instruction is being executed from within a program is, AFAIK, not a feature.

Best

Paulo

I don't follow you. Conditional jumps are done to either jump the next instruction or not. That is fine and expected. But the point is that RCL A is not a conditional jump instruction, just a RCL (with increment of the indices if in User mode), and that is what makes it awkward. Why should it jump over the implicit RTN, just because the end of the matrix was reached?

I'm giving up. Maybe someone will explain this. I'll be happy if it happens (and feel stupid, too, but I'm getting used to that ;-) )

Paulo

Edited: 3 Feb 2012, 4:47 p.m.

Best regards

Thomas

Quote:
Conditional jumps are done to either jump the next instruction or not. That is fine and expected.

At least I was not aware that they jump over the implicit RTN instruction at the very end and start again at line 000.

Quote:
I'm giving up. Maybe someone will explain this.

Hopefully the excerpt from the manual above does.

Cheers

Thomas

I feel sssoooo ashamed. Another instance of RTFM, hey?

:-)
Paulo

Edited: 3 Feb 2012, 5:38 p.m.

Quote:

Have a nice weekend!

We had a hard time to get the automatic return on the last step right. It was causing so much grief that I was happy to get rid of it completely by forcing an END statement as the last step in any program.

Agreed, this was one of the worst bits in the program execution support. Made worse by the introduction of END statements :-(

The current enforced END is a bit confusing to me at times I feel. Single or back step with an empty program from run and you stick at the END, switch to program mode and it swaps between steps 0 and 1. Don't step and you insert after then END making a new program. This has caught me out a few times now.

- Pauli

Quote:
The current enforced END is a bit confusing to me at times I feel.

I know. :-(

But we need it nonetheless. If you switch to program mode now and the program memory is empty (just containing the single END statement) the PC is reset to zero. I may change it to not putting the END into empty program memory and just add it together with the first command entered. But this will cause problems in other areas.

This discussion may look a bit misplaced in this forum because it deals with very specific implementation details of WP 34S. But I believe this helps to understand how much care and thought is needed to get things right for the user.

This happens also on the HP11C and HP16C, and even on a HP-34C. I believe this is also the same some many pre-HP41C machines - without END statement.

You may add the HP-12C to the list. It appears if you manage to make the conditional statement the last one and avoid the GTO 00 statements that are otherwise added at the end. Just include a few dummy statements until you have a multiple of 8.

It doesn't occur in earlier models I checked and not in subsequent models like the HP-32Sii , HP-20S or the HP-35S as well.

Cheers

Thomas

Wow! The 15C has two known bugs now :-)
It only took 30+ years to find and identify.

- Pauli