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.*

Andreas J Guelzow:
> the non-legacy version of CHIDIST is CHISQDIST. CHIDIST uses the
> Chi-Square distribution plus gives the right tail probability, this
> conflicts with the otehr DIST functions that give cumulative (left-tail)
> or density values.

Problem is, "LEGACY." as a prefix doesn't really tell the reader
what the function _does_, and in alphabetic sorts it gets far
removed from a "non-legacy" function.

I would rather call the old CHIDIST a different name than LEGACY.CHIDIST.

I don't think we need to have _all_ of the distribution functions give
right-hand tails; instead, we can just note that this PARTICULAR
function with a right-hand tail is included to aid interoperability
with existing documents, and then point to using CHISQDIST
instead (which returns the left-hand, and is thus more consistent).

> Excel's NORMSDIST is essentially NORMDIST with the second and third
> argument of NORMDIST set to 0 and 1. It would make much more sense to
> have them optional. (There is the problem wit the fourth argument that
> picks cumulative vs density.)

What 'problem' do you mean?

I presume, then, that:
Excel NORMSDIST(x) = NORMDIST(x;0;1;TRUE()) ?
Is that right?

As far as "have them optional" in NORMDIST, we could certainly do that,
just by declaring default values for the later parameters, presumably:
 Number Mean = 0; Number StandardDeviation = 0; Logical Cumulative = TRUE()
If we do that, then I think we need to define defaults for the other
similar DIST functions.

By the way, the current text for LEGACY.NORMSDIST is _not_ correct,
because it is NOT the same as a single-parameter version of NORMDIST -
we don't have such a thing.  Adding default values would fix that.

If we do that, then we could eliminate NORMSDIST;
implementations that have a "NORMSDIST" could just translate that to
NORMDIST(one-param).  But if we do that, then applications cannot
round-trip perfectly - if they save as NORMDIST(x), then when an app
reads it back, it won't know if the user entered NORMDIST() or
NORMSDIST().  Obviously it doesn't matter logically, but users may
very well be unhappy about that.  In other cases we've been careful
to NOT lose that kind of information.  I think it'd be better
if we could continue to recover exactly what the user
stated, just as we do with POWER() and ^.

So I see value in doing both: include NORMSDIST
(without LEGACY.), so that round-tripping will not cause any
change in the names of the functions used by the user
(as perceived by the user).  Define it in terms of NORMDIST.
In addition, give reasonable defaults for those distribution functions;
it will make them easier to use.

> Similarly for NORMSINV and NORMINV.

I'd propose similar changes, e.g., make NORMINV have default values for
parameters 2 and on, and restore the "old" function without
the LEGACY prefix.
> CHITEST really doesn't make any mathematical sense.

I think that needs to be explained in the normative text, if that's really
the case.  I don't understand _why_ it doesn't make any sense -
can you help me understand that?  Preferably in text that we can
include, to explain to users why they shouldn't use it?

--- David A. Wheeler

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