[comp.lang.c] Math functions

jeff@stormy.atmos.washington.edu (Jeff L. Bowden) (02/14/89)

In article <795@atanasoff.cs.iastate.edu> hascall@atanasoff.cs.iastate.edu (John Hascall) writes:
>In article <515@larry.UUCP> jwp@larry.UUCP (Jeffrey W Percival) writes:
>>I have a question about how much optimizing I should worry about when
<>writing programs in C.  Suppose I have this code fragment:
>
<>	x = (1 + cos(r)) / (cos(r) * sin(r));
>>	y = (cos(r) - sin(r)) / (1 + sin(r));
<
>>I made this up, but the point is the re-use of the sin() and cos()
<>calls.  Now, can I expect the compiler to form only one call to sin and
>>cos?  ...
<
>  I think it will/should call the function each time it appears as
<  the compiler has no way of knowing the "side-effects" of a
>  function call (i.e., file operations, accessing global variables, etc).

Even if the compiler knew something about the math functions (i.e. they are
not going to do i/o with the user) it still might have to generate the calls.
I have heard that for math libraries to be IEEE conformant they must round
up and down on .5 *randomly* with a uniform distribution.  I was floored when
I heard this.  Anyone know if it is actually true?
--
"Security and Liberty are at war.  Which side are you on?"

tim@crackle.amd.com (Tim Olson) (02/14/89)

In article <JEFF.89Feb13122608@stormy.atmos.washington.edu> jeff@stormy.atmos.washington.edu (Jeff L. Bowden) writes:
| Even if the compiler knew something about the math functions (i.e. they are
| not going to do i/o with the user) it still might have to generate the calls.
| I have heard that for math libraries to be IEEE conformant they must round
| up and down on .5 *randomly* with a uniform distribution.  I was floored when
| I heard this.  Anyone know if it is actually true?

P854 only specifies that conforming implementations provide add,
subtract, multiply, divide, square-root, remainder, round-to-integer in
floating-point format, conversions, and comparisons.  For these
operations, the result must be infinitely-precise, modified by the
rounding mode in effect.  There is no "random" rounding mode.  For
"round to nearest" (the default), if the two nearest representable
values are equally near, the one with its least significant bit zero is
delivered. 


	-- Tim Olson
	Advanced Micro Devices
	(tim@crackle.amd.com)

diamond@diamond.csl.sony.junet (Norman Diamond) (02/15/89)

news@beaver.cs.washington.edu writes:

> Even if the compiler knew something about the math functions (i.e. they are
> not going to do i/o with the user) it still might have to generate the calls.
> I have heard that for math libraries to be IEEE conformant they must round
> up and down on .5 *randomly* with a uniform distribution.  I was floored when
> I heard this.  Anyone know if it is actually true?

'fraid I don't know if it's true, but if it is, the IEEE should send someone
back to school for grade 9 arithmetic.  (So should many other organizations
though.)

xxxxx.5 should be rounded to an EVEN number, xxxxx or xxxxx+1  (all of these
numbers scaled by whatever exponent).  In binary, .bbbb01 becomes .bbbb0 and
.bbbb11 becomes .cccc0 where .cccc0 == .bbbb0 + .00010 (and if there is an
overflow, then the 1.cccc gets shifted down).

> "Security and Liberty are at war.  Which side are you on?"

I'm on each person's side.  If you want security, feel free to do your best,
but don't interfere with someone else's liberty, as long as they don't inter-
fere with yours....
Norman Diamond, Sony Computer Science Lab (diamond%csl.sony.jp@relay.cs.net)
  The above opinions are my own.   |  Why are programmers criticized for
  If they're also your opinions,   |  re-inventing the wheel, when car
  you're infringing my copyright.  |  manufacturers are praised for it?