Re: [commons-numbers] branch fraction-dev updated: NUMBERS-91: Added ofInt() factory methods and made BigInteger-based constructor private

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [commons-numbers] branch fraction-dev updated: NUMBERS-91: Added ofInt() factory methods and made BigInteger-based constructor private

Gilles Sadowski
On Thu, 27 Dec 2018 23:54:57 +0000, [hidden email] wrote:
> This is an automated email from the ASF dual-hosted git repository.
>
> ericbarnhill pushed a commit to branch fraction-dev
> in repository https://gitbox.apache.org/repos/asf/commons-numbers.git
>
>
> The following commit(s) were added to refs/heads/fraction-dev by this
> push:
>      new ebb8e03  NUMBERS-91: Added ofInt() factory methods

Why not rely on method overload?  There is no need to duplicate
part of the the method's signature in its name.

Gilles

> and made
> BigInteger-based constructor private
> ebb8e03 is described below
>
> commit ebb8e03f139b8cec84564b3e558fea39b71d2f24
> Author: Eric Barnhill <[hidden email]>
> AuthorDate: Thu Dec 27 15:54:51 2018 -0800
>
>     NUMBERS-91: Added ofInt() factory methods and made
> BigInteger-based
>     constructor private
> ---
>  .../commons/numbers/fraction/BigFraction.java      | 68
> +++++++---------------
>  1 file changed, 20 insertions(+), 48 deletions(-)
>
> [...]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [commons-numbers] branch fraction-dev updated: NUMBERS-91: Added ofInt() factory methods and made BigInteger-based constructor private

Eric Barnhill
I am overloading:

public static BigFraction ofInt(final BigInteger num) {
        return new BigFraction(num, BigInteger.ONE);
    }

    public static BigFraction ofInt(BigInteger num, BigInteger den) {
    return new BigFraction(num, den);
    }

    private BigFraction(BigInteger num, BigInteger den) {

Did my comment not give that impression?

On Thu, Dec 27, 2018 at 4:52 PM Gilles <[hidden email]> wrote:

> On Thu, 27 Dec 2018 23:54:57 +0000, [hidden email] wrote:
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > ericbarnhill pushed a commit to branch fraction-dev
> > in repository https://gitbox.apache.org/repos/asf/commons-numbers.git
> >
> >
> > The following commit(s) were added to refs/heads/fraction-dev by this
> > push:
> >      new ebb8e03  NUMBERS-91: Added ofInt() factory methods
>
> Why not rely on method overload?  There is no need to duplicate
> part of the the method's signature in its name.
>
> Gilles
>
> > and made
> > BigInteger-based constructor private
> > ebb8e03 is described below
> >
> > commit ebb8e03f139b8cec84564b3e558fea39b71d2f24
> > Author: Eric Barnhill <[hidden email]>
> > AuthorDate: Thu Dec 27 15:54:51 2018 -0800
> >
> >     NUMBERS-91: Added ofInt() factory methods and made
> > BigInteger-based
> >     constructor private
> > ---
> >  .../commons/numbers/fraction/BigFraction.java      | 68
> > +++++++---------------
> >  1 file changed, 20 insertions(+), 48 deletions(-)
> >
> > [...]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [commons-numbers] [...] NUMBERS-91: Added ofInt() factory methods [...]

Gilles Sadowski
Hello Eric.

On Thu, 27 Dec 2018 17:00:15 -0800, Eric Barnhill wrote:

> I am overloading:
>
> public static BigFraction ofInt(final BigInteger num) {
>         return new BigFraction(num, BigInteger.ONE);
>     }
>
>     public static BigFraction ofInt(BigInteger num, BigInteger den) {
>     return new BigFraction(num, den);
>     }
>
>     private BigFraction(BigInteger num, BigInteger den) {
>
> Did my comment not give that impression?

I was in fact wondering why "ofInt" rather than just "of".

Best,
Gilles

>> [...]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [commons-numbers] [...] NUMBERS-91: Added ofInt() factory methods [...]

Eric Barnhill
Fractions are constructed using either ints or doubles. In the case of
ints, the numerator and denominator are passed (or the denominator is
assumed to be one). Constructing fractions from doubles is more algorithmic
work: if I pass a known fixed quantity such as 0.6 of course it will not be
hard for the constructor to determine that is the equivalent of 3 / 5 .
However if doubles are being passed of unknown precision, then I may want
to request a max value on the denominator, or a precision within which the
simplest fraction should be returned, or even the maximum iterations in the
computation.

I think of those as qualitatively very different activities so I called
them ofInt and ofDouble. The example I had in mind was probably Complex,
where we have ofPolar and ofCartesian. I suppose you are right, in this
case the hard typing of the passed variables alone could invoke either an
int or double based method while with Complex, both constructors are taking
doubles.

You do then have some very similar methods, for example of(int a, int b)
will be an integer fraction with a on top and b on bottom; while calling
of(double a, int b) will produce a fraction that approximates double a with
max denominator b.

Those two processes are so different that it might be more clarifying to
distinguish them as ofInt(int a, int b) and ofDouble(double a, int b)

Eric


On Fri, Dec 28, 2018 at 4:33 AM Gilles <[hidden email]> wrote:

> Hello Eric.
>
> On Thu, 27 Dec 2018 17:00:15 -0800, Eric Barnhill wrote:
> > I am overloading:
> >
> > public static BigFraction ofInt(final BigInteger num) {
> >         return new BigFraction(num, BigInteger.ONE);
> >     }
> >
> >     public static BigFraction ofInt(BigInteger num, BigInteger den) {
> >     return new BigFraction(num, den);
> >     }
> >
> >     private BigFraction(BigInteger num, BigInteger den) {
> >
> > Did my comment not give that impression?
>
> I was in fact wondering why "ofInt" rather than just "of".
>
> Best,
> Gilles
>
> >> [...]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [commons-numbers] [...] NUMBERS-91: Added ofInt() factory methods [...]

jodastephen
I'd suggest `of` and `ofXxx` for factories that perform little work,
such as assigning to instance fields, and `from` and `fromXxx` for
factories that perform meaningful work or conversion.

Stephen


On Fri, 28 Dec 2018 at 17:24, Eric Barnhill <[hidden email]> wrote:

>
> Fractions are constructed using either ints or doubles. In the case of
> ints, the numerator and denominator are passed (or the denominator is
> assumed to be one). Constructing fractions from doubles is more algorithmic
> work: if I pass a known fixed quantity such as 0.6 of course it will not be
> hard for the constructor to determine that is the equivalent of 3 / 5 .
> However if doubles are being passed of unknown precision, then I may want
> to request a max value on the denominator, or a precision within which the
> simplest fraction should be returned, or even the maximum iterations in the
> computation.
>
> I think of those as qualitatively very different activities so I called
> them ofInt and ofDouble. The example I had in mind was probably Complex,
> where we have ofPolar and ofCartesian. I suppose you are right, in this
> case the hard typing of the passed variables alone could invoke either an
> int or double based method while with Complex, both constructors are taking
> doubles.
>
> You do then have some very similar methods, for example of(int a, int b)
> will be an integer fraction with a on top and b on bottom; while calling
> of(double a, int b) will produce a fraction that approximates double a with
> max denominator b.
>
> Those two processes are so different that it might be more clarifying to
> distinguish them as ofInt(int a, int b) and ofDouble(double a, int b)
>
> Eric
>
>
> On Fri, Dec 28, 2018 at 4:33 AM Gilles <[hidden email]> wrote:
>
> > Hello Eric.
> >
> > On Thu, 27 Dec 2018 17:00:15 -0800, Eric Barnhill wrote:
> > > I am overloading:
> > >
> > > public static BigFraction ofInt(final BigInteger num) {
> > >         return new BigFraction(num, BigInteger.ONE);
> > >     }
> > >
> > >     public static BigFraction ofInt(BigInteger num, BigInteger den) {
> > >     return new BigFraction(num, den);
> > >     }
> > >
> > >     private BigFraction(BigInteger num, BigInteger den) {
> > >
> > > Did my comment not give that impression?
> >
> > I was in fact wondering why "ofInt" rather than just "of".
> >
> > Best,
> > Gilles
> >
> > >> [...]
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [commons-numbers] [...] NUMBERS-91: Added ofInt() factory methods [...]

Gilles Sadowski
In reply to this post by Eric Barnhill
On Fri, 28 Dec 2018 09:17:08 -0800, Eric Barnhill wrote:

> Fractions are constructed using either ints or doubles. In the case
> of
> ints, the numerator and denominator are passed (or the denominator is
> assumed to be one). Constructing fractions from doubles is more
> algorithmic
> work: if I pass a known fixed quantity such as 0.6 of course it will
> not be
> hard for the constructor to determine that is the equivalent of 3 / 5
> .
> However if doubles are being passed of unknown precision, then I may
> want
> to request a max value on the denominator, or a precision within
> which the
> simplest fraction should be returned, or even the maximum iterations
> in the
> computation.
>
> I think of those as qualitatively very different activities

I agree.

> so I called
> them ofInt and ofDouble.

But we could consider:
Cat.1
  * of(long, long)
  * of(int, long)
  * of(BigInteger, BigInteger)
  * ...
and
Cat.2
  * ofDouble(double)
  * ofDouble(int, double)
  * ...
where "Cat.1" and "Cat.2" delineates the very different handling
which you referred to; and in the case of "Cat.1", an exact (?)
representation is constructed, while "Cat.2" could be lossy.
The former can also be construed as closer to the convention for
"ValJO" ("BigFaction" not being "ValJO" does not preclude choosing
the simplest name for its factory methods).

> The example I had in mind was probably Complex,
> where we have ofPolar and ofCartesian. I suppose you are right, in
> this
> case the hard typing of the passed variables alone could invoke
> either an
> int or double based method while with Complex, both constructors are
> taking
> doubles.

Quite right, there is some inconsistency; we may consider using
"of" if the "ValJO" aspect is more important that the equivalence
between polar and Cartesian input (cf. also the suggestion that
conversion methods should be name "from...", to which I'm not really
a fan yet).
If there is no strong argument yet for either, we could open a JIRA
report asking for opinions.  And leave that open as long as we
release "beta" versions.

> You do then have some very similar methods, for example of(int a, int
> b)
> will be an integer fraction with a on top and b on bottom; while
> calling
> of(double a, int b) will produce a fraction that approximates double
> a with
> max denominator b.
>
> Those two processes are so different that it might be more clarifying
> to
> distinguish them as ofInt(int a, int b) and ofDouble(double a, int b)

IMHO, it is not sufficiently self-documenting anyway: one has to go
to the docs in order to understand the difference; hence my proposal
to have "of" for the "obvious thing" (a/b) and "ofDouble" for the more
elaborate "transform".
Not sure if I'm clear in why the "non-symmetric" makes sense. :-}

Best regards,
Gilles

>
> Eric
>
>
> On Fri, Dec 28, 2018 at 4:33 AM Gilles <[hidden email]>
> wrote:
>
>> Hello Eric.
>>
>> On Thu, 27 Dec 2018 17:00:15 -0800, Eric Barnhill wrote:
>> > I am overloading:
>> >
>> > public static BigFraction ofInt(final BigInteger num) {
>> >         return new BigFraction(num, BigInteger.ONE);
>> >     }
>> >
>> >     public static BigFraction ofInt(BigInteger num, BigInteger
>> den) {
>> >     return new BigFraction(num, den);
>> >     }
>> >
>> >     private BigFraction(BigInteger num, BigInteger den) {
>> >
>> > Did my comment not give that impression?
>>
>> I was in fact wondering why "ofInt" rather than just "of".
>>
>> Best,
>> Gilles
>>
>> >> [...]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [commons-numbers] [...] NUMBERS-91: Added ofInt() factory methods [...]

Eric Barnhill
I think you make some good points here. Why call the "straightforward"
factory method ofInt when there is no reason not to use a long, or
BigInteger (or I suppose byte). These could all be handled with the
overloaded factory method of(). For Fraction, it is probably reasonable to
have only int-based constructors, but BigFraction should IMO take ints,
longs, or BigIntegers.

Similarly, the decimal case requires conversion, iteration and estimation.
I don't think there are scenarios under which it fails, but if the rounding
criterion were too strict, it would be unlikely to deliver what the user
wants (e.g. submitting .142857 but rounding to the first decimal place). So
Fractions with decimal input could be covered by the overloaded factory
method from() .

So just of() and from(), I think we could get a three person consensus on
this! :)

Eric

On Fri, Dec 28, 2018 at 10:34 AM Gilles <[hidden email]>
wrote:

> On Fri, 28 Dec 2018 09:17:08 -0800, Eric Barnhill wrote:
> > Fractions are constructed using either ints or doubles. In the case
> > of
> > ints, the numerator and denominator are passed (or the denominator is
> > assumed to be one). Constructing fractions from doubles is more
> > algorithmic
> > work: if I pass a known fixed quantity such as 0.6 of course it will
> > not be
> > hard for the constructor to determine that is the equivalent of 3 / 5
> > .
> > However if doubles are being passed of unknown precision, then I may
> > want
> > to request a max value on the denominator, or a precision within
> > which the
> > simplest fraction should be returned, or even the maximum iterations
> > in the
> > computation.
> >
> > I think of those as qualitatively very different activities
>
> I agree.
>
> > so I called
> > them ofInt and ofDouble.
>
> But we could consider:
> Cat.1
>   * of(long, long)
>   * of(int, long)
>   * of(BigInteger, BigInteger)
>   * ...
> and
> Cat.2
>   * ofDouble(double)
>   * ofDouble(int, double)
>   * ...
> where "Cat.1" and "Cat.2" delineates the very different handling
> which you referred to; and in the case of "Cat.1", an exact (?)
> representation is constructed, while "Cat.2" could be lossy.
> The former can also be construed as closer to the convention for
> "ValJO" ("BigFaction" not being "ValJO" does not preclude choosing
> the simplest name for its factory methods).
>
> > The example I had in mind was probably Complex,
> > where we have ofPolar and ofCartesian. I suppose you are right, in
> > this
> > case the hard typing of the passed variables alone could invoke
> > either an
> > int or double based method while with Complex, both constructors are
> > taking
> > doubles.
>
> Quite right, there is some inconsistency; we may consider using
> "of" if the "ValJO" aspect is more important that the equivalence
> between polar and Cartesian input (cf. also the suggestion that
> conversion methods should be name "from...", to which I'm not really
> a fan yet).
> If there is no strong argument yet for either, we could open a JIRA
> report asking for opinions.  And leave that open as long as we
> release "beta" versions.
>
> > You do then have some very similar methods, for example of(int a, int
> > b)
> > will be an integer fraction with a on top and b on bottom; while
> > calling
> > of(double a, int b) will produce a fraction that approximates double
> > a with
> > max denominator b.
> >
> > Those two processes are so different that it might be more clarifying
> > to
> > distinguish them as ofInt(int a, int b) and ofDouble(double a, int b)
>
> IMHO, it is not sufficiently self-documenting anyway: one has to go
> to the docs in order to understand the difference; hence my proposal
> to have "of" for the "obvious thing" (a/b) and "ofDouble" for the more
> elaborate "transform".
> Not sure if I'm clear in why the "non-symmetric" makes sense. :-}
>
> Best regards,
> Gilles
>
> >
> > Eric
> >
> >
> > On Fri, Dec 28, 2018 at 4:33 AM Gilles <[hidden email]>
> > wrote:
> >
> >> Hello Eric.
> >>
> >> On Thu, 27 Dec 2018 17:00:15 -0800, Eric Barnhill wrote:
> >> > I am overloading:
> >> >
> >> > public static BigFraction ofInt(final BigInteger num) {
> >> >         return new BigFraction(num, BigInteger.ONE);
> >> >     }
> >> >
> >> >     public static BigFraction ofInt(BigInteger num, BigInteger
> >> den) {
> >> >     return new BigFraction(num, den);
> >> >     }
> >> >
> >> >     private BigFraction(BigInteger num, BigInteger den) {
> >> >
> >> > Did my comment not give that impression?
> >>
> >> I was in fact wondering why "ofInt" rather than just "of".
> >>
> >> Best,
> >> Gilles
> >>
> >> >> [...]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>