From: Peter Seibel
Subject: Order of float and float precision contaigon defined?
Date:
Message-ID: <m3k7deqvr8.fsf@javamonkey.com>
Just checking my understanding. While CLHS 12.1.4.1 (Rule of Float and
Rational Contagion) says:
For functions such as + that take more than two arguments, it is
permitted that part of the operation be carried out exactly using
rationals and the rest be done using floating-point arithmetic.
Section 12.1.4.4 (Rule of Float Precision Contagion) doesn't talk
about the order of conversion, talking only about the type of the
return value:
The result of a numerical function is a float of the largest format
among all the floating-point arguments to the function.
However 12.1.1.1 (Associativity and Commutativity in Numeric
Operations) does say:
For functions that are mathematically associative (and possibly
commutative), a conforming implementation may process the arguments
in any manner consistent with associative (and possibly commutative)
rearrangement.
I assume that means that whether an expression like:
(+ 1/3 1.0s0 1.0d0)
is equivalent to
(+ (float (+ (float 1/3 1.0s0) 1.0s0) 1.0d0) 1.0d0)
or
(+ (+ (float 1/3 1.0d0) (float 1.0s0 1.0d0)) 1.0d0))
is up to the implementation. Does that seem right?
-Peter
--
Peter Seibel ·····@javamonkey.com
The intellectual level needed for system design is in general
grossly underestimated. I am convinced more than ever that this
type of work is very difficult and that every effort to do it with
other than the best people is doomed to either failure or moderate
success at enormous expense. --Edsger Dijkstra
From: Steven M. Haflich
Subject: Re: Order of float and float precision contaigon defined?
Date:
Message-ID: <3EAD815F.3050402@alum.mit.edu>
Peter Seibel wrote:
> I assume that means that whether an expression like:
>
> (+ 1/3 1.0s0 1.0d0)
>
> is equivalent to
>
>
> (+ (float (+ (float 1/3 1.0s0) 1.0s0) 1.0d0) 1.0d0)
>
> or
>
> (+ (+ (float 1/3 1.0d0) (float 1.0s0 1.0d0)) 1.0d0))
>
> is up to the implementation. Does that seem right?
Neither of these expressions are necessarily equivalent.
What you missed is this: Function call semantics guarantees
that the three argument subforms to + are evaluated in
order (which doesn't matter, since they are all manifest
self-evaluating constants). But the lamguage says nothing
about the associative order in which the three arguments
are reduced by +. An implementation might execute this as
(+ (+ 1/3 1.0s0) 1.0d0)
or
(+ 1/3 (+ 1.0s0 1.0d0))
or it might conceivably run on a processor with 3-input
adders and do something weird. Don't laugh, but at least
in the integer domain, many historical cisc processors
had index/base register address computation microcode that
could usefully be invoked to do some limited kinds of
3-input addition in one instruction, although this was
only applicable in the integer domain.
From: Peter Seibel
Subject: Re: Order of float and float precision contaigon defined?
Date:
Message-ID: <m3el3mqts9.fsf@javamonkey.com>
"Steven M. Haflich" <·················@alum.mit.edu> writes:
> Peter Seibel wrote:
>
> > I assume that means that whether an expression like:
> > (+ 1/3 1.0s0 1.0d0)
>
> > is equivalent to
>
> > (+ (float (+ (float 1/3 1.0s0) 1.0s0) 1.0d0) 1.0d0)
>
> > or (+ (+ (float 1/3 1.0d0) (float 1.0s0 1.0d0)) 1.0d0))
>
> > is up to the implementation. Does that seem right?
>
>
> Neither of these expressions are necessarily equivalent. What you
> missed is this: Function call semantics guarantees that the three
> argument subforms to + are evaluated in order (which doesn't matter,
> since they are all manifest self-evaluating constants). But the
> lamguage says nothing about the associative order in which the three
> arguments are reduced by +. An implementation might execute this as
>
> (+ (+ 1/3 1.0s0) 1.0d0)
>
> or
>
> (+ 1/3 (+ 1.0s0 1.0d0))
>
> or it might conceivably run on a processor with 3-input adders and
> do something weird. Don't laugh, but at least in the integer domain,
> many historical cisc processors had index/base register address
> computation microcode that could usefully be invoked to do some
> limited kinds of 3-input addition in one instruction, although this
> was only applicable in the integer domain.
Fair enough. So it's safe to say that the various bits of contagion
can also happen in any order?
-Peter
--
Peter Seibel ·····@javamonkey.com
The intellectual level needed for system design is in general
grossly underestimated. I am convinced more than ever that this
type of work is very difficult and that every effort to do it with
other than the best people is doomed to either failure or moderate
success at enormous expense. --Edsger Dijkstra