Newsgroups: comp.lang.apl
Path: watmath!watserv2.uwaterloo.ca!mach1!torn!utnut!cs.utexas.edu!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!destroyer!gumby!calvin!ursa!abalje47
From: abalje47@ursa.calvin.edu (Alan Baljeu)
Subject: Re: efficient J programs (shellsort)
Message-ID: <abalje47.735855110@ursa>
Sender: news@calvin.edu (The Annoying News Pseudo-User)
Nntp-Posting-Host: ursa
Organization: Calvin College
References: <abalje47.735520194@ursa> <1993Apr23.203153.822@csus.edu>
Date: Mon, 26 Apr 1993 20:11:50 GMT
Lines: 67

vpcsc4@sfsuvax1.sfsu.edu (Emmett McLean) writes:

> My experience has been that it really depends on what you are trying
> to do. I've seen a _few_ instances where tacit verbs consistently
> out performed their explicit counter parts, and many instances where
> the difference in performance was at best very marginal and not
> consistent. In your example, ShellSort might be written using explicit
> definition in such a way that no boxing is required. Since boxing is
> an expensive operation, the explicit version such a version 
> would run faster.
Why is boxing so expensive?
I would have guessed boxing would be implemented by creating an array of
pointers to the original object.  Indirection is not a very costly operation,
really.  It sounds like entire arrays are being copied over.


> (I am keeping my fingers crossed that ISI can find
> someone to work on a debugger for the fall release. 1!:2&2 only
> isn't much to work with.)
(before the debugger, how about just improving error messages.  When a verb
that has been created on a high level of nesting, (shellsort is a relatively
small example) it is rather difficult to determine the source of 
"domain error".  I've seen APL systems that point out exactly what they were
trying to evaluate at the time of error.  Instead of "range error", how about
"expected this range:       for this verb:     "?

> As I mentioned, there is alot of overhead with boxing and opening. This
> is also true with APL (Incidentally, J compares favorably to other APL's on
> boxing time).  And generally, the larger the item being boxed ( or
> being opened) the more overhead there is.
I still don't see why boxing is so difficult.  Please enlighten me.

>>5) As far as I know, there are no searching verbs/conjunctions.  Did I
>>overlook one?  It seems to me such is called for, and searching is likely
>>a big part of the inefficiency.
> Post what you'd like to see. I think the dyadic case of i. (indexOf)
> is J's fundamental starting verb for writting searching verbs.    This
> may be what you are overlooking.

indeed, I hadn't looked at indexOf before.  It does do searching, but it does
not accomplish what I want.  Problems are:
1. It is O(n) where n is the size of the left hand array. On a Sparc IPC:
	x =. i.100000
	100 (6!:2) 'x i. 10'
0.584882

Obviously, it is attempting to look at every item in the array even though 
10{x = 10 is what it is looking for.  The point of a search verb is save time
by not going the whole way.  This is especially true in shellsort.

2. I don't want to search for 10, I want the first number larger than 10.
i. won't even do that unless I generate a whole new array which consists
of 1s and 0s.  (in which case I might as well use characteristic.)  So what
I really need is a searching adverb: search for function = 1;
Like this: (>&10) search x
However, this solution doesn't cover all grounds, because some time I
will need a binary search. Arrays are ideal for binary search, but J isn't
because the notation is still a bit clumsy.  (but ^: etc is a big improvement 
over `:k)  I would really like to learn of a better J-ish style for doing that
kind of thing.

> Emmett

Alan Baljeu
--
			 Alan Baljeu
abalje47@ursa.calvin.edu
