dev

[Gabinou]

Hello,

I am hoping to be able to contribute to your project. I have implemented some stochastic process objects and analysis functions. I have used your existing processes as templates and used the same naming conventions. Sphinx comments have also been added.

I have added 2 stochastic processes:

• The mixed poisson process: the rate is a random variate that changes upon every call to sample. Users need to input a random distribution and its parameters so that a sample can be drawn.
• The non-homogeneous Poisson Process (NHPP): the rate varies over time and space. The user needs to input a function/rate arrays and boundaries of evaluation. The sample points are created in the data space using the thinning/rejection acceptance algorithm. Multidimensional functions/arrays (and boundaries for each dimension) can be inputted to generate points in n-dimensional space.

Some analysis functions have been added in the stochastic.analysis folder. These include one non-parametric estimation method for 1D NHPP as well as an implementation of 2D kolmogorov-smirnov (2DKS) tests to analyze distribution of points in a 2D space. There are two 2DKS tests: ks2d1s: computes the likelihood that some 2D points were generated by a given density distribution. ks2d2s: computes the likelihood that two sets of data points were generated from the same density distribution.

I have also built some fixtures and test cases for these stochastic processes, and for the analysis functions.

I am hoping to contribute further by implementing the Cox process (or doubly stochastic Poisson Process). I am also thinking about implementing more generation algorithms for the NHPP. From now will work on each feature in its separate branch.

Please tell me what you think about these features and if I can ameliorate or contribute with other features.

Thank you very much.

[crflynn]

Hi @Gabinou,

Thanks for your interest in the project. This looks to be a pretty large pull request with a ton of changes (115 commits!). It also looks like you've made changes to almost every file in the repository, even files that don't appear to be associated with the features you've described in the PR description.

Unfortunately, I have to reject this PR for a number of reasons:

• tons of files changed with no association to proposed features
• lots of extra files associated with a separate set of documentation (?)
• separate license file (?)
• the test configuration has been deleted, causing CI tests to fail
• extraneous log files
• code quality and inconsistent naming

While I do appreciate your interest and hard work, I think that big changes like this would be better off discussed in smaller parts and merged into the library one at a time (if they are appropriate).

My advice to you, if you're still interested in contributing, is to:

• use the issues tab to create an issue that describes a more granular feature request, e.g. a new process to include. We can discuss the changes for each feature within each issue, i.e. how to implement, outlining methods, tests, docs, etc.
• keep changes to a minimum, i.e. only change files associated with your changes
• don't modify any top-level files besides the README unless absolutely necessary (if we agree on a feature that you decide to build I will credit you in the documentation as a contributor)
• ensure that your changes include tests that cover all your new code
• ensure that your changes are included in the existing documentation
• take a look at python style guides like PEP8 and flake8 to write clean and legible code.

Feel free to comment here if you have any questions.

[Gabinou]

Thank you very much for your comments. I will take them to heart as I do wish to contribute.

I do have some questions: 1- How can I ensure that my changes are included in the existing documentation? Is simply writing appropriate Sphinx comments sufficient? 2- Can you show me one or two examples of bad code/inconsistent naming?

[crflynn]

1- The docs configuration is using sphinx with autodoc, which means that in the .rst files you specify the classes for which to generate documentation. Autodoc grabs the class and method docstrings when it builds the docs so they should be defined appropriately. 2- Mostly I was referring to code like this which is pretty difficult to read due to formatting and doesn't follow the code style guides that I referenced.