I have an Advantage module that appears to be slightly damaged. All of the functions I've tested work as expected, with the exception of the MDET routine. Whenever the determinant of a matrix is computed either from the MATRX programme or by calling MDET directly the matrix whose determinant is being computed is overwritten with garbage. The correct determinant is computed, although immediately recomputing it will result in an incorrect result due to the matrix being overwritten. In particular the diagonal elements are being rewritten with garbage, often involving non-alphanumeric characters. The garbage is not, however, random---the same input matrix is consistently overwritten with the same garbage elements.

My first inclination was to simply write my own programme to compute the determinant of a matrix, call it MDET, and then expect that it would be called in preference to the MDET routine in the module, as per the documentation. Unfortunately while this works for direct invocation (e.g. via [ALPHA]MDET[ALPHA]) this does not work within the MATRX programme. I gather that this means that the MATRX programme is using some sort of direct addressing of the routine that has precedence over a user-written function.

My question is if there is some way to coerce a programme (like MATRX) to use a user-written function in the way I want to.

The ROM-based MATRX program calls MDET via a ROMPTR / XROM call, not by name.

So if you want to override the (obviously faulty) ROM MDET, you may have to write your own MATRX program, and call your MDET from there.

Actually this could be achieved by copying the ROM-based MATRX program to main RAM via COPY,

then replace the MDET call to your own routine, which should have a different name, like MDET1.

The latter insures the correct call is gerenrated, not an XROM call again;-)

HTH

Ray

Like the HP15C, MDET uses a technique called LU Decomposition. The Advantage implementation re-writes some of the elements of the original matrix to save storage space, but that doesn't mean that the code is wrong or the function misbehaves.

Try to execute MINV *twice* on the matrix after the determinant is calculated - this should restore the "original" matrix in its unaltered status.

Quote:

Actually this could be achieved by copying the ROM-based MATRX program to main RAM via COPY, then replace the MDET call to your own routine, which should have a different name, like MDET1.

That makes sense. I was just wondering/hoping if there was some way to instruct the calculator to always prefer one routine over the other. Like if there was a hash table for all the routines defined by connected modules and user programmes that you could overwrite or something like that.

Quote:

Like the HP15C, MDET uses a technique called LU Decomposition. The Advantage implementation re-writes some of the elements of the original matrix to save storage space, but that doesn't mean that the code is wrong or the function misbehaves.

I'm familiar with LU decomposition; I wrote an RPN implementation of Crout's algorithm (shamelessly cribbed/transposed from the FORTRAN from my ancient copy of

*Numerical Recipes*) when I had problems with the builtin function.

But unfortunately the function is definitely misbehaving; it is not overwriting the input matrix with numeric data, it's overwriting the matrix with nonsense. This also causes functions which opaquely call the in-module MDET (e.g. the solver in the MATRX programme) to provide incorrect results.

Quote:

it is not overwriting the input matrix with numeric data, it's overwriting the matrix with nonsense

This is standard behavior, it's done to save storage space.

Try the double inversion and see what results...

Quote:

This is standard behavior, it's done to save storage space.

Try the double inversion and see what results...

Two inversions doesn't give the original matrix after taking the determinant. If I enter a matrix and then invert it twice without taking any other action it works as expected. If the matrix is entered, the determinate computed, and then the matrix is inverted twice then the diagonal elements are all incorrect in an apparently arbitrary (but consistent) way.

And like I said, this also affects functions which (I presume) invoke MDET internally. Working through the examples in the Advantage module documentation, for example, consistently gives incorrect results. It's also easy to determine that the solver is giving incorrect results with trivial cases (a matrix full of zeros, for example).

Thanks for pointing out that the non-numeric data isn't indicative of a fault by itself; I don't have another copy of the module to compare with.

I can't think of anything that could be causing the behaviour I'm seeing in the module apart from some sort of damage to the module itself. I'm using it in a 41-CV, and I've reset the calculator's memory (several times) with power on-backspace. If it was a 15C I might think it was some problem with real/imaginary data entry, but the MATRX programme explicitly queries for this and I presume handles things appropriately (I've just been testing with 2x2 and 3x3 real matrices).

I'd be delighted if this turned out to be some sort of error on my part (since that would be easier to fix than replacing the module or writing a bunch of code to work around the problem), but I can't think of anything it could be.

All I can suggest is trying w/ another module - perhaps you can share your matrix data (which - forgive me for being so basic, but I'm assuming it's invertible and det#0).

Have you tried to reset your HP-41, after doing a backup of course?

There are many occasions for memory contents (main and extended) getting invalid in the HP-41,

so that would be a way to filter out a (rather unlikely) hardware defect.

HTH

Ray

Quote:

All I can suggest is trying w/ another module - perhaps you can share your matrix data (which - forgive me for being so basic, but I'm assuming it's invertible and det#0).

I appreciate the offer, but it's pretty obvious something's wrong somewhere. Given an input matrix of [ [0, 0], [0, 0] ], taking the determinant, then inverting twice gives something like [ [-11.2, 0], [0, 23.7] ].

The first data I noticed this with was the sample problem in the Advantage module documentation---I started looking into it when following the example led to a bogus result. And since then I've just been testing with toy examples (like an all-zero 2x2 matrix) for which mistakes are easy to identify by analysis.

Quote:

Have you tried to reset your HP-41, after doing a backup of course?

I've cleared memory (several times) via power on/backspace. Are you aware of any flags that if set/unset might result in weird module behaviour?

I know that the 41C doesn't have a builtin self-test. Are there any user programmes that do self-testing or diagnostics? I know there's a (rare) module for this, but unfortunately I don't have one.

Quote:

Given an input matrix of [ [0, 0], [0, 0] ], taking the determinant, then inverting twice gives something like [ [-11.2, 0], [0, 23.7] ].

Well, any singular Matrix (with Det=0) will yield the same absurd result since it won't be invertible. That's why I asked before if det#0 as a condition.

It's highly unlikely (albeit of course possible) that there's such an issue in the module, affecting just one function - that's what made me suspicious in the first place.

So I'm not saying there isn't a problem, but definitely the all-zero Matrix won't be a good troubleshooting aid.

Quote:

Well, any singular Matrix (with Det=0) will yield the same absurd result since it won't be invertible. That's why I asked before if det#0 as a condition.

Is this true on a working Advantage module? I would've expected it, like for example the 15C, to `invert' [[0, 0], [0, 0]] to [[10e99, 0], [0, 10e99]] as an artefact of the numerical algorithm used (and the limits of the machine itself). This is what the Advantage module I have gives if the matrix is inverted immediately after entering. Inverting again gives [[10e-99, 0], [0, 10e-99]], again matching the behaviour of the 15C. Attempting to do the same thing following taking the determinant gives the nonsensical result.

In any case it gives a similarly nonsensical result for [[1, 2], [3, 4]]. Specifically, inverting and re-inverting after taking the determinate does not give the original matrix, but rather apparently arbitrary values in the diagonal elements.

Quote:

It's highly unlikely (albeit of course possible) that there's such an issue in the module, affecting just one function - that's what made me suspicious in the first place.

I don't know if it's only in one function; I've only seen problems with one function, but I haven't attempted to manually check every function in the module. It's even possible that there are different errors in, for example, the solver used by MATRX as well as MDET. I was just assuming that the solver called MDET internally and so the problem with MDET explained the spurious results given by the solver.