From: dajhawk18xx@@nowhere.com   
      
   Thomas Koenig wrote:   
      
   > 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 :-)   
      
   Any extension to the existing standard is at least possible. But the   
   real question is whether there are enough (or any at all) applications   
   that require only (or mainly) complex multiplications as opposed to   
   additions. I can't think of any.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)