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] List of functions in OpenFormula, dealingwith LEGACY.*


Hi,

On Friday, 2008-06-20 17:33:46 -0400, David A. Wheeler wrote:

> > > LEGACY.NORMSDIST => NORMSDIST
> > >   where NORMSDIST(x) = NORMDIST(x;0;1;TRUE())
> > >   since this is also well-defined and useful
> > 
> > I disagree here. In fact I could see much more reason for dropping
> > LEGACY.NORMSDIST completely rather than turning it into a non-legacy
> > function. After the above change with respect to the default values of
> > NORMDIST,
> > 
> > NORMSDIST(x) = NORMDIST(x)

This indeed doesn't make much sense.

> > As a consequence there is no reason why, in the file format, we would
> > distinguish between NORMSDIST and NORMDIST. While NORMSDIST would could
> > exist in some legacy MS Excel files, when the file is converted to
> > openformula format NORMSDIST could (should) just be translated into
> > NORMDIST.

I don't like that idea. It poses extra work on implementors when storing
Excel files and legacy ODF files as new ODF formula. I propose to stick
with LEGACY.NORMSDIST here. We included LEGACY.NORMSDIST to ease
implementation of ODFF, do we want to leave that road for an idealistic
clean room spec?

> > It really does not make sense to have two versions of the same function,
> > even if one of them can be called with additional arguments.

We also included LOG10 for interoperability, where LOG10(x) == LOG(x).
Do we want to kick all that out now?

> Well... I guess the issue here is being able to restore _exactly_ what was
> entered into the application, without change.  In some sense we already do this;
> "%" is functionally equivalent to "/ 100", but no one wants to enter "5%"
> and load back "5/100".
> 
> > > Rename:
> > > LEGACY.CHIDIST => CHISQDISTRIGHT
> > >   since this is well-defined and useful (no need to eliminate)
> > 
> > Since CHISQDISTRIGHT is just (1 - CHISQDIST(...;TRUE())) I would
> > question whether it is indeed useful, but that probably lies in the eyes
> > of the beholder.
> > Having said that, if we want to accept this as a non-legacy function, I
> > would think that we should similarly have right tail functions for all
> > other DIST functions. I don't think it makes sense for a standard to
> > treat one distribution special in this regard. (IN fact if we wanted to
> > treat one special then it should be the normal distribution rather than
> > the chisquare distribution.)
> 
> Are you hard over on this?  If so, then I think we should add *RIGHT
> functions for all the distributions.  There aren't that many
> distributions, and this is trivial to implement.  So it's a bonus for users,
> and no big deal for implementors.

It adds unnecessary complexity to the spec and implementation. A user
who needs to distinguish between left tail and right tail distributions
should really be able to write (1-dist). We also didn't introduce
specialized versions of SUM() to obtain negative results ...

> > > LEGACY.CHITEST unchanged; maybe we can get more info on it.

Whatever we may come up with, we should nail down the naming of
functions _now_ and do not change it later. OOo3.0 implementation is
short before code freeze, and of course we want to write function names
that comply with the spec, so could we please come to a conclusion? I'm
fine with LEGACY.NORMSDIST and CHISQDISTRIGHT, anyone else?

Thanks
  Eike

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

PGP signature



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