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/

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.

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.

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

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

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

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/

"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

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

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.

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).

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.

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.

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

"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" ...

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" ...

[...]

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".

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

"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

3. Announcing: ACM SIGAPL APL2007 -- Arrays and Objects

4. ACM SIGAPL / APL2007 Conference / Montreal / one week away

5. Announcing: ACM SIGAPL APL2007 -- Arrays and Objects

6. APL2007 reminder: early (cheaper) registration ends Thursday 9/13

7. cannot get updates from "microsoft updates" "windows updates" OR "office updates" sites to work

8. Windows XP Update Failure, Update problem, Update freezes, Update hangs

9. Office Update optional updates should list some available updates

10. Update including Top, Orderby and updating 2 columns in an update query using TOP

11. Software Updates Not Updating to the Latest Updates

12. critical update from Windows Update continuously wants to update

13. Microsoft Update and Windows Update Fail at "Checking for Updates"

14. XP SP2 Will Not Download The First 3 Critical Updates - Updated Info - Updated More

15. Datagrid not updated during delete, but updated during insert and update