Right now BigFraction and Fraction are separate parallel classes.
I propose altering this so that BigFraction extends Fraction, overrides its methods, but also keeps its own unique methods. I think it would be an improvement to the API to have both classes share the same interface (and indeed an interface-based solution would be possible, but strikes me as overkill, since I don't see any additional classes beyond Fraction and BigFraction). BigFraction would in addition have its current methods to convert BigIntegers to ints and longs. Among the elegancies afforded by this change, if a Fraction operation causes overflow as previously discussed, a BigFraction could be returned and should be able to handle all further calls to Fraction unaltered. (This might not always be desired behavior, so Fraction may need to contain a setting to either throw and exception, or convert to BigFraction in case of overflow.) So I propose writing a ticket for this change. As sub-points on the ticket the BigFraction class could be conformed to Fraction class in terms of reduction of constants and producing a VALJO. Eric |
Hi Eric.
On Thu, 13 Dec 2018 11:20:12 -0800, Eric Barnhill wrote: > Right now BigFraction and Fraction are separate parallel classes. > > I propose altering this so that BigFraction extends Fraction, > overrides its > methods, but also keeps its own unique methods. > > I think it would be an improvement to the API to have both classes > share > the same interface (and indeed an interface-based solution would be > possible, but strikes me as overkill, since I don't see any > additional > classes beyond Fraction and BigFraction). BigFraction would in > addition > have its current methods to convert BigIntegers to ints and longs. > > Among the elegancies afforded by this change, if a Fraction operation > causes overflow as previously discussed, a BigFraction could be > returned > and should be able to handle all further calls to Fraction unaltered. > (This > might not always be desired behavior, so Fraction may need to contain > a > setting to either throw and exception, or convert to BigFraction in > case of > overflow.) Doesn't this setting achieve at runtime what the application developer should decide at compile time (by instantiating the class that has the desired behaviour)? > > So I propose writing a ticket for this change. As sub-points on the > ticket > the BigFraction class could be conformed to Fraction class in terms > of > reduction of constants and producing a VALJO. Inheritance and ValJO turn out being contradictory (see thread with subject "Inheritance and ValJO ?"). And (IIUC) the workaround/alternative hinted at by Stephen in that same thread might not be directly applicable because, here, the instance fields are different in "Fraction" and "BigFraction" ("long" vs "BigInteger"). I've just noticed that "BigInteger" is not final; hence "BigFraction" cannot be a ValJO either.[1] I don't think that we should rule out a "Fraction" interface. A "Fraction64" class would be an explicit "long"-based ValJO (with operations that are fast, but throw in case of overflow). "BigFraction" would be the fail-safe implementation. If it allows for faster operation in some cases, it could hold a "Fraction64" instance field (i.e. what you propose would be achieved through composition rather than inheritance). Does this make sense? Regards, Gilles [1] So this issue: https://issues.apache.org/jira/browse/NUMBERS-75 should probably be resolved as "Invalid". > > Eric --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
Thanks for this response and it took me some time to think your various
points through. On Thu, Dec 13, 2018 at 4:59 PM Gilles <[hidden email]> wrote: > > On Thu, 13 Dec 2018 11:20:12 -0800, Eric Barnhill wrote: > > > Among the elegancies afforded by this change, if a Fraction operation > > causes overflow as previously discussed, a BigFraction could be > > returned > > and should be able to handle all further calls to Fraction unaltered. > > (This > > might not always be desired behavior, so Fraction may need to contain > > a > > setting to either throw and exception, or convert to BigFraction in > > case of > > overflow.) > > Doesn't this setting achieve at runtime what the application > developer should decide at compile time (by instantiating the > class that has the desired behaviour)? > Yes. Perhaps I have been spending too much time writing Python lately. > > > > > So I propose writing a ticket for this change. As sub-points on the > > ticket > > the BigFraction class could be conformed to Fraction class in terms > > of > > reduction of constants and producing a VALJO. > > Inheritance and ValJO turn out being contradictory (see thread > with subject "Inheritance and ValJO ?"). > And (IIUC) the workaround/alternative hinted at by Stephen > in that same thread might not be directly applicable because, > here, the instance fields are different in "Fraction" and > "BigFraction" ("long" vs "BigInteger"). > > I've just noticed that "BigInteger" is not final; hence > "BigFraction" cannot be a ValJO either.[1] > It sounds like this is sufficient to disqualify this proposal. I don't think that we should rule out a "Fraction" interface. > Since BigFraction and Fraction have the use cases covered for now (improved, I would argue, by only the former requiring Big* classes) I propose wrapping up this work and leaving this until after a release. > [1] So this issue: > https://issues.apache.org/jira/browse/NUMBERS-75 > should probably be resolved as "Invalid". > Done. But, there were some "peripheral" improvements that came out of making Fraction a ValJO that should still be applied to BigFraction, for example conforming both classes to use the same factory methods, and reducing the absurd number of BigFraction constants. Shall I reopen and rename the ticket to focus on these changes, or is it better to start a new one? Eric |
Hi Eric.
On Thu, 27 Dec 2018 11:53:39 -0800, Eric Barnhill wrote: > Thanks for this response and it took me some time to think your > various > points through. > > On Thu, Dec 13, 2018 at 4:59 PM Gilles <[hidden email]> > wrote: > >> >> On Thu, 13 Dec 2018 11:20:12 -0800, Eric Barnhill wrote: >> >> > Among the elegancies afforded by this change, if a Fraction >> operation >> > causes overflow as previously discussed, a BigFraction could be >> > returned >> > and should be able to handle all further calls to Fraction >> unaltered. >> > (This >> > might not always be desired behavior, so Fraction may need to >> contain >> > a >> > setting to either throw and exception, or convert to BigFraction >> in >> > case of >> > overflow.) >> >> Doesn't this setting achieve at runtime what the application >> developer should decide at compile time (by instantiating the >> class that has the desired behaviour)? >> > > Yes. Perhaps I have been spending too much time writing Python > lately. :-) >> >> > >> > So I propose writing a ticket for this change. As sub-points on >> the >> > ticket >> > the BigFraction class could be conformed to Fraction class in >> terms >> > of >> > reduction of constants and producing a VALJO. >> >> Inheritance and ValJO turn out being contradictory (see thread >> with subject "Inheritance and ValJO ?"). >> And (IIUC) the workaround/alternative hinted at by Stephen >> in that same thread might not be directly applicable because, >> here, the instance fields are different in "Fraction" and >> "BigFraction" ("long" vs "BigInteger"). >> >> I've just noticed that "BigInteger" is not final; hence >> "BigFraction" cannot be a ValJO either.[1] >> > > It sounds like this is sufficient to disqualify this proposal. > > > I don't think that we should rule out a "Fraction" interface. Maybe not. How to call the implementations? "BigFraction" and ... "SmallFraction"? > > Since BigFraction and Fraction have the use cases covered for now > (improved, I would argue, by only the former requiring Big* classes) > I > propose wrapping up this work and leaving this until after a release. Fine. >> [1] So this issue: >> https://issues.apache.org/jira/browse/NUMBERS-75 >> should probably be resolved as "Invalid". >> > > Done. Thanks. > But, there were some "peripheral" improvements that came out of > making Fraction a ValJO that should still be applied to BigFraction, > for > example conforming both classes to use the same factory methods, +1 > and > reducing the absurd number of BigFraction constants. +1 > Shall I reopen and > rename the ticket to focus on these changes, or is it better to start > a new > one? I'd go for new one. Best regards, Gilles > > Eric --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
Free forum by Nabble | Edit this page |