> >> > 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.
What do you mean? A little example maybe?
> > 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.
We'll do that of course.
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
