Phil Steitz wrote:
> Thanks, Bernhard for the contribution in MATH236. I would like to
> suggest a couple of improvements.
>
> First, I think the return type should be List, not Collection, as
> there is an order to the elements in the returned collection (as
> stated in the API doc, the order is by increasing argument).
>
> Second, since we are also making the method that returns the argument
> public, I would prefer to name that "getArgument" (preferred) or
> "getArg" instead of "getPhi".
>
> Finally, in the loop that generates the roots, it would be better to
> compute the pie slice once and then add it each time instead of
> computing k* 2 * Math.PI/ n for each k > 1.
>
> If there are no objections, I will make these changes.
>
> Thanks again for the contribution.
>
> Phil
I made the changes above, but as I was updating the tests, I noticed
another thing. Behavior for complex numbers with NaN and infinite
parts is, well, "interesting." It is consistent with what we do
elsewhere in this class to just apply computational formulas and
document behavior for infinite and NaN; but the current implementation
is hard to document correctly and the results are a little strange for
infinite values.
I see three reasonable choices here, and am interested in others'
opinions. Please select from the following or suggest something else.
1) Leave as is and just point out that the computational formula will
behave strangely for infinite values.
2) return {Complex.NaN} or {Complex.INF} respectively when the number
has a NaN or infinite part.
3) return {Complex.NaN} when either part is NaN; but for infinite
values, compute the argument using getArgument (atan2), generate the
arguments for the roots from this and select the real/im parts of the
roots from {0, inf, inf} to match the argument (this will always be
possible because atan2 always returns a multiple of pi/4 for infinite
arguments). For example, the 4th roots of real positive infinity would
be {inf + 0i, 0 + infi, inf + 0i, 0 + infi}
2) is probably the most defensible mathematically; but 3) is closer to
the spirit of C99x. Unfortunately, since our implementation of multiply
is 2)like, 3) does not guarantee that nth roots actually solve the
equation r^n = z.
Phil

To unsubscribe, email: devunsubscribe@commons.apache.org
For additional commands, email: devhelp@commons.apache.org
