On 26 July 2011 14:40, Gilles Sadowski <gil...@harfang.homelinux.org> wrote:
> On Tue, Jul 26, 2011 at 02:00:39PM +0100, sebb wrote:
>> On 26 July 2011 13:19, Gilles Sadowski <gil...@harfang.homelinux.org> wrote:
>> > Hi.
>> >
>> > [This is related to issue MATH-622.]
>> >
>> > Looking at the "CompositeFormat" and "RealVectorFormat", I notice an
>> > unusual
>> > use of the "getInstance" method name. Unless I'm mistaken, "getInstance" is
>> > most often used when the object stores a reference to a singleton. And in
>> > those class, this does not seem to be the case: When I write
>> > ---
>> > RealVectorFormat.getInstance().getFormat().setMaximumFractionDigits(6);
>> > ---
>> > the output is unaffected, the default being to display 2 fraction digits),
>> > which is not suitable for debugging.
>> >
>> > I think that there should be a way to modify at once all outputs formatted
>> > through "CompositeFormat", i.e. an actual singleton instance of
>> > "NumberFormat"
>> > that is used by all "default" formatting.
>> >
>> > Do you agree? Any caveats?
>>
>> The singleton will need to be thread-safe.
>>
>> A mutable singleton is thread-hostile (*), so if this approach is
>> taken, the Javadoc need to make this very clear.
>
> I don't particularly like it either but do you see another way?
Yes - create the singleton once, with the required settings.
> Yes, there is: To not use CM's formatting in the definition of the
> "toString()" methods and/or overload them as
> ---
> public String toString(NumberFormat fmt) { /* ... */ }
> ---
> Then when debugging, one will be able to fairly easily write:
> ---
> RealVector v = new ArrayRealVector(new double[] {1.2345678, 2.3456789});
> System.out.println("v=" +
> v.toString(CompositeFormat.getDefaultNumberFormat(8)));
> ---
>
>> (*) Thread A sets the digit count, thread B sets it differently;
>> thread A may not get the desired digit count.
>
> For debugging, the expectation is that the user sets it once, at the
> top-level ("main"); so that will not be a problem usually.
Yes, but my point is that the user needs to made aware of this.
>
> Gilles
>
> ---------------------------------------------------------------------
> 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
