Newsgroups: comp.lang.apl
Path: watmath!watserv1!torn!utcsri!rpi!zaphod.mps.ohio-state.edu!mips!darwin.sura.net!haven.umd.edu!socrates!socrates!rockwell
From: rockwell@socrates.umd.edu (Raul Deluth Miller-Rockwell)
Subject: Re: SIGNUM of teaching numerical methods
In-Reply-To: andrew@rentec.com's message of 15 Jul 92 16:56:02 GMT
Message-ID: <ROCKWELL.92Jul18201144@socrates.umd.edu>
Sender: rockwell@socrates.umd.edu (Raul Deluth Miller-Rockwell)
Organization: Traveller
References: <13JUL92.15740134.0088@UNBVM1.CSD.UNB.CA> <1060@kepler1.rentec.com>
	<ROCKWELL.92Jul14234800@socrates.umd.edu> <1070@kepler1.rentec.com>
Date: Sun, 19 Jul 1992 01:11:44 GMT
Lines: 72

Andrew Mullhaupt:
   This problem is to permute the rows and columns of a band matrix in
   such a way that the bandwidth is reduced, (but that the system of
   linear equations that the matrix represents is preserved). Whenever
   one talks about band matrices, it should be assumed that the matrix
   is large enough that the matrix cannot practically be stored in a
   dense form.

Hmm... Sounds like an interesting sort of problem.  But it seems to me
that there ought to be no solution for the general case -- that you're
concentrating on revealing a structure which is there, but obscured.
This isn't necessarily bad, but I do wonder if there might be other
ways of expressing the structure?

This isn't even my area -- most of my work is textual, or with
discrete math.  But, it seems to me that you're focussing on
converting between two intermediate forms, not focussing on a class of
result.  Mostly, though, if I found that I had to do such
manipulations, and they were time critical, I'd have a routine made up
to do precisely this manipulation.  [Compiled APL, maybe, hand coded
assembly if that was inadequate -- maybe use compiled APL for argument
passing, get someone real good at assembly to do the detail work].

But, I kinda doubt that this is completely applicable to your case,
because I kinda doubt that this band compression is the essence of the
operation you're trying to speed up -- sounds like it is just a piece
of the way you express the overall operation [whatever that is].  If
this is true, you'll lose because it's not band compression that's
eating your time, it's argument passing overhead.  If it's false,
well, then you'd be using a hand coded routine to implement it, and
you'd be describing it using a simple but extravagant APL expression
which computes the same result.

Hmm.. Maybe it would be nice to have a generalized NP-complete or
NP-hard operation [one which solves some sort of generalized packing
problem or graph problem, using one or more of the well-known
"approximate solution" techniques].  No?

   Band-reduction code can be found for example in the Yale Sparse
   Matrix Package.

And if I ever have a need for Band-reduction code, I might look there.
More likely, I'll first look in a math text to see what kind of
properties this operation has, and I'll work to get a better
understanding of the overall problem I'm working with.

   Yup. As long as _something else_ is there, APL is bearable. But
   then the problem is what use is the expressivity of APL for the
   complex algorithms which require high performance?

They don't follow the 90/10 rule?  [that 10 percent of the code takes
90 percent of the time].

   The list of things which might actually look _great_ in APL but
   can't be in APL for performance reasons is almost as long as the
   list of things which are really putrid looking in APL but can go
   fast enough.

Well, if you start optimizing the solution before you know that the
solution is, you can shot yourself in the foot, performance wise.
I've run into quite a number of problems where by taking *out* an
optimization and making the code run *slower* I can solve the overall
problem *faster*.  This is a simple consequence of the fact that the
resulting code is more generally applicable to the problem at hand.

I'll agree that there are occasionally operations which are so time
critical that they must be hand-coded.  But, if you're spending the
bulk of your design time down at this level, there's a good chance
that there is a better way of approaching the problem.

-- 
Raul Deluth Miller-Rockwell                   <rockwell@socrates.umd.edu>
