Hello everyone i'm trying to figure up why does my calculate app cannot work with numbers bigger then 2^28.
The next num after the biggest is the smallest. Now I understand that the problem is with the definition of my variables but its an integer and at c++ integer variables are 8 bits numbrer that allows me to calculate 2^32.. so how do I get ridd of this bug?
Hey I solved the problem. If you want to do an app that calculates extreme numbers change the variables you use to "double" variable that can calc numbers until 2^64
Related
I'm actually using Math.sin() in my android app to calculate a sinus of a given angle (using Math.toRadians(angle_in_degrees)). For exemple when I want to get the Math.cos(90) which is 0, the result is 6.123233... E-17. Thanks you.
For floating point numbers, the system can often only approximate their values. For instance, the system would return something like 0.333333 for the expression (1.0 / 3). The number of 3s after the decimal point will be different depending on whether you're a floats or doubles, but it will still be limited to some finite length.
If you're just displaying the value, then you can limit the number of digits using something like String.format("%0.2f", value) or by rounding it using one of the rounding functions such as Math.round().
The tricky part comes when you need to compare the value to something. You can't just use if (value == some_constant) or even if (value == some_variable). At minimum, you usually have to use something like if (Math.abs(value - some_constant) < 0.001). The actual value of the '0.001' depends on the needs of your particular application and is customarily defined as a named constant.
For more complicated needs, you can implement the algorithm in the Floating-Point Guide.
You're getting back an approximation from Math.cos(Math.toRadians(90)) which is
6.123233... E-17 == 0.00000000000000006123233... which is basically 0
The following link should help clear things up as far as the precision of doubles/floats in programming.
http://www.java67.com/2015/09/float-and-double-value-comparison-in-java-use-relational.html
I am beginner and trying to write some calculations with App Inventor 2.
I am trying to write a code to calculate Net present value.
The formula of NPV = - investment + CF/(1+i)power up by years of investment, which means if years of investment are > 1 the second part of formula will repeat until it reached the number of years.
I successfully code the formula for one year that works correct, but have problem with the "repeating" the second part powered by number of years.
I tried to declare years as variable to use it as powering number but think something is wrong with it.
In my opinion I need to split the powering number somewhere to memory and then increase it by 1 until the required number. However have no clue how to do it.
Can anyone help?
Screenshot of the blocks
Following the calculation from the NPB Calculator,
this is converted into blocks the following
Note: for a better clarity and to avoid such long calculation blocks as in your screenshot, I used External Inputs instead of Inline Inputs, which is the default. You can switch that from the context menu after doing a right mouse click onto one of the calculation blocks.
EDIT: screenshot updated for changing cashflows using a list.See also
How to work with Lists by Saj and
How to work with Lists and Lists of lists (pdf) by appinventor.org
We have problem in our Android application with rounding numbers. In calculation made in Java we use BigDecimal and this helps, but we have problem with SQLite, for ex.
SELECT ROUND(150.075 * 100) / 100 (= 150.07, not 150.08!)
What you think about this (not elegant) solution:
SELECT ROUND(150.075 + 0.00000000000009, 2) (= 150.08)
We checked it on more then 5 000 incorrect values and it's works good.
That's because due to floating point inaccuracies, 150.075 * 100 is not the same as 15007.5. The decimal representation for 150.075 in double-precision floating point is 150.07499999999999999722444243843711.
To get the behavior you want, use the two-argument version of ROUND() which lets you specify the number of decimal digits:
sqlite> SELECT ROUND(150.075, 2);
150.08
How can i check if a number is between two other numbers in Android
if(number1.matches("[1024-65535]+"));
else{
One way to solve your problem is to convert all values that need to be compared into ints. Then the comparison is trivial.
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.