Re: opinions on additional calc functions

This UNO add-in thing turns out a bit too complex for me. I've managed
as far as getting a libpricinglo.so compiled but "make install"
doesn't copy it into destination. Also there's no entry of the new
add-in in services.rdb, which I think is needed. I've already modified

Repository.mk
scaddins/*.mk
postprocess/packcomponents/makefile.mk
solenv/gbuild/extensions/pre_MergedLibsList.mk

but I must be missing something?


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

The only function which is already in Gnumeric and I'm trying to
implement here is opt_bs() and I'll keep the parameters the same then.
Having 7-9 different functions may be ok if you only have one option
pricing function, but my plan is for 4 functions and I'm not going to
spam calc with 4*9=36 functions. :) 

I should say I'm also trying to add two pricing functions
(opt_barrier() and opt_touch()) in Gnumeric but I've not reached an
agreement with the developers on exactly this issue so it probably
will simply be implemented without the "Greek flag" (delta, gamma,
vega, etc).

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

No, that's right, but that would explode the number of functions
unnecessarily. If string inputs are a big problem then I'd rather go
for char inputs (or even int as a last resort).

Cheers, Tino