Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!crdgw1!uakari.primate.wisc.edu!aplcen!visual1.jhuapl.edu!dave
From: dave@visual1.jhuapl.edu (Dave Weintraub)
Newsgroups: comp.lang.apl
Subject: Re: Statistical Functions in J
Message-ID: <1991May29.191441.1279@aplcen.apl.jhu.edu>
Date: 29 May 91 19:14:41 GMT
References: <1991May12.145907.19563@yrloc.ipsa.reuter.COM> <356@tslwat.UUCP> <1991May21.042804.21102@yrloc.ipsa.reuter.COM> <414@tslwat.UUCP>
Sender: news@aplcen.apl.jhu.edu (USENET News System)
Reply-To: dave@visual1.jhuapl.edu (Dave Weintraub)
Organization: Johns Hopkins University
Lines: 22

In article <414@tslwat.UUCP>, louk@tslwat.UUCP (Lou Kates) writes:
|> ...
|> 
|> Personally I   would   rather have   a wider  family of  powerful
|> operations at my disposal (such as regression, constrained linear
|> optimization a la simplex  or Karmarker, eigenvalue calculations,
|> etc.) that are not easily derivable from each other rather than a
|> large  set  of functions which are all readily derivable from the
|> ideas of regression  and   projection.  My own preference, and  I
|> suspect that of many others too, would be  that if   you feel the
|> need to  have zillions of functions at  your  disposal,  define a
|> standard library so that you can take them out of the language so
|> as to keep  the   language  smaller  and more    manageable.   If
|> performance is the  issue   then   there  is  nothing  to  stop a
|> particular  implementation  from implementing  certain   standard
|> library functions in the kernel.
|> 
|> Lou Kates, Teleride Sage Ltd., louk%tslwat@watmath.waterloo.edu
|> 519-725-0646
I fully agree.  This is the path taken by IBM with APL2: write external
functions (in Assembler, FORTRAN, PL/I,  C, ...) and make these available
using QuadNA.