From: dajhawkxx@nowherel.com   
      
   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.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)