C vs. FORTRAN (was: What should be added to C)

rgh%inmet.uucp at BRL.Arpa rgh%inmet.uucp at BRL.Arpa
Wed Jun 11 06:37:34 AEST 1986


GVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGV
From: Root Boy Jim <rbj at ICST-CMR.ARPA>
To: brl.arpa!gwyn at seismo.css.gov, dgary%ecsvax.uucp at BRL.ARPA, ecsvax!dgary at mcnc.CSNET
Subject: Re:  C vs. FORTRAN (was: What should be added to C)
Cc: info-c at BRL-SMOKE.ARPA
Return-Path: <info-c-request at BRL.ARPA>
Redistributed: Xerox-Info-C^.x at XEROX.ARPA
Received: from BRL-AOS.ARPA by Xerox.COM ; 03 JUN 86 19:30:16 PDT
Received: from brl-smoke.arpa by AOS.BRL.ARPA id a004397; 3 Jun 86 20:13 EDT
Received: from icst-cmr.arpa by SMOKE.BRL.ARPA id a008635; 3 Jun 86 20:01 EDT
Received: by icst-cmr.ARPA (4.12/4.7)	id AA16302; Tue, 3 Jun 86 19:57:33 edt
Message-Id: <8606032357.AA16302 at icst-cmr.ARPA>
GVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGV

	There are a number of good reasons for building integer exponents into
	the language, one of which is the possibilities for optimization.  An

Doug, I am surprised that you ignored DMR's rationale for not putting
exponentiation into C, or were you merely requesting a library function.
Yes, I know you didn't write this but I'm responding to you here anyway.

	obvious one is converting x**3 into x*x*x, not to mention having the
	compiler recognise at what level one should not do this optimization.
	More subtle is the use of "algebraic" optimizations.  For instance,
	converting
	
		a*x**3 + b*x**2 + c*x + d
	to
		d + x * (c + x * (b + a*x))
	
	which replaces eight multiplications with three and not only executes
	faster but (most of the time) greatly reduces precision problems.
	Granted that this can be coded by the programmer; how many do you think
	will actually do it?  Yup...

Anyone who wants the benefits. It could be argued that by allowing
programs to be optimised, you promote laziness in coding techniques.
In this example, the notation looks quite similar to the original
form, especially if you write it backwards.

Any optimizer smart enuf to make this transformation should be able to
do the same for the longhand as well: a*x*x*x + ...
	
By making it harder to code poorly, you make it harder to code well by
comparison. Don't give away all our wizardly secrets :-)

	(Root Boy) Jim Cottrell		<rbj at cmr>
	- if it GLISTENS, gobble it!!



More information about the Comp.lang.c mailing list