Real/complex infinities, etc.

[uunet!CEBAF.GOV!CELARIER]

Dear Colleagues:

I am greatly concerned about a trend I seem to be observing in many
of the discussions amongst the NCEG postings.  The latest, concerning
infinities in complex arithmetic, hit closest to home with me, but
have analogies in the discussions of integer representations, treatment
of exceptions, etc.

Let me reiterate my greatest concern about the ascendancy of any flavor
of C as a language for math/science:  That is not what it was designed
for, and the tenor of a number of the discussions (particulary, con-
tributions from the compiler-writing community) do not give one much
hope that it ever will be.

When, as a mathematician, I write a symbol, it means just what I want
it to mean:  It has a definite domain, which may be a subset of something
like the integers, the real line, or one or another complex topology.
Modulo the floating-point representation question, I should be able to
represent an instance of this symbol (its binding) and algebraic operations
on it in the programming language of the day.  Forcing me into a 
particular topology of the complex plane (relative to the meaning of 
infinity, for example) makes your language less useful to me, unless I
happen to be working on a problem for which that topology is appropriate.
If I want something else, I will have to program my way around it, and 
I may as well be doing it in assembly language, as in C (or Fortran, or...)

Explicit typing is enforced in C - which is sometimes a hassle, but 
it keeps one honest.  Why, then, is there so much resistance to the idea
of defining the behavior of intrinsic functions in exceptional or
ambiguous cases?  I think that one should always have the opportunity
to tell the computer how I want something done, such as choice of 
Riemann branch in a square-root.  It's okay if there's a default 
behavior for functions ( and default types for variables  :-) ),
so long as I can intervene without going to a language that (at 
considerable expense, often) allows me to overload.

Perhaps this would make writing compilers more difficult, but that
is not my problem (sorry!)  If you do not provide me an environment
in which I can gain this kind of control without excessive 
programming acrobatics, then your compiler looks like an assembler
to me.

I have been watching some, but not all, of the discussions in NCEG,
and I keep wondering if this is really how progress is to be made.
By insisting on such a detailed agreement between nceg-compatible
C (whatever that will eventually look like) and old K&R C, a great
deal of ham-stringing will result.  I fear it as much as I fear that
the HDTV standard really will be chained to NTSC, which was chained
to the original B&W broadcast standard.  Pretty scarry stuff.


-------------------------------------------------------------------|
Dr. Edward A. Celarier		Office: (804) 727-5276	           |
Department of Chemistry		  Home: (804) 722-6393	           |
Hampton University					           |
Hampton, VA 23668		Bitnet: CELARIER a CEBAFVAX        |
USA			      Internet:	CelarieraCebaf2.Cebaf.Gov  |
-------------------------------------------------------------------|