opinions on additional calc functions
Eike Rathke
erack at redhat.com
Thu Nov 29 12:40:20 PST 2012
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
-------------- 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/d5489056/attachment.pgp>
More information about the LibreOffice
mailing list