Prev: Clean way to write Double into String without the trailing ".0" ?
Next: 32-bit characters in Java string literals
From: abc on 22 Dec 2009 10:33
Tom McGlynn wrote:
> 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

You're right. Apparently I was a little confused about the error message
I saw. I was thrashing about and experimenting with that part of the
code and there must have been some other issue that caused the error.

Trying it again now, it turns out it works perfectly well without the cast.
From: markspace on 22 Dec 2009 15:29
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.
First  |  Prev  | 
Pages: 1 2 3 4
Prev: Clean way to write Double into String without the trailing ".0" ?
Next: 32-bit characters in Java string literals