🚀 go-pugleaf

In article <TED.90Aug3120910@kythera.nmsu.edu>, ted@nmsu.edu (Ted Dunning) writes:
> 
> In article <2426@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:
> 
>    Which machine's floating point representation are you going to use?
> 
> whichever machine you are on.

Then you do not have full portability.  In using a Monte Carlo procedure,
you will get an acceptance on one machine rejected on another.  If many
random inputs go inot an observation, all observations after this happens
are different.  This is a lack of portability, and is not merely a matter
of accuracy.

			......................

> 	   c{'z} ={tc} {-}{|}{ta}a{'x} OP{mod} {|}{tb}b{'y} {/\{~}w}
> 
>    is the way I would write the general vector instruction on the
>    CYBER 205.
> 
> care to justify this?  or is the fact that you would write it that was
> sufficient to make everyone want to write it that way?

Only partially.  I do not expect someone else to come up with exactly
the same thing, but it would be very similar.  The vector c is the destination
vector, with z an optional offset; tc overrides the type (half or full) of
the operation, - means negation, | means absolute value, ta and tb can
override the vector or scalar aspect of the corresponding type, and if
vectors they can have an offset, if present w is a bit vector determining
which values are substituted, and ~ means complementation.  OP is the operator,
and some of the operators have modifications, with defaults depending also
on the types.

Compare this with the customary assembler type of statement for ease of
understanding.

>    Packing and unpacking floating-point numbers are portable
>    constructs, but I know of no HLL which has them.
> 
> actually this isn't even true, since the sizes of and limits on the
> components can very tremendously from machine to machine.

So can the sizes of the various types in C or Fortran.  It is no less
portable than the arithmetic operators in the HLLs.

>    These should be operators, not function calls.
> 
> you don't ever seem to answer the point that you only need to do fast
> what you do often.  do you really unpack as many floats as you
> multiply?  why does this operation need to be an operator instead of a
> function call?

Even if the function is totally inlined, so that it is as fast as
an operation, I see no more reason why =PACK (or something like
that) should be a function call than +.  There also is the problem,
lacking in most languages (I believe this can be done in LISP) of
multiple returns from an operation.  +UP (unpack) returns two values,
as does division with quotient and remainder.

> is it that there some deep psychological need to unpack things
> quickly?

Why do some computer scientists seem to have some deep psychological
need to make things clumsy?  If I want to unpack things, I see no reason
why I should have to use inadequate notation because the language guru
does not see why someone would want to unpack.  Nor should I have to 
pass an address and load because they forgot, more than 30 years ago,
that natural operations can return more than one result.

Why should I have to do things slowly because of the antipathy of some
computer scientists to the idea of the user using the relatively simple
structure of the machine?  Why do they want to leave out the natural
hardware operations?  By a natural hardware operation, I mean one which
can be done easily by simple use of computer circuits and at most
nanocode.

>    The idea of open subroutines, a cross between macros and inlining,
>    existed at the time of Fortran I.  Fortran VI on the CDC3600
>    allowed 3 additional types (to make a total of 8), and allowed the
>    user to define the Fortran operations on these types, but only by
>    subroutine calls.
> 
> these seem irrelevant.  unless, of course, you are still programming
> in fortran I, or on the 3600.
> 
>    Why can we not have additional operator SYMBOLS added to a HLL?
> 
> you can.  note prolog.
> 
>    C and C++ allow additional types, only they do not call them types.
> 
> they do if you define them with typedef in c.  if you don't, then they
> aren't really types since they are syntactically distinguished.
> 
> in c++, they call them structures or classes.  the fact that they are
> types is never denied, this only recognizes the etymology of the
> situation. 

At least according to all the C manuals I have read, typedef does not
allow one to add types, only add aliases.  That there were other types
was explicitly recognized long before C and C++.

>    I was informed by soeone at ATT that the non-allowance of
>    additional operator symbols in C++ was an unfortunate oversight.
> 
> only partially.  it does preserve the ability of the language to be
> parsed by a static parser.  if you allow new operators and new
> precedences, then you get into the serious problem of needing to
> extend the parser in non-trivial ways *at compile time*.  the lisp
> community has been trying to get this just right for decades and is
> still trying.  prolog newcomers still cause insiders to giggle by
> asking for a context free grammer for the language.

This is true.  I would be willing to give up a heck of a lot on precedence
structure, however.  The precedences, except for the common arithmetic
operators, are fairly arbitrary, anyhow.  Why not allow the parser to
ask the programmer for the preference order, as well as evaluation order
if it makes a difference?  A lot can be helped by allowing explicitly
temporary variables to handle intermediate results.

There are ways around the problem of precedence.  Maybe we should get rid
of it completely, like APL.  There are parentheses.  The compliler can
ask the programmer these facts.

When coding myself, I have had only trouble with these arbitrary precedences.
Which has higher precedence, << or +?

> why don't you admit that the fact that *you* don't see any reason for
> something does not mean that there isn't a reason.  you have provided
> ample evidence that it only means that you don't see.

The only reasons I have seen advanced are that not too many people would
use them.  Suppose someone comes to me with a new type of statistical
problem.  After some work, an appropriate class of numerical procedures
is produced for that problem.  I see how a given machine works on the various
procedures, and it is definitely not the case that the same procedure works
well on all machines.  Now, I have to go into contortions to get the procedure
reasonably implemented.

One does not use a different part of statistics for problems in biology
and problems in physics.  One should not have to use a different programming
language for different types of problems.  If a mathematical notation is
clumsy, it usually does not last long.  Neither should clumsy notation in
Fortran or C or Lisp or assembler.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (Internet, bitnet)	{purdue,pur-ee}!l.cc!cik(UUCP)