On Sun, 30 May 2004, Stephen Colebourne wrote:
> What about getNumerator()/getDenominator() - won't these change if 2/4 is
> held differently?
yes.
> I believe that we need to preserve the 2/4 concept
> distinct from 1/2, at least in the [lang] version.
I don't believe so. I can't imagine any reason why we would not want
these to be indistinguishable. It makes the operation of the entire class
more intuitive. I'd be more inclined to agree with you if I heard from
some large user of this class where (for some reason) these concepts
wanted to remain separate. I don't believe this user exists.
[And remember that fractions are reduced arbitrarily for some arithmetic
operations, so if you (for some reason) wanted a non-reduced fraction, it
would be hard to guarantee that it remained so.]
Most likely all users are just manually salting their code aggressively
with calls to f.reduce(), perhaps introducing some bugs by forgetting some
cases. Making Fraction reduce all fractions by itself will fix these
user bugs.
> The [lang] code needs to work and be reliable. However I suspect that a
> [math] version and [lang] version may be appropriate with slightly different
> semantics.
I'd rather not encourage people to use a broken interface. The current
Fraction has a number of actual bugs and encourages the programmer to make
others by its surprising behavior. In my opinion, fixing the obvious bugs
in Fraction without fixing the surprising behavior would just
encourage people to use Fraction and so make the surprising behavior more
dangerous.
If Fraction is to be moved to math, I'd probably suggest deprecating
lang.Fraction with the following text, "This implementation of Fraction
is not robust and make produce suprising behavior in corner cases,
especially when large numerators or denominators are used (and because
fractions are not kept in reduced form, the numerator and denomiator will
tend to grow larger as arithmetic is performed). Users are strongly
encouraged to migrate to o.a.c.math.Fraction, which has an identical API
but maintains fractions in simplified form and works reliably with
numerators and denominators over the whole int range from
Integer.MIN_VALUE to Integer.MAX_VALUE."
If you're willing to change 'identical' to 'near-identical', I'd suggest
removing the 'reduce()' and 'getReducedFraction()' methods from Fraction
(instead of just deprecating them) when/if the class is moved.
It was a significant amount of work to fix all the corner cases in
Fraction. At the moment I don't have time to repeat that work for a
non-reduced-Fraction 'minimal' patch. You are welcome to do that
if you like. Be careful of Integer.MIN_VALUE. Keeping the updated test
cases is probably a good start, although you'll want to add new test cases
checking that unreduced fractions also behave reliably, especially in
regard to overflow.
--scott
Ft. Meade Castro EZLN mail drop DNC Columbia IDEA Soviet Albanian
Cheney terrorist Blair cracking domestic disruption Attache Mk 48
( http://cscott.net/ )
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
