Problem with Absolute Value of Floating Point PARAM

[damianmoz]

Beyond the 5 basic mathematical operations, addition, subtraction, multiplication, division and square root which can affect IEEE 754 exceptions, there are also simple operations which never raise an IEEE 754 exception

copy(source)
negate(course)
abs(source)

In Chapel, the first two are implemented for params. Because Chapel nominally implements the last with a routine from the system matrhematical library, it cannot return the absolute value of a param as a param. One can argue that this is an oversight because the compiler can figure that out for itself for a param argument and when the argument is a const the optimizer will most likely on modern hardware discard any reference to the implied routine and implement the operation as a single machine instruction.

inline proc abs(param x : real(?w)) param do if x < 0 then -x else x;

I am not suggesting that this implementation is the way to go. It just provides a workaround.

[damianmoz]

Technically there is a fourth simple operation which is the assignment to the absolute value of one source of the negative (or sign) bit of a second source, nominally called copysign(). But I did not want to complicate the discussion.

[mppf]

@damianmoz - thanks for filing the issue. I've created PR #24127 to add the missing param overloads for real/imag abs. I understand that you'd also like to have abs on a param complex return a param. That one is a bit more complicated to implement so I created issue #24125 to record it as a feature request. Please feel free to comment there (or here) about the urgency of that feature.

[damianmoz]

Not urgent. I figure that param complex(w) is a lot more difficult and will take even longer. It was more that I noticed the issue across the break and I figured that Chapel needed this completeness of features across all of its floating point and integral types eventually.

[bradcray]

@damianmoz / @mppf: Is this issue now complete other than the abs on param complex returning complex, now spun off to #24125? If so, is it OK if I close this one in favor of that one?

[damianmoz]

Yes (as far as I can tell) to the first question and Yes to the second question.