opinions on additional calc functions

Eike Rathke erack at redhat.com
Thu Nov 29 09:21:46 PST 2012


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20121129/b40e5ece/attachment.pgp>


More information about the LibreOffice mailing list