Newsgroups: comp.lang.apl
Path: watmath!watserv2.uwaterloo.ca!torn!howland.reston.ans.net!agate!news.ucdavis.edu!csus.edu!sfsuvax1.sfsu.edu!vpcsc4
From: vpcsc4@sfsuvax1.sfsu.edu (Emmett McLean)
Subject: Re: efficient J programs (shellsort)
Message-ID: <1993Apr23.203153.822@csus.edu>
Sender: news@csus.edu
Organization: San Francisco State University
References: <abalje47.735520194@ursa>
Date: Fri, 23 Apr 1993 20:31:53 GMT
Lines: 98

>
>In the process, I came to several questions about 
>efficiency in general when using J.

>I know J has a built in sort, but that is irrelevant here.
>(what algorithm does it use?)

 It uses C's qsort in vg.c

>-@_: is negative infinity, and was placed to get around the case where the
>item to be inserted (left argument originally) was less than all items in the
>array.

 Um. If you haven't already done so, experiment with the alternative :

 nill =. ''"_

 
>Anyway, this whole exercise leads me to ask questions about efficiency in J.
>
>1) The above verbs were written tacitly (not using the : operator)
>because I like the form better, and I believe it is supposed to be faster.
>Is that correct?

 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.

 I prefer the functional format because I don't like the process
 of editing, loading, and checking. But I think it would be a mistake to 
 code in the functional style only for enhanced performance. Also, one can
 make a good case for the explicit style by pointing out that
 the control structures of explicit definition provide for smoother
 algorithms. (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.)
>
>2) Does J spend a lot of time trying to parse my verbs as I have renamed
>all the basic verbs? If that's so, may I suggest an optimization:
>Parse it once, and translate to indigenous form, then execute it.
>(I don't mean destroy the original form).

 It does this. That is, it only parses tacit verbs once, when it is
 defined.  For example their shouldn't be much of a difference between
 ~. and (~: # ])
 
>
>3) My algorithms involved taking apart arrays and putting them together
>in various forms.  Observe the proliferation of: head tail , ; a: b: take
>Does J use a lot of resources to handle these?  How about key?
>Are all these verbs implemented by "make another array"?

 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.

>
>4) In some places, ` could replace ; with some modifications.  Is that
>more efficient?

 I don't think so, but it would not be less efficient.
>
>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.
>
>6) Can someone here find an obviously better verb than any of those I have?
>One that is more in the spirit of J, or avoids J's weaknesses?  Try to
>keep in the spirit of Shell too, though.
>
 We're counting on you!

>7) Doing iterations seems somewhat painful.  Is there a better way to
>use them, without concatenating all the values you want into one array
>of boxes?  Is there a way to get along without all those values?  Like
>perhaps the iteration counter?

 I agree. Programming in J can be painful. But I prefer it to other
 languages (perhaps not Manugistics APL but it's not available here.)
 Experiment with using key without boxing.

 Finally, you are going to find occassions where J preforms *alot* slower
 than C. For example in instances where data *must* be handled sequencially
 where upon each interation a large table is updated . Until someone
 optimizes amend that's just the way it is. 
 

 Emmett
