Newsgroups: comp.lang.apl
Path: watmath!watserv2.uwaterloo.ca!torn!cs.utexas.edu!uunet!uunet.ca!geac!itcyyz!yrloc!rbe
From: rbe@yrloc.ipsa.reuter.COM (Robert Bernecky)
Subject: Re: Numerical Analysis + APL/J
Message-ID: <1992Aug12.043633.22495@yrloc.ipsa.reuter.COM>
Reply-To: rbe@yrloc.ipsa.reuter.COM (Robert Bernecky)
Organization: Snake Island Research Inc, Toronto
References: <BEVAN.92Aug3165658@jaguar.cs.man.ac.uk> <1149@kepler1.rentec.com> <1992Aug10.160516.1953@yrloc.ipsa.reuter.COM> <1167@kepler1.rentec.com>
Date: Wed, 12 Aug 92 04:36:33 GMT
Lines: 56

In article <1167@kepler1.rentec.com> andrew@rentec.com (Andrew Mullhaupt) writes:
>In article <1992Aug10.160516.1953@yrloc.ipsa.reuter.COM> rbe@yrloc.ipsa.reuter.COM (Robert Bernecky) writes:
>>In article <1149@kepler1.rentec.com> andrew@rentec.com (Andrew Mullhaupt) writes:
>>>However, the Jacobi iteration is going to be _quite_ slow compared to languages
>>>which can modify small pieces of big arrays quickly. However, Jacobi iteration
>>>is pretty much obsolete, so it's not such a great example.
>>
>>Andrew:
>>I don't know whose crummy APL interpreter you are using, but don't confuse
>>poor implementations with poor design: 
>
>That's not the only thing standing in the way of a fast Jacobi iteration.
>Like a lot of eigen-computations, you end up chasing down diagonals and
>applying small transformations. The loop overhead will hurt, accessing the

Reread the line you included above:
a. loop overhead: This is associated with interpreters, and some are worse
   than others. Switch to a compiler.
b. The line just below here (Won't fit in cache) has nothing to do with
   language design, but rather with hardware design. In particular,
   it presumes that all caches are wonderful AND that they'll never be
   big enough. Both assumptions are (for different reasons) false.
   And, both have nothing more to do with APL than with any other language.


>elements of the matrix (which in real life doesn't fit in cache) will hurt
>
>Worst of all, the Jacobi iteration is one of those times when you have to
>make sure that APL doesn't screw you up with quad-CT. There's nothing

Umm, that's why people set comparison tolerance to zero. The comparisons
are not weirdo, merely different from computer hardware weirdo.
Setting it to zero gives you computer hardware weirdo.


>less enjoyable than having to analyze an algorithm just for APL's wierdo
>comparisons, so the best thing is to disable it. Better yet, dynamically
>
>I haven't used APL seriously since I left Morgan Stanley*. Until an APL 
 
This is clear.

>mapped variables I won't be using APL anytime soon. Splus gives me this,
>and that makes up for what (if it were APL) might very well be record
>breaking sloth.

What's Splus? (EMail is OK). Bob




Robert Bernecky      rbe@yrloc.ipsa.reuter.com  bernecky@itrchq.itrc.on.ca 
Snake Island Research Inc  (416) 368-6944   FAX: (416) 360-4694 
18 Fifth Street, Ward's Island
Toronto, Ontario M5J 2B9 
Canada
