🚀 go-pugleaf

In article <sb9e0INNdbb@network.ucsd.edu> mbk@lyapunov.ucsd.edu (Matt Kennel) writes:
>rbe@yrloc.ipsa.reuter.COM (Robert Bernecky) writes:
>: 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. 
>
>This is an unusual and mostly irrelevant situation, due primarily to the fact
>that mathematics is nice enough to be able to embed the group of integers
>in the fields of real and complex numbers and have all arithmetic operations
>be compatible and make sense.  This automatic special case conversion is
>built in to nearly all compilers for common languages these days as a special
>treat for the users.  (Pocket calculators just run everything in base 10
>floating point, in any case, right?)

Example of utility of this from Real Life (sorry to bring factual
material into Usenet, Land Of Unsubstantiated Opinion, but whatcha
gonna do?):
  Morgan Stanley Bank in NYC runs a foreign exchange trading system 
  under SHARP APL. On Black Monday a few years ago, trade volumes and
  $$ were so high that most systems either died (overflow) or got
  drastically behind, giving their traders Very Bad Data, causing said
  traders to trade themselves (and their firms) much further into the
  red. Morgan's APL-based system not only didn't die (integers went to
  real instead of getting integer overflow death), but the system didn't
  fall behind, AND Morgan made a profit that day! 

  The specification of "I'll make this integer because it'll run faster, 
  and take less space, and I KNOW IT CAN't possibly overflow" school
  was totally unprepared for the volumes traded that day. 
  It simply was not thought possible. 

>On the other hand, what does it mean to index an array with a complex number?

Where I come from, we get "index error". We also signal "index error"
on things like indexing with negatives, or with numbers > shape of array
axis, unlike C and Fortran. But that's only because we're silly types
who care more about correct results than speed.


>I don't want this error to go until runtime whence it realizes I made
>a typo along time ago when writing it, but the compiler couldn't be sure
>that I wouldn't have passed some integers in that part of the array.

k>(This is of course unsolvable in general because it can't predict what I'm
>going to type in as inputs).

You also cannot predict that your indices will be integral unless you insert an
explicit floor, when you're indexing to do interpolation, etc., so the
point is merely wrong. A little coercion is fine. A blind coercion
is wrong.

>: 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.
>
>In general you'd have to write different algorithms for different data
>types anyway, because most algorithms just plain don't make sense for
>all datatypes, and computers can't invent them from scratch---humans have to.

Umm, maybe I'm missing the point here. The idea is that you DON'T write
the algorithm: the system supplies one for you which is likely better than
you can write, if you are a Normal Programmer, rather than one of the few
Whiz Kids around. If you go to industry, mind you don't get bruised
toes when the scales fall from your eyes, when you see what real (small r)
programmers are, by and large.
University CS departments and national labs are the exception, not the
rule.

>If there's some commonality, then I believe common practice
>is to make a new abstract data type with methods to perform the
>operations that make sense.  The programmer has to write out the specifics
>of implementing those methods anyway, and I find it very unlikely that
>a compiler could always figure out how to do it.

Tsk. No faith in compiler writers. I do believe that abstract data types
have their place. I further believe that compilers can make better code
 with them than without them.


>
>: As for code being buggy: Not as likely as if you have to write AND 
>: MAINTAIN the same algorithm for many different data types.
>
>There's no such thing as a free lunch. Somebody has to make the code
>for all the special cases sometime, somewhere.

That's right. Let's let the compiler writer/interpreter writer do it 
ONCE, and let the users ALL benefit from that skill. If you can do 
better than the compiler writer, send them your resume.


>
>: a. Verbosity masks comprehension. If you need comments, add them.
>
>(You wouldn't happen to be an editor of Physical Review Letters, would
> you?  :-) )
  Nope. (Would a longer answer be more comprehensible?)

>
>Following this suggestion, I think all further articles in this
>thread should be encoded using indexes in /usr/words/dict and
>passed through compress(1).

Yuck. Guffaw. Please add above paragraph to FQS (Frequently Quoted
Statemente in USENET). 

>More seriously, I think that this attitude is a big mistake.  A "verbose"
>language is formalized, explicit and precise commentary.  It may not add

Any formal language conforms to this definition. APL happens to be all
the above, AND be executable, which often is a good way to determine
that your idea and reality differ.

>anything that a compiler absolutely _needs_ to make code, but it adds many
>things that a human needs to rapidly understand the code when reading, and I
>think humans should come first.  I don't think that it should take any

Nope. I disagree. Consider the lowly matrix product. In APL, we 
write:     M +.* N
The + and * are taken from the last line of the 5 lines of Fortran.
You can replace them with and.equal to get associative array search,
or.and to get a transitive closure step, etc.

In APL, the user thinks "matrix product", writes "+.*", and the interpreter
sees a matrix product. 

In Fortran, the user thinks "matrix product", writes 5 lines of code
with 3 new induction variables, which may or may not match the ACTUAL
shape of the arrays, the compiler stares at those 5 lines, and, thanks to
years of effort on compiler design, is able to turn those 5 lines back 
into "matrix product". This is simple? 
 
Now, I know Fortran 90 has some array features in it which partially
invalidate the above, but (a) I can pick other examples (b) Fortran
got those ideas from APL.

>comments ought to be reserved for more abstract issues.  Naturally, if the
>language is too primitive, the lack of powerful features may make it
>cumbersome, but _not_ impossible, to solve some problems.  It's hard to use,

Nonsense. Here, let me limber up my TUring machine here, and ...
( I agree).

>but in an easy way.  A language with hyper-punctuated, over-notated and just
>plain bassackwardsly bizzare syntax engenders headaches every fucking time
>anybody tries reads the code.  (C++ programmers: feel a little familiar?)

I suspect that a defacto set of (Your-language-here) definitions of the
J primitives would simplify learning and reduce the "Oh, how ugly" 
syndrome. 

>Only professional mathemeticians truly have the ability and facility to deal
>with things like this without semi-herculean effort, and mathemeticians are
>about as far away from "real life" as it gets.  No insult intended, but it's
>just not the thing for "the rest of us".

Mathematicians never use the same notation twice anyway.
That's why their books are so thick...

>I'm also of the opinion that humans have biological specialization for
>certain kinds of language, and by language I emphatically *dont* mean
>everything that's turing equivalent.
>
>Do you not think that, say, Italian is easier to learn than Classical
>Chinese for native English speakers?  

I think it may be sociological more than biological. In particular,
Japanese find APL very easy to learn "because it has a lot of symbols". 
(This was a quote from a group being shown APL by Joey Tuttle, formerly
of I.P. Sharp Associates). 

Would a Chineseu person find it easier to learn Italian or ENglish? 

Robert Bernecky 
Snake Island Research Inc  (416) 368-6944   FAX: (416) 360-4694 
18 Fifth Street, Ward's Island
Toronto, Ontario M5J 2B9 
Canada