# Why Can't Processing Do Basic Math lol
**URL:** https://discourse.processing.org/t/why-cant-processing-do-basic-math-lol/24277
**Category:** Beginners
**Created:** [October 1, 2020, 8:32pm UTC](https://discourse.processing.org/t/why-cant-processing-do-basic-math-lol/24277 "2020-10-01T20:32:35Z")
**Posts on this page:** 9
**Page:** 1
### Author:  [@wyattsworlddd](https://discourse.processing.org/u/wyattsworlddd)
#### Post date: [October 1, 2020, 8:32pm UTC](https://discourse.processing.org/t/why-cant-processing-do-basic-math-lol/24277/1 "2020-10-01T20:32:35Z")
Hey yall! I’m building a model that can simulate the trading that occurs across a liquidity pool and to experiment with how I can use a balancer contract account to tend the pool and keep a stable currency ratio. The issue I’m having is with my math in calculating the pool balances after a transaction, something weird is happening… I think it might have to do with the weird parsing of data from string to float I’m doing to generate numbers with decimals rounded to a specific decimal point. This is the first time I’m using the nf() function and I think I’m using it correctly, but now some of my math is rounding to weird decimal places where it should’nt. Anyways I’ve included the code below with some context:
The first part of the code works fine. It parses the string data from my accounts[] array from the corresponding account to a float and sets the variable BuyLimit equal to the max amount of money that the account can spend. Next I calculate a random float less than the BuyLimit and set it equal to the String buy.
The next chunk checks the values of the exchange pools before the transaction. When the software starts they are set to 100,000. The first print line confirms that in the console. My issue is when I go to change the pool values with " poolTokenOne = poolTokenOne - Float.parseFloat(buy); " , they end up as the wrong number when I println() again to check their value after the transaction.
Like I said maybe this has to do with the weird Float.parseFloat thing or my nf() rounding, but I tried checking just the output of the Float.parseFloat(buy) with a println() prior to the transaction and the value to be subtracted comes out equivalent to the original buy amount which is how it should be. To me this indicates the issue is occurring not in the Float.parseFloat as I have the correct value to subtract, but when the equation of subtraction occurs on that value from poolTokenOne.
I’m really confused here because poolTokenOne and poolTokenTwo are assigned as floats so when I parse the buy string into a float I’m subtracting or adding proper data types in a simple equation but the solution always comes out wrong…
For example if the buy amount was 328.153. When I call the transaction it should be doing:
Pool A
100,000 = 100,000 - 328.153 = 99,671.847
Pool B
100,000 = 100,000 + 328.153 = 100,328.153
Instead I end up with the final values of:
poolTokenOne = 99,671.844
poolTokenTwo = 100,328.16
It doesn’t make any sense to me there not even redistributing its like they round to weird values. If I took .003 from the difference in the wrong vs correct output for pool one and added it to pool two I don’t even get the correct pool two value, the ratio is off. In this case it creates .004 coins that don’t exist.
ex: 99.671.847 - 99,671.844 = .003 + 100,328,153 /= 100,328.16)
Seriously someone with more experience please help, what’s going on here? Why is processing failing to do basic subtraction and addition? Why am I an idiot? 😀
```auto
if (tokenSelector <= 5) {
println("A Pool Selected");
println(" ");
// Call a random buy from Token A balance
float buyLimit = Float.parseFloat(accounts[accountSelector-1]);
println("Buy Limit: " + buyLimit);
String buy = nf(random(0,buyLimit),0,decimal);
println("Buy Amount: " + buy);
println(" ");
println("Token A Bal Pre Transaction: " + poolTokenOne);
println("Token B Bal Pre Transaction: " + poolTokenTwo);
println(Float.parseFloat(buy));
poolTokenOne = poolTokenOne - Float.parseFloat(buy);
poolTokenTwo = poolTokenTwo + Float.parseFloat(buy);
println(" ");
println("Token A Bal Post Transaction: " + nf(poolTokenOne,0,decimal));
println("Token B Bal Post Transaction: " + poolTokenTwo);
} else if (tokenSelector > 5) {
```
---
### Author:  [@Chrisir](https://discourse.processing.org/u/Chrisir)
#### Post date: [October 1, 2020, 8:38pm UTC](https://discourse.processing.org/t/why-cant-processing-do-basic-math-lol/24277/2 "2020-10-01T20:38:46Z")
Hey and welcome to the forum!
It’s a general computer problem
See [https://en.m.wikipedia.org/wiki/Round-off\_error](https://en.m.wikipedia.org/wiki/Round-off_error)
---
### Author:  [@wyattsworlddd](https://discourse.processing.org/u/wyattsworlddd)
#### Post date: [October 1, 2020, 8:46pm UTC](https://discourse.processing.org/t/why-cant-processing-do-basic-math-lol/24277/3 "2020-10-01T20:46:32Z")
Sooooo, would running my poolTokenOne = 100,000 float through the same nf function when I declare it fix this error? Also I wouldn’t have to parse back to a float from a string being the nf function outputs a string not a float.
Meaning change these parts of my code:
```auto
// Global Declaration
String poolTokenOne = nf(100,000, 0, 3);
// Update of value
poolTokenOne = poolTokenOne - buy;
```
Or…?
---
### Author:  [@GoToLoop](https://discourse.processing.org/u/GoToLoop)
#### Post date: [October 1, 2020, 8:51pm UTC](https://discourse.processing.org/t/why-cant-processing-do-basic-math-lol/24277/4 "2020-10-01T20:51:25Z")
> [@wyattsworlddd](#):
>
> ex: 99.671.847 - 99,671.844 = .003
> **[float / Reference](https://processing.org/reference/float.html)**
>
> Data type for floating-point numbers, e.g. numbers that have a decimal point. Floats are not precise, so adding small values (such as 0.0001) may not always increment precisely due to rou…
> **[double / Reference](https://processing.org/reference/double.html)**
>
> Datatype for floating-point numbers larger than those that can be stored in a float. A float is a 32-bit values that can be as large as 3.40282347E+38 and as low as -3.40282347E+38. A
```auto
float a = 99671.847;
float b = 99671.844;
println(a, b, a - b); // 99671.84 99671.84 0.0
double c = 99671.847d;
double d = 99671.844d;
println(c, d, c - d); // 99671.847 99671.844 0.0029999999969732016
exit();
```
---
### Author:  [@wyattsworlddd](https://discourse.processing.org/u/wyattsworlddd)
#### Post date: [October 1, 2020, 9:41pm UTC](https://discourse.processing.org/t/why-cant-processing-do-basic-math-lol/24277/5 "2020-10-01T21:41:35Z")
So if I’m understanding this correctly being floats aren’t necessarily precise I should use a double even though storage wise they’re kind of over kill and then just throw everything away after the three decimal places that I want with the nf() function?
But I still don’t understand the math going on, why if you’re subtracting 99671.847 - 99671.844 do you not get 0.003 even with the double type and its precision? Why do we get 0.0029999999969732016? I didn’t pass it any values past the three decimal places as I’ve rounded the values of the equation to three decimal places prior, why is the answer giving me something like the value subtracted with was 99761.84499999903921 or whatever… Those values shouldn’t exist unless the computer is again rounding wrong. This isn’t like a huge number I’m subtracting, I should be able to subtract accurately 3 decimal places past zero?
---
### Author:  [@GoToLoop](https://discourse.processing.org/u/GoToLoop)
#### Post date: [October 1, 2020, 10:50pm UTC](https://discourse.processing.org/t/why-cant-processing-do-basic-math-lol/24277/6 "2020-10-01T22:50:23Z")
> [@wyattsworlddd](#):
>
> , I should be able to subtract accurately 3 decimal places past zero?
Even the primitive datatype `double` can’t deal perfectly well w/ fractional precision.
As a workaround you can use the primitive datatype `long` and treat its 3 rightmost digits as if they were its fractional part:
> **[long / Reference](https://processing.org/reference/long.html)**
>
> Datatype for large integers. While integers can be as large as 2,147,483,647 and as low as -2,147,483,648 (stored as 32 bits), a long integer has a minimum value of -9,223,372,036,854,775,808 a…
Or as a more properly solution go w/ the datatype BigDecimal:
[https://Docs.Oracle.com/en/java/javase/11/docs/api/java.base/java/math/BigDecimal.html](https://Docs.Oracle.com/en/java/javase/11/docs/api/java.base/java/math/BigDecimal.html)
---
### Author:  [@quark](https://discourse.processing.org/u/quark)
#### Post date: [October 2, 2020, 8:22am UTC](https://discourse.processing.org/t/why-cant-processing-do-basic-math-lol/24277/7 "2020-10-02T08:22:24Z")
The double data type uses 8 bytes, that 64 bits. This means there are 18,446,744,073,709,551,616 different possible combinations of bit arrangements but there is an _ **infinite** _ number of floating point numbers (FPN). This means that only an _ **infinitely small** _ number of FPNs can be stored in a computer with 100% accuracy, it would seem that 0.003 is one of them.
---
### Author:  [@neilcsmith](https://discourse.processing.org/u/neilcsmith)
#### Post date: [October 2, 2020, 11:26am UTC](https://discourse.processing.org/t/why-cant-processing-do-basic-math-lol/24277/8 "2020-10-02T11:26:21Z")
> [@wyattsworlddd](#):
>
> should use a double even though storage wise they’re kind of over kill
Processing’s choice of float over double as a default was always a mistake in my opinion. The storage concern only really comes in when you have lots of data, such as big arrays, and even then doing calculations on them as doubles can make more sense.
For comparison, all the new functional and stream stuff added in Java 8 supports `int`, `long` and `double`, but not `float`.
---
### Author:  [@SomeOne](https://discourse.processing.org/u/SomeOne)
#### Post date: [October 2, 2020, 4:32pm UTC](https://discourse.processing.org/t/why-cant-processing-do-basic-math-lol/24277/9 "2020-10-02T16:32:36Z")
That’s life with floating point values and computers. If you need real precision then you need to work around. One option what @GoToLoop suggested: use int or long int and treat part from the right as decimal part. You’ll get precision you need, but you need to divide those numbers before you show them. Divisor depends on amount of decimal places you use.
Java has [BigDecimal class](https://docs.oracle.com/javase/7/docs/api/java/math/BigDecimal.html) that can handle arbitrary accuracy with decimal number, but using it is not as straight forward.