Hi.
On Sat, 28 Jan 2017 14:38:21 -0500, Raymond DeCampo wrote:
[...]
Now, for the contents of the "fraction" module.
(1)
My main current concern is the formatting-related classes; as for
"complex", I think that
1. formatting (and I/O) is out of scope, and
2. the implementation were problematic in CM already.
Hence, I'd prefer to drop support altogether.[1]
I see your point of view, but allow me to play devil's advocate. It
seems
natural to create the formatter for a new object, in particular a
number
type, close to the type itself. Making new objects and expecting
another
project to implement the formatting seems like what economists call
an
externality. I suppose it really depends how everyone maintaining
text
would feel about it. I am somewhat concerned about how the release
cycle
would work, in particular for the initial released, where text would
have
to wait for a release of numbers before including the formatting and
then
users would not have formatting until the next release of text.
That said if the people maintaining text agree I have no objection.
[Text] is also a new component. It is not unthinkable that its scope
can encompass flexible formatting of such things as "fractions".
As suggested, someone having a clear idea of what would be the use
cases for formatting fraction, complex, and the likes, can create a
new "commons-text-math-formatting" module (that would depend on the
necessary modules from [Numbers]).
From my experience with them, the formatting class from [Math] are
not worth keeping.
A lot of other codes should IMHO be given higher priority.
My point is that, generally, people using "fraction" can do with the
constructors (to input data) and the accessors (to read result).
Moreover, developers of "fraction" usually would not want to spend
inordinate amounts of time to satisfy new formatting requests (that
tend to translate into hundreds of lines of code, cf. CM).
The formatting code itself is not part of the concept, and so IMO
effectively out of scope.
There is no more sense to output "ugly" ASCII than there would be
to generate any other output formats that would be more suited to
represent mathematical concept (e.g. LaTeX).
For logging and debugging purpose, "toString" should be quite fine.
Regards,
Gilles
(2)
Another concern is what to do with the "XxxField" classes.
Do we have any idea if the user base uses these classes? It's no
problem
to continue to maintain them (at least from my point of view) but I
am
having difficulty imagining the use case.
(3)
All "@since" tags must be removed.
(4)
Right now, I think that we should not advertize specific exceptions.
I.e. they should have at most "package" visibility, or maybe even
better: private inner class.
The Javadoc "@throws" should mention the JDK's parent class.
This is a departure from what was done in CM, where the design was
trying to satisfy mixed requirements, never shown (IMO to be really
necessary for a supposedly "low-level" library).
That suits me fine.
My stance is that whenever an exception is thrown from an
application,
there is a programming error that must be solved by looking at the
code (to find the faulty call or bug in the library).
Regards,
Gilles
[1] There could be a "math-module" in "Commons Text" that would do
such things, with the support of more advanced text manipulation
classes.
On Sat, Jan 28, 2017 at 8:36 AM, Gilles
<gil...@harfang.homelinux.org>
wrote:
Hi Ray.
On Sat, 28 Jan 2017 12:44:27 -0000, raydeca...@apache.org wrote:
Add maven module for fractions package from commons-math
Resolves pull request #4
Whenever possible, we aim at small commits (unless they are all of
the same kind, and it is obvious what is being done repeatedly).
In particular, independent codes should be added incrementally, to
allow for easier review.
For example, modifications to "pom.xml", addition of
"ArithmeticUtils",
"Fraction" and "BigFraction", etc.
Please note that you worked on an outdated branch.
[Please read the guidelines in "doc/development".]
Can you fix that (using "rebase" I guess) before we discuss the
contents of the commit?
Also to allow easy review: the commit message should refer to the
JIRA issue identifier).
Thanks,
Gilles
[...]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
