so far I'm only able to calculate this for the very special cases of simple interest/discount, and compound rates

however, for more general cases, we'd need calculus since \delta_t = \frac{a`(t)}{a(t)}, which requires taking the derivative of of the accumulation function

This function and payments class has been moved to a new module

currently only accepts a discount function, although it works if payments already have discount factors provided

but, if payments do not have discount factors attached, then we should be able to supply just an interest rate or accumulation object/function as well

Although an npv function exists to calculate net present value, it would be nice to have a solver that can solve for missing amounts. For example, if a payment happens on an unknown date, but the npv and the rest of the information is provided, we should be able to solve for that date.

convert_rate can be refactored to reduce the number of cases

we should have an if/else for the known patterns, each of which then calls its own specialized conversion function (which I need to make) for the case.

for example, there are 4 x 4 different cases for the 4 different patterns, if each pattern had its own function for converting to the other patterns, we'd need just 4 cases, otherwise the function will grow exponentially as we discover more patterns

Since SimpleAmt has been deprecated, we need new examples

This has been moved to another module, should go into the value chapter

You should be able to:

1. Insert payments
2. Remove payments
3. Modify payments
   a. modify payment time
   b. modify payment discount
   c. modify payment amount

Not all accumulation functions have K explicitly defined. It would be nice to have k as an optional argument, and when it is not given, the value for k should be extracted from the given accumulation function.

Since a solver solves for a missing variable, it should be possible to pass a solver directly to a class (Annuity, Accumulation, etc.) to initialize it without needing to repeat the other arguments.

I would anticipate in calculating the term, we'd see a bug if the user would supply overlapping payments that occurred at the same time.

There are a lot of these functions and some of them share arguments, like i for interest rate. Make sure all the names are the same.

Right now you must supply the period and term, from which the number of payments will be derived.

An alternative approach would be to allow for supplying the period and number of payments, from which the term will be derived. This would better match actuarial notation since the n in \ax{\angln} refers to the number of payments.

It would be nice if we didn't have to call Rate.rate every time we wanted to add it to something.

See Vaaler & Daniel, problem 1.7.5. We can solve this by supplying a TieredTime to an Accumulation object, and then using the discount function.

I wonder if some people will try to use the compound solver in this scenario. The function does not support complex growth functions such as TieredTime, so it may be worthwhile to implement this feature. This is not high priority since there is already a way to do this using the Accumulation class.

this new feature will cause the code to break if the arguments are not correctly provided

proposed format:

[nom/eff]_[int/disc]_from_[nom/eff]_[int/disc]

it may be convenient for users to have a single interest rate conversion function rather than having to memorize or look up all the different specific converters:

1. apr
2. apy
3. nominal_from_eff
4. effective_from_nominal
5. interest_from_discount
6. discount_from_interest

There may be more, so I might wait until I get further in my sources before getting to this.

It won't really make sense if the tiers are provided out of order since the way they are defined depends on the order. These classes should enforce this rule.

it can only accept an effective interest rate, needs to accept discount, nominal interest/discount, and force of interest

this should be high priority, otherwise it'll break

Tiered investments are now possible, but the code is quite messy, it may be possible to simplify it.

Expected behavior:

When supplying npv() with discounted payments, I would expect for it to work without needing to supply a discount function.

Observed behavior:

Traceback (most recent call last):
  ...
    exec(code_obj, self.user_global_ns, self.user_ns)
  File "<ipython-input-3-822aaf6bee2c>", line 7, in <module>
    test = npv(payments=payments)
TypeError: npv() missing 1 required positional argument: 'discount_func'

right now Rate() needs several arguments for the most common form, single-period compound interest. To make things more convenient, simply calling something like Rate(.05) should result in a compound interest rate of 5% for a 1-year period.

I've so far counted at least 16 different types of interest-discount conversions, leading me to think that it may be difficult for the user to handle.

All these different rates can be abstracted to a general class, which can then be handled by the existing amount/accumulation classes.

I will need to make sure that the underlying mechanics work first, so it may be some time until I get to this.

See Vaaler and Daniel example 3.5.3. This method was originally written to solve for the value of a deferred annuity several years beyond the last payment.

Now that the Annuity class takes an argument for deferrals, pt_bal() returns the same answer as eq_val(), the equation of value for the underlying payments class. Because of this, I'm not so sure if pt_bal() needs to exist or repurposed for something else.

An alternative would be to rewrite the method to return the value of an annuity t years after the last payment.

removed old examples, but need to redo them with the new class

I haven't really seen solvers in other packages that are general in the sense that the return type can change depending on what parts of an equation are missing. It may be better to break up a general function into multiple functions - one for each case. By doing so, we can avoid confusion on what a function is supposed to return and reduce semantic errors.

This is kind of an edge case since most TVM problems involve compound interest, so somewhat low priority.

This might also apply to growth functions where accumulation and discounting do not yield the same value for certain points of time. For example, if we invest $1 at 5% simple interest, it grows to $1 x (1.15) = $1.15 at time 3. We can get the present value by multiplying by the discount function, (1 + .05 * t) ^ -1. But what we can't do is get the time 2 value by multiplying 1.15 by the discount function with t=1.

That is, $1 x (1.10) is not equal to $1.15 / 1.05.

When textbooks transition to compound interest, students may get used to its convenient properties and forget that you cannot just multiply by v * t when going backwards in time for 2 periods for certain growth functions other than compound interest.

In the general case, one must first bring the value back to time zero and then grow the pv up to the point in time for which you want to have the value.

The value module is the most obvious place I can think of where this may be a problem, so we should check there first.

When the former is not using an approximation method, I would have expected it to deliver the same results as the latter. This isn't the case for D&V example 3.10.1, so we should check out why.

I have not encountered issues yet but this is a known theoretical constraint that may cause semantic errors in the future.

Maybe there ought to be a way to combine financial instruments governed by different growth rules so we can calculate the combined value at desired points in time. See Daniel & Vaaler example 3.12.10.

It may be confusing to users to have to call a separate class each time they want to use the discount rate, so maybe it would be better to just enable the compound accumulation/amount class to accept a discount rate instead.

However, it could be confusing if users realize there are two available arguments - interest and discount rate - without knowing the difference between the two. I'll need to work through more problems and reach out to the community on their opinion.

My sources don't go into great detail about inflation, except in the case of annual effective interest. However, handling general inflation for all the different interest rates (nominal, force, discount, etc.) is another story. It may be a concept worth exploring.

The demo should be update with something other than simple interest, just to demonstrate more advanced capabilities.

Payments can accept a list of payments, but it should accept more sources, such as:

1. pandas DataFrame
2. SQL
3. delimited text files (csv, tsv, etc.)

I might want to re-add delta_t which was only implemented for simple interest but was taken out with the deprecation of the SimpleAmt and SimpleAcc classes. It has known forms for certain growth patterns so I may add limited support for those forms.

I suspect this may automatically solve itself once #39 closes, but it's still worth making note that this needs to be fixed.

it would be nice to actually see the payments when executing the object

Certain growth functions aren't defined on all real numbers, so when the checks use an invalid domain value , a ZeroDivisonError may happen. There's a temporary fix pushed, but these routines can be more thoughtfully written.

Right now the Annuity class isn't well-equipped to handle general accumulation functions. See Vaaler & Daniel textbook example 3.3.12 where the interest rate changes from .06 to .05. The shortcut formulas are only valid when the compound interest rate does not change.

The create_payments() function currently accepts lists of times, amounts, and discount factors, along with an optional discount function.

I'd like for the user to be able to have more options for creating payments, by supplying other information that is mathematically equivalent to the above. Off the top of my head, I can think of:

1. A dictionary of payments, which include times, amounts, and optionally, discounts
2. A compound interest rate
3. An accumulation object

Yet, at the same time I want to avoid redundancy. If a person inputs an accumulation object, an interest rate, and a discount function, for instance, there's a chance they will be inconsistent with each other, so the user should not be able to insert all of these simultaneously.

Since the NominalInt/Disc classes have been removed, this section of the documentation needs to be redone.

While the current classes are convenient from a theoretical standpoint, in practical applications, the APR is often used instead. Existing classes may need to be able to handle APR instead of just APY.