APL2007 update

APL2007 update

Post by Mike Ken » Thu, 04 Oct 2007 21:21:32


APL 2007 in Montreal (only 2 1/2 weeks away, Oct 20-22).

Summary program information is now available
on the APL2007 home page

http://www.yqcomputer.com/

with a link to the comprehensive program description at

http://www.yqcomputer.com/ #a2


Registration for APL2007 is at

http://www.yqcomputer.com/
 
 
 

APL2007 update

Post by Beliavsk » Thu, 04 Oct 2007 21:49:38

I wonder if any APL programmers have tried Fortran 90 or a later
version of the language. F90 introduced array operations into the
language, which is something APL is known for. Considering that
Fortran compilers are more widely available than APL interpreters,
what are the main advantages of the latter that keep some people using
it? What about APL vs. another interpreted language such as Octave of
Python+Numpy?

The repeated announcements of an APL conference in comp.lang.fortran
are what "provoked" me to ask this question.

 
 
 

APL2007 update

Post by Michael Me » Thu, 04 Oct 2007 22:53:30


At the time I briefly used APL, around 1981, its fans claimed that, as an
interpreted language, it could be used very effectively to develop
algorithms. For production purposes, these would then be translated into
Fortran. So, the one did not exclude the other.

Regards,

Mike Metcalf
 
 
 

APL2007 update

Post by glarocqu » Fri, 05 Oct 2007 03:19:05


The announcement of an APL conference is APL2007, and it is organized
by SIGAPL.
This conference will focus on Array Programming Languages, not only on
the
traditional APL. So users of Fortran 90, J, Octave and Python and
others Array
Programming Languages are more than welcome to come to Montreal and
participate
in the debate. It has been the policy of SIGAPL to promote links among
users
of all Array Programming Languages for several years.

Guy Larocque
SIGAPL Chairman
 
 
 

APL2007 update

Post by neitze » Fri, 05 Oct 2007 05:42:55


Bob Bernecky did so, and he wrote a fine description why F90 is
still miles away from APL. I'll dig out the exact APL QQ reference
tomorrow. (IIRC the main point was that F90 has a rather constrained
set of array operations; REDUCE exists is limited to a few primitive
arithmetic operations only.)

Martin Neitzel
 
 
 

APL2007 update

Post by jk » Fri, 05 Oct 2007 07:00:54


Yes, I did. As an exercise I re-coded Phil Benkard's SUMROUND-function
(APL91 - Stanford) in Fortran90. The function was rounding of values to
a given number of decimals (or rather powers of 10) in the left arg, with the
requirement that the sum of the rounded off values should exactly equal the
rounded off sum of the bare values (e.g. as required in financial reports).
Executing the Fortran90 on 10000 values gave me time not only to get
and drink coffee, but even to collect and burn the beans.
That's why I stuck to APL.

An other funny story is that in some project the "programmer's team" wanted
to see Fortran code, while the work was already done in APL by the responsible
engineers satisfactorily (funny? silly? but true!).
The APL-people decided to write an APL code that produced the thing in
Fortran, so, they had their Fortran code (APL Toronto '93 - it's on video tape).
But why? How would you ever write, test and debug 20.000 lines of Fortran?
S.E & O.

Jan Karman
http://www.yqcomputer.com/
 
 
 

APL2007 update

Post by jk » Fri, 05 Oct 2007 16:42:50

"jk" <*axy*@planet.nl> wrote in message
news:4704113d$1$25500$ XXXX@XXXXX.COM ...

As Phil Benkard put it that time in his paper 'A Dance of Rounds' litteraly:
"Rounding off is a bit of lying."
How much are you lying? In the platina grey pre-computer days my actuarial
science courses provided a few simple lessons in numerical analysis on the
topics of 'shorthand multiplication and division'. The aim was to know how much
exactly you were lying in rounding off. E.g. 23.456 x 53.14, in which 53.14 had
been somewhere between 53.135xx and 53.144xx, myriads of those manually
with the comptometer or sumlock, later by electrical machines. Not surprising
that Phil's routine is still one of my favourite subjects - in fact it's a
beauty! I'll remember it "when I'm 94 ...", because Phil's function did exactly
what I had learned far back in the past.

The fact that the APL routine consisted of say 30 characters (including the
header, line-numbering and both the del's, that is) and the Fortran90 code
needed two pages A4 is, in the meantime, a corny, if not a stale remark.
Reasoning backwards, it's a very instructive excercise to take a sheet of paper
and pencil and construct a table with a real example, following the process in
Phil's APL function (backwards of course, each primitive a column) in order to
see what's happening. This indepth paper & pencil analysis is indispensible
when coding in Fortran(90).
By the way, web-teaching, which is poisoning our students these days, will never
cross this sort of exercises, although they are crucial in learning.

Re the Fortran90 routine: I had to cancel the process at five by <Ctrl>+C.
The APL-function took a few seconds (on a VAX/VMS 750 system in VAX APL).

You might wonder how K is performing in this funtion. In K, you rather talk
about an array of say 500,000 or 6,000,000 items (remember that a middle-sized
life-insurance office is a billion half penny's business).
An always attractive, intriguing, what do I say, seducing property of this sort
of APL-routines is that they often can be mirrored into K (I'm now talking
about the body of the function). The characters will be different but the
primitive functions are the same. Here is the K-routine:

f:{x*(_ y)+(<>d)<-0.5+/d:(y:y%x)!1}

It's identical to Phil's APL routine, and you even may now reversively mirror to
APL from it, x and y being right and left arg respectively.
The sequence "<>" is the bottleneck for the Fortran code: you'll need the
indices from the grading up and down! They are "wheighing" the values to be
rounded, deciding whether it's going up or down. (Look at the paper with the
analysis).
The Fortran90 SORT routine only gives you the sorted array - who needs it?

I had expected the K-routine to performing sub-second on a (few) million items,
but it's still between one and two on my PC. That figures the tax of the
function to the CPU.

A J-function would probably look a bit different - I'm not familiar enough with
J to provide the routine. Eugene McDonnell will certainly have done so in one of
his "At Play with J".

Happy Fortranning!!
Jan Karman
http://www.ganuenta.com





 
 
 

APL2007 update

Post by Walter Spe » Fri, 05 Oct 2007 21:57:11


I used DEC-10 APLSF a lot back in the 1970s. Also used the CDC 6000/ ***
UMASS version some. Fun language!

Sadly, Fortran does not have a Standardized SORT routine. Some Fortran
implementations do offer entry points into the qsort(3c) routine.
But these are slow due to the necessary calls to the user-defined
comparison routine.

The High Performance Fortran (HPF) Standard had GRADE_UP and GRADE_DOWN
intrinsics defined. (I wonder where they got those names from? ;)
HPF 2.0 defined SORT_UP and SORT_DOWN intrinsics. However HPF is mostly
ignored by vendors these days. Even the good parts.

W.
 
 
 

APL2007 update

Post by jk » Sat, 06 Oct 2007 00:08:31


This is a bit beyond my scope, but I'd say that the bottleneck for Fortran lies
in the sorting, the APL-{grade-up} {grade-down}, in other words a different
approach of sorting. In that operation APL gives you the indices for the array
to be sorted, while Fortran gives - by a runtime routine - the sorted array.
Please, see also the later postings.
Sorting is a big thing in computing. Performance may stand or fall with the
sorting algorithm. As far as I know, e.g. Dyalog uses Hoare's
algorithm for sorting - the fastest one known at present (I was told by somebody
who is supposed to know).
 
 
 

APL2007 update

Post by Dan Nagl » Sat, 06 Oct 2007 00:31:17

Hello,




Well, there is no Fortran sort. So the design
of the external sort routine is determined by the author
of the external sort routine.

Also, the amount of memory traffic (I presume that's the issue
you're implying here) will be the same for sorting the indices,
usually Fortran default integers, as for any other data type
requiring one numeric storage unit.

Perhaps there should be a standard Fortran sort, but as of the present,
there isn't.

--

Dan Nagle
Purple Sage Computing Solutions, Inc.
 
 
 

APL2007 update

Post by nospa » Sat, 06 Oct 2007 01:46:50


Which is to say that the criticism seems to have nothing to do with
Fortran, but rather with an author who either did not know Fortran or
chose not to use it. Doesn't sound like a very good basis for judgement
to me.

--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
 
 
 

APL2007 update

Post by jk » Sat, 06 Oct 2007 02:24:41

"dpb" < XXXX@XXXXX.COM > wrote in message news:fe35d5$vtm$ XXXX@XXXXX.COM ...

In the Fortran routine I used the external routine ('runtime routine') that came
with the compiler;
APL has it's own {grade-up}, {grade-down} - but we write 199x ? and I haven't
seen anything since. I had other APL-funtions that tumbled on "sorting" (not
really, but when benchmarked). Some authors wrote entire books on sorting
(Flores, Knuth, Lorin and others), so it must be something wothwhile to think of
...
All I can say is that it seems the system was apparantly working and working on
the sorting part. (It reminds me of the paper of Dan King on Arthur Whitney's,
while demo-ing his Kdb, where a manager said: "Well, I can do that too with my
system" - making his machines hang, in the meantime telling that he "really must
go by now" ...


 
 
 

APL2007 update

Post by Bob Smit » Sat, 06 Oct 2007 02:25:35


[...]

I'd be surprised if Dyalog uses Hoare's algorithm (also known as
Quicksort) as it is not a stable sort.

--
_________________________________________
Bob Smith -- XXXX@XXXXX.COM

To reply to me directly, delete "despam".
 
 
 

APL2007 update

Post by jk » Sat, 06 Oct 2007 03:19:39

Bob,

Pete Donnelly told me ... about 10 years ago.
 
 
 

APL2007 update

Post by seth » Sat, 06 Oct 2007 03:53:46

In article <4704113d$1$25500$ XXXX@XXXXX.COM >,



"Distributive rounding" I remember doing that in the late 1970's in
APL 5100. My sarcastic comment was about the bank's Board of
Directors being able to check if numbers added up.

Doing it in two dimensions makes life interesting.

Even in one dimension, the problem isn't quite so simple: is it more
harmful to round 1.4 up to 2, or 10.3 up to 11? Your inputs are 1.4,
10.3, and 30 X.01's.

Seth