▼
Posts: 1,545
Threads: 168
Joined: Jul 2005
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 NONexact mode machines, nonTINY ELEMENT flag machines as an article for accuracy.
WP 34S 0.999997119354
HP28S 0.970960198039
HP15C 1.080204421
HP35s 1.00282960115
HP71B 0.97095056196
HP48G 0.999945522778
Casio FX9860G Slim 1.0000000369657
Here are some starting values.
▼
Posts: 59
Threads: 5
Joined: Jul 2011
Posts: 306
Threads: 3
Joined: Sep 2009
HP50g (with flags set as stated) gives the same answer as the HP48g.
The TI89 in approx mode gives 0.999718361859.
Posts: 18
Threads: 1
Joined: Sep 2007
TI nSpire CX CAS:
0.9997183618585
Posts: 167
Threads: 33
Joined: Jul 2011
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 nonexact option, or am I stuck with exactness even if I don't want it? The user's guide appears not to discuss the subject.
▼
Posts: 306
Threads: 3
Joined: Sep 2009
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.
▼
Posts: 167
Threads: 33
Joined: Jul 2011
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.
▼
Posts: 306
Threads: 3
Joined: Sep 2009
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.
▼
Posts: 59
Threads: 5
Joined: Jul 2011
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
Posts: 540
Threads: 22
Joined: Jan 2005
HP41CX with Advantage ROM: 1.082014365, in just over 14 seconds.
Best,
 Les
[http://www.lesbell.com.au]
▼
Posts: 1,253
Threads: 117
Joined: Nov 2005
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.
Posts: 901
Threads: 113
Joined: Jun 2007
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/cgisys/cgiwrap/hpmuseum/archv015.cgi?read=72366 . One of the inputs that you will find there is your submission "TI CC40 beats the HP71B" which gives the CC40 result as 1.00282671. The thread also includes the result for the TI95 and other machines.
Palmer
▼
Posts: 1,545
Threads: 168
Joined: Jul 2005
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 FX9860G Slim 1.000000036966
WP 34S 0.999997119354
Quite amazed at the FX9860G.
▼
Posts: 263
Threads: 42
Joined: Aug 2007
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
Posts: 901
Threads: 113
Joined: Jun 2007
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?
▼
Posts: 1,545
Threads: 168
Joined: Jul 2005
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 FX9860G 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
HP48G 0.99994552277800 0.00005447722200 1,473.72
TI89 0.99971836185900 0.00028163814100 7,618.90
TI nSpire CX CAS 0.99971836185850 0.00028163814150 7,618.90
TI86 0.99964680433800 0.00035319566200 9,554.69
TI82 0.99964680430000 0.00035319570000 9,554.69
TI83+ 0.99964680400000 0.00035319600000 9,554.70
TI95 1.00067670842400 0.00067670842400 18,306.39
TI59 0.99836009871850 0.00163990128150 44,362.78
TI CC40 Computer 1.00282671000000 0.00282671000000 76,468.46
HP35s 1.00282960115000 0.00282960115000 76,546.67
HP28S 0.97096019803900 0.02903980196100 785,587.77
HP48S 0.97096019803900 0.02903980196100 785,587.77
HP71B 0.97095056196000 0.02904943804000 785,848.45
HP15C 1.08020442100000 0.08020442100000 2,169,698.42
HP 41 Advantage ROM 1.08201436500000 0.08201436500000 2,218,661.21
HP41 Math ROM (1.81476270400000) 2.81476270400000 76,145,256.27
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
WP 34S New Pauli firm 1.00000008439107 0.00000008439107 2.28
The latest firmware should do better. :)
Posts: 114
Threads: 3
Joined: Sep 2010
Maybe I am missing something but how did you get an answer with a 35S? Are you using Stefan's matrix program?
▼
Posts: 1,545
Threads: 168
Joined: Jul 2005
Actually, I'm not sure. I took that result from the earlier post about this matrix from the forum.
▼
Posts: 114
Threads: 3
Joined: Sep 2010
I found it now. Yes, the 35S result is from Stefan's Matrix MultiTool Program for the HP35s.
hope these links work:
link
link
link
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
Thanks for excavating! I found the oldest thread the most interesting  there are two more matrices to investigate :)
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
The 34S gets 1 and 1 for their determinants :)
 Pauli
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
Amazing, our baby, isn't it? Thanks for coding :)
Posts: 3,229
Threads: 42
Joined: Jul 2006
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.
Posts: 901
Threads: 113
Joined: Jun 2007
Gene:
The next thing that you might want to explore could be the results with AM2 and AM3 which are even more difficult.
Palmer
▼
Posts: 1,545
Threads: 168
Joined: Jul 2005
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 lockup 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!
Posts: 3,229
Threads: 42
Joined: Jul 2006
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
▼
Posts: 1,545
Threads: 168
Joined: Jul 2005
to fix the memory issues with the inverse function?
▼
Posts: 1,216
Threads: 75
Joined: Jun 2011
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 reintroducing the matrixrowoperations (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 rowops 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.
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
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.
▼
Posts: 255
Threads: 22
Joined: May 2011
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 bellyaching and complaining is just not appropriate!
Posts: 1,216
Threads: 75
Joined: Jun 2011
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!
Posts: 255
Threads: 22
Joined: May 2011
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 misattributed MED to Pauli when it looks like Marcus created it. Sorry Marcus!! Very cool tool...
Edited: 5 Oct 2011, 2:04 p.m.
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
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.
▼
Posts: 255
Threads: 22
Joined: May 2011
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 :)
Posts: 59
Threads: 5
Joined: Jul 2011
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
▼
Posts: 2,761
Threads: 100
Joined: Jul 2005
Something like this, perhaps?
▼
Posts: 1,545
Threads: 168
Joined: Jul 2005
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.
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
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
▼
Posts: 59
Threads: 5
Joined: Jul 2011
Checking HP39gs with 58.1 gives det=9636025.49994, not that bad ;)
Regards
Posts: 3,229
Threads: 42
Joined: Jul 2006
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
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
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)?
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
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
▼
Posts: 163
Threads: 7
Joined: Jul 2007
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
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
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
Posts: 3,229
Threads: 42
Joined: Jul 2006
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
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
The higher accuracy of this result should be achievable from a key stroke program by taking advantage of one of the multiplyadd sequences available.
 Pauli
▼
Posts: 1,545
Threads: 168
Joined: Jul 2005
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 FX9860G 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
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
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 multiplyadds need to be recoded using complex multiplication which will take a bit of stack shuffling and a few extra steps.
 Pauli
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
I can live with 9x9 as well :)
Posts: 3,229
Threads: 42
Joined: Jul 2006
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
▼
Posts: 1,545
Threads: 168
Joined: Jul 2005
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
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
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
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
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.
Posts: 3,229
Threads: 42
Joined: Jul 2006
Gene, time to update the 34S's determinant result, we have an image :)
 Pauli
Posts: 3,229
Threads: 42
Joined: Jul 2006
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
Posts: 1,253
Threads: 117
Joined: Nov 2005
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 tradeoff, but you guys know what you're doing.
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
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.
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
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
▼
Posts: 163
Threads: 7
Joined: Jul 2007
I would say even 16 digits (and 39 for the inner products, reminiscent of 'floating2') is plenty for solving 10x10 systems.
It is better to get an indication that your matrix condition is bad than to get a toogoodtobetrue result...
Cheers, Werner
Posts: 3,229
Threads: 42
Joined: Jul 2006
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
Posts: 653
Threads: 26
Joined: Aug 2010
Very interesting  please take a closer look at this:
Quote:
HP15C 1.080204421
HP35s 1.00282960115
The 15C uses its internal 13digit precision and (supposedly) a stateoftheart 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
▼
Posts: 901
Threads: 113
Joined: Jun 2007
HP15C 1.080204421
HP35s 1.00282960115
TI59 0.9983600987185
TI95 1.000676708424
Quote:
The 15C uses its internal 13digit precision and (supposedly) a stateoftheart 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 TI59 and TI95 both use 13 digit precision but the TI59 truncates rather than rounds to the 13th digit. In addition, the TI59 has the multiplication anomaly. But, both machines beat the HP15C result. Kahan's "Mathematics Written in Sand" paper gave yhe following illustration of the capability of the HP15C:
Quote:
... For example, let E be a multiple of the notorious Hilbert matrix E(i,j) = 360360/(i+j1) 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 illconditioned matries like E, prone to systemic concellation, but is due to the extraprecise accumulation of scalar products to 13 sig. dec. during matrix operations.
My recollection (I will have to search for the results) is that the ML02 program in the TI59 Master Library module returns an inverse which is correct to approximately five significant digits. What do you think of that?
▼
Posts: 163
Threads: 7
Joined: Jul 2007
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 10digit calculator.
Depending on the algorithm used, however, you might get lucky.
LUfactorisation 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 10digit arithmetic with 13digit 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
