Hi.
2019-12-29 1:15 UTC+01:00, Alex Herbert <alex.d.herb...@gmail.com>:
>
>
>> On 21 Dec 2019, at 11:42, Gilles Sadowski <gillese...@gmail.com> wrote:
>>
>>> ...
>>
>> So, would you suggest that no "Number"-like class should ever throw
>> an exception (but instead return the equivalent of "Double.NaN”)?
>
> Yes. As it was the method could throw for some invalid input and not others.
> This is inconsistent. Changing to return a NaN equivalent is more neutral.
> Through the rest of the code all the computations that may end up computing
> NaN just return NaN. There is no raising of exceptions even when the ISO C99
> standard states that an exception may be raised, i.e. these do not throw
> ArithmeticException. Removing all exceptions from the class could be stated
> as a design decision in the class javadoc. The only exceptions are from the
> parse(String) method.
+1
Could also be considered as a simplification (no wondering about
which exception raise...).
Acceptable rationale for not throwing is that caller code can always
do the checks and act accordingly (throw or propagate NaN).
>
> I have been documenting the class using MathJax. This has raised a few more
> discrepancies with the c++ standards:
>
> 1. Static constructors
>
> Complex:
>
> ofCartesian(x, y)
> ofPolar(rho, theta)
>
> No public constructor.
>
> C++
>
> complex(x, y) // This is a public class constructor for type
> <complex>
> polar(rho, theta)
>
> Should we change to the same name,
-0
> add synonyms
-0
> just accept the API
> difference?
>
> Sticking to the VALJO design would leave it as is and document that ofPolar
> matches the functionality of the ISO C++ polar method.
+1
Priority (IMO) would be to try and establish consistency within Java.
>
>
> 2. Reciprocal
>
> I had to change the implementation of reciprocal to call divide,
> effectively:
>
> Complex.ONE.divide(this)
>
> This uses scaling for the divisor and can compute values that the previous
> version could not such as:
>
> Complex.ofCartesian(Double.MAX_VALUE, Double.MAX_VALUE).reciprocal()
>
> It also better handles NaN and infinite edge cases.
Great.
>
> This method seems redundant. The origin in CM3 was due to Complex
> implementing the FieldElement interface. This has reciprocal() as a required
> method.
>
> It also has multiply(int) hence why that method was originally in the
> numbers version of Complex. This has now been dropped as it is redundant
> with multiply(double). Since we do not have to support the FieldElement
> interface I would suggest dropping reciprocal as well.
+1
>
> 3. Equals
>
> Why are there so many static equals functions using
> o.a.c.numbers.core.Precision with ULP and deltas?
>
> boolean equals(Complex x, Complex y, int maxUlps)
>
> @return {@code true} if there are fewer than {@code maxUlps} floating
> * point values between the real or imaginary, respectively, parts of
> {@code x}
> * and {@code y}.
>
>
> boolean equals(Complex x, Complex y)
>
> @return equals(x, y, 1)
>
>
> boolean equals(Complex x, Complex y, double eps)
>
> @return {@code true} if the values are two adjacent floating point
> * numbers or they are within range of each other.
>
>
> boolean equalsWithRelativeTolerance(Complex x, Complex y, double eps)
>
> {@code true} if the values are two adjacent floating point
> * numbers or they are within range of each other.
>
>
> These are all helper methods. None are required for the test suite. I do not
> see the need to have them in the core Complex class. The methods do not
> cover all possible ways to measure equality, just some using the Precision
> class. I would drop these and leave it to a user to decide how to measure
> equality.
+1
>
> However I do note that similar methods are in the CM3 Complex class. Leaving
> them here would make porting to numbers easy. I think that before the 1.0
> release is the time to decide if they should be maintained in Complex, in
> another class such as ComplexPrecision for legacy support of porting from
> CM3, or dropped. In the later case a note could be added to the package
> javadoc to state how to replicate the equals functionality from CM3 using
> numbers.Precision.
Let's drop, and wait for actual use cases.
Thanks,
Gilles
>
> Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
