Re: Derivates docs

Anthony wrote:-

1) Wouldn't it be simpler if time-to-expiry is given in years,
to be consistent with the annualization of the vol and the risk-free
rate - saves the usual 365/365.25 tedium.  Also the docs don't appear
to state the compounding assumption of the risk-free rate (I assume
it's annualized as well).

We discussed this, and it might be done for a future release.  The risk
free rate is continuous.

2) These ten funcs are often collapsed into one by many financial
spreadsheet libraries - they take a parameter "C" or "P" for the
option type and a string argument to specify the requested output.
(If the output argument is an array one can return various values
for the price of a single calculation - not too important for BS
since it's quick but it's a helpful style for more heavyweight stuff)
Also when one is sceptical about say the gamma you can change an
input cell to see the delta, not edit the function call also risking
that the signature is different.

Exactly; I suggested all this too.  I also suggested something that
no library I've ever seen provides - S for straddle.  So simple,
yet so annoying, if you're a trader, that it isn't provided.  Also,
functions to solve for forward price and vol.  I think this improved
function won't take a risk-free rate at all; it should take a
forward rate and return an undiscounted premium, IMO.

I hope to add these.

3) Spreadsheet gurus (wrong word, I really mean "nargs" but I suspect
it's a britishism) will often implement their own functions which
improve the builtin stuff.  The COUPNCD stuff I was just reading is
a prime example, and without disrespect to the B-S code referenced
here I might be doing the same.  I imagine this is quite common, so
that statistics nargs have their own regression functions
with extra bells and whisles and diagnostics and so on.  One issue
comes to mind: if I implement a function with the same name and
signature as a function in, can I have both
libraries loaded? I presume not?  If not, should I be able to,
calling derivatives::blaa or mylib::blaa explicitly? I'm
imagining the plugin manager could have a toggle to 'export' the
names into the unqualified namespace...

Dunno.  I reckon we should prefix all the non-Excel built-ins.  e.g.
calXXXX for calendar functions, optXXX for option-related stuff etc.
I think its cleaner to use like that, too.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]