Determinants of the AM1 matrix



#2

AM1 Matrix

This is one of Valentin's matrices to test accuracy in computing a determinant. We have talked about it before. The exact determinant should be 1. Let's gather a list of results for various NON-exact mode machines, non-TINY ELEMENT flag machines as an article for accuracy.

WP 34S                  0.999997119354            
HP-28S 0.970960198039
HP-15C 1.080204421
HP-35s 1.00282960115
HP-71B 0.97095056196
HP-48G 0.999945522778
Casio FX-9860G Slim 1.0000000369657

Here are some starting values.


#3

TI82stats: 0.9996468043

#4

HP50g (with flags set as stated) gives the same answer as the HP48g.

The TI89 in approx mode gives 0.999718361859.

#5

TI nSpire CX CAS:

0.9997183618585

#6

My shiny 39g+, acquired at HHC 2011, yields 1 exactly for AM1, suggesting that it's running in exact mode.

Does the 39g+ have a non-exact option, or am I stuck with exactness even if I don't want it? The user's guide appears not to discuss the subject.


#7

For the 50g, to not get 1 exactly, not only do you need to turn off exact mode but you also have to set the "retain small element" flag.


#8

The 39g+ appears to be an unflagged calculator.

Changing the (7,7) element of AM1 to 69.0 didn't trick the calculator: the determinant is still 1.


#9

I skimmed through the 39g+ manual; it doesn't seem to have an exact mode.

My best guess is that it may be in fraction mode, so it's rounding 0.999.. to the fraction 1. You should be able to check in the Mode menu, under number format.


#10

HP39GS: 1.0000000000E0 quite instantaneously.

If I get some time, I'll experiment a bit with the sensitivity of the determinant computation to coefficients of the matrix.

Regards

#11

HP-41CX with Advantage ROM: 1.082014365, in just over 14 seconds.

Best,

--- Les

[http://www.lesbell.com.au]


#12

Same result (but of course) but instantaneous on the CL.

Edit: it gave me a good opportunity to put my PMTM method to test, a real breeze inputing all those matrix elements "in a row"

Edited: 1 Oct 2011, 5:15 a.m.

#13

Gene:

I suggest that you should go back and look at all the work that we did with this matrix back in 2005. A good place to start would be with the thread "More Matrix Results on HP and TI Machines" at http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/archv015.cgi?read=72366 . One of the inputs that you will find there is your submission "TI CC-40 beats the HP-71B" which gives the CC-40 result as 1.00282671. The thread also includes the result for the TI-95 and other machines.

Palmer


#14

Thanks, Palmer!

I had already grabbed those results and put them into a spreadsheet to keep up with all of this. The best results on this matrix so far are:

Casio FX-9860G Slim 1.000000036966
WP 34S 0.999997119354

Quite amazed at the FX-9860G.


#15

Hmmm....I'm thinking that these results along with the LBL A + loop, Savage benchmark, 8 queens results, etc could be added to this spreadsheet...

Perhaps you're doing this already?

TomC

#16

Quote:
I had already grabbed those results and put them into a spreadsheet to keep up with all of this.

Why don't you dump those results as an Article in this site?

#17

I will soon! Results so far! The ratio column is the error of the model listed divided by the error of the best model. The 39g+ is not listed because I do not believe it can possibly really return a 1 for a result. Sorry...

Calc	                 Value 	                 Error           	 Ratio of error to best 
Casio FX-9860G Slim 1.00000003696570 0.00000003696570
WP 34S New Pauli firm 1.00000008439107 0.00000008439107 2.28
WP 34S RRM 0.99999711935400 0.00000288064600 77.93
HP-48G 0.99994552277800 0.00005447722200 1,473.72
TI-89 0.99971836185900 0.00028163814100 7,618.90
TI nSpire CX CAS 0.99971836185850 0.00028163814150 7,618.90
TI-86 0.99964680433800 0.00035319566200 9,554.69
TI-82 0.99964680430000 0.00035319570000 9,554.69
TI-83+ 0.99964680400000 0.00035319600000 9,554.70
TI-95 1.00067670842400 0.00067670842400 18,306.39
TI-59 0.99836009871850 0.00163990128150 44,362.78
TI CC-40 Computer 1.00282671000000 0.00282671000000 76,468.46
HP-35s 1.00282960115000 0.00282960115000 76,546.67
HP-28S 0.97096019803900 0.02903980196100 785,587.77
HP-48S 0.97096019803900 0.02903980196100 785,587.77
HP-71B 0.97095056196000 0.02904943804000 785,848.45
HP-15C 1.08020442100000 0.08020442100000 2,169,698.42
HP 41 Advantage ROM 1.08201436500000 0.08201436500000 2,218,661.21
HP-41 Math ROM (1.81476270400000) 2.81476270400000 76,145,256.27

#18

WP 34S New Pauli firm	 1.00000008439107 	 0.00000008439107 	 2.28 
The latest firmware should do better. :-)
#19

Maybe I am missing something but how did you get an answer with a 35S? Are you using Stefan's matrix program?


#20

Actually, I'm not sure. I took that result from the earlier post about this matrix from the forum.


#21

I found it now. Yes, the 35S result is from Stefan's Matrix Multi-Tool Program for the HP-35s.

hope these links work:

link

link

link


#22

Thanks for excavating! I found the oldest thread the most interesting - there are two more matrices to investigate :-)


#23

The 34S gets 1 and 1 for their determinants :-)


- Pauli


#24

Amazing, our baby, isn't it? Thanks for coding :-)

#25

The current 34S result is 1 exactly.
I very much doubt we'll go back to the less accurate version.

This will make all the other errors infinite :-)


- Pauli

Edited: 4 Oct 2011, 5:15 p.m.

#26

Gene:

The next thing that you might want to explore could be the results with AM2 and AM3 which are even more difficult.

Palmer


#27

works out to 1.000 ... to the limits of returned precision.

The internal precision was (according to Pauli):

1.00000000000000000000000004678227405010

Amazing.

However, it did turn out a lock-up error trying to take the inverse of the AM3 matrix, which is being worked on.

Palmer, we need to get you a 34s. Email me!

#28

In case anyone is interested, I've added a matrixtest.wp34s file to the library that contains the AM1, AM2 and AM3 matrices. In each case the 49 elements are stored from register 20 and the determinant is taken. The matrix descriptor for all three is 20.07.


Just assemble and install in the emulator or on the real hardware.


- Pauli


#29

to fix the memory issues with the inverse function?


#30

Quote:
to fix the memory issues with the inverse function?

Not only this!

Now there's a little confusion about the SVN updates:

4 hours ago Pauli made changes to SVN 1683 removing M.LU and re-introducing the matrix-row-operations (there was a new wp34s.op).

Now Marcus has made a new build SVN 1685 where these last changes are NOT valid (i.e. M.LU is back and row-ops not included).

And there should be also a M.DIAG (which is used in the new matrix.wp34s), but it doesn't exist in the current build.

Slowly it's going to be a mess ...

Franz

Edited: 5 Oct 2011, 11:49 a.m.


#31

It was just a missing update (or commit). I'll fix it soon.

SVN had not warned me about the fact that my local copy wasn't up to date. It should be fixed now.

BTW, please never complain about inconsistencies in the SVN builds, just tell us, preferably with an email! SVN is not a release mechanism and you can expect that there are non working build checked in just to keep the team members in sync.


Edited: 5 Oct 2011, 2:03 p.m.


#32

Quote:
BTW, please never complain about inconsistencies in the SVN builds, just tell us, preferably with an email! SVN is not a release mechanism and you can expect that there are non working build checked in just to keep the team members in sync.

Hear, hear! Very well said!

People have to realize that you and Pauli are ~9 timezones apart and SVN is used as the communication tool to pass files around -- as in any distribute development. You are kind enough to let us in on the bleeding edge of the development so the belly-aching and complaining is just not appropriate!

#33

Quote:
BTW, please never complain about inconsistencies in the SVN builds, just tell us, preferably with an email!

Where did I complain? I was just informing!
#34

Wow! Pauli I just got back from my adventure to San Diego and find the matrix stuff in place!! The editor is very cool.

One question about power consumption... I noticed that the RPN indicator was flashing and had to remember that this meant a program was still executing(?). Does this mean that there is a larger power drain while MED is running?

Cheers...

(BTW: Thanks to all who made me feel so welcome in the HHC group. You are a genuinely nice bunch of people!)

Edit: It looks like I may have mis-attributed MED to Pauli when it looks like Marcus created it. Sorry Marcus!! Very cool tool...

Edited: 5 Oct 2011, 2:04 p.m.


#35

MED is mine. :-)

It's RCL that is flashing while a PSE is in progress or while a program is running, not RPN. The power drain is only slightly higher than in deep sleep, it should still be well under 1mA.


#36

Hi Marcus,

Correct again! It is RCL that is flashing.

(Looks like I got an edit in just a minute before you corrected me on the author :-)

#37

It is interesting not to believe the result provided by HP39g or gs.
Just do the experiment. On my 39gs I have checked the display: scientific with 11 figures and even tested det(AM1)-1 to see possible hidden value. In any case, The result is exactly 1.
I'm probably missing something. Please give me your light ;-)

Regards


#38

Something like this, perhaps?


#39

Yes, perhaps. I have worked with the 39g+ and 39gs and simply have no reason to think they have a better way to handle numbers like this than the 49g+ or 50g have / had.

I'm not disputing it returns a 1, but perhaps it always does things that are flag selectable on the 50g - such as the tiny element flag and noting that the matrix had integers so the determinant must be an integer.

That's cheating. :-) At least from an accuracy perspective. After all, the actual result might work out to be 48.4802 and it rounds it to 48 because of such things. An integer, yes, but still wrong because the math inside was so bad.


#40

As Crawl wrote on the other thread, change the first element of AM1 to 58.1 and see what happens. The correct answer is 9636025.5. This should bypass the everything is an integer check.


- Pauli


#41

Checking HP39gs with 58.1 gives det=9636025.49994, not that bad ;-)

Regards

#42

The 34S might get an accuracy boost if I ever get time to finish the matrix code. All the new row operations will be performed in higher precision with correct rounding.

Unfortunately, I don't think there is enough RAM to unpack the matrix and do a LU decomposition completely at the higher precision. I'll have a think though.


- Pauli


#43

Not regarding any pivoting, an LU decomposition should be doable in place so RAM isn't an issue here. Adding pivoting might get tricky because you need the information about row or column swaps somewhere. Maybe in a condensed format in a register (using binary)?


#44

I know that an LU decomposition can be done in place (if you don't mind overwriting the matrix itself) and the code I've written can do this. However, I was talking about unpacking the matrix registers into the higher precision internal format and doing the decomposition on these instead. The big advantage is greatly increased precision.

I am pretty sure there isn't enough volatile RAM to do this. 3600 bytes would be required just to store the unpacked matrix.

The space for the pivots is small -- ten integers and these can be packed into one register easily. The largest matrix that can be decomposed on the device is 10x10.


- Pauli


#45

3600 bytes for 49 elements? That would amount to 70+ bytes per number, that is one hell of a precision.

Standard quadruple precision is only 16 bytes, delivering about 35 decimal digits of precision.

Why does it take so much memory?

Cheers, Werner


#46

3,600 bytes is for 100 numbers (a 10x10 matrix). They are 36 bytes each in a not well packed decimal format.

The unpacked format I'm using internally is not terribly space efficient three digits in two bytes plus some overhead. All arithmetic is done in this format so any space saving measures will require packing and unpacking to operate on them.


We're running 39 digits internally. Quadruple precision reals are available and they consume 16 bytes and give 34 digits but require packing and unpacking into the internal format I'm already using. I'd rather not pay the flash space cost for these pack/unpack routines for just this function.


- Pauli

#47

WP 34S using the determinant command I just finished coding:

1.000000084391072


This also means I've coded the Doolittle algorithm for the LU decomposition and I should be able to use this for solving equations and find a matrix inverse in place :-)


Assuming this fits into the stack space available on the hardware. If it doesn't the answer will still be the same, but the matrix will be modified (like the 15C does).


- Pauli


#48

Great news! :-)


#49

The higher accuracy of this result should be achievable from a key stroke program by taking advantage of one of the multiply-add sequences available.


- Pauli


#50

That is a great improvement. It has almost caught up with the 9860G result. The three leaders now are:

Calc Value Error Ratio of error to best
Casio FX-9860G Slim 1.00000003696570 0.00000003696570
WP 34S New Pauli firmware 1.00000008439107 0.00000008439107 2.28
WP 34S RRM 0.99999711935400 0.00000288064600 77.93


#51

You missed the highly accurate recoding which returns 1 exactly :-) We're checking if it is going to fit into available RAM or not. One solution here is to not allow 10x10 determinants and inverses -- limit it to 9x9 or 8x8 instead. I'm not too keen on this. What do folks here think about limiting the maximum invertible matrix size?

I'm sure the RRM program can be modified to achieve the same accuracy as the firmware you mention. The multiply-adds need to be recoded using complex multiplication which will take a bit of stack shuffling and a few extra steps.


- Pauli


#52

I can live with 9x9 as well :-)

#53

Actually, the high precision determinant is calculated as 1.00000000000000000000000000000396321014

This rounds to exactly 1 when reduced to the 16 digits stored in registers.


- Pauli


#54

I saw the highly accurate result. Just was not going to update the table until it was in a published flash.

9x9 ought to be good enough for anyone - Bill Gates


#55

Yeah, getting it to fit into RAM looks difficult to impossible. However, I've had an idea which might just work and give only slightly worse results. I'll try to code something up tomorrow and see how it turns out.


- Pauli


#56

I did some coding. The software still supports a 10x10 LU decomposition without disturbing the original matrix but the accuracy isn't the full 39 digits. I had to reduce it to 21 digits to make it fit. We are working on a better solution.

#57

Gene, time to update the 34S's determinant result, we have an image :-)


- Pauli

#58

I managed to get the high precision determinant fitting into RAM and giving a result of 1.00000000000000000000000008048808860320 which rounds to 1 exactly when returned to the stack.

Now to see how much flash this is costing us...


- Pauli

#59

I don't know, probably as soon as you limit the size to 9x9 you'll get users needing support of higher dimensions, even if not such a precise result.

It's a trade-off, but you guys know what you're doing.


#60

It's all set. Pauli managed to do an LU decomposition to 33 digits in available volatile memory for up to 10x10 elements. The trick was using the decimal128 packed format for the data.

More then 10x10 will not be possible with just 100 registers.


#61

There are 34 digits in a decimal128 actually. Instead of the 39 we usually use internally and the 16 in a decimal64 (our register format).

The calculated results are:

full precision:	1.00000000000000000000000000000396321014
decimal128: 1.00000000000000000000000008048808860320
decimal64: 1.000000084391072

The first two round to exactly 1 of course.

The reason there are 39 digits in the decimal128 result is that I'm still doing the accumulations and multiplications using the 39 digit numbers. The 34 digit ones are just for storing the LU decomposition of the matrix as it is being calculated.


- Pauli


#62

I would say even 16 digits (and 39 for the inner products, reminiscent of 'floating-2') is plenty for solving 10x10 systems.

It is better to get an indication that your matrix condition is bad than to get a too-good-to-be-true result...

Cheers, Werner

#63

I've tried the same problem converting the matrix to internal precision and performing all operations at this precision. The determinant calculation gives a result of 1.000000000000000 when rounded back to register precision. Now to see if we can squeeze this version of the code into the hardware constraints -- I'm not confident it is possible.

- Pauli

#64

Very interesting - please take a closer look at this:

Quote:
HP-15C                  1.080204421                   
HP-35s 1.00282960115

The 15C uses its internal 13-digit precision and (supposedly) a state-of-the-art algorithm. Nevertheless, the better result here comes from the 35s which has to rely on the 12 digits available for user programs. Either the 35s matrix algorithm is absolutely great or this result is a positive exception and the 35s is otherwise outperformed by the 15C. What do you think?

Dieter


#65

HP-15C 1.080204421

HP-35s 1.00282960115

TI-59 0.9983600987185

TI-95 1.000676708424

Quote:
The 15C uses its internal 13-digit precision and (supposedly) a state-of-the-art algorithm. Nevertheless, the better result here comes from the 35s which has to rely on the 12 digits available for user programs. Either the 35s matrix algorithm is absolutely great or this result is a positive exception and the 35s is otherwise outperformed by the 15C. What do you think?

The TI-59 and TI-95 both use 13 digit precision but the TI-59 truncates rather than rounds to the 13th digit. In addition, the TI-59 has the multiplication anomaly. But, both machines beat the HP-15C result. Kahan's "Mathematics Written in Sand" paper gave yhe following illustration of the capability of the HP-15C:
Quote:
... For example, let E be a multiple of the notorious Hilbert matrix E(i,j) = 360360/(i+j-1) for 1<= i,j <= 8. The constant 360360 ensures that every element of E is an integer, hence exact, and 8x8 is as large a matrix as fits in the calculator. In under 90 seconds it gets the inverse of E correct to roughly three sig. dec., three more than are expected ... ... This extra accuracy is no accident with ill-conditioned matries like E, prone to systemic concellation, but is due to the extra-precise accumulation of scalar products to 13 sig. dec. during matrix operations.

My recollection (I will have to search for the results) is that the ML-02 program in the TI-59 Master Library module returns an inverse which is correct to approximately five significant digits. What do you think of that?


#66

The condition number for AM1 is about 9e10, meaning you stand to lose 11 digits and thus can't trust your result at all on a 10-digit calculator.

Depending on the algorithm used, however, you might get lucky.

LU-factorisation can be performed resulting in either a unit lower triangular matrix L or a unit upper triangular matrix U. The 42S does the former. If you calculate the determinant of AM1 on a 42S, you get:

    0.970960198039
By no means an exceptional result, seeing that it uses 12 digits and accumulates dot products with the 15 digit internal precision. It indeed loses 11 digits in the process.
Now calculate the determinant of TRANS(AM1), which amounts to simulating the L*unitU factorisation:
    0.999403205613
All of a sudden, we have a result that is 2 digits better.
That's what happened in the 15C as well, I gather. It uses 10-digit arithmetic with 13-digit inner products, but uses a different order of operations. Anyone willing to calculate DET(TRANS(AM1)) on a 15C and post the results?

Cheers, Werner


Possibly Related Threads...
Thread Author Replies Views Last Post
  AFTER HP-Prime update, Shift+Matrix CRASHES Joseph Ec 3 709 12-06-2013, 11:06 AM
Last Post: Joseph Ec
  HP Prime Matrix TERRIBLE bug and question uklo 19 1,885 11-25-2013, 12:10 PM
Last Post: Mic
  HP Prime: editing a matrix Alberto Candel 6 738 11-20-2013, 06:26 PM
Last Post: Helge Gabert
  Absolute Value and Matrix BruceTTT 5 731 11-11-2013, 11:52 PM
Last Post: Walter B
  WP-34S Matrix operations with routine-local registers? Tom Grydeland 1 411 09-04-2013, 10:46 AM
Last Post: Marcus von Cube, Germany
  Matrix Characteristic Polynomial - Reloaded. Ángel Martin 12 1,073 08-22-2013, 05:33 PM
Last Post: Thomas Klemm
  Matrix Richard Berler 3 475 08-18-2013, 06:24 PM
Last Post: Paul Dale
  Advantage/CCD Matrix Challenge Ángel Martin 1 373 08-09-2013, 06:22 PM
Last Post: Thomas Klemm
  [HP -Prime CAS] List, Matrix, Vector as one Array? CompSystems 0 288 07-26-2013, 05:22 PM
Last Post: CompSystems
  ELO - Domination Matrix Kimberly Thompson 0 278 06-21-2013, 05:34 PM
Last Post: Kimberly Thompson

Forum Jump: