Re: [office-formula] Call for volunteers, undefined functions, plan for this week

[Eike Rathke <erack@sun.com>]

Hi Andreas,

On Saturday, 2007-02-10 10:05:51 -0700, Andreas J Guelzow wrote:

> > > CURRENT (tricky semantics)
> > 
> > Actually not that tricky, it simply pushes the current calculation value
> > on the stack and makes it available as an argument to the next
> > operation, for example in
> > =A1+B2+IF(CURRENT()>3;STYLE("red");STYLE("green")) used to compare the
> > result of A1+B2 and conditionally apply a cell style.
> 
> Why is A1+B2 the current calculation value? Wouldn't you expect the IF
> to be evaluate before any of the additions are evaluated?

No, for +-*/ operators I expect a left-to-right calculation according to
precedence and associativity. We also say so in "3.1 Expression
Calculation" section 3. paragraph a), there is a problem though, we only
say _should_ and not _must_


> > Which adds STYLE to this list. I have both on my TODO agenda. They may
> > not sound that useful at first, but STYLE sometimes is used to have more
> > fine grained control than a fixed number of Conditional Formats allow.
> > Additionally the STYLE function has a timeout feature to switch to
> > another style after a while. Useful with real time Add-Ins.
> 
> Is there consensus how "Styles" look like as formula values?

In OOo the STYLE function always returns 0, so it may be used in
a general (term)+STYLE() context without changing the result.


> > BAHTText
> > That's a strange one and converts numbers into Thai numerals,
> > originating from a Thai localized Excel version. It seems Thai
> > spreadsheet users can't do without, so it was also implemented in OOo.
> > It even made it into Ecma/Excel.
> > 
> > We have a spec for it, so defining the function shouldn't be a problem.
> > See http://specs.openoffice.org/calc/compatibility/bahttext.odt
> 
> May be it shouldn't be a problem, but we are talking about an
> international standard. There is nothing special about Thai so if we
> include a BAHTTEXT we should have the same for any other language.
> (Perhaps a two argument version were the second argument is a language
> identifier defaulting to thai/baht with applications free to support the
> languages of their choice.)

I'd very much hesitate to define a general purpose internationalized
function for native numerals. If you take Korean, for example, there are
11 different systems to write out numbers.

If we dropped BAHTTEXT, I guess the proper way to write it anyway would
be COM.MICROSOFT.BAHTTEXT then?

  Eike

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