From: tkoenig@netcologne.de   
      
   David Jones  schrieb:   
   > Steven G. Kargl wrote:   
   >   
   >> On Sun, 19 Nov 2023 13:28:18 +0000, Thomas Koenig wrote:   
   >>   
   >> > David Jones  schrieb:   
   >> >   
   >> >> 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.?   
   >> >   
   >> > Multiplication and especially division would likely be faster - you   
   >> > would have to multiply the two moduli and add and normalize the   
   >> > modulus to lie between 0 and 2*pi.   
   >> >   
   >> > However, the normalization step can have unintended execution speed   
   >> > consequences if the processor implements it via branches, and   
   >> > branches can be quite expensive if mispredicted.   
   >> >   
   >> > Addition is very expensive indeed in polar notation.  You have to   
   >> > calculate the sin() and cos() of each number, add them, and then   
   >> > call atan2() (with a normalization) to get back the original   
   >> > representation.   
   >> >   
   >> > If you're doing a lot of multiplication, and not a lot of addition,   
   >> > that could actually pay off.   
   >>   
   >> If a vendor used magnitude and phase as the internal representation,   
   >> then that vendor would not be around very long.  Consider cmplx(0,1).   
   >> The magnitude is easy.  It is 1.  Mathematically, the phase is   
   >> pi/2, which is of course not exactly representable.   
   >>   
   >> % tlibm acos -f -a 0.   
   >>    x =  0.00000000e+00f, /* 0x00000000 */   
   >> libm =  1.57079637e+00f, /* 0x3fc90fdb */   
   >> mpfr =  1.57079637e+00f, /* 0x3fc90fdb */   
   >>  ULP = 0.36668   
   >> % tlibm cos -f -a 1.57079637   
   >>    x =  1.57079625e+00f, /* 0x3fc90fda */   
   >> libm =  7.54979013e-08f, /* 0x33a22169 */   
   >> mpfr =  7.54979013e-08f, /* 0x33a22169 */   
   >>  ULP = 0.24138   
   >>   
   >> 7.549... is significantly different when compared to 0.   
   >   
   > If it were worth doing, the obvious thing to do would be to use a   
   > formulation where you store a multiple of pi or 2*pi as the effective   
   > argument, with computations done to respect a standard range.   
      
   It could also make sense to use a fixed-number representation for   
   the phase; having special accuracy around zero, as floating point   
   numbers do, may not be a large advantage.   
      
   The normalization step could then be a simple "and", masking   
   away the top bits.   
      
   This is, however, more along the lines of what a user-defined   
   complex type could look like, not what Fortran compilers could   
   reasonably provide :-)   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)