3

I have a SQLDB with table of field REAL. In my layout I have set its field size to allow only 8+2 digits. In my object I have used the data-type of the field as "float".

qs[0] = "CREATE TABLE " + RELATION_TABLE_NAME + "(id TEXT PRIMARY KEY, name TEXT NOT NULL, startBal REAL NOT NULL, currentBal REAL NOT NULL);";

<EditText android:text="" android:id="@+id/relCurrBalTxt" style="@style/EditTextStyle"
 android:inputType="numberDecimal" android:maxLength="11" android:hint="12345678.99" />

I entered value "87654321.99" in my editText and clicked save. It populates the object

// Send the data to object 
rowData.setValue(2, Float.parseFloat(sbalTxt.getText().toString()));
// In object, this is how I save it
this.setCurrentBalance( ((Float)value).floatValue() );  // value is Object type

// Saving data in ContenteValues to save to DB
// LOG Rcvd from Object while Saving CurrBal: 8.765432E7
values.put("currentBal", new Float(rowData.getValue(3).toString()));

On saving, it directly show the table with the updated data. While showing it in table I use DecimalFormat to make sure it is shown in proper manner :

    field_type = r.getFieldType(field);
// Get Data
str = r.getValue(field).toString();

// Format accordingly
if(field_type.equals(DBRow.DOUBLE_TYPE) || field_type.equals(DBRow.FLOAT_TYPE)) {
        double douValue = Double.parseDouble(str);
            //NumberFormat nf = NumberFormat.getNumberInstance(Locale.ITALY);
            //DecimalFormat df = (DecimalFormat) nf;
            DecimalFormat df = new DecimalFormat();
            df.applyPattern("##,###,###.##");
            df.setGroupingUsed(true);
            str = df.format(douValue);
        //  Log.v("DF", "While Showing in Table : double = " + douValue + " String = " + str);
        } 

((TextView) tr.getChildAt(field)).setText(str);

HERE it showed me the value : 8.765432E7

When I again selected that row to see the values in EditText I see : 87654320.00

How is the value changed ? In other instance also I saved the data as "50009876.99", but somehow it doesn't save .99 and makes that as .00 i.e 50009876.00.

Why things are not working correctly ? Where am I going wrong ?

Any help is highly appreciated.

*EDIT : DecimalFromat code used to display in table *

        // Format accordingly
    if(field_type.equals(DBRow.DOUBLE_TYPE) || field_type.equals(DBRow.FLOAT_TYPE)) {
        /*
                      WAS USING THIS CODE TILL NOW
    DecimalFormatSymbols dfs = new DecimalFormatSymbols();  
    String decep = String.valueOf(dfs.getDecimalSeparator());
    int index = str.indexOf(decSep); 
    if (index > 0) {
       // If digits after decimal are more than 2
       if (str.substring(index+1).length() > 2) {
        str = str.substring(0, index+3);
    }
    }
    DecimalFormat df = new DecimalFormat();
            df.setGroupingUsed(true);
            str = df.format(Double.parseDouble(str));

            if (addRow)
        create_addTextView(tr, str, true); 
    else 
        ((TextView) tr.getChildAt(field)).setText(str);

            */

                 // DECIMALFORMAT CODE
            double douValue = Double.parseDouble(str);
            DecimalFormat df = new DecimalFormat();
            df.applyPattern("##,###,###.##");
            df.setGroupingUsed(true);
            str = df.format(douValue);

            if (addRow)
       create_addTextView(tr, str, true); 
    else 
      ((TextView) tr.getChildAt(field)).setText(str);

}
Tvd
  • 4,463
  • 18
  • 79
  • 125

1 Answers1

6

I think your problem is that you store the numbers as Float. Float does not have very good precision - it actually has only 23 binary digits of precision as seen here. This means that you can not store accurately in float 7 digits before the decimal point or even worse - 7 digits before the point and a couple after. This means that you have incorrectly chosen the type of the balance variable - you can not store in Float 8+2. I would recommend you to change the type to Double, which has significantly larger range of precision.

Boris Strandjev
  • 46,145
  • 15
  • 108
  • 135
  • by reading SQLite docs, that REAL supports float, I intended to use Flaot, else Double is my preferred choice. Will REAL data type of SQLite also support Double ? – Tvd Jan 28 '12 at 11:20
  • 3
    I have never tried it, but it should. I think you are a bit confused with the terms - when they say floating number they mean the general term. No one said SQLite is to work only with Java, thus no need for direct mapping to its types. Furthermore: 1) android provides put of Double in the ContentValues which means this should be fine; 2) The SQLite real type is 8 byte number, which means it actually perfectly corresponds to Double, not Float. – Boris Strandjev Jan 28 '12 at 11:27
  • Thanks. I changed my data type from float to double in Object and whereever used. Now I treid to save "87654321.98" & "98765432.89", the numbers I find in table dispaly are "8.76" & "9.87" respectively. If I see the same record in EditText, then I see "8.765432E7" & "98765432" respectively. Still why the numbers are changed, can't make out. And this problem am facing only when the number is 8+2. If its 7+2, then I don't see any issues. "7654321.77" & "9876543.99" shows perfectly the same in table. – Tvd Jan 28 '12 at 11:40
  • See the post here: http://stackoverflow.com/a/1826095/1108032. I think the problem in your case is that you get an exponent with so big numbers, but this post should show you how to specify a format that does not allow exponent. – Boris Strandjev Jan 28 '12 at 11:52
  • Using DecimalFormat, number with 7+ digits gets rounded off. Like the 7+2 digit "7654321.77" turned "7654322", 8 digit "87654321.87" turns "87654320". Have added the numberformat code in Q. used to display the numbers in table. – Tvd Jan 28 '12 at 12:40
  • let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/7122/discussion-between-boris-strandjev-and-tvd) – Boris Strandjev Jan 28 '12 at 13:12
  • By default, DecimalFormat uses Half_Rounding. I don't see a way to set RoundingMode as Unnecessary using Decimalformat or BigDecimal. Then how to avoid the round off mode ???? – Tvd Jan 28 '12 at 13:16