 |
AppletTalk.com
Java discussions newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
polilop
Guest
|
 Posted: Thu Mar 24, 2005 2:51 pm Post subject: need just 6 digits |
 |
|
I have a recordset's
rs.getDouble("EXCHRATE1")
the thing is that that some return a number
that has 8 digits some return 10 some 6 but i need
just 6 (after the decimal point).
Is there a way to trim the double variable without converting
to string?
|
|
| Back to top |
|
 |
polilop
Guest
|
| Posted: Thu Mar 24, 2005 3:18 pm Post subject: Re: need just 6 digits |
|
|
thx a lot
this is done in one line cool.
"Tor Iver Wilhelmsen" <tor.iver.wilhelmsen (AT) broadpark (DOT) no> wrote
| Quote: | "polilop" <fmatosic (AT) inet (DOT) hr> writes:
that has 8 digits some return 10 some 6 but i need
just 6 (after the decimal point).
You mean you need to show 6 digits? Use java.text.DecimalFormat.
Is there a way to trim the double variable without converting
to string?
If you need to trim it, multiply by 100000 and cast back to double
(the int multiplication will convert to int).
|
|
|
| Back to top |
|
|
Tor Iver Wilhelmsen
Guest
|
| Posted: Thu Mar 24, 2005 3:20 pm Post subject: Re: need just 6 digits |
|
|
"polilop" <fmatosic (AT) inet (DOT) hr> writes:
| Quote: | that has 8 digits some return 10 some 6 but i need
just 6 (after the decimal point).
|
You mean you need to show 6 digits? Use java.text.DecimalFormat.
| Quote: | Is there a way to trim the double variable without converting
to string?
|
If you need to trim it, multiply by 100000 and cast back to double
(the int multiplication will convert to int).
|
|
| Back to top |
|
|
Thomas G. Marshall
Guest
|
| Posted: Fri Mar 25, 2005 12:11 am Post subject: Re: need just 6 digits |
|
|
Tor Iver Wilhelmsen coughed up:
| Quote: | "polilop" <fmatosic (AT) inet (DOT) hr> writes:
that has 8 digits some return 10 some 6 but i need
just 6 (after the decimal point).
You mean you need to show 6 digits? Use java.text.DecimalFormat.
Is there a way to trim the double variable without converting
to string?
If you need to trim it, multiply by 100000 and cast back to double
(the int multiplication will convert to int).
|
/Huh/ ?
1. Multiplying a double by an int does *NOT* convert it to an int.
2. For 6 digits, you mean 1,000,000. Not 100,000.
3. Here is a quick test with results:
Code:
double d = 9.123456789;
System.out.println("just the multiplication: " +
d * 1000000);
System.out.println("With a built in cast to int: " +
(int)(d * 1000000) / 1000000.D);
Output:
just the multiplication: 9123456.789
With a built in cast to int: 9.123456
--
Framsticks. 3D Artificial Life evolution. You can see the creatures
that evolve and how they interact, hunt, swim, etc. (Unaffiliated with
me). http://www.frams.alife.pl/
|
|
| Back to top |
|
|
Thomas G. Marshall
Guest
|
| Posted: Fri Mar 25, 2005 2:06 pm Post subject: Re: need just 6 digits |
|
|
Thomas G. Marshall coughed up:
| Quote: | Tor Iver Wilhelmsen coughed up:
"polilop" <fmatosic (AT) inet (DOT) hr> writes:
that has 8 digits some return 10 some 6 but i need
just 6 (after the decimal point).
You mean you need to show 6 digits? Use java.text.DecimalFormat.
Is there a way to trim the double variable without converting
to string?
If you need to trim it, multiply by 100000 and cast back to double
(the int multiplication will convert to int).
/Huh/ ?
1. Multiplying a double by an int does *NOT* convert it to an int.
2. For 6 digits, you mean 1,000,000. Not 100,000.
3. Here is a quick test with results:
Code:
double d = 9.123456789;
System.out.println("just the multiplication: " +
d * 1000000);
System.out.println("With a built in cast to int: " +
(int)(d * 1000000) / 1000000.D);
Output:
just the multiplication: 9123456.789
With a built in cast to int: 9.123456
|
Just an aside to this, btw.
This technique, while always /seems/ to work in my experience, I *think* it
may be fraught with a certain peril. The final division is an attempt at a
base-10 division. It is entirely possible that base 10 inaccuracies
(division by 1,000,000) /might/ yield an inexact result, resulting in far
more digits than you expect. At least I suspect this is possible given some
IEEE floating point rounding rules. For example, I wouldn't rule out the
following result:
9.1234559999999999999
--
Enough is enough. It is /not/ a requirement that someone must google
relentlessly for an answer before posting in usenet. Newsgroups are
for discussions. Discussions do /not/ necessitate prior research. If
you are bothered by someone asking a question without taking time to
look something up, simply do not respond.
|
|
| Back to top |
|
|
Patricia Shanahan
Guest
|
| Posted: Fri Mar 25, 2005 7:30 pm Post subject: Re: need just 6 digits |
|
|
Thomas G. Marshall wrote:
| Quote: | This technique, while always /seems/ to work in my
experience, I *think* it may be fraught with a certain
peril. The final division is an attempt at a base-10
division. It is entirely possible that base 10
inaccuracies (division by 1,000,000) /might/ yield an
inexact result, resulting in far more digits than you
expect. At least I suspect this is possible given some
IEEE floating point rounding rules. For example, I
wouldn't rule out the following result:
9.1234559999999999999
|
I don't think you will ever get more than 6 digits after the
decimal point. See the description of Double.toString(double
d) in the API documentation:
"There must be at least one digit to represent the
fractional part, and beyond that as many, but only as many,
more digits as are needed to uniquely distinguish the
argument value from adjacent values of type double. That is,
suppose that x is the exact mathematical value represented
by the decimal representation produced by this method for a
finite nonzero argument d. Then d must be the double value
nearest to x; or if two double values are equally close to
x, then d must be one of them and the least significant bit
of the significand of d must be 0."
Let d1 be the original double, and let x1 by the infinite
precision result of the division in (int)(d1 * 1000000) /
1000000.D).
x1 is the result of dividing an integer by 1,000,000 so it
is exactly representable as a decimal fraction with 6 digits
after the decimal point. The double d that results from
doing the division in Java is the result of IEEE
round-to-nearest rounding of x1, so x1 meets the "Then d
must be the double value nearest to x; or if two double
values are equally close to x, then d must be one of them
and the least significant bit of the significand of d must
be 0." condition. Any longer fraction has more digits than
are needed.
Of course, this reasoning breaks down if you do any more
calculations before converting back to a String, even
something as apparently harmless as adding 0.1.
Patricia
|
|
| Back to top |
|
|
Thomas G. Marshall
Guest
|
| Posted: Fri Mar 25, 2005 9:38 pm Post subject: Re: need just 6 digits |
|
|
Patricia Shanahan coughed up:
| Quote: | Thomas G. Marshall wrote:
This technique, while always /seems/ to work in my
experience, I *think* it may be fraught with a certain
peril. The final division is an attempt at a base-10
division. It is entirely possible that base 10
inaccuracies (division by 1,000,000) /might/ yield an
inexact result, resulting in far more digits than you
expect. At least I suspect this is possible given some
IEEE floating point rounding rules. For example, I
wouldn't rule out the following result:
9.1234559999999999999
I don't think you will ever get more than 6 digits after the
decimal point. See the description of Double.toString(double
d) in the API documentation:
"There must be at least one digit to represent the
fractional part, and beyond that as many, but only as many,
more digits as are needed to uniquely distinguish the
argument value from adjacent values of type double. That is,
suppose that x is the exact mathematical value represented
by the decimal representation produced by this method for a
finite nonzero argument d. Then d must be the double value
nearest to x; or if two double values are equally close to
x, then d must be one of them and the least significant bit
of the significand of d must be 0."
Let d1 be the original double, and let x1 by the infinite
precision result of the division in (int)(d1 * 1000000) /
1000000.D).
x1 is the result of dividing an integer by 1,000,000 so it
is exactly representable as a decimal fraction with 6 digits
after the decimal point. The double d that results from
doing the division in Java is the result of IEEE
round-to-nearest rounding of x1, so x1 meets the "Then d
must be the double value nearest to x; or if two double
values are equally close to x, then d must be one of them
and the least significant bit of the significand of d must
be 0." condition. Any longer fraction has more digits than
are needed.
Of course, this reasoning breaks down if you do any more
calculations before converting back to a String, even
something as apparently harmless as adding 0.1.
Patricia
|
This reasoning breaks down before that I'm afraid. All of what you are
talking about had precisely to do with how to convert a value to a string as
accurately as possible. It did /not/ stipulate at all how that value came
into being in the first place. Long before it gets string converted there
is a double divided by 1,000,000.D. That is enough to create an inaccurate
number in some cases.
In other words, the java system would have no way to tell if the number was
or wasn't truly 9.12345599999999999 at that point.
--
Puzzle: You are given a deck of cards all face up
except for 10 cards mixed in which are face down.
If you are in a pitch black room, how do you divide
the deck into two piles (may be uneven) that each
contain the same number of face-up cards?
Answer (rot13): Sebz naljurer va gur qrpx, qrny bhg
gra pneqf naq syvc gurz bire.
|
|
| Back to top |
|
|
Patricia Shanahan
Guest
|
| Posted: Fri Mar 25, 2005 10:51 pm Post subject: Re: need just 6 digits |
|
|
Thomas G. Marshall wrote:
| Quote: | Patricia Shanahan coughed up:
Thomas G. Marshall wrote:
This technique, while always /seems/ to work in my
experience, I *think* it may be fraught with a
certain peril. The final division is an attempt at a
base-10 division. It is entirely possible that base
10 inaccuracies (division by 1,000,000) /might/
yield an inexact result, resulting in far more digits
than you expect. At least I suspect this is
possible given some IEEE floating point rounding
rules. For example, I wouldn't rule out the
following result:
9.1234559999999999999
I don't think you will ever get more than 6 digits
after the decimal point. See the description of
Double.toString(double d) in the API documentation:
"There must be at least one digit to represent the
fractional part, and beyond that as many, but only as
many, more digits as are needed to uniquely distinguish
the argument value from adjacent values of type
double. That is, suppose that x is the exact
mathematical value represented by the decimal
representation produced by this method for a finite
nonzero argument d. Then d must be the double value
nearest to x; or if two double values are equally close
to x, then d must be one of them and the least
significant bit of the significand of d must be 0."
Let d1 be the original double, and let x1 by the
infinite precision result of the division in (int)(d1 *
1000000) / 1000000.D).
x1 is the result of dividing an integer by 1,000,000 so
it is exactly representable as a decimal fraction with
6 digits after the decimal point. The double d that
results from doing the division in Java is the result
of IEEE round-to-nearest rounding of x1, so x1 meets
the "Then d must be the double value nearest to x; or
if two double values are equally close to x, then d
must be one of them and the least significant bit of
the significand of d must be 0." condition. Any longer
fraction has more digits than are needed.
Of course, this reasoning breaks down if you do any
more calculations before converting back to a String,
even something as apparently harmless as adding 0.1.
Patricia
This reasoning breaks down before that I'm afraid. All
of what you are talking about had precisely to do with
how to convert a value to a string as accurately as
possible. It did /not/ stipulate at all how that value
came into being in the first place. Long before it gets
string converted there is a double divided by
1,000,000.D. That is enough to create an inaccurate
number in some cases.
|
I did stipulate that x1 was the result of dividing an int by
1000000.D, and d the result of IEEE round-to-nearest applied
to x1.
| Quote: |
In other words, the java system would have no way to tell
if the number was or wasn't truly 9.12345599999999999 at
that point.
|
I'm not sure which of two claims you are making here, so
I'll answer each of them. If you mean something else, please
clarify:
Possible Claim 1. "9.12345599999999999 is the infinite
precision result of the division, or at least is closer to
it than 9.123456 is."
Conversion of an int to double is always exact. 1000000.D is
exactly representable as a double. The infinite precision
result of dividing an integer by 1,000,000 can be
represented in decimal with no more than 6 digits after the
decimal point.
Possible Claim 2. "The infinite precision result of the
division was 9.123456. It is not exactly representable in
double, so the actual result will be the nearest double to
it. The double d that results from that rounding gets
printed as 9.12345599999999999."
The rules I quoted for conversion from a double d to String
ensure that if 9.123456 and 9.12345599999999999 both have d
as their nearest double, the result will be 9.123456 because
it has fewer digits in the fractional part.
Patricia
|
|
| Back to top |
|
|
Thomas G. Marshall
Guest
|
| Posted: Sat Mar 26, 2005 12:11 am Post subject: Re: need just 6 digits |
|
|
Patricia Shanahan coughed up:
| Quote: | Thomas G. Marshall wrote:
Patricia Shanahan coughed up:
Thomas G. Marshall wrote:
This technique, while always /seems/ to work in my
experience, I *think* it may be fraught with a
certain peril. The final division is an attempt at a
base-10 division. It is entirely possible that base
10 inaccuracies (division by 1,000,000) /might/
yield an inexact result, resulting in far more digits
than you expect. At least I suspect this is
possible given some IEEE floating point rounding
rules. For example, I wouldn't rule out the
following result:
9.1234559999999999999
I don't think you will ever get more than 6 digits
after the decimal point. See the description of
Double.toString(double d) in the API documentation:
"There must be at least one digit to represent the
fractional part, and beyond that as many, but only as
many, more digits as are needed to uniquely distinguish
the argument value from adjacent values of type
double. That is, suppose that x is the exact
mathematical value represented by the decimal
representation produced by this method for a finite
nonzero argument d. Then d must be the double value
nearest to x; or if two double values are equally close
to x, then d must be one of them and the least
significant bit of the significand of d must be 0."
Let d1 be the original double, and let x1 by the
infinite precision result of the division in (int)(d1 *
1000000) / 1000000.D).
x1 is the result of dividing an integer by 1,000,000 so
it is exactly representable as a decimal fraction with
6 digits after the decimal point. The double d that
results from doing the division in Java is the result
of IEEE round-to-nearest rounding of x1, so x1 meets
the "Then d must be the double value nearest to x; or
if two double values are equally close to x, then d
must be one of them and the least significant bit of
the significand of d must be 0." condition. Any longer
fraction has more digits than are needed.
Of course, this reasoning breaks down if you do any
more calculations before converting back to a String,
even something as apparently harmless as adding 0.1.
Patricia
This reasoning breaks down before that I'm afraid. All
of what you are talking about had precisely to do with
how to convert a value to a string as accurately as
possible. It did /not/ stipulate at all how that value
came into being in the first place. Long before it gets
string converted there is a double divided by
1,000,000.D. That is enough to create an inaccurate
number in some cases.
I did stipulate that x1 was the result of dividing an int by
1000000.D, and d the result of IEEE round-to-nearest applied
to x1.
In other words, the java system would have no way to tell
if the number was or wasn't truly 9.12345599999999999 at
that point.
I'm not sure which of two claims you are making here, so
I'll answer each of them. If you mean something else, please
clarify:
Possible Claim 1. "9.12345599999999999 is the infinite
precision result of the division, or at least is closer to
it than 9.123456 is."
Conversion of an int to double is always exact. 1000000.D is
exactly representable as a double. The infinite precision
result of dividing an integer by 1,000,000 can be
represented in decimal with no more than 6 digits after the
decimal point.
|
"represented in decimal". No, you're missing my point. It's not the
divisor that is a worry here per se, it is the action of the division. Let
me express my concerns this way:
A 1.0 is cleanly represent by a double. So is a 3.0. That matters not in
the least, because a 1.0 / 3.0 is not, and congruent to your argument: "the
infinite precision result of dividing an integer by 3.0 can be represented
in decimal with no more than 1 digit after the decimal point" is wrong, only
because "represented in decimal" is not the issue. It's the values before
it gets string converted.
*However* if you take that resulting .333333333333333333333333333333 and
multiply it by 3 you will /almost/ without fail get a 1.0 (string
converted), because of the rounding notions of the particular IEEE floating
point you are using.
Dividing a 9123456.789 by a 1,000,000.D just might not nail precisely
9.123456 on all floating point implementations. This one *does* in java, as
I've shown. I can experiment with an enormous loop and check the result
lengths programmatically: unfortunately I'm out of time right at the moment.
| Quote: | Possible Claim 2. "The infinite precision result of the
division was 9.123456. It is not exactly representable in
double, so the actual result will be the nearest double to
it. The double d that results from that rounding gets
printed as 9.12345599999999999."
The rules I quoted for conversion from a double d to String
ensure that if 9.123456 and 9.12345599999999999 both have d
as their nearest double, the result will be 9.123456 because
it has fewer digits in the fractional part.
|
That's only if d is equally distant from the two. What if d is closest to
9.1234559999999999999? I argue that /that/ just may be the case
*sometimes*, but do not know.
--
Everythinginlifeisrealative.Apingpongballseemssmalluntilsomeoneramsitupyournose.
|
|
| Back to top |
|
|
Patricia Shanahan
Guest
|
| Posted: Sat Mar 26, 2005 1:36 am Post subject: Re: need just 6 digits |
|
|
Thomas G. Marshall wrote:
| Quote: | A 1.0 is cleanly represent by a double. So is a 3.0.
That matters not in the least, because a 1.0 / 3.0 is
not, and congruent to your argument: "the infinite
precision result of dividing an integer by 3.0 can be
represented in decimal with no more than 1 digit after
the decimal point" is wrong, only because "represented in
decimal" is not the issue. It's the values before it
gets string converted.
|
My comment, although I specifically talked about division of
an integer by 1,000,000 in decimal, generally applies to
division of an integer by an integer power of the radix. If
R is a positive integer, J is an integer, and N is a
non-negative integer, using "**" to represent
exponentiation, J/(R**N) has no more than N digits in its
radix R expansion.
It is true for division of integers by powers of two in
binary, or powers of 16 in hexadecimal, or powers of ten in
decimal. It does not apply to division by 3 in decimal,
because 3 is not an integer power of 10.
Of course, 1/3 does have an exact one digit representation
in radix 3, "0.1".
| Quote: | Dividing a 9123456.789 by a 1,000,000.D just might not
nail precisely 9.123456 on all floating point
implementations. This one *does* in java, as I've shown.
I can experiment with an enormous loop and check the
result lengths programmatically: unfortunately I'm out of
time right at the moment.
|
I don't understand this comment. Are you claiming that
9.123456 is exactly representable as a Java double? It isn't.
| Quote: | That's only if d is equally distant from the two. What
if d is closest to 9.1234559999999999999? I argue that
/that/ just may be the case *sometimes*, but do not know.
|
I think this may be the key point. Double.toString(d) does
not pick the the decimal expansion that is closest to d.
Because two is a factor of ten, and Java doubles, other than
NaNs and infinities, are binary fractions, each double
number is exactly equal to a terminating decimal fraction.
The exact equivalent would always be the closest decimal
number, but often has an inconveniently long fractional part.
Instead, Double.toString(d) picks the one with the fewest
digits in the fractional part from all the decimal fractions
that would round to d.
Suppose d is the double that results from the division, the
IEEE round-to-nearest of 9.12456.
Consider the set X of decimal fractions x_i for which d is
the double that would result from IEEE round-to-nearest
applied to x_i. 9.123456 is in X, because d was obtained
from it by IEEE round-to-nearest. X contains
9.1234559999999991219965522759594023227691650390625, the
exact decimal representation of d. 9.1234559999999999999 is
between those two numbers, so it must also be in X.
Incidentally, it is closer to d than 9.123456 is.
The rules I quoted from the API documentation force
Double.toString(d) to choose 9.123456 in preference to
9.1234559999999999999, or the even closer
9.1234559999999991219965522759594023227691650390625, because
9.123456 has fewer digits than either of them in its
fractional part.
Patricia
|
|
| Back to top |
|
|
Thomas G. Marshall
Guest
|
| Posted: Sat Mar 26, 2005 4:21 am Post subject: Re: need just 6 digits |
|
|
Patricia Shanahan coughed up:
....[rip]...
| Quote: | The rules I quoted from the API documentation force
Double.toString(d) to choose 9.123456 in preference to
9.1234559999999999999, or the even closer
9.1234559999999991219965522759594023227691650390625, because
9.123456 has fewer digits than either of them in its
fractional part.
Patricia
|
Fair enough, and well written post.
--
It's time for everyone to just step back, take a deep breath, relax,
and stop throwing hissy fits over crossposting.
|
|
| Back to top |
|
|
Patricia Shanahan
Guest
|
| Posted: Sat Mar 26, 2005 9:53 pm Post subject: Re: need just 6 digits |
|
|
Thomas G. Marshall wrote:
| Quote: | Patricia Shanahan coughed up:
...[rip]...
The rules I quoted from the API documentation force
Double.toString(d) to choose 9.123456 in preference to
9.1234559999999999999, or the even closer
9.1234559999999991219965522759594023227691650390625,
because 9.123456 has fewer digits than either of them
in its fractional part.
Patricia
Fair enough, and well written post.
|
Thanks.
The "(int)(d * 1000000) / 1000000.D" technique does have
some issues.
To avoid overflow on the conversion to int, the original
double, d, must be in the range -2147.483648 through
2147.483647 (Integer.MIN_VALUE/1000000.0 through
Integer.MAX_VALUE/1000000.0).
Extending the range by using long instead of int invalidates
my correctness argument, because some long values lack exact
double representations. I don't know whether the proposition
is true or not in that case.
Patricia
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
