Re: opinions on additional calc functions

> I suggest to open a new directory under scaddins/source, e.g.
> scaddins/source/pricing (or scaddins/source/financial if you plan to add
> other functionality than pricing) and create a new Add-In, for a simple
> approach how to create an Add-In see scaddins/source/datefunc

Ok, will do. I've already submitted a patch which placed everything
under scaddins/source/analysis (the one where you pointed out the
error with commit-msg). Do I need to delete this patch or can I just
leave it on gerrit?

> Btw, if Gnumeric already has them, how does it write them to ODF? We
> should do the same for interoperability.

Within content.xml it writes something like

 <table:... table:formula="of:=[.E$9]*ORG.GNUMERIC.OPT_BS([.E$8];...

> > As for parameters they are mainly of double type but some are of enum
> > type. The enums could be mapped to integers but I've a slight
> > preference for STRING inputs but not sure how that is viewed here with
> > regard to localisation? E.g. I'm currently using "p" to specify a put
> > and "c" for a call, and "i" for in, "o" for out, and "delta" for delta
> > (d/dS), "gamma" for gamma (d^2/dS^2), etc.
>
> Constant string arguments to functions MUST NOT be localized. I'd rather
> use integers there, so no one can complain about unlocalized terms.
> Which also eliminates the need of cascaded if(){}else if(){}else if(){}
> ... chains with slow string comparisons and use switch case statements
> instead.

What I like about the char/string inputs is that they are descriptive.
Integers are much less intuitive to the user. Gnumeric currently
implements "p"/"c" inputs but they are strongly opposed to "delta",
"gamma", etc and move them into the function names, e.g.
opt_bs_delta(), opt_bs_gamma() and so have 7 instead of one function
(something I won't repeat). If there are no strong objections, I'd
prefer to go with char/string inputs or anything which is more
intuitive for the user?

Thanks, Tino