YAMP has been a valuable learning experience for me. It meets all of my original design criteria, even though it is a little slower than what would be considered competitive. It meets my needs for analyzing sophisticated statistical linear models. It also gets around many of the problems I have encountered in the "professional" packages, mainly the 640k barrier on the PC. Speed isn't very important if it only means that I bounce off the limitations sooner. I don't really mind slapping in a program and letting it run overnight, provided it doesn't bomb on memory. Besides the new class of personal computers are becoming extremely powerful. It runs fairly well with a 2 meg disk cache, or ram-disk. I have only run out of memory once with this configuration.
To a large extent, I modeled it after a very good program called Matrix by Will Alexander [#!AW:Ma!#]. Matrix is an interpreted matrix language that Will loaned me for my dissertation research. YAMP represents many of the things I wish were in Matrix. In many regards, using the Borland IDE may be considered similar using to an interpreter. In fact, YAMP would have been impossible for me to write without the source debugger of the IDE. The beauty of C++ is that I had a full blown language at my disposal after I created the VMatrix class. I didn't have to write an interpreter.
The package supports recursive matrix functions. Two memory models are available: in RAM and out of RAM. In–ram matrices are limited to 64k in size. External matrices are stored in a virtual memory file that can be stored in a RAM disk, and is limited to 32 megs. Virtual matrices can be larger than 640K. The in ram memory model works in all but the tiny memory model.
I think YAMP is portable but I do not have the resources to test it. The in-ram version should port to UNIX easily. You can increase the 8190 in the allocation routine on machines that do not have a segmented memory architecture, and automatically page memory. I would love to test it on a VAX or a CRAY. Another question is how well in parallelizes. I took a FORTRAN style in the loops, so this may help. The stack may be a bottleneck though.
Plans: These are more speculative than concrete. I really feel that YAMP is about finished.
If you have in comments or suggestions, please contact me at my mailing address or send mail on Compuserve to my user id 71530,1170. I hope you find YAMP simple enough to use, and not too confusing. I also hope that the personal tone of the popular computer science literature was not too much of turn-off, including the humor.
That is it for YAMP. I will fix any bugs people send me, but it is time to move onto other designs. I don't plan any more extensions or improvements. Many of the design problems I had with YAMP are solved in Coplien [#!CJ:AC!#]. I have figured out how to use the brackets operator to address the virtual memory space on both sides of the equals sign. This gets rid of big M and little m. It also allows A[i][j] easily. This makes it easier to move existing code C into the new design.
Shantih.