Looking for TVM contributions
|
05-24-2024, 02:20 PM
(This post was last modified: 05-24-2024 04:01 PM by SlideRule.)
Post: #21
|
|||
|
|||
RE: Looking for TVM contributions
Are you familiar with the following publication, Time, Value, Money: applications on the TI-83, EXPLORATIONS, by Texas Instruments?
BEST! SlideRule |
|||
05-24-2024, 02:58 PM
Post: #22
|
|||
|
|||
RE: Looking for TVM contributions | |||
05-24-2024, 03:04 PM
Post: #23
|
|||
|
|||
RE: Looking for TVM contributions
(05-15-2024 12:57 PM)dm319 Wrote: I had a go last night adapting the plus42 code into R and using the Rmpfr package which has arbitrary precision ... Plus42 algorithm to check Plus42 may not show numbers are accurate. Unless, of course, Rmpfr setup with much higher precisions to compensate. For better accuracy, we may apply time-symmetry. Plus42 core_commands9.cc Code: do_pv(): expm1(-n*log1p(i)) == (1+i)^-n - 1 The problem is with positive (n*i), and |n| is huge, expression approaches -1. Numerically, there are only so many representable numbers between -0.9 to -1.0 lua> expm1(-30), expm1(30) -0.9999999999999064 10686474581523.463 We may use time symmetry, turned n to -n: {n,i,pv,pmt,fv} --> {-n,i,fv,-pmt,pv} fv = -(-pmt * (-expm1(n * log1p(i)) / i) + pv * exp(n * log1p(i))) pv = -(fv - pmt * (-expm1(n * log1p(i)) / i)) / exp(n * log1p(i)) Plus42 core_commands9.cc Code: do_n(): do_n() is better if |fv| is small (best if fv=0) do_i_pct_yr() and do_pmt() is better if |pv| is small. (best if pv=0) Apply time-symmetry to reduce cancellation errors, we get tvm(n,i,pv,pmt,fv), and tvm_begin(n,i,pv,pmt,fv) |
|||
05-24-2024, 04:09 PM
Post: #24
|
|||
|
|||
RE: Looking for TVM contributions
(05-24-2024 02:58 PM)dm319 Wrote: … have a link? Time, Value, Money: applications on the TI-83 BEST! SlideRule ps: revised original post w/ url |
|||
05-24-2024, 09:22 PM
Post: #25
|
|||
|
|||
RE: Looking for TVM contributions | |||
05-24-2024, 10:05 PM
Post: #26
|
|||
|
|||
RE: Looking for TVM contributions
(05-24-2024 03:04 PM)Albert Chan Wrote: Plus42 algorithm to check Plus42 may not show numbers are accurate. Yes, throwing all the digits at it! And requiring the solver to reach the current precision, so I think it's fairly trustworthy for i. Though there's a question for you further down... (05-24-2024 03:04 PM)Albert Chan Wrote: Apply time-symmetry to reduce cancellation errors Thank you Albert. As usual, it will take me several months before I start to understand this. However, this makes more sense now, as I couldn't understand why the plus42 code didn't have p in the equation. But sounds like you are inverting time to work this out? Clever! I'm trying to work out how accurate plus42 and my solver is for this problem: do_n(I%YR = 25%, PV = -100000, PMT = 2083.333334, FV = 0, p = 0) and this one: do_n(I%YR = 25%, PV = -100000, PMT = 2040.816327, FV = 0, p = 1) Just curious what you would calculate the accuracy of plus42 for this? I'm using a lot of digits in R, but this one is more discrepant that usual. |
|||
05-24-2024, 11:50 PM
Post: #27
|
|||
|
|||
RE: Looking for TVM contributions
Business Interest Calculations is another significant source for TVM solutions on the HP-12C programmable calculator.
BEST! SlideRule |
|||
05-25-2024, 01:09 AM
Post: #28
|
|||
|
|||
RE: Looking for TVM contributions
(05-24-2024 10:05 PM)dm319 Wrote: do_n(I%YR = 25%, PV = -100000, PMT = 2083.333334, FV = 0, p = 0) lua> i,pv,pmt,fv = .25/12, -1e5, 2083.333334, 0 lua> -(pv + fv) / (fv*i - pmt) * i -0.99999999968 lua> -log1p(_) / log1p(i) -- do_n() 1060.303385972225 We avoided cancellation error, (fv*i - pmt) = -pmt, but it had to calculate -log1p(-1 + ε) lua> pv*i, pmt -2083.333333333333 2083.333334 lua> pv*i + pmt 6.666668923571706e-07 lua> -(pv + fv) / _ * i 3124998942.076121 lua> log1p(_) / log1p(i) -- do_n(), time-symmetric version 1060.3033735821105 If we apply time symmetry, -log1p(-1+ε) issue goes away. However, (pv*i + pmt) denominator had massive cancellation! Let's scale money by 3e6, to avoid massive cancellation error (we work with integers, to avoid lua dec↔bin conversion error) lua> pv,pmt = pv * 3e6, pmt * 3e6 lua> pv*i + pmt 2 lua> -(pv + fv) / _ * i 3.125e+09 lua> log1p(_) / log1p(i) -- do_n() 1060.30339000051 Plus42: 3.125E9 LN1+X .25 Enter 12 ÷ LN1+X ÷ 1,060.303390000510007127328529884891 Quote:I couldn't understand why the plus42 code didn't have p in the equation. No, not time-symmetry. p=1 get transformed to p=0, thus not in tvm formula. (see tvm_begin()) For this problem, we have exactly the same issue. Again, scale money by 3e6, to avoid cancellation errors. lua> pmt = 2040.816327 * 3e6 lua> pv, fv = pv+pmt, fv-pmt -- do_n(), p=0 lua> pv, pmt, fv -293749999998 6250000002 -6250000002 lua> pv*i + pmt -- = 23 / 16 1.4375 lua> -(pv + fv) / _ * i -- = 1e11 / 23 4347826086.956522 lua> log1p(_) / log1p(i) -- do_n() 1076.3195443677068 Plus42 : 1E11 Enter 23 ÷ LN1+X .25 Enter 12 ÷ LN1+X ÷ 1,076.319544367706646435106131044347 |
|||
05-25-2024, 01:43 PM
Post: #29
|
|||
|
|||
RE: Looking for TVM contributions
(05-25-2024 01:09 AM)Albert Chan Wrote: Let's scale money by 3e6, to avoid massive cancellation error This makes me despair!! So sadly my compensating for my lack of mathematical knowledge with increasing precision, is not working out for me: Code:
both of these give me: Code:
Which appears to be wrong! And this is because of bin vs floating point? Doing this: Code: # puzzle 9 yields this: Code:
Which is closer to the plus42/nstk tvm result, and which sounds like is the correct one. But I thought you could compensate for binary calculations by using more precision no? |
|||
05-25-2024, 03:04 PM
Post: #30
|
|||
|
|||
RE: Looking for TVM contributions
(05-25-2024 01:43 PM)dm319 Wrote: pmt <- mpfr(2083.333334,precision) pmt turned float (53 bits precision), then mpfr. It should be quoted. p2> from gmpy2 import * p2> get_context().precision = 113 # binary128 p2> i = mpfr(25) / 1200 p2> pv = mpfr(-1e5) p2> pmt = mpfr('2083.333334') p2> fv = mpfr(0) p2> -log1p(-(pv + fv) / (fv - (pmt / i))) / log1p(i) mpfr('1060.30339000051000712732851994886109',113) p2> log1p(-(pv + fv) / (pv + (pmt / i))) / log1p(i) mpfr('1060.30339000051000712732851861304841',113) Scale by million, to work with integer. p2> pv *= 1e6 p2> pmt = rint(pmt * 1e6) # pmt rounded to integer p2> log1p(-(pv + fv) / (pv + (pmt / i))) / log1p(i) mpfr('1060.30339000051000712732852988489078',113) |
|||
05-25-2024, 08:40 PM
Post: #31
|
|||
|
|||
RE: Looking for TVM contributions
(05-25-2024 03:04 PM)Albert Chan Wrote: pmt turned float (53 bits precision), then mpfr. It should be quoted. Oh my that makes sense! I checked the representation of 2083.333334 and the 64bit representation comes to 2.08333333399999992252560332417E3. The risks of using a library I'm completely unfamiliar with! |
|||
06-02-2024, 02:46 PM
Post: #32
|
|||
|
|||
RE: Looking for TVM contributions
(05-24-2024 11:50 PM)SlideRule Wrote: Business Interest Calculations is another significant source for TVM solutions on the HP-12C programmable calculator. Thank you for sharing this, I've been reading through it - it's a very good read. Doesn't assume any basics but can quickly escalate to quite complicated problems (including the difficulties in solving for i). |
|||
06-09-2024, 02:04 AM
Post: #33
|
|||
|
|||
RE: Looking for TVM contributions
Data for my wife's Ti BA II Plus and a Sharp EL-735 in my collection.
Code: | # | Ref | N | I%YR | PV | PMT | FV | P/YR | End | Results for the secant solver on Sharp and in C are forthcoming, after I verified it with more experiments. I may also elect to improve it a bit more. - Rob "I count on old friends to remain rational" |
|||
06-09-2024, 12:15 PM
Post: #34
|
|||
|
|||
RE: Looking for TVM contributions
(06-09-2024 02:04 AM)robve Wrote: - Rob Thank you Rob! This is great, and two interesting non-HP calculators too. Very interesting that the TI returns for problems 5 and 6, much like the solver in the TI-83+, also choosing to return the same two roots (first one 14.4, second one the negative root). Which suggests to me they use a similar solver_for_i algorithm, but the precision is quite different between them. Overall the TI does very well, putting it squarely better than the HP-12c. Overall I put it at a similar level to the HP-10bII+ (due to adding new problems I don't have full data on the HP-10bII+) and just below the HP-12c platinum, but with quite different pros and cons. The Sharp does especially badly on problem 3, which suggests it hasn't optimised the (1+i)^N - an issue on the HP-80 and HP-70. It conveniently finds 0 for problem 4, but like other ones that do this (like the BWK business and HP-92) it also finds 0 for problem 7 unfortunately. Problem 9 and 10 showed a good result with 9, but not the 'begin' counterpart 10. I had this issue with a particular formula on the DM42. It doesn't fair so well on your problem 11 - putting it above the HP-80 and 70 only. Overall I have put it above the HP-22/27, below the HP-37/38, and just below the Victor (though more data needed on the Victor). I will update the results with these two. |
|||
06-09-2024, 03:29 PM
Post: #35
|
|||
|
|||
RE: Looking for TVM contributions
(06-09-2024 12:15 PM)dm319 Wrote: I will update the results with these two. FYI to compare age. The Sharp is vintage from 1989 or about, a successor to the popular EL-733. They are similar, except that the EL-735 has more memory and a "database". The EL-735 is very easy to use with a well-thought through keypad layout like the 733, much easier than the new TI BA series. In my view, the Sharp is also one of the nicest looking machines in metal with distinguishable color keys and labels. But that's secondary. - Rob "I count on old friends to remain rational" |
|||
06-09-2024, 06:05 PM
Post: #36
|
|||
|
|||
RE: Looking for TVM contributions
Ah thank you Rob, I found it hard to find the date of the Sharp.
I can see they both have the n/i/pv/pmt/fv keys in that order (I guess established from the HP-37E onwards). In terms of UI - do they work in the same way as the HPs, in that a second consecutive press of those buttons triggers a 'solve'. The solver built into the HP-83+ is a right pain to use. It is set out like a table, then you use alpha-solve to solve for a specific value. You can calculate in-place (i.e. you can put 24x60x365 as input), but there isn't an intuitive way to do chain calculations on it. I.e. problem 2 is not fun to calculate as it needs constant to and fro-ing out of the application to the 'calculator' and back again. Always had a fondness for Sharps - probably because that was my first one in a school that was 99% Casio. |
|||
06-09-2024, 10:00 PM
(This post was last modified: 06-09-2024 10:05 PM by dm319.)
Post: #37
|
|||
|
|||
RE: Looking for TVM contributions
These are the latest results:
Code: | calculator | manufacturer | year | ref | 1 | 1b | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | I was pondering the different strengths and weaknesses of the calculators - when you look through the results you start to get a feel for which calculators are similar and different to each other. It reminded me of some analyses I've carried out on high dimensional data. To be honest what follows is overkill, but it is interesting as long as the data isn't over-interpreted. Method: The above table, I switched all -Inf to -50, and all ERR to 10. NAs were then filled by random forest imputations, a small amount of noise was added, and each calculator was dimension-reduced using tSNE (T-test stochastic neighbour embedding). My understanding of this algorithm is that it looks at the probabilities of the calculator in relation to the density of other calculators, and tries to match this from the high dimensional environment to a 2d environment. It doesn't work that well for low numbers, and actually, I probably should have just used PCA. But it is done now and I have a plot. Ignore the x and y axis, and ignore overall distance or position. The only useful information is that close together calculators performed similarly. Enjoy! |
|||
06-12-2024, 08:48 PM
Post: #38
|
|||
|
|||
RE: Looking for TVM contributions
Results for the SHARP PC-1421 on an emulator (PockEmul). I trust the emulator is identical to the real metal, because it uses the original ROM with an emulated CPU.
Oof, this is interesting. It's not as good as the SHARP EL-735 results (1 1b 2 3 8 12) and even has some buggy output (4 5 6 11). Note that result 9 is the same as my SHARP program result. These test cases aren't vanilla TVM, but still disappointing and shows that rate solvers aren't created the same. Code: | # | Ref | N | I%YR | PV | PMT | FV | P/YR | End | - Rob "I count on old friends to remain rational" |
|||
06-12-2024, 11:56 PM
Post: #39
|
|||
|
|||
RE: Looking for TVM contributions
Very interesting! Weird how they can be similar and so different, and what is going on with 11?!
The TVM program does very well on 3, much better than the calculators. 6 is a surprise result from PC-1421, 9 and 10 oddly best result with the 735. 11 is disaster for PC-1421, great result from the TVM program. I've updated all results here: https://forum.swissmicros.com/viewtopic....400#p32400 There are now a couple of graphs at the end just for fun. |
|||
06-13-2024, 09:28 PM
(This post was last modified: 06-25-2024 10:32 PM by Albert Chan.)
Post: #40
|
|||
|
|||
RE: Looking for TVM contributions
(06-12-2024 08:48 PM)robve Wrote: | 11 | robve | 60x24x365 | 1/6% → ? | 0 | -0.01 | ?→ FV | =N | yes | (06-12-2024 11:56 PM)dm319 Wrote: Very interesting! Weird how they can be similar and so different, and what is going on with 11?! Initial guess (hard coded?) may be too high for the problem. Edge guess is not the best, but will converge without issue. Plus42 does not allow user-input rate guess on purpose! lua> n = 365*24*60 -- = 525600 lua> i = 1/(600*n) -- = 3.1709791983764586e-09 lua> fv = tvm(n,i,0,-1,nil) lua> fv -- unit = cents 526038.2426000326 lua> tvm(n,nil,0,-1,fv) * n -- APR 0.0016666666666665247 Or, we can use a quickie formula (04-09-2022 05:47 PM)Albert Chan Wrote: \(\displaystyle I ≈ \frac{1}{P} - \frac{P}{N^2}\) P = -PV/PMT, so we apply time reversal, to FV/PMT. (negated N make no difference here) 1/P is edge rate, time reversal simply switched to other edge. lua> p = -fv lua> n/p - p/n -- APR estimate 0.001666895167500626 What if we supply a guess, say 0.1% ? lua> tvm(n,1e-3,0,-1,fv, true) 0.001 -1 -5.137033888903107e+219 -nan -nan -nan false Why does it fail? Because we use Newton's method from the wrong edge! The other edge = pmt/-pv = ∞, but 1e-3 is just as bad. (technically, ∞ is not an edge) (06-11-2024 03:32 PM)Albert Chan Wrote: For extreme rate, npmt(i) is basically linear, slope = (pv if n>0 else -fv) With pv=0, npmt(i) look like L shape. Guess must be from the left of L tvm() rate guess = pmt/fv ≈ -2e-6 For plots, I dropped fractional cents --> fv = 526038 This is what npmt look like from the left, and the right npmt = ((pv+fv)/((1+x)^n-1) + pv)*x + pmt plot 526038*x/((1+x)^525600-1)-1, x=-2e-6 .. 2e-6 plot 526038*x/((1+x)^525600-1)-1, x = 0 .. 1e-3 NPV is not the same as npmt, but same kind of issue apply. NPV = (fv-pmt/x) * ((1+x)^-n-1) + (pv+fv) plot (526038+1/x) * ((1+x)^-525600-1) + 526038, x = -2e-6 .. 2e-6 plot (526038+1/x) * ((1+x)^-525600-1) + 526038, x = 0 .. 1e-3 |
|||
« Next Oldest | Next Newest »
|
User(s) browsing this thread: 12 Guest(s)