Re: [office-formula] Functions that need to be identified as TBD

[Eike Rathke <erack@sun.com>]

Hi David,

On Monday, 2006-09-11 18:10:45 -0400, David A. Wheeler wrote:

> First, there are the "_ADD" functions of OpenOffice.org; "_ADD" is a weird
> marker that OOo adds, saying "these are functions with Excel-compatible
> semantics that are DIFFERENT than the semantics of my functions without _ADD".

Well, actually the marker "_ADD" isn't that weird because it was used
for functions that were provided with the Excel Analysis AddIn (also
known as ToolPak).


> Also, as an illustration that things don't stand still, KOffice had earlier implemented
> an "EASTERSUNDAY(year)" function. OOo now sports a compatible one.

Erm.. OOo respectively StarOffice have that since 1999.

> This function may be a challenge. On the one hand, if you need it you REALLY need
> it (it's very difficult to do without if you need it).
> On the other hand, it's obviously related to
> a religious date (and to a particular group's definition - Roman Catholics and
> Protestants would find it useful directly, but Orthodox Christians
> would expect a different value).  Many may be more comfortable if we find
> a way to incorporate many important dates (of many religions/cultures), yet
> we don't want to create a new nonstandard mechanism for doing so.
> We may want to punt on this one for now; comments?

I'd include EASTERSUNDAY though, it is a very commonly used date at
least in Christian influenced countries and there are at least two
applications supporting the function. Further calculations of religious
dates could be provided by AddIn functions that are not to be specified
here and now.


> Consider adding EUROCONVERT (and compare to OOo's CONVERT).

Note that OOo's CONVERT is not only about Euro conversion, the factors
are drawn from configuration entries and may include almost arbitrary
conversion factors.

> The Euro is here (surprise!), but it's still useful for long-term financial
> instruments. But I just need to know if there's enough reason to
> include it in the spec itself.
> 
> We've "stolen" Gnumeric's bit operations, but they do not have
> BITNOT(x;bits) or BITNEGATION(x;bits) (two's complement) functions.
> These functions CAN be implemented using BITXOR, though with a little pain.
> Anyone want to pitch for additional functions directly?

Maybe there is a reason that they're not implemented in Gnumeric?


> Here's what I propose, as a starting point:
> * Use "WEEKNUM" for the Excel semantics function, and add a function
>    "ISOWEEKNUM" for the ISO semantics.  Both KSpread and Gnumeric already
>    use "ISOWEEKNUM" as the name of the ISO-implementing function.
>    Implementations can tell the difference, btw - if a formula starts with "oooc:"
>    it could map functions differently than if "=" is the beginning value).

Sigh.. ok, another one to map.

> * OOo's "ERRORTYPE" produces values that really only make sense to OOo, so
>    I propose that it NOT be in the spec - OOo can save it as ORG.OPENOFFICE.ERRORTYPE.
>    The function "ERROR.TYPE()" would stay in the standard and be the portable
>    way to query (ERROR.TYPE maps the Error into a short list of integers - but
>    there's no requirement that the list of Errors ACTUALLY be that list).

Makes sense.

> * For CONVERT_ADD, CUMIPMT_ADD, CUMPRINC_ADD, DURATION_ADD,
>    EFFECT_ADD, NOMINAL_ADD, GCD_ADD, ISEVEN_ADD, ISODD_ADD, LCM_ADD:
>    define functions without the "_ADD" with Excel semantics, and have "_OOO"
>    functions with the OOo semantics, e.g., "DURATION" vs. "DURATION_OOO".
>    The "_OOO" naming convention is lousy; it's more
>    of a placeholder so that we can differentiate the functions.  Suggestions?

I'd rather rename _ADD to _XL and keep the names without _ADD as they
are.

>    Many of these (GCD_ADD, ISEVEN_ADD, ISODD_ADD, LCM_ADD) are trivially
>    different - should these be implementation-defined (and NOT separate functions)?

The _ADD functions exist only because there was one implementation
defining them, and they were implemented to follow this one
implementation. I think it doesn't make sense to have these as
implementation defined.

>    Should these just be application-specific functions when exchanged?
>    We need to compare CONVERT_OOO and EUROCONVERT as well.

They are different in functionality. EUROCONVERT is just that, plus
triangulation and rounding. CONVERT_OOO is more like CONVERT_ADD but
without hard-coded factors, though also without the automatic unit
abbreviation prefixes.

> * Consider adding EUROCONVERT (and compare to CONVERT_OOO).
>    Obviously it's still useful for long-term financial instruments, so I just need to know
>    if there's enough reason to include it in the spec itself.

Probably yes.

> * No "EASTERSUNDAY" in the spec; use ORG.KOFFICE.EASTERSUNDAY() if you have it.
>    If there's a follow-on effort (there probably should be), revisit this.

Objection: if at all, use ORG.OPENOFFICE.EASTERSUNDAY instead. ;-)
I still don't see though why we shouldn't simply use EASTERSUNDAY.

  Eike

-- 
Automatic string conversions considered dangerous. They are the GOTO statements
of spreadsheets.  --Robert Weir on the OpenDocument formula subcommittee's list.