You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Gilles <gi...@harfang.homelinux.org> on 2017/01/29 00:00:52 UTC
Re: [Numbers] Further work on NUMBERS-6
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
>>> <gi...@harfang.homelinux.org>
>>> wrote:
>>>
>>> Hi Ray.
>>>>
>>>> On Sat, 28 Jan 2017 12:44:27 -0000, raydecampo@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Numbers] Parsing and formatting classes
Posted by Gilles <gi...@harfang.homelinux.org>.
On Wed, 1 Feb 2017 07:36:32 -0500, Raymond DeCampo wrote:
> On Wed, Feb 1, 2017 at 4:43 AM, Gilles <gi...@harfang.homelinux.org>
> wrote:
>
>> On Tue, 31 Jan 2017 20:25:37 -0500, Raymond DeCampo wrote:
>>
>>> On Tue, Jan 31, 2017 at 11:27 AM, Gilles
>>> <gi...@harfang.homelinux.org>
>>> wrote:
>>>
>>> On Sun, 29 Jan 2017 17:02:05 -0500, Raymond DeCampo wrote:
>>>>
>>>> On Sun, Jan 29, 2017 at 11:15 AM, Gilles
>>>> <gi...@harfang.homelinux.org>
>>>>> wrote:
>>>>>
>>>>> On Sun, 29 Jan 2017 10:36:07 -0500, Raymond DeCampo wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>>> Well the first use-case that comes to my mind is accepting user
>>>>>>> input
>>>>>>>
>>>>>> from
>>>>> some kind of GUI and turning it into a Fraction instance. The
>>>>> second
>>>>> would
>>>>> be extracting Fraction values from some kind of text
>>>>> representation,
>>>>> e.g.
>>>>> CSV file, XML, etc.
>>>>>
>>>>>
>>>> I'd agree about parsing the output of "toString()" (i.e. a
>>>> "Locale"-independent format, similar to what the JDK does for
>>>> subclasses of "Number").
>>>>
>>>> But to be able to ensure valid input from CSV, XML, etc. would
>>>> require out-of-band information that will clutter the API to no
>>>> end.
>>>>
>>>>
>>> You've misunderstood. You asked for use-cases. Suppose you are
>>> consuming
>>> an XML file and wish to end up with Fraction instances. You would
>>> use
>>> your
>>> friendly neighbor XML parser to extract the bits of text from the
>>> XML.
>>> Then you would use FractionFormat to convert the text into Fraction
>>> instances. Just like you would use NumberFormat to convert bits of
>>> text
>>> from the XML to integers. This requires no additional code in the
>>> FractionFormat class.
>>>
>>
>> Misunderstood? I'm not so sure. What is the package of the
>> "NumberFormat" class?
>>
>>
> I was referring to your statement that "ensur[ing] valid input from
> CSV,
> XML, etc. would require out-of-band information that will clutter the
> API
> to no end."
>
> There would be no need for the API (no matter which commons component
> it
> lives in) to have any knowledge of the containing text format.
At the very least, the "Locale" of the input must be passed, or
problems
will ensue. "Locale" is "out-of-band" IMHO.
>> "Double.valueOf", for example, does not parse localized
>> representation
>> of numbers. Providing the equivalent of "NumberFormat" instead of
>> that
>> method is going to cause problems.[1]
>>
>
> There is no reason it could not be "in addition to", rather than
> "instead
> of".
Agreed. That's what I wrote in the previous message (quoted below)...
And in this case, I'd rather stick to the layout of the JDK, which
emphasizes that the two functionalities are distinct.
You may not agree that [Text] is a better home, but then you have to
make the case why.
Please note that we should strive to make the "spin-offs" of Commons
Math as stable as possible. I certainly would like to avoid any
potentiality of having to release Numbers 2.0 because we copied a 10
years old utility (that was probably never used outside of Commons
Math's error message formatting) without having looked at better
alternatives.
IMO, the game is currently about finding the truly low-level math
utilities, and make them really independent (that is bona-fide
components) so that their development become separate, guided
by internal consistency and not entangled with released scheduled
to fix unrelated stuff.
In the case of a "fraction", the accessors
getNumerator()
getDenominator()
are the only inputs required in order to create a string representation
of the instance.
These accessors are trivial (and thus unlikely to ever need an API
break) while the formatting part is far from trivial, and surely
would benefit from more elaborate functionality likely to also be
part of [Text].
I hope I made my point clear this time. :-}
Gilles
>>
>> So, to summarize, I think that
>> 1. "valueOf(String)" (and similarly "parseFraction(String)") are
>> fine
>> to implement in the [Numbers] component.[2]
>> 2. localized versions should be implemented in the [Text]
>> component.
>>
>> And similarly for "Complex" (although in that case, we may end up to
>> only accept the Cartesian representation).
>>
>> Regards,
>> Gilles
>>
>> [1] On systems where the default locale is not "US".
>> [2] Using private methods or package-scoped classes.
>>
>>
>>
>>>> But I think we are reaching the end of the useful phase of the
>>>> discussion
>>>>
>>>>> so that said, I don't really have strong feelings on the matter.
>>>>> I
>>>>> would
>>>>> leave it in were it up to me but I wouldn't oppose you if you
>>>>> wanted to
>>>>> take it out.
>>>>>
>>>>>
>>>> I want to take it out because the current code was unhelpful in
>>>> the
>>>> one case where I needed it (to change the precision of the printed
>>>> value, which was about the simplest use-case). And I could not fix
>>>> it
>>>> without a lot of work (to undo what the formatting instance was
>>>> doing)
>>>> in order to get the same output as "toString()"!
>>>>
>>>> You (and Rob) are most welcome to move the code to [Text] if you
>>>> see
>>>> value in that implementation.
>>>>
>>>>
>>>>
>>>> Regards,
>>>> Gilles
>>>>
>>>>
>>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Numbers] Parsing and formatting classes
Posted by Raymond DeCampo <ra...@decampo.org>.
On Wed, Feb 1, 2017 at 4:43 AM, Gilles <gi...@harfang.homelinux.org> wrote:
> On Tue, 31 Jan 2017 20:25:37 -0500, Raymond DeCampo wrote:
>
>> On Tue, Jan 31, 2017 at 11:27 AM, Gilles <gi...@harfang.homelinux.org>
>> wrote:
>>
>> On Sun, 29 Jan 2017 17:02:05 -0500, Raymond DeCampo wrote:
>>>
>>> On Sun, Jan 29, 2017 at 11:15 AM, Gilles <gi...@harfang.homelinux.org>
>>>> wrote:
>>>>
>>>> On Sun, 29 Jan 2017 10:36:07 -0500, Raymond DeCampo wrote:
>>>>
>>>>>
>>>>>
>>>>>> Well the first use-case that comes to my mind is accepting user input
>>>>>>
>>>>> from
>>>> some kind of GUI and turning it into a Fraction instance. The second
>>>> would
>>>> be extracting Fraction values from some kind of text representation,
>>>> e.g.
>>>> CSV file, XML, etc.
>>>>
>>>>
>>> I'd agree about parsing the output of "toString()" (i.e. a
>>> "Locale"-independent format, similar to what the JDK does for
>>> subclasses of "Number").
>>>
>>> But to be able to ensure valid input from CSV, XML, etc. would
>>> require out-of-band information that will clutter the API to no
>>> end.
>>>
>>>
>> You've misunderstood. You asked for use-cases. Suppose you are consuming
>> an XML file and wish to end up with Fraction instances. You would use
>> your
>> friendly neighbor XML parser to extract the bits of text from the XML.
>> Then you would use FractionFormat to convert the text into Fraction
>> instances. Just like you would use NumberFormat to convert bits of text
>> from the XML to integers. This requires no additional code in the
>> FractionFormat class.
>>
>
> Misunderstood? I'm not so sure. What is the package of the
> "NumberFormat" class?
>
>
I was referring to your statement that "ensur[ing] valid input from CSV,
XML, etc. would require out-of-band information that will clutter the API
to no end."
There would be no need for the API (no matter which commons component it
lives in) to have any knowledge of the containing text format.
> "Double.valueOf", for example, does not parse localized representation
> of numbers. Providing the equivalent of "NumberFormat" instead of that
> method is going to cause problems.[1]
>
There is no reason it could not be "in addition to", rather than "instead
of".
>
> So, to summarize, I think that
> 1. "valueOf(String)" (and similarly "parseFraction(String)") are fine
> to implement in the [Numbers] component.[2]
> 2. localized versions should be implemented in the [Text] component.
>
> And similarly for "Complex" (although in that case, we may end up to
> only accept the Cartesian representation).
>
> Regards,
> Gilles
>
> [1] On systems where the default locale is not "US".
> [2] Using private methods or package-scoped classes.
>
>
>
>>> But I think we are reaching the end of the useful phase of the discussion
>>>
>>>> so that said, I don't really have strong feelings on the matter. I
>>>> would
>>>> leave it in were it up to me but I wouldn't oppose you if you wanted to
>>>> take it out.
>>>>
>>>>
>>> I want to take it out because the current code was unhelpful in the
>>> one case where I needed it (to change the precision of the printed
>>> value, which was about the simplest use-case). And I could not fix it
>>> without a lot of work (to undo what the formatting instance was doing)
>>> in order to get the same output as "toString()"!
>>>
>>> You (and Rob) are most welcome to move the code to [Text] if you see
>>> value in that implementation.
>>>
>>>
>>>
>>> Regards,
>>> Gilles
>>>
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [Numbers] Parsing and formatting classes
Posted by Gilles <gi...@harfang.homelinux.org>.
On Tue, 31 Jan 2017 20:25:37 -0500, Raymond DeCampo wrote:
> On Tue, Jan 31, 2017 at 11:27 AM, Gilles
> <gi...@harfang.homelinux.org>
> wrote:
>
>> On Sun, 29 Jan 2017 17:02:05 -0500, Raymond DeCampo wrote:
>>
>>> On Sun, Jan 29, 2017 at 11:15 AM, Gilles
>>> <gi...@harfang.homelinux.org>
>>> wrote:
>>>
>>> On Sun, 29 Jan 2017 10:36:07 -0500, Raymond DeCampo wrote:
>>>>
>>>>>
>>>>> Well the first use-case that comes to my mind is accepting user
>>>>> input
>>> from
>>> some kind of GUI and turning it into a Fraction instance. The
>>> second
>>> would
>>> be extracting Fraction values from some kind of text
>>> representation, e.g.
>>> CSV file, XML, etc.
>>>
>>
>> I'd agree about parsing the output of "toString()" (i.e. a
>> "Locale"-independent format, similar to what the JDK does for
>> subclasses of "Number").
>>
>> But to be able to ensure valid input from CSV, XML, etc. would
>> require out-of-band information that will clutter the API to no
>> end.
>>
>
> You've misunderstood. You asked for use-cases. Suppose you are
> consuming
> an XML file and wish to end up with Fraction instances. You would
> use your
> friendly neighbor XML parser to extract the bits of text from the
> XML.
> Then you would use FractionFormat to convert the text into Fraction
> instances. Just like you would use NumberFormat to convert bits of
> text
> from the XML to integers. This requires no additional code in the
> FractionFormat class.
Misunderstood? I'm not so sure. What is the package of the
"NumberFormat" class?
"Double.valueOf", for example, does not parse localized representation
of numbers. Providing the equivalent of "NumberFormat" instead of that
method is going to cause problems.[1]
So, to summarize, I think that
1. "valueOf(String)" (and similarly "parseFraction(String)") are fine
to implement in the [Numbers] component.[2]
2. localized versions should be implemented in the [Text] component.
And similarly for "Complex" (although in that case, we may end up to
only accept the Cartesian representation).
Regards,
Gilles
[1] On systems where the default locale is not "US".
[2] Using private methods or package-scoped classes.
>>
>> But I think we are reaching the end of the useful phase of the
>> discussion
>>> so that said, I don't really have strong feelings on the matter. I
>>> would
>>> leave it in were it up to me but I wouldn't oppose you if you
>>> wanted to
>>> take it out.
>>>
>>
>> I want to take it out because the current code was unhelpful in the
>> one case where I needed it (to change the precision of the printed
>> value, which was about the simplest use-case). And I could not fix
>> it
>> without a lot of work (to undo what the formatting instance was
>> doing)
>> in order to get the same output as "toString()"!
>>
>> You (and Rob) are most welcome to move the code to [Text] if you see
>> value in that implementation.
>>
>>
>>
>> Regards,
>> Gilles
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Numbers] Parsing and formatting classes
Posted by Raymond DeCampo <ra...@decampo.org>.
On Tue, Jan 31, 2017 at 11:27 AM, Gilles <gi...@harfang.homelinux.org>
wrote:
> On Sun, 29 Jan 2017 17:02:05 -0500, Raymond DeCampo wrote:
>
>> On Sun, Jan 29, 2017 at 11:15 AM, Gilles <gi...@harfang.homelinux.org>
>> wrote:
>>
>> On Sun, 29 Jan 2017 10:36:07 -0500, Raymond DeCampo wrote:
>>>
>>>>
>>>> Well the first use-case that comes to my mind is accepting user input
>> from
>> some kind of GUI and turning it into a Fraction instance. The second
>> would
>> be extracting Fraction values from some kind of text representation, e.g.
>> CSV file, XML, etc.
>>
>
> I'd agree about parsing the output of "toString()" (i.e. a
> "Locale"-independent format, similar to what the JDK does for
> subclasses of "Number").
>
> But to be able to ensure valid input from CSV, XML, etc. would
> require out-of-band information that will clutter the API to no
> end.
>
You've misunderstood. You asked for use-cases. Suppose you are consuming
an XML file and wish to end up with Fraction instances. You would use your
friendly neighbor XML parser to extract the bits of text from the XML.
Then you would use FractionFormat to convert the text into Fraction
instances. Just like you would use NumberFormat to convert bits of text
from the XML to integers. This requires no additional code in the
FractionFormat class.
>
> But I think we are reaching the end of the useful phase of the discussion
>> so that said, I don't really have strong feelings on the matter. I would
>> leave it in were it up to me but I wouldn't oppose you if you wanted to
>> take it out.
>>
>
> I want to take it out because the current code was unhelpful in the
> one case where I needed it (to change the precision of the printed
> value, which was about the simplest use-case). And I could not fix it
> without a lot of work (to undo what the formatting instance was doing)
> in order to get the same output as "toString()"!
>
> You (and Rob) are most welcome to move the code to [Text] if you see
> value in that implementation.
>
>
>
> Regards,
> Gilles
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [Numbers] Parsing and formatting classes
Posted by Gilles <gi...@harfang.homelinux.org>.
On Sun, 29 Jan 2017 17:02:05 -0500, Raymond DeCampo wrote:
> On Sun, Jan 29, 2017 at 11:15 AM, Gilles
> <gi...@harfang.homelinux.org>
> wrote:
>
>> On Sun, 29 Jan 2017 10:36:07 -0500, Raymond DeCampo wrote:
>>
>>> On Sat, Jan 28, 2017 at 7:00 PM, Gilles
>>> <gi...@harfang.homelinux.org>
>>> wrote:
>>>
>>> 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".
>>>>
>>>>
>>> At the risk of raising a sore subject, wasn't the expectations of
>>> third
>>> parties that someone else maintain code for them part of the
>>> impetus for
>>> the current effort?
>>>
>>
>> I'm not sure I understand what you wrote here.
>>
>> So shouldn't we get buy-in from the commons-text team
>>> before we make a decision?
>>>
>>
>> My proposal does not imply that someone else should implement
>> the code.
>>
>> For example, if you feel confident that the input parsing and
>> output formatting classes are useful and well implemented, you
>> can start a discussion on this ML (with subject prefix [Text]),
>> to inquire about objections to moving them to [Text].
>> It seems that it was informally agreed that [Text] is a somewhat
>> higher level component, i.e. that it can have runtime dependencies.
>>
>> 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 existence of some formats shouldn't result in an obligation to
>>> support
>>> whatever formats are requested.
>>>
>>
>> Certainly.
>> But it is easier to justify as "out of scope", rather than "we don't
>> care about format X".
>> Then if someone comes up with a good library that can handle the
>> "Commons Numbers" types, our incomplete code will become obsolete,
>> and any work put in it will have been useless. The question is:
>> Are there _currently_ any use-cases for it?
>>
>> If there aren't, please let's not rush to add it to the new
>> component.
>>
>>
>>>> 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.
>>>>
>>>>
>>> I imagine that the greater value is in the parsing portion of the
>>> format
>>> classes, not the output portion.
>>>
>>
>> I do not have enough imagination. ;-)
>>
>>
> Well the first use-case that comes to my mind is accepting user input
> from
> some kind of GUI and turning it into a Fraction instance. The second
> would
> be extracting Fraction values from some kind of text representation,
> e.g.
> CSV file, XML, etc.
I'd agree about parsing the output of "toString()" (i.e. a
"Locale"-independent format, similar to what the JDK does for
subclasses of "Number").
But to be able to ensure valid input from CSV, XML, etc. would
require out-of-band information that will clutter the API to no
end.
> But I think we are reaching the end of the useful phase of the
> discussion
> so that said, I don't really have strong feelings on the matter. I
> would
> leave it in were it up to me but I wouldn't oppose you if you wanted
> to
> take it out.
I want to take it out because the current code was unhelpful in the
one case where I needed it (to change the precision of the printed
value, which was about the simplest use-case). And I could not fix it
without a lot of work (to undo what the formatting instance was doing)
in order to get the same output as "toString()"!
You (and Rob) are most welcome to move the code to [Text] if you see
value in that implementation.
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Numbers] Parsing and formatting classes (Was: Further work on NUMBERS-6)
Posted by Raymond DeCampo <ra...@decampo.org>.
On Sun, Jan 29, 2017 at 11:15 AM, Gilles <gi...@harfang.homelinux.org>
wrote:
> On Sun, 29 Jan 2017 10:36:07 -0500, Raymond DeCampo wrote:
>
>> On Sat, Jan 28, 2017 at 7:00 PM, Gilles <gi...@harfang.homelinux.org>
>> wrote:
>>
>> 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".
>>>
>>>
>> At the risk of raising a sore subject, wasn't the expectations of third
>> parties that someone else maintain code for them part of the impetus for
>> the current effort?
>>
>
> I'm not sure I understand what you wrote here.
>
> So shouldn't we get buy-in from the commons-text team
>> before we make a decision?
>>
>
> My proposal does not imply that someone else should implement
> the code.
>
> For example, if you feel confident that the input parsing and
> output formatting classes are useful and well implemented, you
> can start a discussion on this ML (with subject prefix [Text]),
> to inquire about objections to moving them to [Text].
> It seems that it was informally agreed that [Text] is a somewhat
> higher level component, i.e. that it can have runtime dependencies.
>
> 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 existence of some formats shouldn't result in an obligation to support
>> whatever formats are requested.
>>
>
> Certainly.
> But it is easier to justify as "out of scope", rather than "we don't
> care about format X".
> Then if someone comes up with a good library that can handle the
> "Commons Numbers" types, our incomplete code will become obsolete,
> and any work put in it will have been useless. The question is:
> Are there _currently_ any use-cases for it?
>
> If there aren't, please let's not rush to add it to the new component.
>
>
>>> 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.
>>>
>>>
>> I imagine that the greater value is in the parsing portion of the format
>> classes, not the output portion.
>>
>
> I do not have enough imagination. ;-)
>
>
Well the first use-case that comes to my mind is accepting user input from
some kind of GUI and turning it into a Fraction instance. The second would
be extracting Fraction values from some kind of text representation, e.g.
CSV file, XML, etc.
But I think we are reaching the end of the useful phase of the discussion
so that said, I don't really have strong feelings on the matter. I would
leave it in were it up to me but I wouldn't oppose you if you wanted to
take it out.
Re: [Numbers] Parsing and formatting classes
Posted by Gilles <gi...@harfang.homelinux.org>.
On Sun, 29 Jan 2017 17:15:02 +0100, Gilles wrote:
> On Sun, 29 Jan 2017 10:36:07 -0500, Raymond DeCampo wrote:
>> On Sat, Jan 28, 2017 at 7:00 PM, Gilles
>> <gi...@harfang.homelinux.org>
>> wrote:
>>
>>> 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".
>>>
>>
>> At the risk of raising a sore subject, wasn't the expectations of
>> third
>> parties that someone else maintain code for them part of the impetus
>> for
>> the current effort?
>
> I'm not sure I understand what you wrote here.
>
>> So shouldn't we get buy-in from the commons-text team
>> before we make a decision?
>
> My proposal does not imply that someone else should implement
> the code.
>
> For example, if you feel confident that the input parsing and
> output formatting classes are useful and well implemented, you
> can start a discussion on this ML (with subject prefix [Text]),
> to inquire about objections to moving them to [Text].
> It seems that it was informally agreed that [Text] is a somewhat
> higher level component, i.e. that it can have runtime dependencies.
>
>>> 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 existence of some formats shouldn't result in an obligation to
>> support
>> whatever formats are requested.
>
> Certainly.
> But it is easier to justify as "out of scope", rather than "we don't
> care about format X".
> Then if someone comes up with a good library that can handle the
> "Commons Numbers" types, our incomplete code will become obsolete,
> and any work put in it will have been useless. The question is:
> Are there _currently_ any use-cases for it?
>
> If there aren't, please let's not rush to add it to the new
> component.
Question about the parsing classes.
(1)
Why isn't there a
public static Fraction parseFraction(String s)
method (similar to the JDK's subclasses of "java.lang.Number").
(2)
Why does method
public Fraction parse(final String source)
in "FractionFormat" throw a subclass of "ArithmeticException" while
"parse" methods of the JDK's "Number" class throw
"NumberFormatException"
(a subclass of "IllegalArgumentException")?
(3)
Why does the parsing depend on "Locale"? ["Number" subclasses do not.]
(4)
Why use "StringBuffer"?
(5)
Why do several of the Javadoc comments in "FractionFormat" mention
"complex format"?
The more we look into these old classes ("@since 1.1"), the more we'll
find that they should have been deprecated, and that probably nobody
uses them (or we should have gotten some remarks about the above).
Regards,
Gilles
>>> 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.
>>>
>>
>> I imagine that the greater value is in the parsing portion of the
>> format
>> classes, not the output portion.
>
> I do not have enough imagination. ;-)
>
> Regards,
> Gilles
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Numbers] Parsing and formatting classes (Was: Further work on
NUMBERS-6)
Posted by Gilles <gi...@harfang.homelinux.org>.
On Sun, 29 Jan 2017 10:36:07 -0500, Raymond DeCampo wrote:
> On Sat, Jan 28, 2017 at 7:00 PM, Gilles
> <gi...@harfang.homelinux.org>
> wrote:
>
>> 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".
>>
>
> At the risk of raising a sore subject, wasn't the expectations of
> third
> parties that someone else maintain code for them part of the impetus
> for
> the current effort?
I'm not sure I understand what you wrote here.
> So shouldn't we get buy-in from the commons-text team
> before we make a decision?
My proposal does not imply that someone else should implement
the code.
For example, if you feel confident that the input parsing and
output formatting classes are useful and well implemented, you
can start a discussion on this ML (with subject prefix [Text]),
to inquire about objections to moving them to [Text].
It seems that it was informally agreed that [Text] is a somewhat
higher level component, i.e. that it can have runtime dependencies.
>> 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 existence of some formats shouldn't result in an obligation to
> support
> whatever formats are requested.
Certainly.
But it is easier to justify as "out of scope", rather than "we don't
care about format X".
Then if someone comes up with a good library that can handle the
"Commons Numbers" types, our incomplete code will become obsolete,
and any work put in it will have been useless. The question is:
Are there _currently_ any use-cases for it?
If there aren't, please let's not rush to add it to the new component.
>>
>> 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.
>>
>
> I imagine that the greater value is in the parsing portion of the
> format
> classes, not the output portion.
I do not have enough imagination. ;-)
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Numbers] Further work on NUMBERS-6
Posted by Raymond DeCampo <ra...@decampo.org>.
On Sat, Jan 28, 2017 at 7:00 PM, Gilles <gi...@harfang.homelinux.org>
wrote:
> 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".
>
At the risk of raising a sore subject, wasn't the expectations of third
parties that someone else maintain code for them part of the impetus for
the current effort? So shouldn't we get buy-in from the commons-text team
before we make a decision?
> 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 existence of some formats shouldn't result in an obligation to support
whatever formats are requested.
>
> 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.
>
I imagine that the greater value is in the parsing portion of the format
classes, not the output portion.
Thanks,
Ray
>
> 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 <gi...@harfang.homelinux.org>
>>>> wrote:
>>>>
>>>> Hi Ray.
>>>>
>>>>>
>>>>> On Sat, 28 Jan 2017 12:44:27 -0000, raydecampo@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>