Hi tino, On Wednesday, 2012-11-28 11:45:50 +0000, tino wrote:
I'm new to libreoffice dev and I'm working on implementing some additional financial (option pricing) functions for calc. So far I've used ./core/scaddins/source/analysis/ locally to add my functions but I've been told scaddins is mainly for ms excel functions and ./core/sc/ is certainly not the right place. So I'd need some advice where to place the new 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
Also, any opinions on naming and parameter inputs are welcome. The functions in question return prices and greeks (partial derivatives of the price to certain input values) of some basic financial options, all using the classic Black-Scholes model. OPT_BS(...): option price of a put/call option OPT_DIGITAL(...): option price of a digital/binary option OPT_BARRIER(...): barrier options (=put/call with barriers) OPT_TOUCH(...): touch/no-touch options (=digitals with barriers) ... I've modelled the names on what is implemented in Gnumeric which has a range of opt_foo(...) functions.
I'm lost here.. I have no idea what these functions would do, financial isn't my domain. Regarding naming of functions, it should be sensible, and if there are already other implementations using the same names may help users in finding the functions they want. Btw, if Gnumeric already has them, how does it write them to ODF? We should do the same for interoperability.
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.
I've attached a code snipped of OPT_BARRIER(...) interface
implementation.
[...]
if(str.compareToAscii("value")==0 || str.compareToAscii("price")==0 ) {
greek=bs::types::Value;
} else if(str.compareToAscii("delta")==0) {
greek=bs::types::Delta;
} else if(str.compareToAscii("gamma")==0) {
greek=bs::types::Gamma;
} else if(str.compareToAscii("theta")==0) {
greek=bs::types::Theta;
} else if(str.compareToAscii("vega")==0) {
greek=bs::types::Vega;
} else if(str.compareToAscii("volga")==0) {
greek=bs::types::Volga;
} else if(str.compareToAscii("vanna")==0) {
greek=bs::types::Vanna;
} else if(str.compareToAscii("rho")==0) {
greek=bs::types::Rho_d;
} else if(str.compareToAscii("rhof")==0) {
greek=bs::types::Rho_f;
} else {
return false;
}
That is ugly, isn't it? ;-) Eike -- LibreOffice Calc developer. Number formatter stricken i18n transpositionizer. GnuPG key 0x293C05FD : 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD Support the FSFE, care about Free Software! https://fsfe.org/support/?erack
Attachment:
pgpyyChTsiF1K.pgp
Description: PGP signature