Converting floats to Strings and back

[dcMan]

Hello,
I'm trying to convert a String to a float, do some arithmetic on it, then
display the new value on a Swing text field. Then do the reverse. Take a
decimal numeric value the operator has entered from the GUI, convert it to a
float do some arithmetic to remove the decimal, convert it back to a String
to save it to a database.

The code works fine until I exceed 8 digits. Beyond 8 digits the float is
stored in memory in scientific notation (found this out by stepping through
using the debugger) so when it is converted to a String I do not get the
correct data. I get something like 1.234567891E7 instead of 12345678.91

I've also tried using a double but I got the same results.

String sWeight = "";
float floatWeight= 0;

//Retrieve weight from database stored as a String values, with no decimals
sWeight = getWeight();
// need to put a two digit decimal place within the number before
displaying, so divide by 100
floatWeight = Float.parseFloat(sWeight) / 100.00;
// convert the float to a string and display on the GUI.
gui_text_field.setText(String.valueOf(floatWeight);


I also need to the same thing in reverse, if the operator manually enters
the weight it must be save back to the database as a String.

String myString = "";
float floatValue = 0;

//Get the text string entered by operator (ex 12345678.91)
myString = gui_text_field.getText();
// move the decimal to the end of the number, so multiply by 100
floatValue = Float.parseFloat(myString) * 100;

// convert the weight to a string
myString = Float.toString((float)floatValue);
// strip out the decimal point
myString = myString.substring(0, myString.indexOf("."));

// save String to the String data column in database, myString should be
equal to 1234567891
saveDataToDatabase(myString);

Thanks in Advance

 

[Roedy Green]

I'm trying to convert a String to a float, do some arithmetic on it, then
display the new value on a Swing text field. Then do the reverse. Take a
decimal numeric value the operator has entered from the GUI, convert it to a
float do some arithmetic to remove the decimal, convert it back to a String
to save it to a database.

see http://mindprod.com/applets/converter.html

You want interconvert float <-> String.

 

[abrasivesponge]

Use the Big Decimal class

 

[Oliver Wong]

Hello,
I'm trying to convert a String to a float, do some arithmetic on it, then
display the new value on a Swing text field. Then do the reverse. Take a
decimal numeric value the operator has entered from the GUI, convert it to
a float do some arithmetic to remove the decimal, convert it back to a
String to save it to a database.

The code works fine until I exceed 8 digits. Beyond 8 digits the float is
stored in memory in scientific notation (found this out by stepping
through using the debugger) so when it is converted to a String I do not
get the correct data. I get something like 1.234567891E7 instead of
12345678.91

The "in memory representation" of a float is probably not in scientific
notation; I'm not sure if the Java Language Specification actually forces
this, but every implementation I've seen stores uses IEEE floating point
format. When you try to get a string representation of the value, that
string may be displayed in scientific notation. To avoid that, you may wish
to use the java.text.DecimalFormat class.

http://java.sun.com/j2se/1.5.0/docs/api/java/text/DecimalFormat.html

- Oliver

 

[Alun Harford]

Hello,
I'm trying to convert a String to a float, do some arithmetic on it, then
display the new value on a Swing text field. Then do the reverse. Take a
decimal numeric value the operator has entered from the GUI, convert it to a
float do some arithmetic to remove the decimal, convert it back to a String
to save it to a database.

The code works fine until I exceed 8 digits. Beyond 8 digits the float is
stored in memory in scientific notation (found this out by stepping through
using the debugger) so when it is converted to a String I do not get the
correct data. I get something like 1.234567891E7 instead of 12345678.91

Unless you want speed (ie. the arithmetic is hard and you've analysed the
result of using floating-point to do it), or you want to demonstrate some of
the nasty things that happen with floating point, use BigDecimal.
a) It requires significantly less use of your brain, which generally reduces
the number of bugs.
b) Your users shouldn't have to think about the limitations of floating
point without a very good reason.

Alun Harford

 

[dcMan]

Thanks, the Big Decimal class worked great.

 

[Oliver Wong]

Unless you want speed (ie. the arithmetic is hard and you've analysed the
result of using floating-point to do it), or you want to demonstrate some
of
the nasty things that happen with floating point, use BigDecimal.
a) It requires significantly less use of your brain, which generally
reduces
the number of bugs.
b) Your users shouldn't have to think about the limitations of floating
point without a very good reason.

I've experimented with using BigInteger instead of int in my code with
mixed results. Code that was integer-math intensive (e.g. finding prime
numbers) typically ran 5 to 7 times slower, which is pretty bad, but not
"noticeable" for typical user applications. I'll probably continue this
practice because for most of my apps, the bottleneck is not the
integer-math, and the extra flexibility is nice.

My question is: is there a "best" way to store BigInteger and BigDecimal
values in databases (particularly in SQL)? The two most obvious solutions to
me is to store them as BLOBs or as strings. I'd probably favor the latter,
because although it uses more storage space and processing time (e.g. to
parse the string back into a BigInteger value), it'll probably be easier to
inspect the DB to make sure all the values are correct during debugging.

- Oliver

 

[Chris Uppal]

My question is: is there a "best" way to store BigInteger and
BigDecimal values in databases (particularly in SQL)? The two most
obvious solutions to me is to store them as BLOBs or as strings. I'd
probably favor the latter, because [...]

Also, other applications that read the data (not Java) will be able to work
with it. E.g. report generators.

Since one of the biggest (arguably the only) reason to keep data in SQL-style
databases is so that the data can be application-independent, it makes sense to
keep data in application-independent formats where possible.

-- chris