home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.lang.fortran      Putting John Backus on a giant pedestal      5,127 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 4,533 of 5,127   
   David Jones to pehache   
   Re: SCALE intrinsic subprogram (aka a Fo   
   17 Nov 23 08:18:57   
   
   From: dajhawkxx@nowherel.com   
      
   pehache wrote:   
      
   > Le 16/11/2023 à 21:01, Steven G. Kargl a écrit :   
   > > >   
   > > > The reason is maybe because the standard doesn't specify how a   
   > > > complex number is internally represented. In practice it is   
   > > > always represented by a pair (real,imag), but nothing would   
   > > > prevent a compiler representing it by (module,argument) for   
   > > > instance. Given that, the standard cannot guarantee the absence   
   > > > of rounding errors.   
   > >   
   > > You are correct that the Fortran standard does not specify   
   > > internal datails, and this could be extended to COMPLEX.   
   > > It would however be quite strange for a Fortran vendor to   
   > > use magnitude and phase   
   >   
   > I fully agree that it would be strange, and I can't see any advantage   
   > to such implementation. Yet, it is not prohibited by the standard.   
   >   
   > > given that the Fortran standard does   
   > > quite often refer to the real and imaginary parts of a COMPLEX   
   > > entity.   
   >   
   > Yes, but it's at the conceptual level   
   >   
   > > Not to mention, the Fortran standard has introduced:   
   > >   
   > > 3.60.1   
   > > complex part designator   
   > >   
   > > 9.4.4 Complex parts   
   > >   
   > > R915 complex-part-designator   is designator % RE   
   > >                                or designator % IM   
   >   
   > Yes again, but behind the hood c%re and c%im could be the functions   
   > m*cos(p) and m*sin(p). And on assignement c%re =  or c%im =   
   >  the (m,p) pair could be fully recomputed.   
   >   
   >   
   > > PS: If a Fortran vendor used magnitude and phase, then the vendor   
   > > would need to specify a sign convention for the phasor.  I'm mpt   
   > > aware of any vendor that does.   
   >   
   > I don't think so, as the phase component would not be directly   
   > accessible by the user. The vendor could choose any convention as   
   > long as the whole internal stuff is consistent, he could also chose   
   > to store a scaled version of the phase in order to have a better   
   > accuracy...   
      
   There seems no reason why the standard might not be extended to allow   
   the two different types of representations of complex variables to   
   exist in the same program, as separate data-types, and to interact when   
   required. Two major questions are:   
      
   (i) whether there are any applications that would be more readily and   
   usefully programmed using the modulus-phase representation?   
      
   (ii) the relative speed of both addition and multiplication in the two   
   representations.?   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca