evans@mhuxt.UUCP (crandall) (04/17/84)
<> How many people out there use C as a numerical language? Aside from faster compilers I think that I'd be happy with the addition of a complex type and some improved math library routines. Any comments from the hornet's nest? Steve Crandall (ihnp4)!mhuxt!evans
ctk@ecsvax.UUCP (04/18/84)
I use C in my research. I have code on both vaxen and ibm-pc's for such
things as QR factorizations, Newton's method, Broyden's method, and
integral equations. While I use Fortran when I need more speed than
a vax provides, C does OK for most of what I need.
Tim Kelley
Dept. of Math.
N.C. State University, box 8205
Raleigh, N.C. 27695-8205
decvax!mcnc!ecsvax!ctk
P.S. I'd like complex variables too. This is something one shouldn't be
expected to write on one's own.nather@utastro.UUCP (Ed Nather) (04/18/84)
[]
From: evans@mhuxt.UUCP (crandall)
How many people out there use C as a numerical language? Aside from
faster compilers I think that I'd be happy with the addition of a
complex type and some improved math library routines.
Any comments from the hornet's nest?
Steve Crandall
(ihnp4)!mhuxt!evans
While you're at it, could you put in "**" for exponentiation? You can even
call it "^" if you must.
--
Ed Nather
ihnp4!{ut-sally,kpno}!utastro!nather
Astronomy Dept., U. of Texas, Austinray@utcsrgv.UUCP (Raymond Allen) (04/18/84)
I do practically nothing but numerical computation on the computer. Although I realize that c was not written to do this, I often use it since it seems to run faster than F77. But, I agree with Steve Crandall. A complex type would be a real asset since, if I were to implement complex arithmetic using c as it stands now (I haven't) I would have to write all sorts of functions to implement + - * / as well as sin, cos, tan, etc. etc. It would be fun but I don't want to waste the time debugging all those routines. C'mon you compilier hackers, let's have a complex type (and double complex) in c. (While you're at it, how about an option to use the IEEE standard floating point that the VAXEN support.) It sure would be nice to have an exponent range of +-300!! (Shine my shoes, trim my beard, give me service!! :-) ) Ray Allen utcsrgv!ray (416) 978-5036
dgary@ecsvax.UUCP (04/18/84)
It has always struck me that that biggest advantage of FORTRAN is the fact it is the only language other than PL/I to have a set of math functions with CONSISTENT NAMES. If such could be added to C...
chris@umcp-cs.UUCP (04/19/84)
If you want complex numbers, you can always borrow the F77 library.
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci (301) 454-7690
UUCP: {seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet: chris@umcp-cs ARPA: chris.umcp-cs@CSNet-Relayjcz@ncsu.UUCP (John Carl Zeigler) (04/19/84)
Wouldn't it be better to provide a library of improved math routines, including a 'typedef' for complex or whatever and maybe a version of 'printf' that understands the desired types? Why muck with the language when a library will do? Tim is right, people don't want to do all that themselves. How about some nifty software house providing the proposed 'extensions' as complete and quality libraries?? Here is a chance for some of you to make money. John Carl Zeigler .
gwyn@brl-vgr.ARPA (Doug Gwyn ) (04/19/84)
C already has exponentiation: z = pow( x, y );
tgg@hou5e.UUCP (04/19/84)
Don't use ^ for exponentiation (what a complicated word!) - you'll find that it's already used for exclusive or. Tom Gulvin AT&T - Holmdel
mat@hou5d.UUCP (04/19/84)
If you INSIST on arbitrarily adding types with odd properties to the
language, do it right.
How do you do it right? Make the language type extensible. I don't
want to start up a C-vs-ADA(tm DOD) debate but ADA has a few things
done right here. Look at how they were done, especiallty the
function "+" ...
garbage. There's a lot of stuff WRONG with ADA types; the length/precision
specifications are roccoco (to say the least) but the extensibiility
was well done. Someday we may learn enough about what was done wrong to
feel confident adding it to C. I don't think that that day has yet come.
--
from Mole End
Mark Terribile
(scrape..dig) hou5d!mat
,.. .,, ,,, ..,***_*.merlyn@sequent.UUCP (04/20/84)
"nather@utastro.UUCP" sez: > While you're at it, could you put in "**" for exponentiation? You can even > call it "^" if you must. Gosh. This guy hasn't read his C manual. Both of these are taken already. A ^ B means A exclusive-or'ed with B A ** B means A times B-dereferenced (B is a pointer-to-number) [parsed like A * (*B) ] I don't think there are any (printable) ASCII characters left for C additions. Hmm, does that make C a dense language? If so, it means that C is to Numbers (and text) as TECO is to Text (and numbers). (Ever figure out what your name does if accidentally typed in as TECO commands?) I can see it now... the next C (D? or P?) has control-character tokens or dollar-prefixes... string concatenation is $+ ... and string search is $? ... and array compare is $= ... and structure less-than is ^S< ... and EOF will be a real ^D ... and complex numbers have an infix ^C ... wow! How neat! Randal L. ("dereferenced") Schwartz, esq. (merlyn@sequent.UUCP) (Official legendary sorcerer of the 1984 Summer Olympics) Sequent Computer Systems, Inc. (503)626-5700 UUCP: ...!XXX!sequent!merlyn where XXX is one of: cdi decwrl nsc ogcvax pur-ee rocks34 shell unisoft vax135 verdix
guy@rlgvax.UUCP (Guy Harris) (04/21/84)
> I don't think there are any (printable) ASCII characters left > for C additions. "@" isn't being used - and the claim that it's the "canonical" line kill character doesn't make it less usable; the C preprocessor uses "#" out the kazoo, but it's the "canonical" character erase character. (Both of which were tolerable choices on the local-echoing system they were originally used on (Multics), but very poor choices on the remote-echoing system they were moved to (UNIX) - DEC, at least, realized that with remote echo you can do a lot better, and did!) (Another point for 4.xBSD, which supports DEC-style control character handling...) Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy
rpw3@fortune.UUCP (04/24/84)
#R:mhuxt:-131100:fortune:16200024:000:405 fortune!rpw3 Apr 23 19:24:00 1984 >> I don't think there are any (printable) ASCII characters left >> for C additions. >"@" isn't being used ... Aw shucks... and I was going to use it to introduce "domains" to C, as in "a->b->c->d" becomes "d@a"... ;-} ;-} ;-} Rob Warnock UUCP: {ihnp4,ucbvax!amd70,hpda,harpo,sri-unix,allegra}!fortune!rpw3 DDD: (415)595-8444 USPS: Fortune Systems Corp, 101 Twin Dolphin Drive, Redwood City, CA 94065
emjej@uokvax.UUCP (04/24/84)
#R:mhuxt:-131100:uokvax:3000022:000:847 uokvax!emjej Apr 24 08:34:00 1984 /***** uokvax:net.lang.c / mhuxt!evans / 5:52 pm Apr 17, 1984 */ How many people out there use C as a numerical language? Aside from faster compilers I think that I'd be happy with the addition of a complex type and some improved math library routines. Any comments from the hornet's nest? /* ---------- */ I would not use C as a numerical language, because of the way it promotes float to double with reckless abandon. I can only assume that someone had a very touching faith in double precision when making that design decision; it's a major loss, and I hope that the ANSI standard gets rid of it. If you don't know what you're doing, double precision won't help you in numerical software, and if you do know what you're doing, promoting float to double for all arithmetic operations and function calls is a waste of time. James Jones
tgg@hou5e.UUCP (04/24/84)
I'll be brash (i.e., not look in K&R) and say that '!', used as a dyodic operation, could be used as expnentiation. It even looks nice and it's better than a function because the compiler can cast as needed to mix types. Note that the expedient #define power(a,b) pow( (double) (a), (double) (b) ) will promote lessors to doubles, it won't recognise situations that don't require promotion. Tom Gulvin AT&T ISL - soon to be Silicon Valley.
pedz@smu.UUCP (04/24/84)
#R:mhuxt:-131100:smu:13800004:000:730 smu!pedz Apr 24 13:19:00 1984 I think all of this is stupid. If you want to add things to a language, then start from scratch, call it something besides the name of an existing language, and leave me alone. I have written an FFT program in C, (using complex numbers) and it was simple. Of course I have the ability to think which may be an asset others are lacking. But seriously, the best approach to this problem is with a preprocessor. It can (could) go through your program and change your "**" to macro calls, your complex adds, subtracts, multiplies, and divides to function calls, and put in the needed declarations in the appropriate spots. Then call this preprocessor RATC (with a soft C so you get RATS) and *presto* you've created a monster.
ab3@stat-l (Rsk the Wombat) (04/25/84)
I use C extensively in image processing and pattern recognition
applications; I have had to create a subroutine library using "complex"
structures in order to make some of the arithmetic palatable.
Now if only IMSL was written in C...
--
Rsk the Wombat
UUCP: { allegra, decvax, ihnp4, harpo, teklabs, ucbvax } !pur-ee!rsk
{ cornell, eagle, hplabs, ittvax, lanl-a, ncrday } !purdue!rskignatz@ihuxx.UUCP (Dave Ihnat, Chicago, IL) (04/26/84)
..."dyodic"??? Dyadic, dammit, it's *dyadic*!!... Incidentally, it's kernel, *not* kernal or other mixes... ...Sorry, but this bugs me... Dave Ihnat ihuxx!ignatz
eric@gang.UUCP (Eric Kiebler) (04/27/84)
[arf] ... and when we are all done, we can call the language ICON instead of C. eric -- from the gang down at... 38.37.45 N 90.12.22 W ..!ihnp4!afinitc!gang!eric !wucs!gang!eric Any sufficiently advanced technology is indistinguishable from a rigged demo.
bobl@zeus.UUCP (04/27/84)
From: uokvax!emjej: "... if you do know what you're doing, promoting float to double for all arithmetic operations and function calls is a waste of time." This is true, but I would add that if you REALLY know what you're doing, floating point in general is a waste of time. As far as I'm concerned, the most serious deficiency in C for numerical purposes is lack of "very long" (i.e., 64 bit) intermediate results in integer computation. I believe the IEEE floating point standard guarantees a wide intermediate result (80 bits?). (I hear DEC isn't too pleased with that.) There should be a similar standard for intermediate integer results. I am *not* suggesting a "long long" type. This would require no modification of C syntax. The only programs that would be affected would be those that relied upon generating overflow within expressions during multiplication. Yes, I know about the "mp" multiple precision package, but if I have to call a function to multiply two long ints, I've lost to floating point. - Bob Lewis ...!tektronix!teklds!bobl
mark@elsie.UUCP (04/27/84)
<> >>I would not use C as a numerical language, because of the way it promotes >>float to double with reckless abandon. I can only assume that someone had >>a very touching faith in double precision when making that design decision; >>it's a major loss, and I hope that the ANSI standard gets rid of it. At the recent UNIFORM (DC) meeting it was indicated that the double-precision only feature of C would *not* be part of the ANSI standard. Those of us with 32 bit machines and numerical problems will be glad to here that, though it will be many years befor all compliers will adhere to the standard. BTW: What is the origin of the double-precision only nature of C? I've heard three differing, but non-conflicting reasons: 1.) PDP-11's did all floating point calculations in double (is this true?) anyway, so why not. 2.) C was written as a systems language which required little little use of floats, so they were added only as an afterthought. 3.) The compilers are much easier to write if one doesn't have to worry about two or more types of float. Do any of the old timers out there know the correct answer(s). -- Mark J. Miller NIH/NCI/DCE/LEC UUCP: decvax!harpo!seismo!rlgvax!cvl!elsie!mark Phone: (301) 496-5688
mp@whuxle.UUCP (Mark Plotnick) (04/28/84)
mark@elsie asks
BTW: What is the origin of the double-precision only nature of C?
Since several people have asked about this, here's the answer from
the archives. Apologies to those who have already seen it.
From physics!alice!research!dmr Wed Sep 8 23:22:25 1982
Subject: float/double in C
Newsgroups: net.unix-wizards
Several people have correctly quoted the manual as calling for evaluation
of expressions on (single-precision) floats in double precision. The
rule was made for 3 reasons.
1) To make certain that floating-point function arguments and return values
were always double (thus avoiding multiple library routines and constant
need for casts.)
2) Because the PDP-11 makes it horribly difficult to mix modes otherwise
(yes, I admit it).
3) Because it is numerically more desirable to evaluate single-precision
expressions in double precision, then truncate the result.
These are in order of importance. Now, the people who actually use C for
numerical work seem to feel that on the VAX, at least, they would gladly
give up reason 3 in favor of increasing the speed of evaluation of expressions
involving single-precision numbers. I am inclined to look kindly on this
reasoning, providing that the first reason above (which is paramount) is
observed. That is, if one wants to compile
double a; float b,c;
a = b+c;
into
addf3 b,c,r0
cvtfd r0,a
one has committed a very venial sin. However, the sin would be mortal
if one got the wrong answer from sin(b) where b was declared "float."
The real problem with the VAX compiler that was originally complained
about is that through a bug it had the worst of both worlds. It did
the arithmetic in single precision and also generated useless conversion
instructions that made the whole calculation slower than if it had been
double in the first place. I understand that this bug has been fixed
in recent versions.
Dennis Ritchie
P.S. I am quite aware that reasons 1,2,3 above can also be adduced
in a discussion of shorts vs. longs. That is a whole other story.
P.P.S. The sinning pun above actually was unintended-- I noticed it only
during proofreading.
nather@utastro.UUCP (Ed Nather) (04/28/84)
[so eat, already]
I can't speak to the historical aspects of the "all double"
nature of floating point operations in C, but I was impressed when I first
encountered it, because it meant:
1. I didn't have to have both single and double precision routines
present if I managed to mix operations -- as I was want to do;
2. I wouldn't encounter the round-off error that is all too common
using single (32-bit) precision;
3. I wouldn't be tempted to "gain a little speed" using single
precision and then find, as I often did, that it was *both* slow
and lacking in needed precision.
I, for one, will be sorry to see it go. Maybe we should work a bit harder
and get fast 64-bit hardware --
32 B I T S I S N O T E N O U G H !
--
Ed Nather
ihnp4!{ut-sally,kpno}!utastro!nather
Astronomy Dept., U. of Texas, Austinguy@rlgvax.UUCP (Guy Harris) (04/28/84)
> BTW: What is the origin of the double-precision only nature of C? I've heard > three differing, but non-conflicting reasons: > 1.) PDP-11's did all floating point calculations in double (is this true?) > anyway, so why not. It's not true, so this isn't the reason. > 2.) C was written as a systems language which required little little use of > floats, so they were added only as an afterthought. > 3.) The compilers are much easier to write if one doesn't have to worry > about two or more types of float. I suspect this may have been part of the reason; *on the PDP-11*, it's easier to write the compiler that way, but not in general. The reason is that the PDP-11 floating point instruction set (the *real* floating point instruction set, not the abortion that came on the 11/35, 11/40, and LSI-11) has two "mode bits". There wasn't enough room in the instruction set for an "add float" and an "add double" instruction, so they had a "set floating" and a "set double" instruction, and the "add float/add double" instruction was one or the other depending on the current mode. Any compiler for the PDP-11 has to keep track of the mode if it doesn't want to generate a flood of unnecessary "set floating" or "set double" instructions. It *can* be done - DEC's Fortran IV Plus compiler does it, although I think it assumes the mode is unknown at the entry to a basic block. Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy
gwyn@brl-vgr.ARPA (Doug Gwyn ) (05/02/84)
I think all three answers (as to why floats are promoted to doubles in C) are applicable, with the amendment that the PDP-11 floating-point processors (FP11s) do not necessarily work in double-precision, but one has to change their mode back and forth to change from double- precision to single-precision arithmetic, so it was simpler to just leave the mode in double-precision all the time (code starts with a SETD instruction to do this). PDP-11 floating-point has never been really satisfactory anyway. It is very hard (but not impossible) to share the FP11 coprocessor among multiple processes; early UNIXes did not properly save & restore the FP11 status upon context switch due to the ansynchronism of the beast. Whoever first introduced 32-bit integers along with the FP11 really botched the job, and these weren't straightened out until the VAX (which is otherwise binary data compatible with the PDP-11). I rather like having all my arithmetic done in double-precision, though. VAX & PDP-11 single-precision isn't good for much serious computation.
donn@sdchema.UUCP (Donn Seeley) (05/06/84)
For what it's worth...
While Jim McGinness was working here at UCSD Chemistry, he put together
a system of 'sed' scripts which operated on the assembly output of the
PCC and caused C programs written to use exclusively 'double' type to
become programs which used single precision. Unsatisfied with that, he
tells me he has plans for a compiler that will implement a 'single'
type, which is identical to 'float' except it is not promoted to double
in expressions. I think a 'single' type would do just what people
want, and fairly simply too. ('Single' is to 'float' as 'short' is to
'int', of course.) For compilers without 'single', just typedef
'single' to 'float' or 'double'.
Are you out there Jim?
Donn Seeley UCSD Chemistry Dept. ucbvax!sdcsvax!sdchema!donnjss@sjuvax.UUCP (Jonathan Shapiro) (05/08/84)
Two points for RATc.
mike@hpdcdb.UUCP (05/21/84)
/***** hpdcdb:net.lang.c / utcsrgv!ray / 9:11 am Apr 18, 1984*/ I do practically nothing but numerical computation on the computer. Although I realize that c was not written to do this, I often use it since it seems to run faster than F77. But, I agree with Steve Crandall. A complex type would be a real asset since, if I were to implement complex arithmetic using c as it stands now (I haven't) I would have to write all sorts of functions to implement + - * / as well as sin, cos, tan, etc. etc. It would be fun but I don't want to waste the time debugging all those routines. C'mon you compilier hackers, let's have a complex type (and double complex) in c. (While you're at it, how about an option to use the IEEE standard floating point that the VAXEN support.) It sure would be nice to have an exponent range of +-300!! (Shine my shoes, trim my beard, give me service!! :-) ) Ray Allen utcsrgv!ray (416) 978-5036 /* ---------- */ There are machines on the market that 1) Have complex functions in library form that are accessible from C or f77 (I know because I've built them). Unfortunately the "complex" type per se isn't available in C but you can easily hack a struct typedef to make one. Double complex is available too. Re 2): All HP machines use IEEE floating pt format. Having implemented it I can attest to the fact that you want to go with IEEE or don't but NEVER mix the two: No one could figure out the library support for code like that. Mike McNelly (303) 226-3800
guy@rlgvax.UUCP (05/24/84)
According to some papers on the "C++" language done at Bell (which they're
now just calling "C" and are calling what those of us in the real world
know as "C" "old C"), you can:
1) add new "abstract data types" to the language
2) overload existing operators and assign their function to
C routines (possibly add new operators, I don't remember
offhand)
3) tell the compiler to expand certain functions inline
and, in one of the papers, they used these functions to add a complex data
type to C - with all the arithmetic operators - without changing the compiler.
The papers are available from AT&T Bell Laboratories; unfortunately, somebody
took them home so I don't have the CSTR numbers available.
Go forth and get them - this may be the (short-term) future of C... (on the
subject of whether all of this is good, the deponent sayeth not)
Guy Harris
{seismo,ihnp4,allegra}!rlgvax!guydavidson@sdcsvax.UUCP (06/05/84)
Naturally, C++ must now be called C, and our familiar C is now old C. The use of the term C++ has caused the problem, since it has a side effect of modifying the referent of the term C. If only the authors of the system had used the name C+1, we could have avoided this unnecessary and confusing side effect. Be warned! -Greg