From: pehache.7@gmail.com   
      
   Le 17/11/2023 à 07:48, Thomas Koenig a écrit :   
   > pehache schrieb:   
   >> Le 16/11/2023 à 02:28, gah4 a écrit :   
   >>> On 11/4/23 2:21 PM, Steven G. Kargl wrote:   
   >>>> The SCALE intrinsic allows one to change the   
   >>>> floating point exponent for a REAL entity.   
   >>>> For example,   
   >>>>   
   >>>> program foo   
   >>>> real x   
   >>>> x = 1   
   >>>> print *, scale(x,1) ! print 2   
   >>>> end program   
   >>>>   
   >>>> This scaling does not incur a floating point   
   >>>> rounding error.   
   >>>>   
   >>>> Question. Anyone know why the Fortran standard (aka J3)   
   >>>> restricted X to be a REAL entity? It would seem that X   
   >>>> could be COMPLEX with obvious equivalence of   
   >>>>   
   >>>> SCALE(X,N) = COMPLX(SCALE(X%RE,N),SCALE(X%IM,N),KIND(X%IM))   
   >>>>   
   >>>> Should the Fortran be amended?   
   >>>   
   >>>   
   >>> Wow, no answer yet.   
   >>>   
   >>> It does seem that sometimes Fortran is slow to add features, especially   
   >>> when need for them isn't shown.   
   >>   
   >> The reason is maybe because the standard doesn't specify how a complex   
   >> number is internally represented.   
   >   
   > I disagree almost entirely.   
   >   
   > Subclause 19.6.5 of F2018, "Events that cause variables to become   
   > defined" has   
   >   
   > (13) When a default complex entity becomes defined, all partially   
   > associated default real entities become defined.   
   >   
   > (14) When both parts of a default complex entity become defined as   
   > a result of partially associated default real or default complex   
   > entities becoming defined, the default complex entity becomes   
   > defined.   
   >   
   > Which means that something like   
   >   
   > real :: a(2)   
   > complex :: c   
   > equivalence (a,c)   
   >   
   > allows you to set values for a(1) and a(2) and you can expect the   
   > components of c to get the corresponding values.   
      
   I almost entirely disagree with your almost entire disagreement :)   
      
   The standard requires the complex type to occupy 2 storage units, which   
   allows the above equivalence, and the above clause tells that a complex   
   is made of two adjacent reals. However it does not tell what are a(1)   
   and a(2) precisely : they could be the module + phase (or the imaginary   
   part and the real part in that order).   
      
   >   
   > This is important for FFT.   
      
   We are all relying on the fact that in your above equivalence a(1) is   
   the real part and a(2) is the imaginary part, all compilers follow this   
   convention, and nobody would "buy" a compiler that would follow another   
   convention. Nonetheless this is just a convention, this is not enforced   
   by the standard.   
      
   --   
   "...sois ouvert aux idées des autres pour peu qu'elles aillent dans le   
   même sens que les tiennes.", ST sur fr.bio.medecine   
   ST passe le mur du çon :    
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   
|