OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-formula message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [office-formula] A few miscellania


> > * On all spreadsheets I've tried, AND() and OR() do NOT short-circuit.
> >    Should we PERMIT short-circuiting (implementation-defined), or FORBID it?
> >    We could define ANDSC() and ORSC() for short-circuiting operations, I supposed,
> >    but I hate to do that.
> 
> Hmm, the way formulas work in KSpread, short-circuiting would be
> impossible to implement without some ugly hack. I guess it's the same
> with other implementations. Plus, it's not like you ever need it, is
> it ? Logicval formulas in spreadsheets usually don't have side-effects
> which would make this necessary.

There are very few cases where you really "need" short-circuiting,
so that's fair enough.

Actually, that raises a related issue - can we guarantee that
"IF()" never computes the "else" part if the condition is false,
and never computes the "then" part if the condition is true?
If IF() short-circuits (never evals the other branch), then that's
a work-around in the incredibly rare case when you need it.
Alternatively, we can simply be silent in the spec about
short-circuiting.

> > * I plan to require handling one-arg AND() and OR(), as they're cheap "convert to logical"
> >    functions, but say that zero-arg AND() and OR() can be Error or Logical
> >    (most, maybe all spreadsheets produce an Error on zero-parameters)
> 
> Sure, why not. Not really necessary, but it may come in handy.

And they seem to be widely supported.  I'd like to get as much
nailed down/specified if it's widely implemented, unless there's
some reason not to (e.g., it would PREVENT implementing something desirable).

> > * I plan to change LOG() so that the second parameter is optional (default=10);

Great!

I plan to continue to try to merge the various "levelled" requirements
inside functions so that functions don't have internal levels.  If we can
do this, it will GREATLY simplify the spec... and it'll make it easier to
use, too.  And even if we can't COMPLETELY do it, if there are only
one or two cases, we can probably handle those specially, without
the full complexities of having every function be levelled internally.

--- David A. Wheeler


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]