Hi.

2020-04-09 11:28 UTC+02:00, Alex Herbert <alex.d.herb...@gmail.com>:
> 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: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Reply via email to