Hi Tino, we are not ignoring this but are quite busy in the moment. It will take a while until we can take a closer look. On a first glance some pieces seems strange:   DEF_ARG_GREEK_FLAG. The description of this flag seems to collide with the description of the functions using that argument. You may want to be more specific of what this flag is doing. The concept of this flag does not seem to lend itself to internationalization: having specific strings as arguments can't be properly translated!

Hi, thanks, no problem. Ok I agree I need to rephrase the flag's description.
It basically means that each function which supports this flag can calculate
its own derivatives with respect to certain input parameters, e.g. "value"
will return f(...) and "delta" will return df(...,S,...)/dS.
It's important to have this inside the function itself or otherwise it would
require far too many functions exported to gnumeric. For example the current
implementation of opt_bs() has many accompanying functions which only
calculate derivatives of opt_bs():

 opt_bs_delta()    (d/dS)
 opt_bs_gamma()    (d^2/dS^2)
 opt_bs_theta()    (d/dt)
 opt_bs_vega()     (d/dvol)
 opt_bs_rho()      (d/dr)

They could all be part of opt_bs() if it had the "GREEK" flag. Btw, "Greek"
is just the word used in the financial literature to describe derivatives
due to the fact each particular partial derivative had been assigned a Greek
letter.
I think it'll be fine not to have "delta", "gamma", etc translated as these
words are fairly universal.

I'll get back with a patch once you had a closer look and probably found
more issues.

While you can obviously make a case for the 'greek' flag. It breaks consistency with such functions as opt_bs_*. Also the 'nearly universal' is questionable since we rare not really using the greek symbols bu there latin names. I would thin kfor example that in greek probably the letter symbol is used rather than the English transliteration. 

So we definitely prefer if you would change your functions into the same style as opt_bs_*.

This can certainly be done but I would caution against it as it would flood
gnumeric unnecessarily with loads of function names as well as code
duplication.
Not only would I have to add 20 instead of 4 functions (2*9 + 2*1, the 2
_prob_ functions don't have greeks), but also future as well as most of
the current functions could have _delta(), _gamma(), etc. as well.

To make it consistent with opt_bs() I'd recommend adding the 'greek' flag
as an optional parameter to opt_bs() and marking opt_bs_delta() etc as
depreciated.
Alternatively, we could discuss the naming of the new functions. My reason
for using the name opt_bs_barrier() for example was that it's an
option (and almost all functions in fn-derivatives start with opt),
it uses the Black-Scholes model as the underlying assumption and it's
a Barrier option. However, the _bs_ bit could be omitted as most of the
currently implemented functions are based on Black-Scholes model
assumptions but don't have _bs_ in the function name. So I guess, it would
be better to name the new functions opt_barrier(), opt_touch(),
opt_prob_hit() and opt_prob_inmoney().

As for the translation issues, whether you use opt_bs_delta(...) or
opt_bs(..., "delta") you still force "delta" on the user, or are you
translating function names as well? We could think of using a single
char input as is done with the (c)all/(p)ut flag. Unfortunately, we
get some collisions so I found having a string input to be the best.
One could also have integer inputs but I find this even worse.

my last comment seems to have not been added here...

20 instead of 4 functions isn't really an issue, IF we have an issue with users finding the right function we should rather provide a better interface there than overloading functions.

Selectors that are strings have created problems in the past (both for Gnumeric as well as for ODF).

In any case, it is impossible to depreciate spreadsheet functions. Once they are used inside a file, that file may exist in perpetuity.

There are plans to translate the function names. That is really not a big issue. The problems arise with string and other constants. So we will not add any more of those.

Function name wise we should keep any common prefix reasonably short, so opt_barrier_delta(), opt_touch(_delta), opt_prob_hit_delta() and opt_prob_inmoney_delta() etc. might be a good choice. (Long common prefixes make the function tooltip unnecessarily long and forces users to type more before they see the interesting function list. The current use of the opt_bs_ prefix is misleading anyways since that is used for some European Options
 functions only. Having a common opt_ prefix is useful to separate these functions from the other areas.

If done correctly there is really no reason for code duplication though. In fact the overall code could be shorter. (You can still have selectors inside the code if necessary that ideally would be enums.)

There has been some more e-mail discussion on this topic. To quote from Morten's e-mail:

----------------------
At the "Gnumeric" level, I do not like to see any argument that basically
is a large switch between fairly unrelated functions.  SUBTOTAL is a big
mess I don't like to see repeated.  Put another way, if one argument to a
function is always expected to be a constant -- not an expression -- picked
from a small set, then as a general guideline that constant should probably
be part of the function name, not an argument.  So,

    FOO_delta (...)
    FOO_theta (...)
----------------------

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnumeric/issues/201.