From: Kevin McMurtrie on
In article <hgpn3u$upc$1(a)news.albasani.net>, Lew <noone(a)lewscanon.com>
wrote:

> Kevin McMurtrie wrote:
> > private static final NumberFormat s_fmt=
> > new DecimalFormat("0.################");
> >
> > ...
> > final String str;
> > synchronized (s_fmt)
> > {
> > str= s_fmt.format(d);
> > }
> > ...
>
> I thought so, too, but that pattern doesn't eliminate the decimal point when
> the fractional part is zero.

When I run it, 10.0d returns "10" and 10.1d returns "10.1".
--
I won't see Google Groups replies because I must filter them as spam
From: Andreas Leitgeb on
abc <abc(a)abc.net> wrote:
> If what you mean by this is the (String)"\\.0$" I had to put it in
> because I found I get an error message there if I remove the (String)
> part like this:
> s = s.replaceAll("\\.0$", ""); // error, with (String) removed

That's just impossible.

Except, of course, if it is really a non-compliant Java-compiler
that you fed your source to.

From: Tom McGlynn on
On Dec 22, 3:27 am, abc <a...(a)abc.net> wrote:
> TomMcGlynnwrote:
> > Personally I think what you've done (absent the redundant cast that
> > others have mentioned) is a perfectly fine way to do what you want.
>
> OK, thanks.
>
> There has been a couple of mentions of the "redundant cast".
>
> If what you mean by this is the (String)"\\.0$" I had to put it in
> because I found I get an error message there if I remove the (String)
> part like this:
>
> s = s.replaceAll("\\.0$", "");  // error, with (String) removed

The literal "\\.0$" is already a String, so casting it to String
should
have no effect. If you can show the exact code you use (i.e., at
least the entire method and preferably a working program) and the
error message you get, I suspect that something else will shake out.
E.g., for me the following program compiles and runs without problem.

public class Test {
public static void main(String[] args) throws Exception {
double x = Double.parseDouble(args[0]);
String s = Double.toString(x);
s = s.replaceAll("\\.0$", "");
System.out.println("S is now:"+s);
}
}

Regards,
Tom McGlynn
From: Kevin McMurtrie on
In article <hgra7n$jsc$1(a)news.eternal-september.org>,
markspace <nospam(a)nowhere.com> wrote:

> Lew wrote:
>
> > Kevin McMurtrie wrote:
> >>
> >> Of course, if throughput was top priority for this example I'd write a
> >> number formatter from scratch rather than pay the overhead of
> >> DecimalFormat's dynamic formatting. That could easily be a 500x
> >> speedup in total long-term throughput.
>
>
> >
> > While I'm suspicious of claims like "500x speedup" without evidence, I
> > am enlightened by your information.
>
>
> I agree with the measurement part. Particularly, with Java 7 coming
> soon, if Kevin has any direct experience with DecimalFormat being slow,
> it might be a good idea to submit an RFE to Sun about it. 500x speed
> improvement on something like simple formatting seems to be begging for
> refactoring.

That would be a ~500x speed-up by hard-coding and optimizing the
specific format needed. DecimalFormat performs nicely as general
purpose class that does just about everything.
--
I won't see Google Groups replies because I must filter them as spam