▼
Posts: 90
Threads: 22
Joined: Jun 2005
Well, since L() and G() won't work on the new 17bII+ ROMs I decided to take a chance on the program size limitation being solved. NO SUCH LUCK! The more accurate 5th order polynomial approximation implementation can calculate the first half correctly, but returns CALLV=0 after about 70 characters into the second half.
This behavior seems similar to the L() and G() problem where G() seems to just return 0, no matter what. The Solver also seems to return 0, instead of an error, when a certain program size is exceeded.
I'm including my BlackScholes program below for those masochists interested in entering it into their own 17bII+'s as an exercise. If you delete the entire second half, you'll get PS*N(d1) for CALLV, so for HP's example
PS=52
PE=45
RF%= 0.5
T=6
S=.2054
CALLV = 37.713812252994
Bob Wang
BlackScholes using 5th Order Polynomial Approximation
BLK.SCHLS.5TH:
0×(PS+PE+RF%+T+S)
+PS×ABS(
IF((LN(PS÷PE)+(RF%÷100+S^2÷2)×T)÷S÷SQRT(T)<0:0:1)
+((((1.061405429
÷(1+.2316419×ABS((LN(PS÷PE)+(RF%÷100+S^2÷2)×T)÷S÷SQRT(T)))1.453152027)
÷(1+.2316419×ABS((LN(PS÷PE)+(RF%÷100+S^2÷2)×T)÷S÷SQRT(T)))+1.421413741)
÷(1+.2316419×ABS((LN(PS÷PE)+(RF%÷100+S^2÷2)×T)÷S÷SQRT(T))).284496736)
÷(1+.2316419×ABS((LN(PS÷PE)+(RF%÷100+S^2÷2)×T)÷S÷SQRT(T)))+.254829592)
÷(1+.2316419×ABS((LN(PS÷PE)+(RF%÷100+S^2÷2)×T)÷S÷SQRT(T)))
×EXP(((LN(PS÷PE)+(RF%÷100+S^2÷2)×T)÷S÷SQRT(T))^2÷2)÷2)
–PE×EXP(RF%×T÷100)×ABS(
IF((LN(PS÷PE)+(RF%÷100+S^2÷2)×T)÷S÷SQRT(T)S×SQRT(T)<0:0:1)
+((((1.061405429
÷(1+.2316419×ABS((LN(PS÷PE)+(RF%÷100+S^2÷2)×T)÷S÷SQRT(T)S×SQRT(T)))1.453152027)
÷(1+.2316419×ABS((LN(PS÷PE)+(RF%÷100+S^2÷2)×T)÷S÷SQRT(T)S×SQRT(T)))+1.421413741)
÷(1+.2316419×ABS((LN(PS÷PE)+(RF%÷100+S^2÷2)×T)÷S÷SQRT(T)S×SQRT(T))).284496736)
÷(1+.2316419×ABS((LN(PS÷PE)+(RF%÷100+S^2÷2)×T)÷S÷SQRT(T)S×SQRT(T)))+.254829592)
÷(1+.2316419×ABS((LN(PS÷PE)+(RF%÷100+S^2÷2)×T)÷S÷SQRT(T)S×SQRT(T)))
×EXP(((LN(PS÷PE)+(RF%÷100+S^2÷2)×T)÷S÷SQRT(T)S×SQRT(T))^2÷2)÷2)
CALLV
▼
Posts: 1,755
Threads: 112
Joined: Jan 2005
Hi, Bob:
Too bad the 17BII+ is giving you such a headache.
Implementing BlackScholes in other HP models can be very
easy, like this very simple code of mine for the HP71B,
which uses a different polynomial approximation. Perhaps
you can use this polynomial instead of yours, to try and
fit the expression in your own machine:
>list
10 INPUT " Current price PS= ";P
20 INPUT "Exercise price PE= ";X
30 INPUT "Risk free rate RF= ";R
40 INPUT "Term of option T = ";T
50 INPUT " Volatility S = ";S
60 PRINT @ R=R/100 @ D1=(LN(P/X)+R*T)/(S*SQR(T))+S*SQR(T)/2 @ D2=D1S*SQR(T)
70 C=P*FNN(D1)EXP(R*T)*X*FNN(D2) @ PRINT " Call Value CV=";C @ END
80 DEF FNN(D) @ N=.5*(1+.196854*D+.115194*D^2+.000344*D^3+.019527*D^4)^(4)
90 IF X<0 THEN FNN=N ELSE FNN=1N
Let's run your own example:
>RUN
Current price PS= 52
Exercise price PE= 45
Risk free rate RF= 0.5
Term of option T = 6
Volatility S = .2054
Call Value CV= 14.2383025355
and the first term is:
>P*FNN(D1)
37.7232626591
more or less in accordance with your result. The corresponding program code for most any vintage
SHARP handheld (the PC1350 for example) is:
100 "S" CLEAR: INPUT "Current price P=";P
102 INPUT "Risk free rate R=";R
104 INPUT "Volatility S=";S
106 INPUT "Term of option T=";T
108 INPUT "Exercise price X=";X
110 D1=(LN(P/X)+R*T)/(S*SQR(T))+S*SQR(T)/2, D2=D1S*SQR(T)
120 D=D1: GOSUB "N": N1=N, D=D2: GOSUB "N": N2=N, CV=P*N1EXP(R*T)*X*N2
130 PRINT "Call Value=";CV: END
140 "N" N=1.5*(1+.196854*D+.115194*D^2+.000344*D^3+.019527*D^4)^4
150 IF X<0 LET N=1N
160 RETURN
Best regards from V.
▼
Posts: 536
Threads: 56
Joined: Jul 2005
hey valentin,
bob’s program uses hasting approx whose error is bounded by 7.5e8, but yours is bounded by 2.5e4. you could get better accuracy (but still less than bob) with a shorter approximation, thus:
UTPN(x) = exp(x*x/24*x/(x/.85+5))/2
error bounded by 9.2e5.
▼
Posts: 1,755
Threads: 112
Joined: Jan 2005
Thank, Hugh, but come to that I could simply use the INTEGRAL keyword and have a relative error of 1.E12 or
so, i.e., nearly full machine precision.
I refrained from doing so as I guess the 17BII+ doesn't
have the INTEGRAL functionality (not to mention the
SHARPs or most BASIC dialects). The idea was to provide
a shorter (if less accurate) formula that perhaps would
do where the longer, more accurate one wouldn't.
Thanks again and best regards from V.
▼
Posts: 536
Threads: 56
Joined: Jul 2005
indeed, and this is a peeve i have with hp’s latest models.
these days, if you’re going to market a professional financial model, it should already have black scholes, utpn, erf, and others together with their inverses to full precision. why not?
is the 17bi++ a rom emulation of the old 17bii (if so, why doesn’t l() & g() work properly) or is it a remake like the 12cp?
if a rom emulation, surely you could add new codes that map into new features, if not, then there’s no excuse not to add the new features.
or is it simply, that the model was completely engineered outside hp and the 17bii was given as a “specification” for the new model?
▼
Posts: 673
Threads: 20
Joined: Oct 2008
I shouldn't bother to rant and rave, but I get so fed up with Hp incompetence in their designs and screw ups!
First you have a bunch of whipped puppies left, if you speak out, Carly's henchmen will hunt you down and find a Compaq drone to replace you with. (a side note here, HP bought Compaq, not the other way around, but guess who lost their jobs, except for Carly. This is easily verified, many Hp execs were replaced with their Compaq counterparts.)
Not that Hp marketing was a whole lot better when they were in charge either.
Today, Hp could make the Hp17Bii+ with buried trig functions (or just toss in the Hp42s with a replacable face plate like the Hp30s) and toggle it between modes. Give it a USB or RS 232 port (I prefer RS 232), and sell it for $100 (same price as an Hp48Gii, which is what the Hp17Bii+ actually does sell for).
But a calculator like that would ROB sales from their graphics line ( I suspect the thought of robbing sales from Ti's graphics line doesn't even come up).
I stand upon this mountain (I am fanatasizing again) and shout, "HP, YOU ARE A BUNCH OF MORONS!"
I don't think they care, or they may even be laughing at the Hp calculator zealot that I am.
I end another RANT!
Posts: 1,755
Threads: 112
Joined: Jan 2005
Hi again, Hugh:
"these days, if you’re going to market a professional financial model, it should already have black scholes, utpn, erf, and others
together with their inverses to full precision. why not?"
Indeed. But nobody cares at KinHPo.
"is the 17bi++ a rom emulation of the old 17bii (if so, why doesn’t l() & g() work properly) or is it a remake like the 12cp?"
I daresay it's a (bad) remake.
"if a rom emulation, surely you could add new codes that map into new features, if not, then there’s no excuse not to add the new features."
Again true. But nobody cares at KinHPo.
"or is it simply, that the model was completely engineered outside hp and the 17bii was given as a “specification” for the new model?"
Most probable. But nobody cares at KinHPo. If someone did, the 33S wouldn't have an antiergonomic key layout, poor display and invisible decimal point, nor would it have nearly 32 Kb of unusable RAM, nor would it fail miserably when doing some essential mathematical operations. The HP12C Platinum wouldn't have a subpar, "pessimized" algorithm to compute the IRR, nor would it have the serious GOTO bug which makes it very difficult to use the 400steps RAM for long programs, nor ...
But who cares ? Who's counting ? Everyone has their own interests and I couldn't be less interested in the latest KinHPo crap. This is a "Museum of HP", so theoretically devoted to the awesome models of old, and as long as I do have a functioning, physical HP15C, HP41CX, HP42S, or HP71B (to name a few, let alone my SHARPs), and a wonderful site dedicated to them such as this, who cares what KinHPo does or doesn't do ? They are NONEXISTENT to me.
Best regards from V.
Posts: 111
Threads: 19
Joined: Jan 1970
Hi Hugh,
Quote:
UTPN(x) = exp(x*x/24*x/(x/.85+5))/2
error bounded by 9.2e5.
That is indeed a good approximation to UTPN(x) for x>=0.
The absolute error bound is [9.14e5, 5.62e5].
I'm curious if you saw this in an HPCC DataFile article
(V23N3p25) about Peter Carr's BlackScholes program for the
HP12C, or did you find it elsewhere?
Review of Peter Carr's HP12C
BlackScholes
Tony
▼
Posts: 536
Threads: 56
Joined: Jul 2005
yes, i confess. i did get this from datafile.
i remember reading this in issue v23n3 from last june and being impressed by the derenzo formula for Q. in the past, i have played with many approximations to this function, but none of these have ever been interested in making the coefficients shorter (ie for calculator programming) which is why the derenzo formula is so elegant.
i am also intrigued by the hp32e’s ability to get full 10 digit accuracy for both is Q and inverse Q functions. i wonder what approximation it uses. whatever it does, its good at it.
▼
Posts: 111
Threads: 19
Joined: Jan 1970
Ah I should have guessed  now I see you in the HPCC MemberPack :). I have Stephen Derenzo's original paper. Brilliant piece of work, and what Peter Carr did with the Q was most ingenious  and stimulated by the challenge of just fitting something reasonable in the HP12C.
▼
Posts: 536
Threads: 56
Joined: Jul 2005
its probably the best use of the 12c program memory ever.
