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
Related
I can easily read 2e15 as "two quadrillion" at a glance, but for 2000000000000000 I have to count the zeroes, which takes longer and can lead to errors.
Why can't I declare an int or long using a literal such as 2e9 or 1.3e6? I understand that a negative power of 10, such as 2e-3, or a power of 10 that is less than the number of decimal places, such as 1.0003e3, would produce a floating point number, but why doesn't Java allow such declarations, and simply truncate the floating-point part and issue a mild warning in cases where the resulting value is non-integral?
Is there a technical reason why this is a bad idea, or is this all about type-safety? Wouldn't it be trivial for the compiler to simply parse a statement like
long x = 2e12 as long x = 2000000000000 //OK for long
and int y = 2.1234e3 as int y = 2123.4 //warning: loss of precision
It's because when you use the scientific notation you create a floating point number (a double in your example). And you can't assign a floating point to an integer (that would be a narrowing primitive conversion, which is not a valid assignment conversion).
So this would not work either for example:
int y = 2d; //can't convert double to int
You have a few options:
explicitly cast the floating point to an integer: int y = (int) 2e6;
with Java 7+ use a thousand separator: int y = 2_000_000;
Because it's a shortcoming of Java.
(Specifically, there is clearly a set of literals represented by scientific notation that are exactly represented by ints and longs, and it is reasonable to desire a way to express those literals as ints and longs. But, in Java there isn't a way to do that because all scientific notation literals are necessarily floats because of Java's language definition.)
You are asking about the rules on writing a integer literals. See this reference:
http://docs.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html
The capability to use scientific notation as an integer literal might make things easier indeed but has not been implemented. I do not see any technical reason that would prevent such a feature from being implemented.
I'm looking for a way to compare 2 strings partial. I need to clear this with an example.
The base string is "equality".
The string I need to check is spelled wrong: "equallaty". I want to conform this is partially correct so the input, even not right in a grammar way, is the same as the base string.
Now I can of course parse the string to an char array. Now I can check every single character, but if I check the first 4 characters they will be right, the rest will be wrong even if there are only 2 mistakes. So the check I want to use is that a minimum of 70 procent of the characters should match.
Is anyone able to help me get on the right track?
Compare the strings with an edit-distance metric like the Levenshtein distance. Such a metric basically counts the number of changes needed to make the strings equal. If the number of changes is small relative to the total size of the string, then you can consider the strings similar.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Why can't decimal numbers be represented exactly in binary?
i get very odd behaviour from simple float maths. eg.
//create a float with value of 1.0
float f = 1.0;
//take 0.1 from its value
f -=0.1;
for the first few times when i minus 0.1 it returns 0.9, 0.8, 0.7......
then for some reason it will return 0.699999999999, 0.59999999999 and so on.
to say this is unexpected is an understatement.
so to fix this i either need to know why it would do this
or a math function similar to Round(float) where it will round the number from 0.5999999 to 0.6.
thank you
edit,
ok sorry for asking lol
any fix available? like Round(float) kinda thing?
other edit:
for the next person to ask about this heres a fix
final DecimalFormat myFormat = new DecimalFormat("#.#");
myFormat.format(myFloatValue)
this will change myFloatValue 0.599999 into 0.6
A computer is a finite device, so it stores floating point numbers with a finite precision. And it stores them as binary floating point numbers -- that is relative to base 2 instead of base 10. A number with a finite representation as a decimal fraction doesn't necessarily have a finite representation as a binary number, so it must be rounded to be stored in a finite computer. In this example, 0.1 will be rounded to
0.1000000000000000055511151231257827021181583404541015625
when stored as a double precision floating point number, so you actually subtract a bit more than 0.1 in each step.
This is due to a fundamental limitation of the floating point representation. Certain numbers, such as 0.1, are not exactly representable using base-2 arithmetic with finite precision.
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 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.