...modify

Of course, one cannot truthfully say that today's applications are any smaller, but they are at least supposed to be better documented.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

...changed

This applies only to the parts of the code that directly use SymPLA. If other parts of the application are dependent on some specific architecture or compiler, this can only be handled by the developer.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

...value

since C++ does not have a read-only attribute for public variables, nor does any other language known to us.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

...C++

Doing so would require a major change in the syntax and the grammatical rules of the C++ language, as Pascal uses explicit declaration of procedures and functions while C++ uses a name followed by a parenthesis. A possible solution could be letting the function defined as int dim(void) be called as both dim() and dim.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

...submatrix

Present implementations can only be restricted to this, but another method of implementation may expand this to all affected submatrices.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

...matrices

Neither the TriangularSolver class nor the LUsolver class presently supports any kind of multiplication, except when they are implicitly converted to Matrix.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

...files

The present implementation is restricted to text files.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

...data

Of course, the ``constness'' problems do not end here, as LAPACK routines do not have enforcement of const, and typecasting away the const may be necessary.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

...frontend

While it may be possible to configure the cfront to produce code that runs on the ACU, there might be problems with the MPL's parallel features. It is likely that separate code in MPL would have been required in any event. In addition, the frontend computer is a much faster sequential computer than the ACU, and has better resources available.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

...data

This might be omitted, or replaced by assertions, but is used in this prototype.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

...benchmarks

Timings of daxpy operations on DEC Alpha and Intel Paragon cannot differentiate between a scaling factor of 1.0 or a scaling factor different from 1.0. This may be because the daxpy always uses a scaled sum, or that scaling has no effect on time to compute.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

...operations

The correct operation count for MasPar would be 50#50 for SymPLA, as MPML only has a complete solver, not triangular solvers like BLAS does. The count is set to the same for both, otherwise the SymPLA benchmark will have to handle MasPar as a special case.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

...MFLOPS

In the addition benchmarks, one FLOP is one addition.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

...computer

This would most likely also be true if the application is ported to a SPMD environment similar the one ScaLAPACK uses, although some problems with vectors may emerge.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

...architecture

Function evaluation is an exception, but even this feature may be kept independent of architecture (but inefficient). Yet, one still has the option to use architecture dependent features.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.