Variables should be consistent throughout a calculation

[parkershepherd]

Very handy tool! As soon as I started playing with it (and the napkin front-end) I immediately wanted to try it out on some finance calculations. I found an issue with calculations that use the same variable multiple times, and put together a napkin showing what I found:

When using the same variable multiple times, it's value should be consistent for the duration of the calculation

num = 1~10
// → 1~10

shouldBeExactlyOne = num / num
// → 0.2~5.4


This consistency should extend to variables that are correlated with other variables

halfNum = num / 2
// → 0.6~4.9

shouldBeExactlyTwo = num / halfNum
// → 0.4~11.4


This example may seem contrived, but consistency is important for many types of calculation. For example a future value annuity calculation has the interest rate in both a numerator and denominator. If the interest rate is sampled twice, you get wildly inaccurate results.

The following example shows that for an interest rate of 5%, and a contribution of $100/mo for 5 years, we expect a future value of $6.8K

PV = 0
// → 0

PMT = 100

r = 0.05
// → 0.050

n = 12
// → 12.0

t = 5
// → 5.0

FV = PV * (1 + r/n)^(n * t) + PMT * ((1 + r / n) ^ (n * t) - 1) / (r / n)
// → 6,800

A lower interest rate of 2% would give us a few hundred dollars less at $6.3K

r = 0.02

FV = PV * (1 + r/n)^(n * t) + PMT * ((1 + r / n) ^ (n * t) - 1) / (r / n)
// → 6,300


If we change the rate to an unsure value between 2% and 5%, I would expect an output of roughly $6.3K~$6.8K, but we surprisingly get an output that's equivalent of an interest rate between roughly -30%~30% D:

r = 0.02~0.05
// → 0.02~0.05

FV = PV * (1 + r/n)^(n * t) + PMT * ((1 + r / n) ^ (n * t) - 1) / (r / n)
// → 3K~14K

r = 0.3
// → 0.30

FV = PV * (1 + r/n)^(n * t) + PMT * ((1 + r / n) ^ (n * t) - 1) / (r / n)
// → 13,600

r = -0.30
// → -0.30

FV = PV * (1 + r/n)^(n * t) + PMT * ((1 + r / n) ^ (n * t) - 1) / (r / n)
// → 3,100


Variable consistency would solve for this issue, but re-assigned variables need to be accounted for:
- For each unsure variable, only sample 1 time for the entire calculation (per iteration)
- If a variable is re-defined, consider it a "new" variable

[WallK]

Yeah, I support this request
The easiest example I could come up with is Gross Margin, which should not go over one (and will not if var is rolled once)

price=500~1000
// → 500~1,000
cogs=100
// → 100
gross_mar = (price - cogs) / price
// → 0.5~1.5