Re: opinions on additional calc functions

Hi tino,

On Thursday, 2012-11-29 18:32:26 +0000, tino wrote:

> > 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.

Great :-)

> 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?

Please abandon it, there's an Abandon Change button if you logged in.


> > 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];...

Ah, that's what I hoped for :-)  we should do the same then.


> > > 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).

Given that Gnumeric already implemented or will implement the functions
I would strictly follow them for interoperability. You can have the
7 different functions at formula level and still internally have them
call one function with an enum, or however you would like to implement
it. Doing things differently doesn't help users.

> If there are no strong objections, I'd
> prefer to go with char/string inputs or anything which is more
> intuitive for the user?

I don't see that specifying a parameter with the name is more intuitive
than using a function with the same name appended. To the contrary,
function names can be localized while string arguments can't.

  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: pgpzjZoV8FoIj.pgp
Description: PGP signature