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] MIN/MAX/MINA/MAXA and no value, zero?



On Tuesday, 2007-03-06 13:12:36 -0500, David A. Wheeler wrote:

> robert_weir:
> > 
> > I don't know if I'd favor having some implementations give an error while others give zero.  If someone has a document that silently fails (gives zero) and then gives an error when they give the spreadsheet to someone else,  then this will certainly cause some user confusion.
> 
> > Also, this is not an arcane function that will be used by few people.  This is not a Bessel function.  MIN and MAX are very basic functions that all will use.  So the impact of confusion would be multiplied. So I'd recommend having a single, complete, unambiguous definition for it.
> 
> Okay.  Giving MAX/MIN/etc 0 parameters _is_ a little arcane, but I agree that the functions themselves certainly are NOT arcane.  I see your point.
> 
> In that case, I think we ought to return "0" when handed 0 parameters.  Note: This means it should be "*" not "+" in the arg list.
> 
> Any objections?

I was mainly referring the case where, for example, a range is given but
there is no numerical value (in the case of MIN/MAX) in that range. So,
since most apps return 0 then and given the explanation of Andreas I'm
fine with specifying this as "return 0 if no values are in the set",
which could also mean to not care about whether parameters are handed or
not. It seems that currently only Gnumeric allows no parameters.

Handing no arguments at all to those functions actually doesn't make
sense. Do we still explicitly want to allow that and say that apps
should return 0 then, or stay with the current {}+ syntax and remove the
"apps should return 0" semantics instead?

  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]