Implemented interface for mark distribution

[JoseKling]

The interface is implemented. Maybe the names can be improved.

What I implemented:

• An AbstractMarkDistribution type for mark distributions different from the ones in Distributions.jl.
• PointProcessMarkDistribution alias for Union{AbstractMarkDistribution,Distribution}.
• The following methods as part of the common interface.
  • mark_distribution -> The distribution of marks at some time t and after history h.
  • sample_mark -> Sample from mark_distribution. Standard implementation assumes the result of mark_distribution has the method rand.
  • densityof -> for mark m at time t after history h. Standard implementation assumes result of mark_distribution has method densityof.
  • fit -> Fit the distribution to a history h. For processes whose event times are independent of the marks.
  • eltype -> Used to initialize empty histories. Standard implementation assumes result of mark_distribution has method eltype.
• Added the CustomProcesses page to the docs.

[github-actions]

Remaining comments which cannot be posted as a review comment to avoid GitHub Rate Limit

JuliaFormatter

---

[JuliaFormatter] _{reported by reviewdog 🐶}

PointProcesses.jl/src/multivariate/independent_multivariate.jl

Line 9 in 3abacf1

struct IndependentMultivariateProcess{P<:AbstractUnivariateProcess} <: AbstractMultivariateProcess

---

[JuliaFormatter] _{reported by reviewdog 🐶}

PointProcesses.jl/src/multivariate/independent_multivariate.jl

Lines 79 to 82 in 3abacf1

	histories = [
	time_change(History(h, d), pp.processes[d]) for
	d in 1:ndims(pp)
	]

---

[JuliaFormatter] _{reported by reviewdog 🐶}

PointProcesses.jl/src/multivariate/independent_multivariate.jl

Lines 104 to 108 in 3abacf1

	fit(
	proc_types[d],
	History(h, d);
	kwargs...,
	) for d in eachindex(proc_types)

---

[JuliaFormatter] _{reported by reviewdog 🐶}

PointProcesses.jl/src/univariate/poisson/inhomogeneous/inhomogeneous_poisson_process.jl

Lines 53 to 55 in 3abacf1

	return InhomogeneousPoissonProcess{F,NoMarks,C}(
	f, NoMarks(), integration_config
	)

---

[JuliaFormatter] _{reported by reviewdog 🐶}

PointProcesses.jl/src/univariate/poisson/simulation.jl

Line 3 in 3abacf1

h_temp = History(times, tmin, tmax)

---

[JuliaFormatter] _{reported by reviewdog 🐶}

PointProcesses.jl/src/univariate/poisson/simulation.jl

Line 18 in 3abacf1

# end

---

[JuliaFormatter] _{reported by reviewdog 🐶}

PointProcesses.jl/test/inhomogeneous_poisson_process.jl

Lines 1288 to 1290 in 3abacf1

	InhomogeneousPoissonProcess{PolynomialIntensity{Float64},NoMarks},
	h,
	[2.0, 0.3],

---

[JuliaFormatter] _{reported by reviewdog 🐶}

PointProcesses.jl/test/mark_distributions.jl

Line 18 in 3abacf1

@test md isa PointProcessMarkDistribution

---

[JuliaFormatter] _{reported by reviewdog 🐶}

PointProcesses.jl/test/mark_distributions.jl

Line 26 in 3abacf1

end

[codecov]

Codecov Report

❌ Patch coverage is 98.64865% with 1 line in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/history.jl	93.75%	1 Missing ⚠️

📢 Thoughts on this report? Let us know!

[JoseKling]

In src/univariate/poisson/poisson_process.jl I deleted the methods

• ground_intensity(pp), ground_intensity(pp, t)
• intensity(pp, m), intensity(pp, t, m) and log_intensity
• mark_distribution(pp), mark_distrbution(pp, t)

One reason is they are conceptually incorrect, the intensity is defined as dependent on the history. ground_intensity(pp) is actually the parameter $\lambda$, so it should be accessed with pp.λ.
Second reason is that now that we are supporting custom mark distributions, intensity and mark_distribution cannot be assumed to not depend on t or h.
Lastly, we just unify the interface.

Should we raise a deprecation error or something like that?

[rsenne]

Hi @JoseKling I'll try and take a look at this later in the week

[rsenne]

Should we raise a deprecation error or something like that?

I would say until we have evidence for a solid user base for anything like this to just delete as we are pre v1. Anyc hanges we can document (which reminds me, we should keep a changelog)

[JoseKling]

about the changelog. Or do you mean something else?

[rsenne]

Or do you mean something else?

Related idea, but basically we would house a CHANGELOG.md per the keep a changelog project.

It's basically the same thing but it tends to be more long format. But its not strictly necessary and we can use the same format for releases

[JoseKling]

There are a couple of lines not reached by the tests. Apart from that, any other issues here?

[rsenne]

Just updated from main--I can take another look

[rsenne]

@JoseKling there are 5 unresolved comments from above can you take a look at them and let me know if you agree/disagree? (I think they were missed because they were hidden)