Programming a Lookup Table for Inflation Calendar on DM42

Post here to share useful tips and tricks, to ask questions about using your DM42 or to report software-related problems
Post Reply
REPORTSFROMLUKE
Posts: 1
Joined: Sat Jul 21, 2018 10:58 am
Location: NYC, USA

Programming a Lookup Table for Inflation Calendar on DM42

Post by REPORTSFROMLUKE » Tue Aug 28, 2018 3:41 am

Hello, everybody. A quant and coding newb,here. I bought a DM42 to deepen my math thinking abilities. A project I want to learn from, and complete by asking questions is to code an inflation calculator to a DM42 program. An example of the sort of program can be seen here:

https://data.bls.gov/cgi-bin/cpicalc.pl

I have the data in a spreadsheet so far, and i know the main operation will be a delta percent calculation.

Wisdom I gleaned from a FB HP calculator user group posting on the matter has reports,

TP:
well the equation is F=P(1+i)^N
Where F is the future value
P is the present value
i is the inflation per period
N is the number of periods.
You can program this in as an equation for the solver, and find values for any of these variables... but there's one problem. Inflation isn't constant, so 'i' won't be a constant value. You'd need to create a table of inflation values for each time period. I don't know if it would be possible to utilize the solver for that....


JB
Well the thing is, it’s all based on empirical data from the years in question, gleaned afterward. So it’s simple, but I think you basically need to store the consumer price index for each year into its own register.

To calculate, you. Take the start and end year and subtract to get the delta. Starting with the CPI for the first year, (indirect addressing would help) find the first year, loop through however many years you are spanning and multiply by each successive year’s CPI in the series.


TP
Yes this would work as well. The key is definitely storing the values in some kind of look-up table.


I hope I am asking the right questions, and will have few more after hearing others' wisdom.

Many kind thanks!

keithdalby
Posts: 498
Joined: Mon Apr 24, 2017 6:38 pm

Re: Programming a Lookup Table for Inflation Calendar on DM42

Post by keithdalby » Tue Aug 28, 2018 6:58 am

Store them in a 2-column matrix (year, index) then it should he be trivial to iterate through the matrix looking for the year you want to start from, etc.

DavidM
Posts: 9
Joined: Mon Nov 13, 2017 7:31 pm

Re: Programming a Lookup Table for Inflation Calendar on DM42

Post by DavidM » Tue Aug 28, 2018 3:33 pm

Actually, you only need a single column. The offset into the matrix infers which time period is applicable (either annual or monthly, depending on which data you want to use).

I've got a custom-built app for, uhm, "another calculator" that uses the same data from the same source (I use the annual averages instead of the monthly amounts to keep things simpler). The actual calculation is simple once you have the data stored. As you are wanting to use this as a self-imposed exercise, I'll refrain from being more specific. I will say, though, that there's no need to resort to TVM calculations for this application. The actual data presented by the BLS allows you to calculate growth rates with basic operations (+, -, *, /). I'm happy to elaborate on the calculation (as opposed to the DM-42 implementation) if needed, but don't want to spoil the fun of discovery unnecessarily.

grsbanks
Posts: 713
Joined: Tue Apr 25, 2017 9:23 am
Location: Preston, Lancs, UK

Re: Programming a Lookup Table for Inflation Calendar on DM42

Post by grsbanks » Tue Aug 28, 2018 6:36 pm

Indirect addressing will probably help you quite a bit here. It should make things easier for you than having to access the elements of a matrix, so I'll give you a few pointers here.

I would suggest that you store your data in registers numbered 100 and above. Say you're starting with data from 1900 for example. Register 100 (noted as R100) would contain the index for the year 1900, R101 for the year 1901, R102 for 1902 etc.

Now, to access registers indirectly and what this means....

Say you want to get at R20, you would simply key in:

Code: Select all

RCL 20
The exact same result would have been obtained if the number 20 was in R10 and you keyed in:

Code: Select all

RCL IND 10
What this basically means is, "Don't give me the contents of R10. Instead, give me the contents of the register whose number is in R10."

You need to use indirect addressing if you want to access registers with a number above 99 because the "RCL" command only waits for 2 digits afterwards. So, to get at R100 you'd have to do something like this:

Code: Select all

100
STO 00
RCL IND 00
Or, if you'd rather avoid using a register to point to the one that you want, you can use a stack register instead, like so:

Code: Select all

100
RCL IND ST X
What that second line says is, "Get me the contents of the register whose number is in the X register of the stack."

And this brings us round to a quick way to get hold of the data for a specific year using the mapping outlined earlier. If R100 is for 1900, R101 for 1901 etc., then all you have to do is subtract 1800 from the year and there you have the number of the register to recall:

Code: Select all

1800
-
RCL IND ST X
"IND" works with anything that expects a number or label. So you can do stuff like:

Code: Select all

STO IND 10
GTO IND 10
These lines mean "Store to contents of the X register into the register whose number is in R10" and "Go to the program label whose number (or alpha label, yes that works too) is in R10."

This is an indirect way of running a program called "MYPRG":

Code: Select all

"MYPRG"
ASTO 00
XEQ IND 00
I'm sure you can work the rest out :)
Not SwissMicros staff, just an enthusiast.

User avatar
akaTB
Posts: 215
Joined: Tue May 02, 2017 11:56 am

Re: Programming a Lookup Table for Inflation Calendar on DM42

Post by akaTB » Tue Aug 28, 2018 7:53 pm

grsbanks wrote:
Tue Aug 28, 2018 6:36 pm

Code: Select all

RCL 20
Another RCL 20, well worth reading. Lots of fun!

Image
Greetings,
    Massimo

-+×÷ ↔ left is right and right is wrong

Post Reply