I store a variable in sqlite db as REAL but in my app I need to use it as BigDecimal.
The problem is, I am not able to save my BigDecimal variable to my sqlite without converting it to float or double.
so I do the following:
bigDecimal.floatValue();
but by doing that a loss of precision occurs.
for example
if I put to my editText from which I get the variable: 123456789
after converting it from bigDecimal to float I get : 123456792
The same happens if I try to cast bigdecimal to string:
String.valueOf(bigDecimal);
the problem occurs ONLY if the variable which I put is at least 8 digits long.
It behaves the same way if its a decimal number and the numbers differ always after the seven digit.
is that a normal behaviour ? how to avoid it?
Related
I have the following data. To me both are Double type. But Firebase always takes 69.0 as 69. Then I can't declare the property price as Double because I'm getting the exception:
firebase.database.DatabaseException: Failed to convert value of type
java.lang.Long to Double
Is there a way to force a Double type to a specific property?
If you're going to store money values in a database, consider that floating point numbers can be inaccurate, due to the way they're represented according to the IEEE 754 specification. A full discussion of this is too long to put here.
You can work around this by multiplying all your prices values by some value that eliminates the fractional part of the number and only stores integers. With US dollars, for example, there is no smaller unit of currency than 1 cent. Instead of storing floating point value .01 to represent this (possibly losing precision), I could multiply it by 100 and store an integer 1, without losing any precision.
If I eliminate floating point numbers from my prices like this, now I'm only storing integer values. After reading them on the client, I still have to format them as dollars and cents, which means I have to write some extra code to format prices values like "399" into "$3.99", which is not that difficult, and I can do it without losing any precision.
If you're storing currency values other than US dollars, you may have a different scheme, but the idea is the same - convert your fractional prices into integers for storage in the database, then format those values as the user would expect to see them.
I am storing a value in database as 0.0004 and displaying the same in EditText but in edittext it as showing as 4.0E-4 tried a lot of things nothing seems to work for me.
Storing value in database is fine but when coming to edittext display it is wrong.
What I have tried:
Increased the size of edit text but didn't solve the problem.
Followed below process
DecimalFormat FORMATTER = new DecimalFormat("0.####");
textvalue.setText(REAL_FORMATTER.format(new_percent.getLong(new_percent.getColumnIndex(bt.column2))));
but the result is same no chage.
Can any one help to solve this..I want the display in edit text as 0.0004 not as 4.0E-4
Thanks for your time.
Instead of giving pattern to the BigDecimal just send directly the value to the constructor parameter.
example:
BigDecimal number = new BigDecimal("4.0E-4");
int ints= number.intValue(); //BigDecimal to integer
double doubles= number.doubleValue(); //BigDecimal to double
Why you retrieve 0.0004 value with the getLong mehod?
As I suppose, you store the 0.0004 in a database in a REAL column type,
so you should retrieve this with getDouble.
DecimalFormat formatter = new DecimalFormat("0.####");
textValue.setText(
formatter.format(
new_percent.getDouble(
new_percent.getColumnIndexOrThrow(bt.column2))));
Finally achieved as below.
BigDecimal.valueOf(Cursor.getDouble(Cursor.getColumnIndex(bt.column2)))
in android eclipse sometimes a calculation result for both double and float when displayed as a string uses a decimal point (desired) but sometimes using an exponent (bad - confusing to user). anyway to avoid the exponent?
See String.format documentation.
Just set the desired format for your numbers. You probably want String.format("%f",number).
I am trying to make a program that takes some user input, runs a few calculations and outputs the answer. My problem is that this answer is sometimes many decimal places long which is causing some aesthetic and layout problems. I only need to display 4 decimal places worth of data. Is there anyway to limit the precision of these numbers at output time? (The Numbers are stored in floats and I'm programming for Android.)
You can format a float to 4 decimal places using String.format.
Example:
String result = String.format("%.4f", theNumber);
See also:
How to nicely format floating numbers to String without unnecessary decimal 0?
String.format(format, args)
Format strings in Java
i have a problem with double values i need to store in an android homed sqlite database. since these double values represent gps values (lat & lng), i really NEED an absolute precision down to the 9th number after the comma.
now i have a table like this:
CREATE TABLE x REAL lng;
and insert sth (hardcoded) like:
INSERT INTO x lng = '1.0';
and when reading lng from this table into some (java) double variable, i get a value like "0.999956837" - this renders the values pretty useless to me.
is there a way to enforce the precision i need other than storing the values as "text" fields (what would make expensive casts neccessary) or storing them as integers (meaning i need to multiply/divide at each write/read-op)?
SQLite is typeless, that means all representation is written as text, probably the wrapper api does some converts you don't know of, that you get those results.
If you need to store the data as string do it.
Just when you read out the double make sure you saved in the right format, you can use getDouble on the column.
double has about 17 decimal digits of precision, so if 9 digits is what you need, there should be no problem (assuming that you don't do any complex calculations on those values). Just make sure you never end up using float, because that has only about 7 digits of precision.
You should also make sure you understand how binary floating-point works, and that it will always result in seemingly "round" values becoming slightly off - which simply does not matter for most applications (including yours) as long as it happes somewhere in the 17th decimal digit. See that link also for alternatives for applications where it does matter.