After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 96737 - Support of (statistical) distributions
Support of (statistical) distributions
Status: RESOLVED FIXED
Product: Gnumeric
Classification: Applications
Component: Analytics
git master
Other All
: Low enhancement
: ---
Assigned To: Jody Goldberg
Jody Goldberg
Depends on:
Blocks:
 
 
Reported: 2002-10-24 19:01 UTC by Morten Welinder
Modified: 2008-09-19 21:28 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Morten Welinder 2002-10-24 19:01:27 UTC
[imported from mailing list]

From: "David J. Braden" <dbraden@rochester.rr.com>

Regarding the distributions with bounded support (e.g., BETADIST, lower 
end of GAMMADIST and WEIBULL, etc.), would you plz consider *not* 
emulating Excel, but rather using standard practice? I.e.,

(1) For distributions, return 0 for x <= lower-bound, and 1 for x >= 
upper-bound.

(2) Return 0 for all densities (either with respect to Lebesgue measure 
or counting measure) when x is outside of the support.  For example,
BETADIST(x,alpha,beta) would return 0 if x < 0 or x > 1, and
BINOMDIST(n,3,0.5,FALSE) would return 0 iff n <> 0, 1, 2 or 3

(3) Fix the discrete densities to correct what Excel does, namely, 
truncating doubles, where integers are expected, before evaluation. 
BINOMDIST(0.5,3,0.5,FALSE) would return 0, not the value returned by 
BINOMDIST(0,3,0.5,FALSE); and BINOMDIST(n,t,0.5,boolean) would return an 
error when t not an integer >= 0, rather than blithely truncating it.
Comment 1 Andreas J. Guelzow 2003-11-17 02:46:49 UTC
Jody,

do you agree that we should _not_ emulate XL? I defintiely would
prefer to implate correct support.
Comment 2 Jody Goldberg 2003-12-11 06:23:54 UTC
This is one of those areas where we're kind of stuck.
If we change the interface imported sheets silently break.  The only way we
could change it would be to add mapping routines too/from our version on
import/export for xls.  Which is not a pretty prospect.
Comment 3 Morten Welinder 2003-12-11 12:57:44 UTC
1+2 should not cause any significant compatibility trouble.
3, on the other hand, would be messy.
Comment 4 Andreas J. Guelzow 2008-09-19 21:28:22 UTC
We are unlikely to change the function that are supposed to be Excel compatible, but we have:

r.dweibull, r.dgamma, and friends that provide the desired service.

So I would consider this fixed.