Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / November 2005

Tip: Looking for answers? Try searching our database.

Converting floats to Strings and back

Thread view: 
dcMan - 21 Nov 2005 17:26 GMT
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 - 21 Nov 2005 17:37 GMT
>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.
Signature

Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

abrasivesponge@gmail.com - 21 Nov 2005 18:12 GMT
Use the Big Decimal class ;)
dcMan - 22 Nov 2005 20:00 GMT
Thanks, the Big Decimal class worked great.

> Use the Big Decimal class ;)
Oliver Wong - 21 Nov 2005 18:20 GMT
> Hello,
> I'm trying to convert a String to a float, do some arithmetic on it, then
[quoted text clipped - 8 lines]
> 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 - 22 Nov 2005 18:05 GMT
> Hello,
> I'm trying to convert a String to a float, do some arithmetic on it, then
[quoted text clipped - 7 lines]
> 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
Oliver Wong - 22 Nov 2005 21:03 GMT
> 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
[quoted text clipped - 5 lines]
> 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 - 23 Nov 2005 10:58 GMT
>     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


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.