Clean way to write Double into String without the trailing ".0" ?
abc
Easy newbie-question here for the experts:
What's a clean way of writing a Double into a String, avoiding
the ".0" at the end ?
The Double.toString() method insists on appending a decimal fraction
".0" no matter what, and I only want the fractions to show up if they
are non-zero.
I found a dirty workaround (see code below), using a regex to remove the
trailing ".0", but there has to be a prettier way to do this.
....
String s = Double.toString(x);
s = s.replaceAll((String)"\\.0$", "");
....
TIA
Knute Johnson
public class test {
public static void main(String[] args) throws Exception {
Double d = new Double(666.234);
System.out.println(String.format("%.0f",d.doubleValue()));
}
}
C:\Documents and Settings\Knute Johnson>java test
666
--
Knute Johnson
email s/nospam/knute2010/
--
Posted via NewsDemon.com - Premium Uncensored Newsgroup Service
------->>>>>>http://www.NewsDemon.com<<<<<<------
Unlimited Access, Anonymous Accounts, Uncensored Broadband Access
rossum
>
>Easy newbie-question here for the experts:
>
>What's a clean way of writing a Double into a String, avoiding
>the ".0" at the end ?
Convert the double into an int or long first?
rossum
Eric Sosman
Perhaps it shows my age, but something inside me cringes
at the notion of wheeling out the regular expression cannon to
kill so simple a canary.
s = s.substring(s.indexOf('.'));
"Cleaner" -- and certainly more flexible -- alternatives are
to use a java.text.DecimalFormat or a java.util.Formatter instead
of toString().
--
Eric Sosman
eso...@ieee-dot-org.invalid
Jeff Higgins
Lew
abc wrote:
>> What's a clean way of writing a Double into a String, avoiding
>> the ".0" at the end ?
>
>> The Double.toString() method insists on appending a decimal fraction
>> ".0" no matter what, and I only want the fractions to show up if they
>> are non-zero.
>
>> I found a dirty workaround (see code below), using a regex to remove the
>> trailing ".0", but there has to be a prettier way to do this.
>
>> ....
>> String s = Double.toString(x);
>> s = s.replaceAll((String)"\\.0$", "");
>
Jeff Higgins wrote:
> String s = Double.toString(x).replaceAll((String)"\\.0$", "");
>
Is there an echo in here?
Why the redundant cast of a 'String' to 'String'?
--
Lew
Jeff Higgins
OOPS .. Oops .. oops
negligent c/p
thanks
abc
>> ....
>> String s = Double.toString(x);
>> s = s.replaceAll((String)"\\.0$", "");
>
> Perhaps it shows my age, but something inside me cringes
> at the notion of wheeling out the regular expression cannon to
> kill so simple a canary.
Same here, hence my question.
>
> s = s.substring(s.indexOf('.'));
Wouldn't this get rid of the decimal fraction part completely, whether
it's non-zero or not? That's not what I want.
> "Cleaner" -- and certainly more flexible -- alternatives are
> to use a java.text.DecimalFormat or a java.util.Formatter instead
> of toString().
Thanks, I'll read up on those.
abc
> On Mon, 21 Dec 2009 21:56:40 +0100, abc <a...@abc.net> wrote:
>
>> Easy newbie-question here for the experts:
>>
>> What's a clean way of writing a Double into a String, avoiding
>> the ".0" at the end ?
> Convert the double into an int or long first?
Aren't int and long both integer types though?
Wouldn't this cause the decimal fraction be lost?
markspace
Yes. Just to be clear to everyone, he wants to remove the trailing
zeros only if they are all zero. If he has a component after the
decimal place with digits besides 0, he wants it printed.
Sorry but I don't see a solution to your problem. I think you will have
to hack it. Regex looks good to me.
Eric Sosman
> Eric Sosman wrote:
>>> ....
>>> String s = Double.toString(x);
>>> s = s.replaceAll((String)"\\.0$", "");
>>
>> Perhaps it shows my age, but something inside me cringes
>> at the notion of wheeling out the regular expression cannon to
>> kill so simple a canary.
>
> Same here, hence my question.
>>
>> s = s.substring(s.indexOf('.'));
>
> Wouldn't this get rid of the decimal fraction part completely, whether
> it's non-zero or not? That's not what I want.
Actually, I botched the substring() call, and ought
to have written
s = s.substring(0, s.indexOf('.'));
... and yes, this version would snip the decimal point and
everything that follows. That's what I thought you wanted,
but on re-reading your message I see that you only wanted to
jettison a literal ".0" and keep other fractional parts.
(I've obviously been hitting the eggnog too hard today ...).
In penance, here's another possibility:
if (s.endsWith(".0"))
s = s.substring(s.length() - 2);
>> "Cleaner" -- and certainly more flexible -- alternatives are
>> to use a java.text.DecimalFormat or a java.util.Formatter instead
>> of toString().
>
> Thanks, I'll read up on those.
Probably the best course, since they'll also spare you
from unpleasantnesses like "10.333333333333334". Note that
PrintStream has convenience methods for using Formatter.
--
Eric Sosman
eso...@ieee-dot-org.invalid
Jeff Higgins
I don't either that why I replied as I did.
The .0 is acting as an indicator that the represented number is a
floating-point approximation, removing it hides that indication.
Good, bad, dirty, clean, pretty, plain?
Depends upon agreement between producer, consumer.
Tom McGlynn
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. I
think the code very clearly reflects your requirement.
If you are concerned with efficiency or feel that you don't want to
unleash the 'big guns' of regular expressions, then perhaps you could
put your conditional code before you do the conversion.
E.g. something like:
double MAX_TEST = Integer.MAX_VALUE;
...
String s;
int ix = (int) x; // If the (int) conversion is slow, perhaps
Math.floor(x)
// and only create the int when you need it.
if (Math.abs(x) <= MAX_TEST && (x == ix)) {
s = Integer.toString(ix);
} else {
s = Double.toString(x);
}
I suspect that's more efficient, but I'd check if it mattered. This
only handles numbers between -2^31 - 2^31. You can get bigger if you
use longs instead. If you have very big numbers then you need to
worry about exponent notation too. The real defect here is that it
that compared to your original the intent is much less clear.
Regards,
Tom McGlynn
Jeff Higgins
> If you have very big numbers then you need to worry about exponent notation too. The real defect here is that it
Good catch.
OK Double.valueOf(1000000.0).toString().replaceAll("\\.0$", "")
OOPS Double.valueOf(10000000.0).toString().replaceAll("\\.0$", "")
Knute Johnson
>
> Yes. Just to be clear to everyone, he wants to remove the trailing zeros
> only if they are all zero. If he has a component after the decimal place
> with digits besides 0, he wants it printed.
>
OK, then I like this :-).
public class test {
public static void main(String[] args) throws Exception {
Double d = new Double(666);
String s = d.toString();
System.out.println(s);
if (s.endsWith(".0"))
s = s.substring(0,s.length()-2);
System.out.println(s);
Jeff Higgins
oops - Double has a static toString(double d)
Double.toString(10000000.0d).replaceAll("\\.0$", "")
<http://java.sun.com/javase/6/docs/api/java/lang/Double.html#toString(double)>
<http://java.sun.com/javase/6/docs/api/java/lang/Double.html#valueOf(java.lang.String)>
Kevin McMurtrie
private static final NumberFormat s_fmt=
new DecimalFormat("0.################");
...
final String str;
synchronized (s_fmt)
{
str= s_fmt.format(d);
}
...
--
I won't see Google Groups replies because I must filter them as spam
Lew
> 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.
--
Lew
Lew
> private static final NumberFormat s_fmt=
> new DecimalFormat("0.################");
>
> ...
> final String str;
> synchronized (s_fmt)
> {
> str= s_fmt.format(d);
> }
> ...
In a heavily multi-threaded, high-throughput environment that synchronized
static formatter could be quite a choke point. If that turns out to be the
case, one could use
str = new DecimalFormat("0.################").format(d);
Naturally you'd want to elevate the string to a final constant either way.
This assumes you don't mind keeping the decimal point when the fractional part
is zero.
Java has come a long way in optimization of uncontended locks, but contended
ones are inherently a bitch. It can be astonishing how much time is spent
waiting to acquire a lock in a contentious scenario, to the severe detriment
of throughput. On projects where I've seen such things actually measured, a
highly-contended synchronization lock has been the major throughput killer,
beating even database I/O despite the latter being very poorly handled in some
cases. And that was with Java 5.
If the formatter is lightly touched, then the lock won't be such an issue.
--
Lew
Kevin McMurtrie
wrote:
When I run it, 10.0d returns "10" and 10.1d returns "10.1".
abc
> 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
Kevin McMurtrie
wrote:
The DecimalFormat constructor is massive and it has synchronization on
globals. It's definitely not appropriate for temporary use in high
performance code.
This kind of problem is exactly what ThreadLocal can solve:
private static final ThreadLocal<NumberFormat> s_fmt=
new ThreadLocal<NumberFormat>()
{
@Override protected NumberFormat initialValue()
{
return new DecimalFormat("0.################");
}
};
...
final String str= s_fmt.get().format(d);
...
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.
Arved Sandstrom
> In article <hgpn3u$upc$1...@news.albasani.net>, Lew <no...@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".
This is the one part of the original problem statement that may have to
be rethought. Does the OP really want that decimal point to be dropped
if the fractional part is zero? There is, after all, a big difference
between the numbers "10" and "10."
AHS
Andreas Leitgeb
> 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.
Tom McGlynn
> TomMcGlynnwrote:
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
Lew
While I'm suspicious of claims like "500x speedup" without evidence, I am
enlightened by your information. The lesson is that when one needs to eke out
maximum performance (memory or speed), one needs to know what they're using
and under what conditions. If the constructor were light weight, my advice
would work. That the constructor is heavy indicates your advice applies. If
the throughput requirements on the object were light, the original simple
synchronization would suffice.
In all cases, optimization without measurement risks being foolish. It was
measurement that revealed the penalty of lock contention in the scenario to
which I alluded, on a structure that had been introduced in a benighted
attempt to optimize throughput.
--
Lew
abc
> 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.
markspace
> 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.
Kevin McMurtrie
markspace <nos...@nowhere.com> wrote:
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.