Path: utzoo!utgpu!water!watmath!clyde!rutgers!rochester!PT.CS.CMU.EDU!IUS1.CS.CMU.EDU!edw
From: edw@IUS1.CS.CMU.EDU (Eddie Wyatt)
Newsgroups: comp.lang.c
Subject: pow again
Message-ID: <629@PT.CS.CMU.EDU>
Date: 12 Jan 88 14:39:18 GMT
Sender: netnews@PT.CS.CMU.EDU
Organization: Carnegie-Mellon University, CS/RI
Lines: 60

In article <521@cresswell.quintus.UUCP>, ok@quintus.UUCP (Richard A. O'Keefe) writes:
> In article <622@PT.CS.CMU.EDU>, edw@IUS1.CS.CMU.EDU (Eddie Wyatt) writes:
> 1>    Actually any operation in a languge need not generate functions calls -
> 1> have we heard of inline expansion?
> ...
> 2> implement.  I don't think anyone will question the reasonableness
> 2> of an infixed notion for exponentiation.
> ...
> 3> properties become harder to detect when using a functional format
> 3> (integers must be typed coerced into doubles).  On machines with
> 3> no hardware support for exponetiation, the answer maybe one could
> 
> His points (1) and (3) contradict each other.

    Points 1 and 3 do not contradict each other.  A function call in C
differs from an operator in that operators may be OVERLOADED or have IMPLICIT
coercion of operands while functions calls must have EXPLICITLY type coercion
its parameters.  This means that 3.0 + 4 is valid while add(3.0,4) would
not be valid (assuming add is a function taking two doubles).
And hence determining that the exponent in the function call
pow(base, (double) int_exp) could be equivalent to an integer is
not as easy as having an integer value given.


> In fact his point (3) is the direct opposite of C's defaults:
> at present, whenever you do
> 	X <operator> Y
> "the usual conversions" are done, which means amongst other things
> that if one operand is double, the other *will* be converted (which
> Wyatt says *won't* happen), whereas if you call a function integers
> will only be promoted to 'int'.  In C, functional *syntax* gives us
> the freedom to have operands of different types:

   We are talking about optimizing code.  You can generate special code
depending on the types of expressions present.  There is nothing wrong
with that provided that the code generated yields the same results in both
the optimized and unoptimized versions.


> 	extern double pow(double base, double expt);
> -vs-	extern double rtp(double base, int power);
> Note that these are quite different functions: rtp(-3.0, 2) is well
> defined, but pow(-3.0, 2.0) is illegal and should signal a matherr.
> (In Common Lisp, (EXPT -3.0 2.0) --> #C(9.0 0.0), a complex number.)

Sorry but there are not two separate functions.  exp is just a partial
function.  It should yield real values for all integer exponents or
bases >= 0.  If Common Lisp choises to say expt(-3.0,2.0) is 9.0+0i
that its problem.  In the true math since (2.0 == 2).  The behavior
of the function should be the same for both 2.0 and 2.


  There was one good point in all that garbage you posted.  That is
noting that exp is partial over the domain of real values.  Do we want
to add an operator to the language that will be so ill-defined.


-- 

Eddie Wyatt 				e-mail: edw@ius1.cs.cmu.edu