▼
Posts: 1,545
Threads: 168
Joined: Jul 2005
It isn't pretty yet and has LOTS of room for optimization (I did not even use recall arithmetic so far ha!) but the translation of the PPC ROM M1 thru M5 routines, the QR, BE and BX routines, and the RRM application program from the PPC ROM manual to run on the 34s works.
I successfully computed the determinant of a 7x7 matrix. Ran FAST.
Problem I have at the moment is my batteries are nearly dead (the program showed BYE! as it quit running).
This program will use memory registers 0 through 9 for internal storage. I started the matrix location at register 10 and up. This means an 8x8 determinant or a 6x6 inverse or 6x6 system of linear equations can be done within the 100 register "limit". It is presently 207 steps, but that will go down with recall arithmetic of course.
Now to do a LOT more testing and cleanup of the code before publishing it. Jake and I will have something soon and if not, perhaps it will be unveiled at the HHC conference in a few weeks.
▼
Posts: 255
Threads: 22
Joined: May 2011
Gene,
Do you think this could be a guinea pig for the symbolic addon to the assembler tool chain? If so, you can send me the code (hopefully with some embedded comments so I can trace it  I haven't worked with a matrix since i graduated 'a while ago') and I will map it to the new format and send it back to you.
The new tool is designed to make things easier to code. Gone are BACK, SKIP, and GTO. Instead you use the single JMP mnemonic with a symbolic label at your target. The tool figures out the rest.
Calling subroutines becomes a bit more obvious as well: "XEQ 04" becomes "XEQ Calculate_Determinat_but_not_on_Thursday".
Both should make maintenance much easier.
Let know if I can help.
Cheers...
▼
Posts: 1,545
Threads: 168
Joined: Jul 2005
Give me an email shout through the forum email or the one you used last time. Let's talk.
▼
Posts: 1,545
Threads: 168
Joined: Jul 2005
Time was right at 2 seconds to do the determinant of this 7x7 matrix.
The true determinant is 1.
The 34s RRM program returns: 0.999997119354
Not bad.
For reference, these were the results for other machines from a thread back in January 2008:
Thread
HP15C 1.080204421
HP71B 0.97095056196
HP28S 0.970960198039
HP35s 1.00282960115
CC40: 1.0028267103..
TI95 1.0006767082..
TI85 0.999646804338
HP48G 0.999945522778
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
Gene, have you considered to use the complex multiply to increase the accuracy of some computations? The intermediate computations in 34S are done at a much higher accuracy then can be achieved with the 16 user visible digits.
▼
Posts: 1,545
Threads: 168
Joined: Jul 2005
No, I have not. This is a first stab at a matrix routine for the 34s. I am merely translating the program and not trying to make it much better. I hope others will be inspired to do that, as it isn't in my quiver of abilities. :)
Posts: 3,229
Threads: 42
Joined: Jul 2006
Looks like the loss is about two thirds of the significant digits. The matrix was chosen well.
Complex multiply might assist here. We could also enable the fused multiply add instruction  although it isn't much easier to use than the multiply. What's really required is a suite of these to handle various stack arrangements.
I'll have a dig though some of the numerical analysis texts I've got to see if there is a "better" algorithm. The Algebraic Eigenvalue Problem or Matrix Computations are probably a good start. Although I'm not sure either covers determinants  somewhat surprisingly they don't seem to be calculated all that often.
 Pauli
▼
Posts: 1,545
Threads: 168
Joined: Jul 2005
Well, I ran the AM1 test because it is a good test.
With the data registers in the 34s, we can "only" do a system of 6x6 or an inverse of a 6x6 system. Determinants can, however, go up to 8x8, so the test was possible.
In reality, I can't imagine (really) anyone today EVER doing something larger than a 6x6 on a handheld. Go find Excel or some PC software package! :)
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
Quote:
In reality, I can't imagine (really) anyone today EVER doing something larger than a 6x6 on a handheld.
I concur, as posted here earlier already.
Posts: 901
Threads: 113
Joined: Jun 2007
Quote:
In reality, I can't imagine (really) anyone today EVER doing something larger than a 6x6 on a handheld. Go find Excel or some PC software package! :)
But doesn't that leave the device less capable than a 15C?
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
My assumption is that the 6x6 limit is imposed by keeping the original matrix together with its inverse. Larger matrices may be processed, given an algorithm that allows inversion inplace.
▼
Posts: 1,545
Threads: 168
Joined: Jul 2005
I hope to present some timing results using AM#1 (a 7x7 matrix) run on the 34s, 41CL at 1X speed, 41CL at 50X speed, and the original 15c soon. Palmer, you remember that matrix because in an earlier thread, you did some analysis on it using even the TI59 ML02 program. :)
The RRM approach on the 34s can compute the determinant of an 8x8 matrix.
This is a limitation only because of the 100 register hard limit on the 34s. The 41C (and 41CL) can handle bigger matrices because you can have up to 319 registers available.
▼
Posts: 901
Threads: 113
Joined: Jun 2007
Quote:
This is a limitation only because of the 100 register hard limit on the 34s. The 41C (and 41CL) can handle bigger matrices because you can have up to 319 registers available.
Marcus must be correct (see the previous post) about keeping the original matrix intact. The TI59, which did NOT keep the original matrix intact and also had only 100 registers could do determinants or inverses for 9x9, and 8th order simultaneous equations. So the obvious question is what's more valuable, keeping the original matrix intact, or solving higher orders?
▼
Posts: 1,545
Threads: 168
Joined: Jul 2005
The RRM program (from the PPC ROM manual) uses the following structure for the matrix:
nxn for the original matrix elements.
another nxn for an identity matrix
and a nx1 column for the coefficients for a system.
So to compute a determinant of a matrix, you just need the square original matrix. The RRM program uses memories 09 so the matrix elements can start in memory 10. Since you have 90 registers free, that means you can do an 9x9 determinant. 10 + 81 < 100.
To invert a matrix, you need nx2n registers. That means you can invert a 6x6. 6x(12) + 10 < 100 but 7(14)+10 is not. No 7x7 inverses.
To solve a system of equations, you need nx(2n+1). A 6x6 would use 6(13)+10 < 100 registers, but a 7x7 system uses too many.
(My math was wrong before  I think you can solve a 9x9 determinant, but only a 6x6 inverse or system.
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
Gene, what's the reason to store a nxn identity matrix? This can certainly be stored more compact.
▼
Posts: 1,216
Threads: 75
Joined: Jun 2011
Quote:
Gene, what's the reason to store a nxn identity matrix? This can certainly be stored more compact.
I don't have the PPCROM manual, but I guess it uses the following method for the inverse:
Transforming the original matrix to an identity matrix (e.g. with Gauss elimination)  applying the same steps to an identity matrix makes this one then the inverse of he original.
But the n*(2n+1) requirement in his statement "To solve a system of equations, you need nx(2n+1)" is something I don't understand (except the routine uses the inverse):
Gauss elimination (even with pivoting) requires no more than n*(n+1), so definitely 9x9 system could be solved.
Franz
▼
Posts: 1,545
Threads: 168
Joined: Jul 2005
Those are the register requirements for the PPC ROM application program RRM.
It always computes the inverse if you are solving a system of linear equations.
Example:
3x3 matrix is stored as:
1 2 3 1 0 0 6
4 5 6 0 1 0 15
7 8 9 0 0 1 24
To do a determinant, you need only the square 3x3 matrix.
To do an inverse, you need the 3x6 matrix.
To solve a system, you need the entire 3x7 matrix.
Again, that is how the RRM program works, which is what has been translated so far.
Seeing as how there has not yet been any other matrix software written for the 34s... ;)
Here's the link to the PPC ROM documentation for the M1 through M5 routines and the RRM application program. When Jake and I were talking about documentation earlier, this is what we were meaning. No real questions here how something works.
PPC ROM Matrix Routines
Edited: 18 Aug 2011, 7:40 a.m.
▼
Posts: 1,216
Threads: 75
Joined: Jun 2011
Quote:
It always computes the inverse if you are solving a system of linear equations.
Yes Gene, that's what I guessed. ;)
Although this needs of course more registers, it also has one advantage: for solving additional equation systems with the same coefficient matrix you can now just use the already computed inverse and don't have to recalculate everything.
Thanks for the manual,
Franz
▼
Posts: 1,545
Threads: 168
Joined: Jul 2005
All I did was translate the great work done 30 years ago by the PPC ROM authors. I am certain improvements can be made for a 34sspecific routine.
Posts: 653
Threads: 26
Joined: Aug 2010
A matrix can be inverted with several methods. One of them simply adds a unit matrix and uses elementary row operations to convert matrix A into its inverse C. Assuming a 3x3 matrix it looks like this.
a11 a12 a13 1 0 0 1 0 0 c11 c12 c13
a21 a22 a23 0 1 0 => 0 1 0 c21 c22 c23
a31 a32 a33 0 0 1 0 0 1 c31 c32 c33
With a bit of tricky programming this algorithm does not require n*2n registers but just n*(n+1) or so.
However, I would like to show a different method which requires not much room and is able to solve linear equation systems and invert matrices. I used this approach thirty years ago for an HP41 program. The idea is as follows:
A matrix can be inverted by solving a set of linear equation systems with different unit vectors:
First column Second column Third column
of inverse: of inverse: of inverse:
1 0 0
A * x1 = 0 A * x2 = 1 A * x3 = 0
0 0 1
The inverse matrix then consists of the three solution vectors x1, x2 and x3.
So, what we need is an algorithm that is able to solve various linear equation systems with the same matrix A, but different vectors b on the right side.
This can be done in a clever way without additional registers. It is best explained with an example of a linear equation system with n = 3 variables:
A * x = b
1 1 1 x1 6
2 3 2 * x2 = 2
4 2 1 x3 3
Usually various elementary row conversions are applied to obtain a matrix with zeroes below the diagonal elements (Gauss algorithm). This is done by adding multiples of certain rows to others:
1 1 1
2 3 2 next: add (2) * row 1
4 2 1 next: add (4) * row 1
1 1 1
0 1 4
0 6 3 next: add (+6) * row 2
1 1 1
0 1 4
0 0 27
And we're done.
Now the same row conversions have to be applied to vector b. Usually this is done at the same time the matrix is converted. But since we want to solve for a whole set of vectors b1, b2 and b3 this is done after the matrix has been processed. This means that the factors (2), (4) and 6 used for the matrix row conversions have to be stored somewhere. This can be done  and that's the key of this method  by storing these factors in those places that now show the zeroes (here shown in parentheses):
1 1 1 1 1 1 1 1 1
2 3 2 => (2) 1 4 => (2) 1 4
4 2 1 (4) 6 3 (4) (6) 27
Now, the same transformations can be applied to vector b:
6 6 6
2 add (2) * row 1 => 10 => 10
3 add (4) * row 1 21 add (6) * row 2 81
The rest ist trivial: x3 = 81 / 27 = 3, insert this in row 2 to get x2 = 2, insert x3 and x2 in row 1 to get x1 = 1.
This way it is possible so solve multiple linear equation systems with the same matrix A and different vectors b. If b are unit vectors, the solutions are columns of the Inverse of A.
The only drawback here is the fact that the Inverse is not calculated as a whole, i.e. first column 1 of the Inverse is evaluated, then column 2, finally column 3. The inverse matrix cannot be used directly for further calculations.
A realworld algorithm would use some more registers to keep track of exchanged rows to optimize accuracy, but that's another story. ;)
Dieter
Posts: 349
Threads: 66
Joined: Apr 2007
Quote:
That means you can invert a 6x6. 6x(12) + 10 < 100 but 7(14)+10 is not. No 7x7 inverses.
This would total 108 required for 7by7's and it is interesting that the 34s actually has 112 registers but sadly, the original 4level stack occupies positions 100 to 103 here. I am almost certain that the X, Y, Z and T registers were numbered at the lower end of the 100through111 positions for good reason, but had X through T been at the top of the list instead, there might have been exactly enough registers to achieve the 7by7 case :)
Jake
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
Jake, switch to a different algorithm and an 8x8 linear system shouldn't be a problem. All the lettered registers in the 34S have a special meaning and can only be used with care for other purposes.
Posts: 3,229
Threads: 42
Joined: Jul 2006
Quote: I am almost certain that the X, Y, Z and T registers were numbered at the lower end of the 100through111 positions for good reason, but had X through T been at the top of the list instead, there might have been exactly enough registers to achieve the 7by7 case :)
Actually there isn't a good reason for putting them there, it is more a bit of an historic accident that is fiddle to remove. A, B, C, D, J and K were later additions (so was I but it was not too late) and at that point there were many assumptions about the stack being registers 100  104. I've been removing these as I notice them but I'm not confident that all are gone yet.
As Marcus points out all the lettered registers are used for various purposes so rearranging things to free a few more doesn't seem ideal either.
 Pauli
Posts: 1,545
Threads: 168
Joined: Jul 2005
Running the RRM program:
41CL at "Normal" speed: 263 seconds
41CL at TURBO 50 speed: 14 seconds
34s: Just under 2 seconds
15c using Matrix 9: About 14 seconds as well
The Exact determinant is 1.
The HP 41 gets 1.797514... as the determinant.
the 34s gets 0.999997... as the determinant.
FWIW, here are values for the determinant from other calculators.
HP41 Math Pac 1.814762704
HP28S 0.970960198039
TI59 0.9983600987185
TI95 1.000676708424
TI CC40 1.00282671
HP48S 0.970960198039
HP48G 0.999945522778
TI86 0.999646804338
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
Quote:
the 34s gets 0.999997... as the determinant.
Gene, can you retry with the different rounding modes (to inf, RM 6, to +inf, RM 5)? It would be interesting to see, if the determinant is dependent on this mode.
Edited: 18 Aug 2011, 12:44 p.m.
▼
Posts: 1,545
Threads: 168
Joined: Jul 2005
No difference at all.
Fix 02, Fix 11. Same result.
0.999997119358228
for the determinant.
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
Gene, the rounding modes don't affect the FIX display or the ROUND command, they are only used when switching back from the internal high precision to the 16 digit register format. Maybe there will be a difference when the programs are using some tricks to benefit from the higher internal precision. Let Pauli have a look at the code.
▼
Posts: 1,545
Threads: 168
Joined: Jul 2005
Pauli has the code.
What would I need to do to put the calculator into these different modes before running the code?
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
Quote: What would I need to do to put the calculator into these different modes before running the code?
The RM command does this.
 Pauli
▼
Posts: 1,545
Threads: 168
Joined: Jul 2005
I do not see it in the index of operations.
Sorry  I can't find it.
▼
Posts: 653
Threads: 26
Joined: Aug 2010
Gene, simply open the PDF manual (here it's version 2.1) and search for "math geek". ;) The RM and RM? commands are listed on page 43 of 87, right before RMDR.
Dieter
▼
Posts: 1,545
Threads: 168
Joined: Jul 2005
on page 43.
So, 1321 version 2.1 did not have these commands, which is the version I had been using.
Version 2.1 Build 1464 appears to.
I do wish the manual numbering system in the file name had the date or version number, rather than merely on the first page.
▼
Posts: 653
Threads: 26
Joined: Aug 2010
My manual says it's version 2.1 1381 from 20110803. ;)
But at least you found it now. The manual's file name indeed should contain the version number. I think that's a good idea.
Dieter
Posts: 4,587
Threads: 105
Joined: Jul 2005
Looking at SVN, you find the date the file was committed. Looking into the manual, you find the # of the last windows build covered on first page, and you see the date of issue on the last page (release notes!). The version # in the file name doesn't make a lot of sense recently, but helps me in my own directory. All will be in line with the next official release. In between, I ask for your understanding  you know you are watching a development project in progress.
Walter
Posts: 1,216
Threads: 75
Joined: Jun 2011
Hi Gene,
where can I find this Albillo matrix (AM1)?
I would like to test it on my TI92+ (accuracy and speed) ...
Franz
Posts: 1,253
Threads: 117
Joined: Nov 2005
No tests with the Advantage MINV???
▼
Posts: 1,545
Threads: 168
Joined: Jul 2005
No, only because the real test is the 34s RRM routine. The 41CL times were only in comparison to the 34s running the same code. :)
I think someone did the 41 ADV module for the determinant but I was really comparing RRM.
Posts: 3,283
Threads: 104
Joined: Jul 2005
Gene, how are the matrices laid out? In rows or columns? Where is the dimension stored?
I'm just working on some support commands which may help to create a comfortable matrix editor/viewer in user code. In principle I try to provide a means to detect numeric input from the user and suspend the program for number entry. R/S will then store the value and return control to the viewer so that up/down, left/right work for navigation.
If we ever release the features, the commands will be KTP? (determine key type) and PUTK (put key into keyboard buffer). They complement the KEY? command already there.
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
Quote:
If we ever release the features, the commands will be KTP? (determine key type) and PUTK (put key into keyboard buffer).
Don't rely on that, maybe they will carry different names :) It is not discussed yet.
Posts: 1,545
Threads: 168
Joined: Jul 2005
AM1 matrix can be found in the forum here:
AM1 Matrix
Marcus, the matrices are laid out in rows.
Register 07 contains the starting register for element (1,1).
Register 08 contains the number of columns.
Register 09 contains the number of rows.
Registers 00 through 06 are used by the RRM program suite.
So if you wanted a determinant of a 3x3, register 07 contains 10, registers 8 and 9 both contain 3, and register 10 contains (1,1), register 11 contains (1,2), register 12 contains (1,3), register 13 contains (2,1), etc.
For inverse calculations and systems, the columns are increase to contain the identity matrix values and the coefficients.
Here's a link to the PPC ROM matrix routine writeup from the manual. The entire manual is well worth reading. :)
The RRM routine begins on page 3 of the linked PDF as "Application Program 1". Actually, it looks to me as if the RRM suite can solve a system of equations using only n(n+1) registers  the inverse matrix storage may not be necessary after all from looking at example 1. That means the RRM suite could solve a 9x9 system (90+10 =< 100).
PPC ROM Matrix routines
▼
Posts: 1,216
Threads: 75
Joined: Jun 2011
Quote:
AM1 matrix can be found in the forum here:
AM1 Matrix
Thanks Gene!
To complete your list:
TI92+: det=1 (exactly!), time about 1 sec ;)
▼
Posts: 1,545
Threads: 168
Joined: Jul 2005
Ah, but you may have to be careful.
The HP 50g has a flag that senses when all the elements of a matrix are integers, then it will make sure the determinant is an integer.
It is possible something like that is going on with the TI92+.
It is nearly impossible to get a 1 without exact integer arithmetic on something like the HP 50g flag thing. :)
▼
Posts: 1,216
Threads: 75
Joined: Jun 2011
Quote:
Ah, but you may have to be careful.
The HP 50g has a flag that senses when all the elements of a matrix are integers, then it will make sure the determinant is an integer.
It is possible something like that is going on with the TI92+.
It is nearly impossible to get a 1 without exact integer arithmetic on something like the HP 50g flag thing. :)
Well, since the TI92+ is a CAS calculator I have of course used it in exact mode (which is its default).
Now I've tried it again and forced it to do in approximate mode, and here the result is 0.999718.
But of course it's nonsense to have a CAS calculator and then not to use its full capabilities ... ;)
Posts: 64
Threads: 17
Joined: Dec 2007
Quote:
Ah, but you may have to be careful.
The HP 50g has a flag that senses when all the elements of a matrix are integers, then it will make sure the determinant is an integer.
It is possible something like that is going on with the TI92+.
It is nearly impossible to get a 1 without exact integer arithmetic on something like the HP 50g flag thing. :)
Some clarifications first:
The HP50G has no "flag that senses" anything at all. Flags are for setup, not for "sensing". It is the software of the system that sets flag 105 (for approximate mode) as soon as some real number (with a decimal point) is found in the matrix in the process of calculation of the determinant. So the "sensing" is not done by the flags themselves but the flags rather indicate "what should happen" or "what happend". The flags are no "active" parts of the software, that is.
On the HP50G in exact mode no reals but only integers or rationals are involved in calculations. The determinant of AM1 is returned as exactly 1 in 1.7 seconds. (No decimal point, so this is no rounded real or anything like that but a nice integer  as it should be.) There is also no kind of "rounding trick" involved during the calculation since this is a symbolic exact calculation of the CAS of the HP50G, which is way superior for accuracy but also much slower of course. (You can even find determinants of symbolic matrices, etc.) Turning AM1 to a numeric matrix with >NUM and then calculating its determinant will return 0.999945522778 in 0.4 seconds. This is not a CAS calculation and so the result is quite close but not exact, as we see. And also much faster.

Now, on another point of view, and I have to say that I will be harsh. I apologize apriori but my mathematical moral is getting angry! Really angry!!! Unbelievably angry!!!
This whole story about recooking and rerecooking and rererecooking the same old soupe of numerical recipes as a "mathematical thing" starts getting really dull. Nothing else than dull!! Sorry to say that, but if we think that mathematics is just arithmetic and the word "calculation" applies mainly to real numbers then we do nothing more than insisting to live back in the times of Wilkinson and the ACE project, when the guys were trying to understand numerical phenomena. I understand nostalgia but, ladies and gentlemen, in the mean time we reached 2011 and we have the HP50G or the TIs or other similar devices, all of them small versions of Mathematica if you will. But no, we won't go beyond real numbers and we simply won't get that there are much much much greater questions than the numeric accuracy of AM1 or any other matrix. Yes sir, this is our calculations, but finding a space of categories that maps the triples of semantic computing onto a selfsupported sequence is no calculation  this is what this mania with numbers is equivalent to. (Guess what? The above problem can be done on an HP50G that is used for some things more than the never ending numeric contests.) And this is also one of the reasons for many companies to not even think of taking the evolution of calculators any step further  why should they? The kids want just numbers. Oh, but then we complain about HP not developing calcs anymore. Well, what for??? We stagnate ourselves! They gave us jet planes and we insist on driving them like bicycles or even inventing new bicycles. We behave as if using a formula of physics for finding a solution to a problem is physics itself, while finding the formula itself is no physics. This is what we do and nothing more!
Now, if the guys after the first computing machines were so stuborn to exclusively stick on to numbers forever then I would not be able to type this message now (, which I assume would be better too for the polite climate of the forum). But I can type this message and I really *have* to get nervous with this kind of numericology and all the numeric contests that are presented as "mathematics". Mathematics! Hear that, hear that, finding a number that does this and that, or finding the determinant of AM1 is finding an exceptional mathematical truth!! It is not the theorem that is the mathematical truth, no, it is the number, the result of the theorem!! And if this is our exceptional mathematical truths for which we use such tools then it becomes evident that there will be no further evolution of these tools. There will never be any sufficient demand for the next step, be it Sage on an iPhone or some new calc. (I mean really new and not the rererecooked numeric soups that we run behind.)
With such a thing like the HP50G available we should work on theorems, not on numbers!!!
Now I have to get into my fridge for cooling down a bit. This was really too much for one night.
Ciao.
▼
Posts: 163
Threads: 7
Joined: Jul 2007
Some further clarifications...
on the 48G/49G/50G, real mode
The flag in question is flag 54 'Use tiny element'.
When set (don't remember if that is default or not), the DET of AM1 is calculated as 0.999945522778
When flag 54 is clear, the DET routine will first analyse the matrix and determine (sense ;) whether it is allinteger or not.
If it is, it will round the result to the nearest integer. Hence, when calculating the determinant of AM1 in real mode, flag 54 clear, it will return exactly 1.
▼
Posts: 1,545
Threads: 168
Joined: Jul 2005
Which of course supports my original contention.
Exact mode is one thing.
Tiny Element in approximate mode "cheats" because the 50g "senses" that a matrix is made entirely of integers.
Thanks,
▼
Posts: 64
Threads: 17
Joined: Dec 2007
Quote:
Which of course supports my original contention.
Exact mode is one thing.
Tiny Element in approximate mode "cheats" because the 50g "senses" that a matrix is made entirely of integers.
Thanks,
There are several different possible combinations here.
A) In exact mode:
A1) Matrix made of integers. Flag 54 makes no difference, as it should be. The result is always 1. This is the right way.
A2) Matrix made of reals.
A2a) Use tiny element, result: 0.999945... , since the HP50G senses the presence of reals and calculates using numerical methods for DET without any replacing of tiny elements to 0. (This is OK under the main principle of doing things approximately or exactly according to the available arguments.)
A2b) Tiny element > 0, result 1. Again the same thing considering choice of exact vs approx. The presence of reals causes the calculator to use numerical methods of DET which is OK. But this time it sets all tiny elements to 0, which is also OK considering the state of flag 54.
Note that in both A2a and A2b there is no switch over to approx mode, which suggests that this is only using a numerical method in exact mode. It is not a general switch to approx mode. So the calc is able to do things approximately (if necessary) in exact mode too.
B) In approx mode:
B1) Matrix made of integers.
B1a  Gene's case of interest) Use tiny element, result: 1. (and not 0.999945... !) The HP50G uses exact calculation under approx mode because it finds an exact matrix, and then it just converts the exact result to a real. There is no "cheating" whatsoever. If the HP50G used approximate methods here, the result had to be 0.999945.... and not 1 since it would have to use tiny elements, which would introduce the nonexact result.
B1b) Tiny element > 0, result 1. Same thing as in B2a. If we take into consideration the case B2a then this suggests that the state of flag 54 is not important when calculating the determinant of an exact matrix in approximate mode. The calc uses the exact method and then simply converts the result to a real.
B2) Matrix made of reals.
B2a) Use tiny element, result: 0.999945... . This is the expected result since we have a numeric matrix and we use tiny elements.
B2b) Tiny element > 0, result 1. Again, this is the expected result since we have a numeric matrix and we set tiny elements to 0.
Note again that there is no kind of mode switching. The choice of calculation method is taken according to what the HP50G is fed with.
For me this is absolutely the correct behavior. The usage or not of tiny elements should not interfere anyway when using exact integers. Much like Mathematica which will keep on calculating exactly until the user tells it to make approximate results, or will calculate approximately when it finds real numers in its arguments.
The whole concept of exact vs approx "mode" seems to be quite a yesterday to me, anyway. If you can analyze the arguments then you can find out how to calculate. The presence or absence of a dot in the numbers should be enough to let the engine decide what to do. Add a command for conversion frot/to integers/reals and that's it. The rest is thinking in modes  never a good idea.
Ciao
▼
Posts: 163
Threads: 7
Joined: Jul 2007
Quote: B1a  Gene's case of interest) Use tiny element, result: 1. (and not 0.999945... !) The HP50G uses exact calculation under approx mode because it finds an exact matrix, and then it just converts the exact result to a real. There is no "cheating" whatsoever.
That is not true I'm afraid.
When the matrix contains reals, the same (numeric) algorithm is used whether you're in approx or exact mode.
Clearing flag 54 (Use tiny element) has the following effect:
 it checks up front whether the matrix contains only integers
 if so, it will *round* the computed determinant to the nearest integer.
That constitues *fiddling* with the result, no matter how you look at it. I'm pretty sure it is possible to come up with an example where the exact determinant is x and DET computes x+1 or x1.
It must be said that the flag's name is misleading. 'Use tiny element' is what it does in SVD and EGV calculations, but not in LU decomp.
Edited: 26 Aug 2011, 1:41 a.m. after one or more responses were posted
▼
Posts: 163
Threads: 7
Joined: Jul 2007
.. and an example is very easy:
just take the AM1 matrix from above, but multiply it by 4.
The exact determinant is then 4^7 or 16384, while DET (with flag 54 clear) returns 16383.
If you take AM1*5, the exact result is 78125, DET returns 78118.
This is what fiddling does: it leads you to believe 78118 is the exact determinant, and it is not.
BTW taking AM1*10 results in a perfect 10000000 again, so the 'integerdetermining' algorithm is a bit more sophisticated than that, and actually determines the position at which the determinant should be rounded.
Posts: 64
Threads: 17
Joined: Dec 2007
Some thoughts here about "modes" and why it is not really a good thing on a calculating machine of that caliber. (I use 0.999945.... here just because I am too lazy to write all digits each time.)
When doing mathematics one does not first set the brain to some "exact" or "approximate" mode. We just use the right symbols. A mathematical assertion is clear and unambiguous not because of setting modes but because of the strict language it uses. (Even its inconsistencies are clear. ;)) This language is made of symbols like numbers, letters, indices, operators, etc. (And we try to keep clarity along with strictness using the least possible concepts and the lest possible symbols.) For example, one could write Det(AM1)=1 or Det(AM1)≈0.999945.... but never Det(AM1)=0.999945..... since the determinant of AM1 is *not* equal to 0.999945.... It is only *approximately* equal to 0.999945.... , which is expressed using ≈ and not = .
The above example, translated to the language of the HP50G would mean that the statement Det(AM1)=0.999945..... is true under the additional premise of approximate mode. In this case using approximate mode is like writing the symbol "≈" . So one could also say that the mathematical symbol "≈" is available on the machine by using approximate mode.
But: As we see here and in so many other examples the usage of modes is anything but clear. The result of the operations in this example can imply that Det(AM1) *is* actually 0.999945..... , and then additional consideration of the state of flag 54 corrects the statement to "Det(AM1) is approximately 0.999945.....". In this case it not so difficult for the user to keep in mind the states of the related flags, but in many many other examples one has to remember many more things that are valid implicitly. In other words the explicitness of the statement is lost. Compare for example the explicit clarity of statements like:
Det(AM1)=1
or
Det(AM1)≈0.999945....
with the implicit clarity of:
Det(AM1)=0.999945....  approximate mode and usage of tiny elements
where the part " approximate mode and usage of tiny elements" is not explicitly written but kept as a setting under the numerous modes of the machine.
To make it even more complicated just multiply some numder of AM1 with the variable X and retry the cases in my last message. A completely different behavior just because of the presence of a variable in the matrix.
It seems that the concept of modes was OK for machines with limited RAM that offered some few flags for angles or number representations, but I doubt that this concept is a good choice for a CAS with much RAM. There are many too many things for the user to be aware of, and this makes lowers unnecesserily the clarity. The part " approximate mode and usage of tiny elements" is simply the symbol "≈"  not really an economic translation, is it? And also not quite obvious when there is no kind of announciator for usage or not of tiny elements. And even less obvious when it is not visible anywhere in the machine what actually "tiny" means, but that's a very long story. (The explanation about "tiny" in the manual is only a tiny part of this long story, which can be used against this statement too. ;)) And even less less obvious when we take symbolic variables in the matrix. And, and and....
All the above is of course more of an issue about user friendliness through consistency, but there is also a second but: Using so many flags and modes and states introduces hidden dangers against consistency due to unexpected interferences. To make it even worse, the different types of operations like commands, operations, functions, analytic functions, programms etc., the behavior of which is influenced by the modes, don't really help to avoid confusion. Just consider the several representations of a complex number on the HP50G in combination with all the relevant modes under usage of the power function. You will get a lot of possible subcases and a lot of possible different results for one and the same mathematical thing, namely (a,b)^c. In many of these cases the result is absolutely correct but in many others of these cases the result is at least not easily understanable. It is not right and it is not wrong and it is both at the same time.
The above is much like the Toolbox of the Mac before OS X. Thousands of functions doing the same thing a bit different  sometimes so, sometimes the other way around, according to "modes". Nobody could manage it consistently anymore and so it started showing severe inconsistencies that were not avoidable. And so the only right decision was to through it away and start from scratch for something else. This brought us OS X. Much more consistent and with much less hidden dangers that can evolve to catastrophes. (I wonder how long it will take until it starts declining under its own growing weight.)
So,
a) just consider the HP50G in exact mode and enter 1 1 + . The result is 2, so it is OK.
b) Now switch to approx mode and enter 1 1 + . The result is 2. since entering the two 1s (without the decimal point) converted them both to 1. For me it is also OK.
c) Now switch to exact mode, enter 1 1, then switch to approx mod and press +. You get 2, an integer and not a real though you are in approx mode. Let's accept that as a consistent result because we are operating with integers, and let's say that integer results should be obtained when integer arguments are used  no matter of mode.
d) But now switch to exact mode, enter 0 1 'X' 'X', then switch to approx mode and integrate. You get 0.5 and not 1/2. Hmm... is that consistent when we have accepted (c)???
You see where it goes to.
Ciao.
Posts: 3,229
Threads: 42
Joined: Jul 2006
While I was away a few days, I started fiddling with what I'd like to see a 34S matrix package look like.
I'd like matricies to be written as descriptors of the form BB.RRCC, where BB is the first register, RR is the number of rows in the matrix and CC the number of columns. Simple to use and very easy for the user to remember. Conversion into other forms will be part of the library internals.
Matrix operations should take one or more of the descriptors from the stack as well as any other required arguments and return a result descriptor to the stack & perhaps stored in I if on the stack doesn't make sense for a particular operation. Storing the result descriptor in I might be worthwhile regardless. Attempts to preserve the stack do not seem worthwhile at least to me unless they fall out naturally.
I've coded some utility routines to take a descriptor from the stack and to return the base and dimensions, loop iterators for all elements or for row or column elements.
I used these to code matrix addition and subtraction.
I started thinking about matrix multiply. I'd really like to use the internal SUM command for each result value since it does a Kahan sum which should increase the accuracy a little much of the time and it doesn't use any of the visible registers.
None of this is opposed to what Gene has done either. The M1  M5 routines will be required in any matrix library and converting them to use slightly different inputs shouldn't be tricky.
 Pauli
Posts: 1,216
Threads: 75
Joined: Jun 2011
Looking for matrix routines I remembered a very efficient, accurate and small algorithm (FaddejewLeverrier), which calculates the determinant, inverse and characteristic polynomial of a nxn matrix in just n iterations  maybe not everyone here knows this method, and so I've made a short pseudocode for it:

Input: nxnMatrix A
B := 0 // 0 = nxn zero matrix
c[n] := 1 // c = (n+1)vector or list [c(n),c(n1),...,c(1),c(0)]
for k := 1 to n
B := B + c[nk+1]*I // I = nxn identity matrix
if k = n then Inv := B
B := A*B
c[nk] := trace(B)/k // trace = sum of diagonal elements
endfor
B := B + c[0]*I
Output: if B <> 0 then return "iteration not convergent"
1) Det := (1)^n*c[0] ... determinant A
2) if Det = 0
then return "singular matrix"
else Inv := Inv/c[0] ... inverse matrix A^1
3) CharPoly := Sum(c[k]*x^k,k,0,n) ... characteristic polynomial cp(A)

I've coded it for my TI92+ (although it has functions for 'det' and 'inv') which needed only a few lines, and tried it with the Albillo matrix AM1  and even running it in approximate mode it returns the exact value 1 for the determinant!
Unfortunately this algorithm would be no advantage for the WP34s, because it also needs a 2nd nxn matrix (B), so the limit would also be a 7x7 matrix for these functions.
Franz
