# HP Forums

Full Version: Are Matrices Relevant?
You're currently viewing a stripped down version of our content. View the full version with proper formatting.

I see complaints about matrix solving ability. Explain the real life relevance of matrices. Where do they arise? Sam

GRIN... Actually, there are many a' ffine use for matricies. If I wanted to dot my "i's" and cross
my "t's", I would say there is no upper limit to their utility.

If I had to rank some of the tools that have transformed my mathematics experience, I would say that matricies have given me an identity and life just wouldn't be normal without them. :-)

Edited: 28 Oct 2007, 3:23 p.m.

Quote:
Explain the real life relevance of matrices. Where do they arise?

• vector rotations
• coordinate transformations
• systems of linear equations
• curve fitting

And many more, but that's what came to mind thinking about it for five seconds.

Very simplistically, you can think back to high school and consider it a way to work with systems of (more than one) equations.

And historically, the presently more commonly encountered form of quantum mechanics, wave mechanics, got its start from matrices, in matrix mechanics.

Oh, how I wish I got a HP-15C.

Edited: 28 Oct 2007, 3:31 p.m.

Hello!

Quote:
Where do they arise?

Just two examples from my world:

- 3D CAD/CAM consists to 95 percent of vectors and matrices. Our customers (we supply them with auxiliary software plugins for their CAD system) design (very) large aircraft where millions of matrix operations are peformed every second on every single workstation. They have more than 1.000 of those in operation. I have been doing this work for over ten years now, but have never performed a single matrix calculation on a pocket calculator. If I have to check a result, it is quicker to write a little program on my workstation, where I can copy & paste the necessary input values, than to type all the figures into a calculator.

- In my other job, I am getting GPS postion and speed readouts updated several times per second, that are again the result of matrix operations used to solve the necessary equations. Again, a pocket calculator might just be able to perform the necessary calcualtions (but not the much more computationally intensive task of receiving and decoding the pseudo-random signals transmitted by the satellites), but we would long have run out of fuel before the necessary input figures were typed into the machine...

Greetings, Max

Quote:
it is quicker to write a little program on my workstation, where I can copy & paste the necessary input values, than to type all the figures into a calculator.

That's partly why HPIL was valuable. It was practical to connect lots of lab instruments to the calculator at once. I did a lot of FFTs in the late 1980's on my HP-71, up to 8192-point, but you can bet I did not type the data in! It came in over HPIL, through the HP82169A HPIL-HPIB (IEEE-488) interface converter.

Edited: 29 Oct 2007, 12:08 a.m.

Quote:
Explain the real life relevance of matrices.

In physical situations, matrices arise when you want to work with and describe real world (multi-dimensional) objects. While there are other ways, using a matrix is often very convenient.

An example?

Let's say you're programming a robot. You tell it that there is an obstacle five meters ahead, and two meters to the right. Now your robot then turns in place 't' degrees to the left. So, how do you calculate the location relative to the robot after the turn?

If you want to use matrices, you'd describe the original coordinates of the obstacle with the matrix

```[[5]
[2]] = C
```

and the rotation matrix:

```[[cos(t) -sin(t)]
[sin(t)  cos(t)]] = R
```

To get your new coordinates, preform the matrix multiplication:
C` = R*C

and you're done! Of course, you could have used two equations, but this is more compact and readable if you have the matrix functionality already built in.

This is a very simple example, but if you write out the equations that you'd need you can see that as you scale dimensions, and the complexity of your operations, using matrices becomes more an more useful. (For example, you can multiply rotation matrices again and again to get the final rotation, and then apply that to all of your coordinates.)

I'm sure someone else can give a better example of using matrices, but this is mine.

The availability of matrix operations in a calculator, programming language, and an extension of a programming language offers valuable shortcut to the user/programmer. Matrix operations make us very easy, for example, to set up statistical summations for multiple regression and then solving for the regression coefficients and other statistics. Such operations absolve the user/programmer from having to manage the matrices element by element.

Try and get hold of a copy of Bradley & Meeks' book "Matrices and Society". It's quite slim, an easy non-technical read, and has some quite surprising examples.

In 1980 I programmed my TI-59 to analyse structural building frames. For example, a frame with three lines of columns and two upper floors would have six nodal intersections. Each node of a plane frame can drift to L or R, stretch/squash up/down, or rotate. That is, it has 3 degrees of freedom ('DoF').

A plane frame structure with 6 nodes has 18 DoF.

When external actions are applied to a structure (eg point loads, uniformly distributed loads such as weight and applied floor loads etc), each DoF deflects and rotates, and develops a corresponding internal action (axial force, shear force and bending moment.

All internal actions are related lineraly to the external actions and to member stiffnesses and all of the displacements at the nearest DoF. These relationships can be expressed as a series of equations.

Nobody who writes down 18 equations bothers to keep repeating all the same variables on every line. Just write a list of the variables then for each line write a list of the coefficients. We call these shorthand forms, "matrices". Solving 18 equations by hand would NEVER be done in real life but with computers and flash calculators we can automate the process.

Without the neat timesaver form of matrices for teh equations this would be ludicrously cumbersome. Alas,here we are, 27 years later with an HP35s calculator that has, what, thirty six times as much memory as the TI-59? Yet I could not easily replicate the above because there are no large-scale matrix functions.

Its a marvellous calculator but I so-oo wish it had either a USB port of removable flash memory cards from which I could save backups on a PC, print etc.. I also am very, very wary about accidental screen lock-up when debugging any rough-and-ready code not prepared with v great care because this fault can leave one having to erase ALL work to date on the machine.

----

John Wasilewski

50G....50G.....50G:-)

Just for the record, you couldn't solve those 18 equations on the TI-59 either, I think.

It did not have matrix equations built-in. It did have a matrix program as one of the master library programs on the plug-in CROM, but that was certainly not written with subroutines in mind. There were no large scale matrix functions in that program that would apply to this stated problem, since it had limits of a 9x9 system.

If you did ever solve such a beast on the TI-59, then you had to write some sort of program for it using other techniques, just as you would the HP-35s.

Of course, if you want to use matrices on a calculator today, then either use an HP42s or a graphing series model such as the HP48, HP49, or HP50g.

But, FYI on the old TI-59 for any readers who aren't familiar with it.

Hi John,

you remind me of good ol' Cato (the Roman), who repeated "ceterum censeo Carthaginem esse delendam" ad nauseam some 200 B.C. Eventually, Carthago was destroyed. So you seem to run the same strategy to push HP to launch a pocket calc with I/O and matrix support, don't you? Good luck :) (me, too, will appreciate your success)

Ouch, you think I'm making it up!

I used a matrix inversion subroutine from the ML module, which was INEFFICIENT (an equation solver would have been better but there wasn't one I think). Also inefficiently, the program did not store the matrix as a packed half bandwidth but stored the whole square matrix, because you have to do this if solving the equations by in-situ matrix inversion (I think!).

I invented a structure labelling notation that didn't number the nodes and members but numbered only the DoF and then entered members using their nodal DoF as idendifiers. See exampe below.

Its a long time ago and I don't remember the matrix size limit of the ML module but I assure you I most certainly DID analyse a structure with 3 lines of cols and 2 upper floors, because that was one of my test structures and I analysed it dozens of times in final testing of teh program. If the ML module was limied to 9x9 as you say then what I must have done is to treat members as axially rigid so that nodal DoF were limied to L/R translation plus rotation and each floor level shared translation DoF.

DoF will thus have been:

Three rotations at 2nd floor

1

2

3

L/R translation at 2nd floor

4

Three rotations at 1st floor

5

6

7

L/R translation at 1st floor

8

Members will thus have been entered as

2nd floor beams 4142 4243

1st-2nd floor cols 8541 8642 8743

1st floor beams 8586 8687

grd-1st floor cols 0085 0086 0087

This member notation allowed the program to add stiffnesses directly into DoF locations. The program then solved the equations for all rotation and translation displacements, then added displacement actions (displacments x stiffnesses) to the original fixiy actions (fixed-end moments and shears), obtaining all member-end moments and shears throughout the structure.

Input was extremely quick and easy. If you number DoF instead of nodes and members, using a diagram, you can reel off member DoF designators in an instant.

I am sorry that I didn't (and still don't) remember the matrix size limits of the ML module, so my number of equations may have been wrong for this particular example structure but I hope the above convinces you that I really DID DO what I said I did in all other respects! If anyone still has a working TI59, I have a copy of teh code somewhere that I can send out.

---
John

Hi, Gene:

Gene posted:

"Of course, if you want to use matrices on a calculator today, then either use an HP42s or a graphing series model such as the HP48, HP49, or HP50g."

I fail to understand why knowledgeable old-timers like you and many other expert people in this Forum consistently fail to recommend the HP-71B for most any purpose at all, always going for some other models instead.

In the particular, important case of matrix handling, it's been my experience that an HP-71B/Math ROM combination beats anything out there in terms of ease of use and sheer productivity. Its excellent classic keyboard with separate numeric pad, plus the convenience of assembly-language matrix keywords makes entering matrices and doing complicated operations with them as easy as pie.

This is further enhanced if you've got peripherals for your HP-71B such as printer, mass storage, or 80-column external display, or else if you're using Emu71 running on your PC, which brings in all these capabilities plus 350x speed to boot.

Even if restricted to the physical, handheld model, I'm pretty sure
the HP-71B is a very strong contender for matrix handling on the field, even if just doing manual computations (which can utilize key assignments for even greater productivity), without resorting to programming. If some programming involving matrices is necessary, then the HP-71B allegedly wins hands down.

The 71-b is out of production. The OP is using currently available technology--he isn't shopping for antiques. Yes, some of the old tools are better, but overall they are less supported day by day.

But as this is a museum, interest and awareness of the 71B and its capabilities is of great interest and I for one am very glad for your posts on the subject. I never would have known of these gems of the past otherwise!

Valentin is of course correct, the 71B with the MATH rom is another great alternative.

However, I am expecting to hear a reply that John only wants an RPN model that can do matrices, which is why I suggested the 42s.

The "proper" way to do matrix work on a handheld today is, IMO, the 48/49/50 graphing series for several reasons...cost and ease of replacing a broken unit being the primary one.

I have picked up HP48gII models off ebay for less than \$30. Same for older 49g models.

You could buy and use 8-10 of these for the usual price of a 42s.

Going with the 71B would be more expensive and require programming in BASIC rather than in an interactive way, such as can be done on the 42s and graphing series.

Given that the lament is that the \$60 HP35s doesn't have all these complicated matrix functions, I was expecting the need to suggest an RPN model (hence the 42s) and given the \$60 price, I was expecting the need to suggest a relatively cheap alternative (hence the graphing models). I just didn't think the 71B fit either of those categories. :-)

BTW, great articles, Valentin, in the latest Datafile issue!

And what I am primarily saying is that the TI-59 matrix systems program in the TI-59 was limited to 9x9 systems.

Equation solvers were nearly 10 years in the future from the 1977 TI-59 introduction dates.

And, no, I don't suggest you're making it up, but that you might have either mis-remembered (possible, of course) or that you had to use some other technique (which you did since you say you "invented" an approach.

Well, you can certainly invent an approach to the problem on the HP35s if you want.

Seems a bit much to take a whack at the HP35s for not doing something out of the box because a calculator form 30 years ago gave you the ability to invent a way to solve a problem on it.

So, you could write a program to do this on the HP 35s as well. That's all.

Hi, Bill:

Bill posted:

"The 71-b is out of production. The OP is using currently available technology--he isn't shopping for antiques."

What "original poster" ? John Wasilewski ? designnut ?

Also, the HP-71B is "currently available technology": you can get any number of them right now in eBay and other places. It's just that you don't want to pay the asked price or shop for it at other places, but it's certainly anything but rare.

Anyway, I'm not complaining about this particular thread or "original poster" (whomever he might be) but on the perceived fact that not even once does anyone recommend getting an HP-71B for any purpose. You can find the RPL models recommended, the HP35S, the HP-41C, 42S, 11C, 15C, 17BII, most any model at all ... except for the HP-71B.

"But as this is a museum, interest and awareness of the 71B and its capabilities is of great interest and I for one am very glad for your posts
on the subject. I never would have known of these gems of the past otherwise!"

Thank you very much, I'll buy you a drink or two for that.

Best regards from V.

Valentin wrote: "Anyway, I'm not complaining about this particular thread or "original poster" (whomever he might be) but on the perceived fact that not even once does anyone recommend getting an HP-71B for any purpose. You can find the RPL models recommended, the HP35S, the HP-41C, 42S, 11C, 15C, 17BII, most any model at all ... except for the HP-71B."

Gene: Ok! I'll do penance by actually getting my HP71B out and using it in the next week. It IS a beauty.

Internally wired 144MB of ram AND internally wired MATH rom. 32K EEPROM containing the X-version of the JPC rom (which I **really** like), and more. :-)

And, my other piece of penance will be to make sure a marvel such as the 71B comes to mind next time I have a chance to recommend a task at which it excels!

Will that do? :-)

Hi again, Gene:

Gene posted:

"Going with the 71B would be more expensive and require programming in BASIC rather than in an interactive way, such as can be done
on the 42s and graphing series."

I don't concur with what you're saying, at all. What do you mean "require programming in BASIC rather than in an interactive way" ?

You don't need any programming at all to use most of the HP-71B capabilities right from the keyword, interactively. That includes matrix capabilities, of course: you don't need to write a single line of code to declare, input and output matrices, to invert them, perform arithmetic with them, solve linear systems, or whatever, be they real- or complex-valued.

Just for instance, to solve a typical 3x3 system, say, you'd key in:

```     DIM A(3,3),B(3),X(3)            [ENTER] (declare matrices)
MAT INPUT A,B                   [ENTER] (input values)
2,1,3,5,-1,4,-3,2,-1,6,8,-2 [ENTER]
MAT X=SYS(A,B)                  [ENTER] (solve the system)
MAT DISP X                      [ENTER] (output results)
```

and as you can see, everything's been done interactively, right from the keyboard, without ever entering even a single program line.

"I just didn't think the 71B fit either of those categories. :-)"

Lame excuses won't save you this time, just simply recognize that you *hate* the HP-71B because it hasn't built-in financial functions like the SHARP EL-5510 handheld does ... :-) :-)

"BTW, great articles, Valentin, in the latest Datafile issue!"

Thank you very much, glad you liked them. Depending on how the incoming HPCC AGM comes out next 10th November 2007, they might turn out to be my last articles for Datafile in the foreseeable future, so keep them for collectible value.

Best regards from V.

Hi, Gene:

Gene posted:

"Will that do? :-)"

YESSSS ! Oh, yesss !! Have a cigar, my friend :-)

And congratulations for your really beefed-up HP-71B. My best one (I own 3) does have 160 Kb RAM + Math ROM + HP-IL ROM plus I also have its Card Reader, but none or them are internally wired.

I do have a curiosity regarding that physical JPC ROM of yours: does it appreciably slow down the machine while it's plugged in ?

This is: do programs (which don't use any of its keywords) run slower than they do if JPC ROM isn't plugged in ? Do interactive execution of command lines slow as well ? Does parsing and executing statements either interactively or in a running program proceed noticeably slower ?

Another question: did you ever get to try and write some programs for your SHARP EL-5510/PC-1421 handheld making use of its built-in financial BASIC statements and functions ? At the very least, did you ever wrote some kind of review, even if in scratch status ? You being an experienced financial guy I would be very specially interested in your opinion, as I've told you before.

Thanks and best regards from V.

You're right - I remembered the ML module and matrix ops but I did not remember its equation limit. I seem to recall that the TI-59 had storage registers 00 to 99 so an 81-field array would not leave a lot of space for other variables or program code.

I had fun compressing the frame analysis program and maximising the structural problem size, and my 3 rows of cols by 2 storey heights was either at the limit or nearly at it. (I actually also did use the program for my work, btw!).

This thread arose solely in reply to a challenge about, iirr, whether matrices have any practical use in the real world. I hope the original poster is now content with assurances from many of us, expressed and implied, that the answer is a resounding 'yes', and that significant matrix handling facilities can be very useful in a good calculator.
---
John

What I claim to have "invented" is a member designation system that is easy to use and eliminates a huge amount of housekeeping code from computer applications to get the program to work out which member-end actions are associated with which global structure DoF - hence feasible in the tiny storage capacity of a calculator.

Instead of numbering nodes, numbering members and listing connectivity by member-end node numbers like this, I just labelled each member witha 4-integer number representing the moments and shear DoF at each end. This allowed member stiffnesses to be added directly to the four DoF making the member's 'name'.

---
John

I'd be delighted to tackle this in the HP35s.
Would need to write a matrix equation solver though (which would be far more efficient than matrix inversion).

Obviously it would be good to find a way of packing the stiffness matrix by storing only the symmetrical halfbandwidth of the coefficients array, but I can't immediately see how to do that when using the member DoF-designator device to avoid 'housekeeping' code.

Also I suspect that the HP35s might run just a bit too slowly for an application like this with maybe 10 or 20 equations to solve and having to us an algorithm to locate every non-zero array coefficient in the packed storage.

Also, alas, there's no realistic prospect at all that I could find the time to take it on, for the foreseeeable future (sigh).

---
John

Quote:
And what I am primarily saying is that the TI-59 matrix systems program in the TI-59 was limited to 9x9 systems.

The ML-02 program in the Master Library for the TI-59 would solve eighth order simultaneous equation problems or ninth order determinants and matrix inversion problems. It should have been possible to solve a ninth order simultaneous equation problem by entering the matrix, inverting the matrix with ML-02, and then using a user program to enter the vector and multiply the inverted matrix by the vector. I am not aware that anyone ever did that. I made a run at it one time but got hung up with the pivoting index.

A TI-59 program which would solve sixteenth order simultaneous equation problems appeared in the 81-2 issue of the Swedish newsletter Programbiten. Last year I translated that program for my sixth, seventh and eighth order linear equation solutions for the hp-33s which appear in the Articles section of this forum.

Those who don't have access to the old issues of Programbiten can find discussions of the program in V8N6P14 ff and V9N1P16 ff of TI PPC Notes including conversions of the program for fast mode. You can find those documents at Viktor Toth's site. I have solved 16x16 systems with the programs.

A program of the same genre for the HP-41 by Valentin Albillo appeared in V7N5P64 of the PPC Calculator Journal would solve up to a 14x14 system with a single memory module and a 30x30 system with all four memory modules in place. I have entered the program in an HP-41 but have only solved up to 9x9 systems.

It would seem to me to be fairly straightforward to convert Valentin's program for use with the hp-35s. I didn't use Valentin's program as the basis for my programs for the hp-33s because I had counted the required number of registers for Valentin's program and found that a direct translation couldn't do an 8x8 considering memory linitations of the hp-33s. I couldn't see a way to reduce the number of registers for Valentin's program. That doesn't mean that there isn't one. I just couldn't push it through. I did find a way to squeeze in a modification of the Programbiten program. Memory limitations shouldn't be a problem on the hp-35s.