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


« Next Oldest  Next Newest »

▼
10282007, 02:51 PM
▼
10282007, 03:22 PM
GRIN... Actually, there are many a' ffine use for matricies. If I wanted to dot my "i's" and cross
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. ▼
10282007, 03:30 PM
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 HP15C. Edited: 28 Oct 2007, 3:31 p.m.
10282007, 03:28 PM
Quote:
And many more, but that's what came to mind thinking about it for five seconds.
10282007, 03:57 PM
Hello!
Quote: 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 pseudorandom 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 ▼
10292007, 12:07 AM
Quote: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 HP71, up to 8192point, but you can bet I did not type the data in! It came in over HPIL, through the HP82169A HPILHPIB (IEEE488) interface converter. Edited: 29 Oct 2007, 12:08 a.m.
10282007, 11:37 PM
10292007, 01:22 AM
Quote: In physical situations, matrices arise when you want to work with and describe real world (multidimensional) 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] and the rotation matrix:
[[cos(t) sin(t)]
To get your new coordinates, preform the matrix multiplication: 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.
10292007, 05:29 AM
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.
10292007, 06:47 PM
Try and get hold of a copy of Bradley & Meeks' book "Matrices and Society". It's quite slim, an easy nontechnical read, and has some quite surprising examples.
10292007, 09:09 PM
In 1980 I programmed my TI59 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 TI59? Yet I could not easily replicate the above because there are no largescale matrix functions.
Its a marvellous calculator but I sooo 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 lockup when debugging any roughandready code not prepared with v great care because this fault can leave one having to erase ALL work to date on the machine. ▼
10292007, 09:37 PM
50G....50G.....50G:)
10292007, 09:38 PM
Just for the record, you couldn't solve those 18 equations on the TI59 either, I think. It did not have matrix equations builtin. It did have a matrix program as one of the master library programs on the plugin 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 TI59, then you had to write some sort of program for it using other techniques, just as you would the HP35s. 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 TI59 for any readers who aren't familiar with it. ▼
10302007, 03:16 AM
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 insitu 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
L/R translation at 2nd floor
Three rotations at 1st floor
L/R translation at 1st floor
Members will thus have been entered as 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 (fixedend moments and shears), obtaining all memberend 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.
▼
10302007, 08:36 AM
And what I am primarily saying is that the TI59 matrix systems program in the TI59 was limited to 9x9 systems. Equation solvers were nearly 10 years in the future from the 1977 TI59 introduction dates. And, no, I don't suggest you're making it up, but that you might have either misremembered (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. ▼
10302007, 06:40 PM
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 TI59 had storage registers 00 to 99 so an 81field 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.
10302007, 06:53 PM
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 memberend 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 memberend node numbers like this, I just labelled each member witha 4integer 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'.
10302007, 07:00 PM
I'd be delighted to tackle this in the HP35s. 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 DoFdesignator 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 nonzero 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).
10302007, 11:11 PM
Quote: The ML02 program in the Master Library for the TI59 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 ML02, 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 TI59 program which would solve sixteenth order simultaneous equation problems appeared in the 812 issue of the Swedish newsletter Programbiten. Last year I translated that program for my sixth, seventh and eighth order linear equation solutions for the hp33s 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 HP41 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 HP41 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 hp35s. I didn't use Valentin's program as the basis for my programs for the hp33s 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 hp33s. 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 hp35s.
10302007, 07:14 AM
Hi, Gene: Gene posted:
In the particular, important case of matrix handling, it's been my experience that an HP71B/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 assemblylanguage 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 HP71B such as printer, mass storage, or 80column 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
▼
10302007, 07:45 AM
The 71b is out of production. The OP is using currently available technologyhe isn't shopping for antiques. Yes, some of the old tools are better, but overall they are less supported day by day.
▼
10302007, 09:52 AM
Hi, Bill: Bill posted:
Also, the HP71B 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 HP71B for any purpose. You can find the RPL models recommended, the HP35S, the HP41C, 42S, 11C, 15C, 17BII, most any model at all ... except for the HP71B.
"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
▼
10302007, 10:10 AM
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 HP71B for any purpose. You can find the RPL models recommended, the HP35S, the HP41C, 42S, 11C, 15C, 17BII, most any model at all ... except for the HP71B." 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 Xversion 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? :)
▼
10302007, 10:31 AM
Hi, Gene: Gene posted:
And congratulations for your really beefedup HP71B. My best one (I own 3) does have 160 Kb RAM + Math ROM + HPIL 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 EL5510/PC1421 handheld making use of its builtin 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.
10302007, 08:31 AM
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 810 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! ▼
10302007, 10:17 AM
Hi again, Gene: Gene posted:
on the 42s and graphing series."
You don't need any programming at all to use most of the HP71B 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 complexvalued.
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) 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. :)"
"BTW, great articles, Valentin, in the latest Datafile issue!"
Best regards from V.
10302007, 01:18 AM
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) 