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