Hi. 2019-12-21 1:07 UTC+01:00, Alex Herbert <alex.d.herb...@gmail.com>: > > >> On 20 Dec 2019, at 23:45, Gilles Sadowski <gillese...@gmail.com> wrote: >> >> Le sam. 21 déc. 2019 à 00:05, Alex Herbert <alex.d.herb...@gmail.com >> <mailto:alex.d.herb...@gmail.com>> a écrit : >>> >>> Looking at the c++ standard [1] we are missing this function: >>> >>> norm() = a^2 + b^2 >>> >>> The field norm of the complex, or the square of the absolute. An example >>> on C++ reference states that this is faster for comparing magnitudes for >>> ranking as it avoids the sqrt() required in abs(). >>> >>> z.abs() > y.abs() == z.norm() > y.norm() >>> >>> >>> I suggest this is added to comply with the standard. >> >> +1 >> >>> >>> >>> It seems odd to me that the constructor ofPolar throws an exception. It >>> does this when the magnitude (rho) for the complex is negative. However >>> if the magnitude is NaN it will not throw an exception and will end up >>> returning NaN. I think this should be changed to return NaN for negative >>> magnitude and avoid exceptions. This is basically stating that the polar >>> representation you used is invalid and so in the Cartesian representation >>> it will be (nan, nan). >>> >>> The C++ standard on this was previously vague and was clarified in [2]: >>> >>> “ >>> -?- Requires: rho shall be non-negative and non-NaN. theta shall be >>> finite. >>> >>> -9- Returns: The complex value corresponding to a complex number whose >>> magnitude is rho and whose phase angle is theta. >>> “ >>> >>> The assumption is that abs(polar(rho, theta)) == rho. >>> >>> If this cannot be ensured then polar(rho, theta) is undefined and we >>> return NaN. >>> >>> >>> Note that if theta is finite and rho is non-negative and non-nan: >>> >>> x = rho * Math.cos(theta) >>> y = rho * Math.sin(theta) >>> >>> In the event that sin(theta) is zero (i.e. theta is zero) then inf * 0 is >>> NaN. In this case the complex could either be: >>> >>> (Inf, nan) or (inf, 0) >>> >>> I have tried 2 c++ implementations and both return (inf, nan). The c++ >>> <complex> header I have found would return (inf, 0). The same header also >>> corrects if cos(theta) is zero however in Java cos(pi/2) is not zero so >>> this is not an issue. >>> >>> Note: >>> If the result is (inf, nan) then abs((inf, nan)) should return inf to >>> satisfy the contract abs(polar(rho, theta)) == rho. This is currently >>> true as abs() uses Math.hypot(x, y) which will return positive infinity >>> if either argument is infinite. So I do not think it matters. An infinite >>> is infinite even when the other part is nan. >>> >>> >>> I suggest we update ofPolar to not throw exceptions and return NAN unless >>> theta is finite and rho is non-negative and non-nan. >> >> +0 >> Not sure how useful it is to instantiate a useless object. > > It would not be instantiated. It can use the singleton NaN. But I do see > your point. Something has gone wrong so raise it as a problem. > > Looking at various implementations the polar(rho, theta) method is used when > computing results in polar coordinates to then return a result. For example > this is used in various sqrt() implementations as the equivalent of: > > Complex.ofPolar(Math.sqrt(z.abs()), z.arg() / 2) > > In this case it would not be nice to throw an exception for a complex z > which is NaN. Instead return NaN as the sqrt of NaN. > > I thought it would be more in line with the c++ standard to not throw > exceptions. I also think that returning NaN is more in line with how > java.util.Math handles invalid cases.
So, would you suggest that no "Number"-like class should ever throw an exception (but instead return the equivalent of "Double.NaN")? Perhaps that's the most neutral approach (careful users will check the return value; others will have to use a debugger in order to find the cause of the failure). In the absence of other arguments, it's indeed safer to adopt the same conventions as C++. Regards, Gilles >>> >>> Alex >>> >>> >>> [1] http://www.cplusplus.com/reference/complex/ >>> <http://www.cplusplus.com/reference/complex/> >>> <http://www.cplusplus.com/reference/complex/ >>> <http://www.cplusplus.com/reference/complex/>> >>> [2] https://cplusplus.github.io/LWG/issue2459 >>> <https://cplusplus.github.io/LWG/issue2459> >>> <https://cplusplus.github.io/LWG/issue2459 >>> <https://cplusplus.github.io/LWG/issue2459>> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
