HP 50g - Problem with matrix function - REF acting the same as RREF
Stephen
I'm new to the HP 50g, and I'm having a problem with one of the matrix
functions.
When working with matrices, and I try to reduce a matrix to Echelon Form
(using the REF function), what it gives me is a Row-Reduced Echelon Form -
as if I had used the RREF function instead.
Essentially, the REF function is acting like the RREF function - and the
two of them give me identical results when applied to a matrix.
For example, if we try the sample from the User's Guide:
Entering in the following matrix:
1 -2 1 0
2 1 -2 -3
5 -2 1 12
Applying REF is supposed to yield:
1 -2 1 0
0 1 -4/5 -3/5
0 0 1 7
And applying RREF is supposed to yield:
1 0 0 3
0 1 0 5
0 0 1 7
-----------------------------
However, applying REF and RREF both give me:
1 0 0 3
0 1 0 5
0 0 1 7
Am I doing something wrong?
I contacted HP support and they confirmed this is a bug, but some people
seem to indicate that it works fine for them, so I'm not sure who's right.
If it is a bug, are there any programs that supply a properly working REF
function? If I knew anything about programming calculators, I'd write my
own, but I'm new to these, so I'm out of luck for the moment.
John H Meyers
> Essentially, the REF function is acting like the RREF function
> and the two of them give me identical results when applied to a matrix.
Exploring via Nosy:
(note that any PTR nnnnn without \<-symbol is an "unsupported" address)
(~xREF ROMPTR 314 48)
::
CK1&Dispatch
BINT4
FPTR 6 34C=^MATREF
BINT5
::
FPTR 6 17A=^LIST2MATRIX
FPTR 6 34C=^MATREF
;
;
(RREF ROMPTR AB 34)
::
CK1&Dispatch
BINT4
FPTR 6 34B=^MATRREF
;
(^MATREF FPTR 6 34C=6:63BA0)
::
PTR 54808\<-^BESTMATRIXTYPE
PTR 547F4
FPTR 3 4F
BINT0
PTR 63D95\<-^MATREFRREF
SWAPDROP
'
PTR 63B14
PTR 65A7A\<-^VUNARYOP
;
(^MATRREF FPTR 6 34B=6:63AD6)
::
PTR 54808\<-^BESTMATRIXTYPE
PTR 547F4
FPTR 3 4F
BINT1
PTR 63D95\<-^MATREFRREF
SWAPDROP
'
PTR 63B14
PTR 65A7A\<-^VUNARYOP
;
Comment:
Should SWAPDROP have been DROP in ^MATREF ?
[r->] [OFF]
John H Meyers
[ [ 1 -2 1 0 ]
[ 2 1 -2 -3 ]
[ 5 -2 1 12 ] ]
Enter the above in Exact mode, then try:
CASCFG REF (should give expected result!)
But it will give RREF result if input matrix is instead "real."
Various slightly different flags may also result
in such things as "Undefined Local Name"
for REF, RREF, RREFMOD, or rref [lower-case command].
CAS is thus almost as fussy about what it will eat
as a CAT :)
[r->] [OFF]
John H Meyers
"RREF with mixed mode matrix"
http://groups.google.com/group/comp.sys.hp48/msg/61c4b0eb96b9c756
"RREF working, but rref & REF not working?"
http://groups.google.com/group/comp.sys.hp48/browse_thread/thread/7379fb16617f5d1b/
"It's almost as hard to train a CAS as a CAT" :)
[or did we already say that?]
[r->] [OFF]
John H Meyers
> Should SWAPDROP have been DROP in ^MATREF ?
I guess not; the BINT0 vs BINT1 argument
must have told ^MATREFRREF which function to perform.
So, as Emily Litella would say, if she were here:
"Never mind!"
http://en.wikipedia.org/wiki/Emily_Litella
http://www.youtube.com/watch?v=V3FnpaWQJO0
[r->] [OFF]
Stephen
"John H Meyers" <jhme...@nomail.invalid> wrote in message
news:op.ug6y9...@miu.edu...
> On Mon, 08 Sep 2008 07:11:27 -0500, Stephen wrote:
>
> [ [ 1 -2 1 0 ]
> [ 2 1 -2 -3 ]
> [ 5 -2 1 12 ] ]
>
> Enter the above in Exact mode, then try:
>
> CASCFG REF (should give expected result!)
>
> But it will give RREF result if input matrix is instead "real."
>
Thanks, John! I didn't need to reset the CAS, it was just a matter of
entering the matrix in exact mode. Thanks for the help! :)
John H Meyers
> It was just a matter of entering the matrix in exact mode.
It's more than that, as REF (and other related commands)
will sometimes not work even in Exact mode,
though I don't know exactly which flag(s) throw it off.
It appears to be safer to use CASCFG before using the CAS at all.
[r->] [OFF]