[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office-formula] Call for volunteers, undefined functions, plan for this week
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]