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?

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

Oops, sounds like there's some miscommunication here; there are two different meanings of "no relevant values", and looks like I understood something different.

Here are the cases I see:
* In the case where there _IS_ at least one parameter provided (e.g., a reference), but no numbers are found in the reference, I believe that we MUST return 0 in these cases.  Most apps do so, and people depend on it.  Sounds like all are agreeing there.
* In the case of "0 parameters", many apps (including Excel) do NOT accept this at all.  Proposal: Let's keep the {}+ notation, meaning that compliant apps are NOT required to accept 0 parameters for them (so an Error would be fine to return)... it'd be an implementation-defined extension to accept 0 parameters in those cases.

--- David A. Wheeler

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