Proposal for statistical distributions

[Jim-215-Fisher]

Besides common descriptive statistics, we need standard modules for various continuous statistical distribution (e.g., gamma distribution) and discrete distribution (e.g., bernoulli distribution). These statistical distributions will be very useful to various computer simulation techniques.
Even though these functions are available in Scipy package for python, I think it is worthwhile to have in stdlib with pure Fortran. There are plenty of source codes on the net, we just need to convert them.

[epagone]

Prior art.

• GSL has a comprehensive section of random number distributions that should be available in Fortran though the fgsl module. This should be stable and well maintained.
• Richard Chandler and Paul Northrop from UCL have developed a nice library in ancient FORTRAN77. Latest update has been in 2003. License is very "liberal" (they only ask to be cited) but the interface is not simple. Documentation is minimal but seems sufficient. No examples or tutorials are provided.
• A library for normal distributions only, one more generic with a large number of distributions and another one focussed on cumulative density function are provided on Jacob Burkardt site. This is Fortran 90 compliant code. The license is GNU LGPL and documentation is adequate with examples.
• This post in a blog is the translation in Modern Fortran of a public domain, simple, Julia library about different distributions. It's simple but documentation is almost non-existent.
• The site of Jean-Pierre Moreau has a number of files available (apparently in a somewhat modern Fortran). However, some files appear to be taken from the book "Numerical Recipes" (which has a peculiar license) and it is not clear if the distributions are included.

[jvdp1]

I agree with @Jim-215-Fisher 's comment. Thank you for the suggestion.

To add to the prior art mentioned by @epagone:

• RANLIB: Fortran90 (license: LGPL) (and its F77 version). I believe this library is also used in Octave.

[Jim-215-Fisher]

Should stdlib be based on GSL through fgsl?

[certik]

@Jim-215-Fisher Unfortunately GSL is GPL licensed, which prohibits its inclusion into stdlib which is MIT licensed.

[ivan-pi]

Don't forget the Software from Alan J. Miller: https://wp.csiro.au/alanmiller/random.html
(a mirror exists at https://jblevins.org/mirror/amiller/)

[arjenmarkus]

i agree with that: it is an extensive collection provided by a well-known professional in the field. It may require some reorganisation, as it is not organised in modules and the like, but it is certainly worth our while. Op di 22 sep. 2020 om 12:59 schreef Ivan <notifications@github.com>:

…

Don't forget the Software from Alan J. Miller: https://wp.csiro.au/alanmiller/random.html (a mirror exists at https://jblevins.org/mirror/amiller/) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#234 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAN6YRZSJTTC675SELMLNWLSHB7Q3ANCNFSM4RUXIQFQ> .

[jvdp1]

i agree with that: it is an extensive collection provided by a well-known professional in the field. It may require some reorganisation, as it is not organised in modules and the like, but it is certainly worth our while. Op di 22 sep. 2020 om 12:59 schreef Ivan notifications@github.com:
…
Don't forget the Software from Alan J. Miller: https://wp.csiro.au/alanmiller/random.html (a mirror exists at https://jblevins.org/mirror/amiller/) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#234 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAN6YRZSJTTC675SELMLNWLSHB7Q3ANCNFSM4RUXIQFQ .

Indeed, I agree. However, it is unclear to me what the license is for these files.

[arjenmarkus]

It says that the code written by Alan Miller is in the public domain, I will ask Jason what this means exactly. Op di 22 sep. 2020 om 13:07 schreef Jeremie Vandenplas < notifications@github.com>:

…

i agree with that: it is an extensive collection provided by a well-known professional in the field. It may require some reorganisation, as it is not organised in modules and the like, but it is certainly worth our while. Op di 22 sep. 2020 om 12:59 schreef Ivan ***@***.***: … <#m_-2168024105408715737_> Don't forget the Software from Alan J. Miller: https://wp.csiro.au/alanmiller/random.html (a mirror exists at https://jblevins.org/mirror/amiller/) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#234 (comment) <#234 (comment)>>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAN6YRZSJTTC675SELMLNWLSHB7Q3ANCNFSM4RUXIQFQ . Indeed, I agree. However, it is unclear to me what the license is for these files. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#234 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAN6YR2XPP2KHV2B46IZE3LSHCANJANCNFSM4RUXIQFQ> .

[Jim-215-Fisher]

If it is public domain, then there is no copyrights.

[Jim-215-Fisher]

In terms of license, as long as there are mathematic formulae, I think license issue should not be a concern.

Based on comments so far, it looks like majority agreed to have statistical distributions in stdlib. So the next question is what kind of API should be. We can either define a data type for each distribution and various type-bound procedures, or define various procedures for each type of distribution directly in the stdlib module. For example, normal distribution one could have:

module stdlib
type :: norm_dist_t
real :: x
real :: loc
real :: scale

contains
generic :: pdf => norm_dist_pdf
generic :: cdf => norm_dist_cdf
.
.
.
end type norm_dist_t

contains
{procedure definition}
.
.
.
end module stdlib

or directly in stdlib module:

module stdlib
function norm_dist_pdf(x, loc, scale)
end function norm_dist_pdf
.
.
.
end module stdlib

The first one is object oriented, data and procedure are encapsulated. The second one is more traditional like intrinsic function call familiar to users. Which one is better?

[arjenmarkus]

In these matters it is not likely that there is a "best" solution. It is a matter of taste, I would say. But I am leaning towards a procedural style in this. Typical use of this functionality: - I have a time series and I want to see if it can be fitted to a normal or log-normal distribution. In that case, I would pass the time series to some function that uses a relevant statistical test (say Lillifors) to determine whether the fit is good enough. Rather than setting up an object that takes the confidence level and perhaps a few other data, why not use a simple function? - I have determined the mean and standard deviation of my data set and new data come in. Do they follow the same distribution? Again a function seems more appropriate. I do see the attractiveness of an object-oriented interface, especially if you want to examine several different data sets against the same distribution, but it feels indirect in many cases. So I would prefer a functional/procedural interface, at least for the moment. An OO interface can be added later. Op wo 23 sep. 2020 om 00:56 schreef Jing <notifications@github.com>:

…

In terms of license, as long as there are mathematic formulae, I think license issue should not be a concern. Based on comments so far, it looks like majority agreed to have statistical distributions in stdlib. So the next question is what kind of API should be. We can either define a data type for each distribution and various type-bound procedures, or define various procedures for each type of distribution directly in the stdlib module. For example, normal distribution one could have: module stdlib type :: norm_dist_t real :: x real :: loc real :: scale contains generic :: pdf => norm_dist_pdf generic :: cdf => norm_dist_cdf . . . end type norm_dist_t contains {procedure definition} . . . end module stdlib or directly in stdlib module: module stdlib function norm_dist_pdf(x, loc, scale) end function norm_dist_pdf . . . end module stdlib The first one is object oriented, data and procedure are encapsulated. The second one is more traditional like intrinsic function call familiar to users. Which one is better? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#234 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAN6YR74DUUVPIAE2UBA4WDSHETTHANCNFSM4RUXIQFQ> .

[jvdp1]

My preference is a procedural style.
This choice "procedural" vs "OOP" style has been already discussed in previous issues (I can't find them back), and, if I remember wel, procedural style should be prefered over OOP. Of course similar functionality in a OOP style could be always proposed on top of the procedural ones.

[Jim-215-Fisher]

Yeh, I have checked the style guide and can't find any recommendation. Anyway, procedure style is the Fortran way. I will go ahead to implement a small module.

[certik]

@Jim-215-Fisher we should put it into the style guide, great idea. Here are some links where it was discussed in the past:

• API for file system operations: directory manipulation #220 (comment)
• Proposal for high level I/O #14 (comment)
• ANSI Colors support #229 (comment)
• Pseudorandom number generator #135 (comment)

[Jim-215-Fisher]

@certik Thanks for the links. BTW, is there a table/list/link showing status of each stdlib module/proposal?