Hi.
2020-04-09 11:28 UTC+02:00, Alex Herbert <[email protected]>:
> Two oddities in fraction:
>
> 1. Zero can be represented as 0 / 1 or 0 / -1
>
> I have not found any location where this manifest as a bug.
:-)
> It is
> handled by the arithmetic and toString methods and the denominator is
> not negated in the method negate() and so negation of 0 / -1 returns the
> same value:
>
> Fraction f1 = Fraction.of(0, -1);
> Fraction f2 = f1.negate();
> System.out.printf("%s/%s (%s) : %s/%s (%s)%n",
> f1.getNumerator(), f1.getDenominator(), f1,
> f2.getNumerator(), f2.getDenominator(), f2);
>
> 0/-1 (0) : 0/-1 (0)
> 0/-1 (0) : 0/-1 (0)
>
> However any future issues could be avoided by detecting a zero numerator
> in the constructors and setting the denominator as 1.
Wouldn't this mean a performance hit for the majority of
instances that are not zero?
>
> 2. There are a lot of pow(exponent) methods in BigFraction compared to
> Fraction:
>
> This is mandated by o.a.c.numbers.core.NativeOperations:
>
> Fraction pow(int)
>
> BigFraction pow(int)
>
> But there are more in BigFraction and one returns a double:
>
> BigFraction pow(long)
> BigFraction pow(BigInteger)
> double pow(double)
>
> I see the long and BigInteger versions as specialisations of the
> pow(int) method. The double variant can be implemented in Fraction using
> the same method from BigFraction as:
>
> /**
> * Returns a {@code double} whose value is
> * <code>this<sup>exponent</sup></code>.
> *
> * @param exponent exponent to which this {@code Fraction} is to be
> raised.
> * @return <code>this<sup>exponent</sup></code> as a {@code double}.
> */
> public double pow(final double exponent) {
> return Math.pow(numerator, exponent) /
> Math.pow(denominator, exponent);
> }
This now strikes me as dangerous.
>
> So either we add this method to Fraction
-1
> or drop it from BigFraction.
+1
Let users perform any "cast" to "double" that could be invalid.
> Note: The methods are present in the CM 3.6 version of BigFraction but
> Fraction did not have any pow methods.
A lot of fixes and improvements were brought in by
Heinrich Bohne a few months ago. [IIRC, some issues
which he had reported are still pending...]
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]