🚀 go-pugleaf

In article <1992Apr7.174954.10303@newshost.lanl.gov> jlg@cochiti.lanl.gov (Jim Giles) writes:
>In article <ROCKWELL.92Apr6230831@socrates.umd.edu>, rockwell@socrates.umd.edu (Raul Deluth Miller-Rockwell) writes:
>|> [...]
>|> >        A(0: :2) = A(1: :2)
>|> [...]
>|> You're leaving out the big picture here, which is: why are you doing
>|> this operation in the first place?  Chances are, there are other ways
>|> of expressing the algorithm which don't involve this sort "partial
>|> array mangling".
>
>On the contrary.  There are numerous numerical problems for which 
>manipulating the odd elements on one time step and the even elements
>on the next is _exactly_ what you want to do.  In fact, for these 
>problems _IF_ an alternate algorithm exists at all, it is usually
>less stable numerically, slower, or both.  This example was chosen
>to demonstrate the simplicity of notation for manipulating arrays with
>stride.

I concur that there are places where J would be required to stand on
its head to handle the even/odd time step functions in what serial
computer programmers call "an efficient manner".  Although there may
be ways of doing this using tesselations, the challenge to the J or APL
implementor remains one of doing it well on a serial computer. 
I think the problem is less severe on parallel machines.

>|> data types -- there's just too much bookkeeping required for operator
>|> syntax to be very useful.
>
>I consider J's treatment of type to be crippled.  It gives me (so far
>as you've presented) inadequate control over the operational use of
>data.  Something like Fortran (or Ada, C, Pascal, Modula, etc.) is
>much preferable to the "typeless" identifier system used in J.

I think this can be handled adequately in a compiled environment,
with use of a bright compiler and assertions embedded in the code.
For example, an assertion that some array is rank 2 is really 
the same thing as a declaration to that effect.
This allows a compiler to construct efficient code based on said
assertion.

>|> 
>|> It's an identity operation on arrays of rank less than two.  That's
>|> different, in my opinion, from "makes no sense".
>
>It generally makes no sense to explicitly apply an identity operation.

I disagree. A lot of conditional application of a function may be
viewed in a functional sense as "Apply f to the elements of the array
which meet the IF condition. Apply identity to those which do not."
This has the property that it may run considerably faster than code
which contains explicit branches and is therefore hard to optimize,
or which may cause pipeline constipation.

>If you know the type of your argument ahead of time, you don't bother.
>If you don't know your type ahead of time, your code will be inefficient
>and likely buggy since you're coding in the dark.

Ah, that depends. Consider the lowly pocket calculator. Do you have to
declare the type of the data you're using? Nope. 
Now, let's write an algorithm. Lessee here.  "a+b-c". There. That
wasn't too hard, was it? WIll it work for integers? Yup. Floats?
Yup. Complex. Yup. 

The point being: Why write 3 or more algorithms when one will suffice?
A fairly reasonable compiler can even do data flow analysis and generate
optimal code if it can determine (perhaps via an assertion - see above)
that the arguments are always of type X.

As for code being buggy: Not as likely as if you have to write AND 
MAINTAIN the same algorithm for many different data types.

>
>That's what I said.  Your rank 5 array is a rank one array whose elements
>are large.  Fortran 90 has a way of doing that.


No. It's a rank 5 array, just as the lad said. 

>
>I'm not interested in novice programmers per se.  I'm interested in
>_expert_ programmers.  But you're right, the decision of whether the
>default semantics of arrays is row-wise of column-wise does not effect
>novices - so the natural column-wise ordering should be chosen since
>that's what most _existing_ programmers are familiar with.

I bleev that Fortran is the only common computer language in which 
arrays are column-oriented.

>|> Here, 'comma rank minus-one' defines the desired operation.
>
>You mean `comma quote underscore one'.  And, I don't know what this
>does, but it appears to explicitly denote a direction - which is what 
>I said _should_ be done.  You have presented an example which supports
>my position which was that there should be no default direction for
>those operations for which no `natural' default exists.

The choice of a default is a convenience to the user. If you wish,
for pedantic or other reasons to ALWAYS specify the direction,
you are free to do so.

>|> The advantage of this rule is 'rank' has a consistent and easily
>|> understandable definition which is usable with any operation in the
>|> language.  No exceptions are needed.
>
>I still don't understand what it does.  Does it apply to the vector
>or to the array?  

It applies to the verb.

>Exactly.  I _wanted_ the function to be more verbose so that I can
>read the code several months later (or read other people's code) and
>have a chance of seeing what it means.  It also gives more explicit
>information to the compiler for optimization purposes.   

a. Verbosity masks comprehension. If you need comments, add them.

b. "It gives... optimization": No, it does not. The compiler has that
   information at hand anyway.

>You gave no J example of the code to do this operation, but I suspect 
>it will contain no clues at all about the rank of it's arguments - and 
>therefore provide neither the compiler nor the programmer any idea what's 
>going on.  Further, the example was stated as requiring a function to 
>handle arrays of rank 4 through 7 - without an run-time test, how does 
>your J code insure that arrays of rank greater than 7 aren't incorrectly 
>passed?

assert ($$ X) e. 4 5 6 7

That is, assert that the shape of the shape of X is a member of 
4 5 6 7.
If it ain't, you croak. 



Robert Bernecky      rbe@yrloc.ipsa.reuter.com  bernecky@itrchq.itrc.on.ca 
Snake Island Research Inc  (416) 368-6944   FAX: (416) 360-4694 
18 Fifth Street, Ward's Island
Toronto, Ontario M5J 2B9 
Canada