Computer related things are changing unbelievably fast. I have started programming about 30 years ago on a Soviet supercomputer BESM-6. Thanks to modern technology you can still see what it looked like now live at 

My first program was similar to that below.

*name test
program main
a = 2*2
print 10, a
10 format('2*2=',F3.0)
*end file

Take these lines, paste them to the window in the link above, press Run, and then you see the listing. In the old time, I entered these lines through a terminal but the listing was produced in the computer center, so to catch it I needed a walk. This means that if there was some mistake, it took some time to see it. Well, actually I was lucky, as an older generation used punch cards to enter the program, when it was necessary to leave the stack of punch cards elsewhere and then wait until an operator put it through a punch card reader.

Taking the above into account, it should be understandable that the work with an operating system through a command line interface (console) was a remarkable progress. And nowadays graphic user interface (GUI) completely replaced the console and majority of users even does not suspect that somewhere on their computer it is still possible to find a command line interface. Interestingly enough is that this concerns even younger programmers. They get so used to an integrated development environment that they just cannot work from the command line.

At the same time the knowledge of the command line interface is important when one starts using numerical libraries. There are many of them and many of them are free, the most famous depository being Netlib . Traditionally numerical libraries are created under Unix environment under the assumption that the use will use make to build them. This clearly is a challenge for a person who has started programming with for example Visual Studio. The goal of my text is to help in this respect.

A small note on console vs. GUI. I use GUI extensively in my personal work but, at the same time, I find a command line to be a convenient tool as well. In my view, one does not exclude another. I would compare GUI with the body language and a console with verbal language. We need to operate with many programs and operations through the mouse are easy to learn. However, the expressive power of the mouse interface is limited, especially when it comes to automation. At the same time, it takes more time to learn console interface but when it is done its expressive power is enormous.

On Windows, the command line interface is represented though cmd. However its own language is very primitive. It is also impossible to use it as such to compile numerical libraries from Internet. A good solution is to employ Cygwin that will brings you at once a Unix-like console with all handy Unix tools together with a GNU Compiler Collection (GCC) and GNU Make. After that the compilation of numerical libraries will be a relatively simple task, as this brings us the same environment that has been used to create these libraries.

Nonetheless, the goal for many programmers on Windows will be the use of the libraries from within Visual Studio. This is also possible and in my text I will show how to achieve it as well. As the gcc object format is compatible with Microsoft Visual Studio, it is possible just to use libraries compiled by gcc. On the other hand, it is possible to use Microsoft Visual C++ from the command line directly. Here it will be necessary to edit makefiles to tell make to use cl instead of gcc but also to make some other changes. This way one can compile native libraries for Visual C under the Cygwin environment but this will require more work while editing makefiles.

The text will consider the use of libraries to solve a system of linear equations. This is a basic problem in numerical methods. Here LAPACK will be used for dense matrices and several solvers such as TAUCS, UMFPACK and MUMPS for sparse matrices. In my view, if one learns how to compile and use these libraries, then he/she can compile and use any numerical library on his/her own. LAPACK is written in Fortran and the question of using a Fortran subroutines from C and C++ will be also considered.

Comments are closed.