Re: [office-formula] Proposal: Move some functions between groups

["David A. Wheeler" <dwheeler@dwheeler.com>]

Eike proposed the following. I agree with all his suggestions
except for ROMAN (I believe we should leave it in its current grouping):

> From the Medium group to the Small group:
> 
> - LOOKUP
>   This complements the MATCH, HLOOKUP and VLOOKUP functions already in
>   the Small group.

I believe this was only because SheetToGo didn't include LOOKUP.
I have no strong objections to moving LOOKUP to the Small group, and
it has the advantage that this means more people can depend on LOOKUP.
Unless someone objects, let's change its grouping.

> From the Large group to the Medium group:
> 
> - ACOT, ACOTH, COT, COTH
>   Why have these in Large while SIN, SINH, TAN, TANH are in Medium? Is
>   this only because of Excel not having them?

Correct.  And you're right, it's rather inconsistent to NOT include COT's
variations while including SIN, SINH, etc.  It's not that hard to
rewrite formulas to avoid ACOTH etc., but including the function would make
it easier to enter math formulas that use them.

So, I agree with that too.

> From the Medium group to the Large group:
> 
> - DATEDIF
>   Hidden function in Excel. This function is only needed for
>   compatibility reasons. This could as well go into the Huge group.

Agree.
 
> - ROMAN
>   What is this good for anyway, except curiosity?

Actually, Roman numerals are still used in lots of places,
including outline values and publishing dates.
If you don't want it, you don't want it... but if you DO want it,
it's hard to create an equivalent using other functions.

I believe we should keep ROMAN where it is.  It's widely
implemented, and though many people don't use it, the folks
who _do_ use it can't easily work around it.

ROMAN has another function too, incidentally... it is ABSOLUTE PROOF
that some implementations can distinguish between booleans and
numbers.  ROMAN(..., True()) is different from ROMAN(..., 1)
in some implementations.  Of course, this odd behavior
is NOT required by our spec.

> From the Medium group to the Huge group:

Instead of "Huge" group, which isn't even documented
in this version of the spec, let's just drop these functions
from the official spec, though I think we should retain
the information about them as notes.  What do you think?

> - DOLLAR
>   Despite its name (which when localized differs completely) this
>   function converts a number to a text containing the currency symbol of
>   the current locale, the function's result depends on the current
>   locale and whether the current locale is supported at all by the
>   application. For exchanging documents reliably this function is
>   absolutely useless, if not counter-productive.
> 
> - USDOLLAR
>   The same, an alias for DOLLAR. Hidden in Excel.
> 
> - CELL
>   System/platform/implementation dependant functionality.
> 
> 
> From the Large group to the Huge group:

Again, I propose dropping them.

> 
> - ASC, DBCS
>   Japanese specific functions to convert between half-width and
>   full-width characters and Katakana. No other functionality in other
>   locales detected yet.
> 
> - PHONETIC
>   Japanese specific function returning the phonetic value of an Input
>   Method Editor (IME) input of a cell content. Would need even the
>   input, not only the content, being stored to get recalculated. No
>   other functionality in other locales detected yet.
> 
> - INFO
>   This function is much system/platform/implementation dependent, exists
>   only for Lotus/Excel compatibility, but is somewhat useless even in
>   Excel because of its nondeterministic behavior, e.g. try
>   =INFO("numfile"), you may get the number of sheets, or one more, or
>   maybe something completely different.
> 
> - VALUEL
>   It is unclear yet what this should exactly do or whether we'd need it
>   at all.

VALUEL was a local invention with little support, even inside our group.
Let's drop VALUEL.

--- David A. Wheeler