🚀 go-pugleaf

In article <1992Apr11.172154.21417@yrloc.ipsa.reuter.COM>, rbe@yrloc.ipsa.reuter.COM (Robert Bernecky) writes:
|> [...]
|> 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". [...]

I brought this up, not as a matter of efficiency, but as one of 
numerical stability.  The even/odd time-step approach is more
numerically stable.  So, it solves a wider variety of problems.
And those that _can_ be solved by other methods still require
finer meshes and shorter time-steps to converge.

|> >[...]
|> >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.

Fine, as long as the assertion can be made up-front and not have to be
repeated at the site of use.  But, J has no clearly identifiable location
to call "up-front".  Where can I put all these assertions?  Or do they 
have to be scattered throughout the code at the site of use of the
things they refer to?

|> [..]
|> >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. 

Fine.  As I've stated before, the pocket calculator analogy is perfectly
appropriate for problems which can be solved by a `session' with such
a calculator.  Such simple problems are beneath the scope of this
discussion.

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

But, you _DON'T_!!!  I agree that for those things in for which
generic algorithms exist for a wide variety of possible aggument
types, you _should_ be able to write _one_ copy: with the appropriate
declarations to specify that it's generic and in what way.  For
the vast majority of sophisticated scientific/numerical work where
the algorithm is not stable, fast, or memory efficient for more than
one data type, writing generic interfaces is a waste.  Having the 
genericity _automatic_ invites misuse and maintenence problems.

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

Which may explain its continuing popularity :-).

|> [...]
|> >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.

Tersness masks comprehension.  It _always_ requires comments (which
fanatics of terse languages _never_ provide).  The issue is one of
compromise - which fanatics of some terseness ethic can't be made
to understand.  If _short_ is a synonym to _right_ in your vocabulary,
there's no point discussing this issue anymore.

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

So far, it has _NOT_ been demonstrated to have _any_ such information
_normally_ at hand.  The programs posted as examples _deliberately_ leave 
the rank, base type, and size of all their arguments unspecified.  The 
fact that you _now_ provide an adequate means of declaring type information
(which you have been avoiding and stating was undesirable) doesn't
eliminate the fact that the recommended coding style _doesn't_ provide
this information and defaults to unecessarily generic code.

|> [...]
|> >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. 

We've alread seen this part.  I admitted already that it did half of
what I want.  How do I prevent X from being _assigned_ the wrong shape
object?  Or, do I have to wait for this expression to be used (which 
may occur _far_ from where X is assigned - making the error hard to 
backtrack).  In short, it appears to me that this is a _run-time_ test
(or, at least, that it usually is - there may be a _rare_ case where
all assignments to X are statically visible to the compiler and that
the compiler _KNOWS_ that it has seen _all_ the assignments).

J. Giles