chapel icon indicating copy to clipboard operation
chapel copied to clipboard

Handling Infinity Within Complex - Low Priority

Open damianmoz opened this issue 5 years ago • 0 comments

This does not really warrant attention now but more notice for the future because there is some inconsistency relative to other types. With a gcc backend, the following

proc main
{
    param x_ok = INFINITY + 45.678e+3i;
    const y_ok = (45.678e+3, 12345.0):complex(128);
    const y_NO = (45.678e+3, INFINITY):complex(128);
    const ztup = (45.678e+3, INFINITY);
    var z : complex(128);

    writeln("Should be inf  +  45678i ?? ", x_ok);
    writeln("Should be 45678 + 12345i ?? ", y_ok);
    writeln("Should be 45678 + inf i  ?? ", y_NO);
    (z.re, z.im) = (45.678e+3, INFINITY);
    writeln("Should be 45678 + inf i  ?? ", z);
}

produces

Should be inf  +  45678i ?? inf + 45678.0i
Should be 45678 + 12345i ?? 45678.0 + 12345.0i
Should be 45678 + inf i  ?? nan
Should be 45678 + inf i  ?? 45678.0 + infi

The parameter x_ok is handled as expected, as is y_ok.

On the other hand, yNAN is computed by chapel as a NaN! Very odd although somewhat consistent with the way gcc handles

double complex t = 45.678e+3 + INFINITY * I;

Here, gcc would create a number which has a real component of NaN and an imaginary component which has the value INFINITY. Weird.

The use of a tuple to feed z the data that yNAN could not handle means we have a workaround, albiet one which can be neither const nor param like x_ok

damianmoz avatar Feb 11 '20 04:02 damianmoz