(j3.2006) Question about IEEE assignment and derived types

Bill Long longb
Fri Dec 14 18:15:37 EST 2007



Michael Ingrassia wrote:
>> Does that make the answer to all 5 questions "processor dependent"?
>>     
>
> I guess you are referring to the sentence
> "La decision de signaler une exception d'operation
> invalide lors de la copie d'un non-nombre indicateur
> sans changement de format est laissee au
> realisateur comme option." ?  (Sorry about omitting the diacriticals.)
>
> As I understand it, the implementor or realisateur might be interpreted
> as including a language standards body.  
> That is, this is a slightly different notion from
> "processor dependent"--  if Fortran insisted you must always signal 
> when copying a signaling NaN, that would be consistent with 754 but 
> simultaneously inconsistent with leaving the answer as "processor dependent"
> in the Fortran standard.
>   

Maybe true in theory, but not really practical. In practice, the 
implementation is what is implemented in hardware.  No one (I would 
hope) is going to design a language where you have to perform a series 
of software checks at each simple intrinsic assignment. 
> But the hardware is still the hardware, so maybe we won't all agree on
> a definite answer.   
That depends on the question.  Dick asked if the IEEE rules *require* 
that the assignment signal.  That question does have a definite answer: No.

> My take is that copies based on intrinsic
> assignment ought to signal, and copies based on memcpy-style memory
> transferought ought not to signal, and I've lost track of which
> sort of copy we modeled allocate+source on.
>   
Interesting take.  In Fortran, I don't see how you would distinguish 
among various copies. Having different conventions for different cases 
would seem very confusing.  Since the hardware types we support (64-bit 
Opteron and Cray processors) do not signal on copies, my take is that a 
copy of a signaling NaN would never signal.  This convention also avoids 
any questions of how to handle internally generated compiler temps. 

Cheers,
Bill



>  
> 	--Michael I.
>
> _______________________________________________
> J3 mailing list
> J3 at j3-fortran.org
> http://j3-fortran.org/mailman/listinfo/j3
>   

-- 
Bill Long                                   longb at cray.com
Fortran Technical Support    &              voice: 651-605-9024
Bioinformatics Software Development         fax:   651-605-9142
Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120

            




More information about the J3 mailing list