[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

On Fri, 28 Dec 2018 09:17:08 -0800, Eric Barnhill wrote:

Fractions are constructed using either ints or doubles. In the caseofints, the numerator and denominator are passed (or the denominator isassumed to be one). Constructing fractions from doubles is morealgorithmicwork: if I pass a known fixed quantity such as 0.6 of course it willnot behard for the constructor to determine that is the equivalent of 3 / 5.However if doubles are being passed of unknown precision, then I maywantto request a max value on the denominator, or a precision withinwhich thesimplest fraction should be returned, or even the maximum iterationsin thecomputation. 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, inthiscase the hard typing of the passed variables alone could invokeeither anint or double based method while with Complex, both constructors aretakingdoubles.

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, intb)will be an integer fraction with a on top and b on bottom; whilecallingof(double a, int b) will produce a fraction that approximates doublea withmax denominator b.Those two processes are so different that it might be more clarifyingtodistinguish 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

EricOn Fri, Dec 28, 2018 at 4:33 AM Gilles <gilles@xxxxxxxxxxxxxxxxxxxxx>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, BigIntegerden) {> 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: dev-unsubscribe@xxxxxxxxxxxxxxxxxx For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxx

- Prev by Date:
**Re: [VOTE][LAZY] Move commons-codec to gitbox after 1.12 release.** - Next by Date:
**Re: [codec] Preparing for 1.12** - Previous by thread:
**Re: [commons-numbers] [...] NUMBERS-91: Added ofInt() factory methods [...]** - Next by thread:
**[codec] Preparing for 1.12** - Index(es):