On Dec 27, 3:16=A0am, Harold <hskol...@[EMAIL PROTECTED]
> wrote:
> A new book about financial derivatives, A Demon of Our Own Design, by
> Richard =A0Bookstaber discusses an APL incident(pages 43- 47). =A0He
> describes a problem that APL had difficulty in handling well - in the
> last century.:) =A0The problem was "there was not enough memory to hold
a
> matrix of high enough dimensionality to solve the problem with an
> acceptable level of precision." =A0Looping through the data was
> inefficient due to the interpreting nature of APL.
>
> Since then, available memory has grown rapidly and I have heard of APL
> compilers. =A0I am curious as to the reaction of experts on APL =A0- to
th=
e
> book and the issues raised.
Harold,
Just ordered a copy of the book, I'll be back when I've had a chance
to read more about the incident.
Generally speaking, although memory has grown, the people who do
financial and other analysss will always be taking advantage of that
to run more complex analyses, so many people will be "following the
borderline".
The fact that straightforward APL algorithms do not always scale is
hardly an argument against the use of APL. Usually the fact that the
simple algorithms ("simple" in the sense that they closely resemble
the mathematical statement of the problem) are possible is key to the
ability of financial experts to express executable solutions to the
problems they face. If they had to use a "traditional" language they
would often not have been able to express the solution (this does of
course make the technical issue go away :-).
There is some recent progress in the direction of APL compilers, but
it is hard to compile APL without losing too many of the features of
the dynamic APL environment. A more complex, less easily debuggable
environment is a serious deterrent to the kind of people who use APL
in this way (they are not "IT minded"). In large APL shops, it is
common to have a small team working closely with the APL experts to
write C code, some teams also use APL to generate C or Fortran code
and subsequently compile and call that for the kind of memory or CPU
hot spots that I imagine were a problem for Mr. Bookstaber.
Successful use of APL often hinges upon insight into where it is a
good idea to use APL and where traditional languages can help work
around the limitations. The good news is that modern computing
framworks (Microsoft.Net in particular, because it is "language
agnostic") are making this much easier than it has been in the past.
Morten Kromberg
Dyalog Ltd.
|
