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

[Eike Rathke <erack@sun.com>]

Hi David,

On Tuesday, 2006-12-19 16:05:52 -0500, David A. Wheeler wrote:

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

Ok, I'm also fine with that.

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

Ah, that might be the reason. However, the reason that SheetToGo didn't
include it may also be because of the weird automagical behavior that
when used with two parameters and the range is wider than tall the
search happens in the first row instead of the first column (new to me,
OOo currently does not implement this), and the result is always
returned from the last column respectively row of the range. A bit
unpredictable and surprising to the user maybe. In Excel 2003 this form
is marked as "provided for compatibility" and more or less deprecated.

So, rethinking, it might indeed be better to not include LOOKUP in the
Small group.


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

OOo's Excel export just was changed to rewrite these if used ;-)
http://www.openoffice.org/issues/show_bug.cgi?id=72768


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

Indeed..

> Of course, this odd behavior is NOT required by our spec.

In fact during import for this function a TRUE may be rewritten as 0 and
FALSE as 4. Odd indeed..


> > From the Medium group to the Huge group:
> > [... DOLLAR, USDOLLAR, CELL ...]
> 
> 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?

I think we should include them in the spec sooner or later as long as
they have a defined behavior, even if ill-defined, but should also say
so. Reason is that if these functions are imported from an alien file
format or earlier versions of ODF applications importers at least would
know what they had to implement to support them.


> > From the Large group to the Huge group:
> > [... ASC, DBCS, PHONETIC, INFO ...]
> 
> Again, I propose dropping them.

Well, OOo recently implemented some of the INFO functionality, and will
implement the DBCS and ASC functions for Japanese support for
compatibility, so we should add information about these functions where
possible. Maybe in a later version of ODFF.

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

Seconded.

  Eike

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