Re: [Numbers] Formatting classes
Hi Eric. Le jeu. 31 janv. 2019 à 22:04, Eric Barnhill a écrit : > > Please ignore previous post which was sent by accident. > > > > > > > Le mar. 29 janv. 2019 à 00:14, Eric Barnhill a > > écrit : > > > > > > Fraction already has a toString() method which should cover VALJO > > concerns > > > by representing the instance in one specific way. > > > > It has 2 different outputs (suppress the fraction bar and denominator > > when it is 1). > > Not sure that's very robust: Expecting a "/" as part of the representation > > will make parsing easier (noting that class is still missing the > > parse/valueOf > > method). > > > > Good point but I think it is not too much to ask to have a logic block: > -- if contains slash: parse numerator and denominator and construct using > of() > -- if doesn't contain slash: parse as double and construct using from() I suspect this would be wrong. The "valueOf" should be the inverse of "toString"; it won't be (IIUC) when "toString" supresses the slash. As I said, a can of worms, not worth spending so much time. > > > > > > The FractionFormat classes allow for options beyond this such as proper > > > fractions or region-specific versions. > > > > IMO it's out of scope for a low-level component, and at least until we > > have an actual use-case. > > Locale-specific input/output is a can of worms that should be handled > > by text-oriented libraries. > > Having output (e.g. error messages) differ from locale to locale is a > > very bad idea (in a low-level component[1]), and so is the capacity (of > > a low-level component) to truncate data that might be needed by the > > caller. [Those two things are the purpose of the "NumberFormat" > > family of classes.] > > > > The AbstractFractionFormat is an extension of NumberFormat. I agree that > these classes would serve better in the NumberFormat family. I don't know what you mean by this last sentence. "NumberFormat" is a JDK class. > However, I > would rather do that than throw away good work. I would be surprised if > these formatting classes had _not_ been designed around some reasonable use > cases. I repeat that the only known case (to me) is in formatting numbers in exception messages. And this CM feature (!) produces truncated output that's a total nuisance. That would not be the first example of sloppy/useless code. Without a demonstrated example of useful application, I strongly favour not introducing this code in [Numbers] (and anything that is Locale-dependent). Its current state will always be available in the repository if we need to revisit this issue later on. > So my proposed workflow is: > -- keep the toString class I'd perhaps simplify it so that a "1" denominator is kept. Not sure about the advantage/drawbacks trade-off. > -- move parse() out of the formatting classes and into the Fraction > classes (and follow above logic) > -- move the formatting classes into the NumberFormat family Same wondering as above about this last sentence. > > > The Javadoc of the "...FractionFormat" classes is also badly out-of-sync > > since most methods refer to "complex" (?), witnessing the extremely low > > usage. > > > > I will write a ticket for this. > > Eric - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Numbers] Formatting classes
Please ignore previous post which was sent by accident. > > Le mar. 29 janv. 2019 à 00:14, Eric Barnhill a > écrit : > > > > Fraction already has a toString() method which should cover VALJO > concerns > > by representing the instance in one specific way. > > It has 2 different outputs (suppress the fraction bar and denominator > when it is 1). > Not sure that's very robust: Expecting a "/" as part of the representation > will make parsing easier (noting that class is still missing the > parse/valueOf > method). > Good point but I think it is not too much to ask to have a logic block: -- if contains slash: parse numerator and denominator and construct using of() -- if doesn't contain slash: parse as double and construct using from() > > The FractionFormat classes allow for options beyond this such as proper > > fractions or region-specific versions. > > IMO it's out of scope for a low-level component, and at least until we > have an actual use-case. > Locale-specific input/output is a can of worms that should be handled > by text-oriented libraries. > Having output (e.g. error messages) differ from locale to locale is a > very bad idea (in a low-level component[1]), and so is the capacity (of > a low-level component) to truncate data that might be needed by the > caller. [Those two things are the purpose of the "NumberFormat" > family of classes.] > The AbstractFractionFormat is an extension of NumberFormat. I agree that these classes would serve better in the NumberFormat family. However, I would rather do that than throw away good work. I would be surprised if these formatting classes had _not_ been designed around some reasonable use cases. So my proposed workflow is: -- keep the toString class -- move parse() out of the formatting classes and into the Fraction classes (and follow above logic) -- move the formatting classes into the NumberFormat family > The Javadoc of the "...FractionFormat" classes is also badly out-of-sync > since most methods refer to "complex" (?), witnessing the extremely low > usage. > I will write a ticket for this. Eric
Re: [Numbers] Formatting classes
>
> > Fraction already has a toString() method which should cover VALJO
> concerns
> > by representing the instance in one specific way.
>
> It has 2 different outputs (suppress the fraction bar and denominator
> when it is 1).
> Not sure that's very robust: Expecting a "/" as part of the representation
> will make parsing easier (noting that class is still missing the
> parse/valueOf
> method).
>
Good point, although it doesn't seem to me too much to ask to have a logic
block:
>
> > The FractionFormat classes allow for options beyond this such as proper
> > fractions or region-specific versions.
>
> IMO it's out of scope for a low-level component, and at least until we
> have an actual use-case.
> Locale-specific input/output is a can of worms that should be handled
> by text-oriented libraries.
> Having output (e.g. error messages) differ from locale to locale is a
> very bad idea (in a low-level component[1]), and so is the capacity (of
> a low-level component) to truncate data that might be needed by the
> caller. [Those two things are the purpose of the "NumberFormat"
> family of classes.]
>
> The Javadoc of the "...FractionFormat" classes is also badly out-of-sync
> since most methods refer to "complex" (?), witnessing the extremely low
> usage.
>
> Best regards,
> Gilles
>
> >
> > It doesn't seem to me like it violates VALJO principles to have an
> > auxiliary class that takes care of these alternate cases. On the contrary
> > from a VALJO perspective it seems like a nice idea to have encapsulated
> > them in an auxiliary class structure.
> >
> > Eric
> >
>
> [1] Application developers can customize at will from the return values of
> "getNumerator()" and "getDenominator()" methods.
>
> > On Sat, Jan 26, 2019 at 12:11 PM Gilles Sadowski
> > wrote:
> >
> > > Le sam. 26 janv. 2019 à 17:24, Gary Gregory a
> > > écrit :
> > > >
> > > > On Sat, Jan 26, 2019 at 10:19 AM Gilles Sadowski <
> gillese...@gmail.com>
> > > > wrote:
> > > >
> > > > > Le sam. 26 janv. 2019 à 14:01, Gary Gregory <
> garydgreg...@gmail.com> a
> > > > > écrit :
> > > > > >
> > > > > > Are we talking about formatting [numbers] specific classes or JRE
> > > > > classes?
> > > > >
> > > > > They are classes that aim to customize the output from classes in
> > > > > [Numbers],
> > > > > (specifically, the way to display a {{Fraction}} or {{BigFraction}}
> > > > > object).
> > > > >
> > > >
> > > > Well, then that code does not belong in [text] since it requires
> [number]
> > > > classes.
> > >
> > > Not what I meant.
> > > People wanting custom formatting of a fraction can get the parts that
> > > define it (i.e. numerator and denominator) and call whatever they want
> > > (e.g. something which might be in [Text]) in order to craft a string
> > > representation of those numbers.
> > > Following ValJO (even if "BigFraction" is not one, strictly speaking),
> > > we want *one* way to represent the contents of the instance.
> > >
> > > Regards,
> > > Gilles
> > >
> > > >
> > > > Gary
> > > >
> > > >
> > > > > The classes provide accessors to the numerator and denominator
> which
> > > can be
> > > > > used by outside code to display the fraction as it wishes.
> > > > >
> > > > > Side note: Similar formatting classes in Commons Math are more of a
> > > > > nuisance
> > > > > than anything, e.g. displaying small numbers as "0" (in exception
> > > > > messages),
> > > > > because the default is to provide 6 decimal digits, thus discarding
> > > > > all significant
> > > > > information.
> > > > >
> > > > > Gilles
> > > > >
> > > > > >
> > > > > > Gary
> > > > > >
> > > > > > On Sat, Jan 26, 2019 at 7:14 AM Gilles Sadowski <
> > > gillese...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Hi.
> > > > > > >
> > > > > > > In reference to the current changes in module
> > > > > "commons-numbers-fraction"
> > > > > > > (on the "fraction-dev"), my opinion is that the formatting
> classes
> > > > > should
> > > > > > > be
> > > > > > > removed.[1]
> > > > > > > At the level of a math component, it's safer to stick to a
> single,
> > > > > > > locale-independent format.[2]
> > > > > > >
> > > > > > > Regards,
> > > > > > > Gilles
> > > > > > >
> > > > > > > [1] Rationale is that pretty-printing is not the purpose of the
> > > library
> > > > > > > (better
> > > > > > > leave that to [Text], or a dedicated module).
> > > > > > > [2] There is a pending issue (NUMBERS-88) that suggests
> > > hard-coding the
> > > > > > > format.
> > > > > > >
> > > > > > >
> > > -
> > > > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > > > > > For additional commands, e-mail: dev-h...@commons.apache.org
> > > > > > >
> > > > > > >
> > > > >
> > > > >
> -
> > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > > > For additional commands, e-mail:
Re: [Numbers] Formatting classes
Hello.
Le mar. 29 janv. 2019 à 00:14, Eric Barnhill a écrit :
>
> Fraction already has a toString() method which should cover VALJO concerns
> by representing the instance in one specific way.
It has 2 different outputs (suppress the fraction bar and denominator
when it is 1).
Not sure that's very robust: Expecting a "/" as part of the representation
will make parsing easier (noting that class is still missing the parse/valueOf
method).
> The FractionFormat classes allow for options beyond this such as proper
> fractions or region-specific versions.
IMO it's out of scope for a low-level component, and at least until we
have an actual use-case.
Locale-specific input/output is a can of worms that should be handled
by text-oriented libraries.
Having output (e.g. error messages) differ from locale to locale is a
very bad idea (in a low-level component[1]), and so is the capacity (of
a low-level component) to truncate data that might be needed by the
caller. [Those two things are the purpose of the "NumberFormat"
family of classes.]
The Javadoc of the "...FractionFormat" classes is also badly out-of-sync
since most methods refer to "complex" (?), witnessing the extremely low
usage.
Best regards,
Gilles
>
> It doesn't seem to me like it violates VALJO principles to have an
> auxiliary class that takes care of these alternate cases. On the contrary
> from a VALJO perspective it seems like a nice idea to have encapsulated
> them in an auxiliary class structure.
>
> Eric
>
[1] Application developers can customize at will from the return values of
"getNumerator()" and "getDenominator()" methods.
> On Sat, Jan 26, 2019 at 12:11 PM Gilles Sadowski
> wrote:
>
> > Le sam. 26 janv. 2019 à 17:24, Gary Gregory a
> > écrit :
> > >
> > > On Sat, Jan 26, 2019 at 10:19 AM Gilles Sadowski
> > > wrote:
> > >
> > > > Le sam. 26 janv. 2019 à 14:01, Gary Gregory a
> > > > écrit :
> > > > >
> > > > > Are we talking about formatting [numbers] specific classes or JRE
> > > > classes?
> > > >
> > > > They are classes that aim to customize the output from classes in
> > > > [Numbers],
> > > > (specifically, the way to display a {{Fraction}} or {{BigFraction}}
> > > > object).
> > > >
> > >
> > > Well, then that code does not belong in [text] since it requires [number]
> > > classes.
> >
> > Not what I meant.
> > People wanting custom formatting of a fraction can get the parts that
> > define it (i.e. numerator and denominator) and call whatever they want
> > (e.g. something which might be in [Text]) in order to craft a string
> > representation of those numbers.
> > Following ValJO (even if "BigFraction" is not one, strictly speaking),
> > we want *one* way to represent the contents of the instance.
> >
> > Regards,
> > Gilles
> >
> > >
> > > Gary
> > >
> > >
> > > > The classes provide accessors to the numerator and denominator which
> > can be
> > > > used by outside code to display the fraction as it wishes.
> > > >
> > > > Side note: Similar formatting classes in Commons Math are more of a
> > > > nuisance
> > > > than anything, e.g. displaying small numbers as "0" (in exception
> > > > messages),
> > > > because the default is to provide 6 decimal digits, thus discarding
> > > > all significant
> > > > information.
> > > >
> > > > Gilles
> > > >
> > > > >
> > > > > Gary
> > > > >
> > > > > On Sat, Jan 26, 2019 at 7:14 AM Gilles Sadowski <
> > gillese...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Hi.
> > > > > >
> > > > > > In reference to the current changes in module
> > > > "commons-numbers-fraction"
> > > > > > (on the "fraction-dev"), my opinion is that the formatting classes
> > > > should
> > > > > > be
> > > > > > removed.[1]
> > > > > > At the level of a math component, it's safer to stick to a single,
> > > > > > locale-independent format.[2]
> > > > > >
> > > > > > Regards,
> > > > > > Gilles
> > > > > >
> > > > > > [1] Rationale is that pretty-printing is not the purpose of the
> > library
> > > > > > (better
> > > > > > leave that to [Text], or a dedicated module).
> > > > > > [2] There is a pending issue (NUMBERS-88) that suggests
> > hard-coding the
> > > > > > format.
> > > > > >
> > > > > >
> > -
> > > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > > > > For additional commands, e-mail: dev-h...@commons.apache.org
> > > > > >
> > > > > >
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > > For additional commands, e-mail: dev-h...@commons.apache.org
> > > >
> > > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
-
To unsubscribe, e-mail:
Re: [Numbers] Formatting classes
Fraction already has a toString() method which should cover VALJO concerns
by representing the instance in one specific way.
The FractionFormat classes allow for options beyond this such as proper
fractions or region-specific versions.
It doesn't seem to me like it violates VALJO principles to have an
auxiliary class that takes care of these alternate cases. On the contrary
from a VALJO perspective it seems like a nice idea to have encapsulated
them in an auxiliary class structure.
Eric
On Sat, Jan 26, 2019 at 12:11 PM Gilles Sadowski
wrote:
> Le sam. 26 janv. 2019 à 17:24, Gary Gregory a
> écrit :
> >
> > On Sat, Jan 26, 2019 at 10:19 AM Gilles Sadowski
> > wrote:
> >
> > > Le sam. 26 janv. 2019 à 14:01, Gary Gregory a
> > > écrit :
> > > >
> > > > Are we talking about formatting [numbers] specific classes or JRE
> > > classes?
> > >
> > > They are classes that aim to customize the output from classes in
> > > [Numbers],
> > > (specifically, the way to display a {{Fraction}} or {{BigFraction}}
> > > object).
> > >
> >
> > Well, then that code does not belong in [text] since it requires [number]
> > classes.
>
> Not what I meant.
> People wanting custom formatting of a fraction can get the parts that
> define it (i.e. numerator and denominator) and call whatever they want
> (e.g. something which might be in [Text]) in order to craft a string
> representation of those numbers.
> Following ValJO (even if "BigFraction" is not one, strictly speaking),
> we want *one* way to represent the contents of the instance.
>
> Regards,
> Gilles
>
> >
> > Gary
> >
> >
> > > The classes provide accessors to the numerator and denominator which
> can be
> > > used by outside code to display the fraction as it wishes.
> > >
> > > Side note: Similar formatting classes in Commons Math are more of a
> > > nuisance
> > > than anything, e.g. displaying small numbers as "0" (in exception
> > > messages),
> > > because the default is to provide 6 decimal digits, thus discarding
> > > all significant
> > > information.
> > >
> > > Gilles
> > >
> > > >
> > > > Gary
> > > >
> > > > On Sat, Jan 26, 2019 at 7:14 AM Gilles Sadowski <
> gillese...@gmail.com>
> > > > wrote:
> > > >
> > > > > Hi.
> > > > >
> > > > > In reference to the current changes in module
> > > "commons-numbers-fraction"
> > > > > (on the "fraction-dev"), my opinion is that the formatting classes
> > > should
> > > > > be
> > > > > removed.[1]
> > > > > At the level of a math component, it's safer to stick to a single,
> > > > > locale-independent format.[2]
> > > > >
> > > > > Regards,
> > > > > Gilles
> > > > >
> > > > > [1] Rationale is that pretty-printing is not the purpose of the
> library
> > > > > (better
> > > > > leave that to [Text], or a dedicated module).
> > > > > [2] There is a pending issue (NUMBERS-88) that suggests
> hard-coding the
> > > > > format.
> > > > >
> > > > >
> -
> > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > > > For additional commands, e-mail: dev-h...@commons.apache.org
> > > > >
> > > > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > >
> > >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
Re: [Numbers] Formatting classes
Le sam. 26 janv. 2019 à 17:24, Gary Gregory a écrit :
>
> On Sat, Jan 26, 2019 at 10:19 AM Gilles Sadowski
> wrote:
>
> > Le sam. 26 janv. 2019 à 14:01, Gary Gregory a
> > écrit :
> > >
> > > Are we talking about formatting [numbers] specific classes or JRE
> > classes?
> >
> > They are classes that aim to customize the output from classes in
> > [Numbers],
> > (specifically, the way to display a {{Fraction}} or {{BigFraction}}
> > object).
> >
>
> Well, then that code does not belong in [text] since it requires [number]
> classes.
Not what I meant.
People wanting custom formatting of a fraction can get the parts that
define it (i.e. numerator and denominator) and call whatever they want
(e.g. something which might be in [Text]) in order to craft a string
representation of those numbers.
Following ValJO (even if "BigFraction" is not one, strictly speaking),
we want *one* way to represent the contents of the instance.
Regards,
Gilles
>
> Gary
>
>
> > The classes provide accessors to the numerator and denominator which can be
> > used by outside code to display the fraction as it wishes.
> >
> > Side note: Similar formatting classes in Commons Math are more of a
> > nuisance
> > than anything, e.g. displaying small numbers as "0" (in exception
> > messages),
> > because the default is to provide 6 decimal digits, thus discarding
> > all significant
> > information.
> >
> > Gilles
> >
> > >
> > > Gary
> > >
> > > On Sat, Jan 26, 2019 at 7:14 AM Gilles Sadowski
> > > wrote:
> > >
> > > > Hi.
> > > >
> > > > In reference to the current changes in module
> > "commons-numbers-fraction"
> > > > (on the "fraction-dev"), my opinion is that the formatting classes
> > should
> > > > be
> > > > removed.[1]
> > > > At the level of a math component, it's safer to stick to a single,
> > > > locale-independent format.[2]
> > > >
> > > > Regards,
> > > > Gilles
> > > >
> > > > [1] Rationale is that pretty-printing is not the purpose of the library
> > > > (better
> > > > leave that to [Text], or a dedicated module).
> > > > [2] There is a pending issue (NUMBERS-88) that suggests hard-coding the
> > > > format.
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > > For additional commands, e-mail: dev-h...@commons.apache.org
> > > >
> > > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Numbers] Formatting classes
> On Jan 26, 2019, at 11:24 AM, Gary Gregory wrote:
>
> On Sat, Jan 26, 2019 at 10:19 AM Gilles Sadowski
> wrote:
>
>> Le sam. 26 janv. 2019 à 14:01, Gary Gregory a
>> écrit :
>>>
>>> Are we talking about formatting [numbers] specific classes or JRE
>> classes?
>>
>> They are classes that aim to customize the output from classes in
>> [Numbers],
>> (specifically, the way to display a {{Fraction}} or {{BigFraction}}
>> object).
>>
>
> Well, then that code does not belong in [text] since it requires [number]
> classes.
We could use the old [lang] pattern here where the number parsing/formatting
lives with number as opposed to with the text utilities. If that is an
insufficient pattern, then we should look at how the JDK organizes this and try
to mirror them.
-Rob
>
> Gary
>
>
>> The classes provide accessors to the numerator and denominator which can be
>> used by outside code to display the fraction as it wishes.
>>
>> Side note: Similar formatting classes in Commons Math are more of a
>> nuisance
>> than anything, e.g. displaying small numbers as "0" (in exception
>> messages),
>> because the default is to provide 6 decimal digits, thus discarding
>> all significant
>> information.
>>
>> Gilles
>>
>>>
>>> Gary
>>>
>>> On Sat, Jan 26, 2019 at 7:14 AM Gilles Sadowski
>>> wrote:
>>>
Hi.
In reference to the current changes in module
>> "commons-numbers-fraction"
(on the "fraction-dev"), my opinion is that the formatting classes
>> should
be
removed.[1]
At the level of a math component, it's safer to stick to a single,
locale-independent format.[2]
Regards,
Gilles
[1] Rationale is that pretty-printing is not the purpose of the library
(better
leave that to [Text], or a dedicated module).
[2] There is a pending issue (NUMBERS-88) that suggests hard-coding the
format.
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Numbers] Formatting classes
On Sat, Jan 26, 2019 at 10:19 AM Gilles Sadowski
wrote:
> Le sam. 26 janv. 2019 à 14:01, Gary Gregory a
> écrit :
> >
> > Are we talking about formatting [numbers] specific classes or JRE
> classes?
>
> They are classes that aim to customize the output from classes in
> [Numbers],
> (specifically, the way to display a {{Fraction}} or {{BigFraction}}
> object).
>
Well, then that code does not belong in [text] since it requires [number]
classes.
Gary
> The classes provide accessors to the numerator and denominator which can be
> used by outside code to display the fraction as it wishes.
>
> Side note: Similar formatting classes in Commons Math are more of a
> nuisance
> than anything, e.g. displaying small numbers as "0" (in exception
> messages),
> because the default is to provide 6 decimal digits, thus discarding
> all significant
> information.
>
> Gilles
>
> >
> > Gary
> >
> > On Sat, Jan 26, 2019 at 7:14 AM Gilles Sadowski
> > wrote:
> >
> > > Hi.
> > >
> > > In reference to the current changes in module
> "commons-numbers-fraction"
> > > (on the "fraction-dev"), my opinion is that the formatting classes
> should
> > > be
> > > removed.[1]
> > > At the level of a math component, it's safer to stick to a single,
> > > locale-independent format.[2]
> > >
> > > Regards,
> > > Gilles
> > >
> > > [1] Rationale is that pretty-printing is not the purpose of the library
> > > (better
> > > leave that to [Text], or a dedicated module).
> > > [2] There is a pending issue (NUMBERS-88) that suggests hard-coding the
> > > format.
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > >
> > >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
Re: [Numbers] Formatting classes
Le sam. 26 janv. 2019 à 14:01, Gary Gregory a écrit :
>
> Are we talking about formatting [numbers] specific classes or JRE classes?
They are classes that aim to customize the output from classes in [Numbers],
(specifically, the way to display a {{Fraction}} or {{BigFraction}} object).
The classes provide accessors to the numerator and denominator which can be
used by outside code to display the fraction as it wishes.
Side note: Similar formatting classes in Commons Math are more of a nuisance
than anything, e.g. displaying small numbers as "0" (in exception messages),
because the default is to provide 6 decimal digits, thus discarding
all significant
information.
Gilles
>
> Gary
>
> On Sat, Jan 26, 2019 at 7:14 AM Gilles Sadowski
> wrote:
>
> > Hi.
> >
> > In reference to the current changes in module "commons-numbers-fraction"
> > (on the "fraction-dev"), my opinion is that the formatting classes should
> > be
> > removed.[1]
> > At the level of a math component, it's safer to stick to a single,
> > locale-independent format.[2]
> >
> > Regards,
> > Gilles
> >
> > [1] Rationale is that pretty-printing is not the purpose of the library
> > (better
> > leave that to [Text], or a dedicated module).
> > [2] There is a pending issue (NUMBERS-88) that suggests hard-coding the
> > format.
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Numbers] Formatting classes
Are we talking about formatting [numbers] specific classes or JRE classes? Gary On Sat, Jan 26, 2019 at 7:14 AM Gilles Sadowski wrote: > Hi. > > In reference to the current changes in module "commons-numbers-fraction" > (on the "fraction-dev"), my opinion is that the formatting classes should > be > removed.[1] > At the level of a math component, it's safer to stick to a single, > locale-independent format.[2] > > Regards, > Gilles > > [1] Rationale is that pretty-printing is not the purpose of the library > (better > leave that to [Text], or a dedicated module). > [2] There is a pending issue (NUMBERS-88) that suggests hard-coding the > format. > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
[Numbers] Formatting classes
Hi. In reference to the current changes in module "commons-numbers-fraction" (on the "fraction-dev"), my opinion is that the formatting classes should be removed.[1] At the level of a math component, it's safer to stick to a single, locale-independent format.[2] Regards, Gilles [1] Rationale is that pretty-printing is not the purpose of the library (better leave that to [Text], or a dedicated module). [2] There is a pending issue (NUMBERS-88) that suggests hard-coding the format. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
