Type of marks

[jucheval]

Hi,

In the current implementation, the mark type M is as follows in the exemples:

1. Univariate point process: M == Int
2. Multivariate point process: M == Int
3. Univariate marked point process: M == Mprime where Mprime is the inherent type of the marks

I think there could be confusion between cases 2. and 3. above when Mprime == Int.

Hence, I am considering to:

• add a ndims argument to the History and concrete subtypes of AbstractPointProcess,
• replace M == Int by M == Nothing in case 1.,
• design Multivariate marked point processes as M == Tuple{Int,Mprime}.

What do you think of that ?

[jucheval]

@gdalle: I guess it is the good way to notify you of the Issue.

[gdalle]

I was already notified but I took the week-end off GitHub ;)

In the current state of the package, I would already use M = Nothing to model a univariate point process (case 1), so I'm not sure why you suggested Int? Granted, it is a bit of a waste to have empty marks, but it also makes package design much simpler to have only one type of process to consider: everything is marked by default and histories are always vectors of marks.

Especially for packages which we have limited resources to maintain, adding a little complexity for the user can often make sense if it removes a lot of complexity for the developer. In this spirit, I'm not sure what the ndims argument brings to the table? And it seems to me that using M = Tuple{Int,Mprime} is already possible as things stand? What is it you cannot do at the moment but want to be achieve with these changes?

If we make changes to accommodate multivariate point processes, the main argument should be speed IMHO. But then we have to decide whether it always makes sense to store the histories of different marks in separate vectors. Are there situations where it could hurt usability or performance?

[jucheval]

Ah ok. I was not sure it triggered a notification.

I agree with your points.

By the way my comment about "confusion between cases 2. and 3." may not be so problematic for users. In case it becomes problematic, I guess that we could recommend to use M == Tuple{Nothing, Int} for Univariate marked PP with Int marks.

Thanks

[gdalle]

For performance reasons, two things that could make sense are (beware of the semantic ambiguity):

• Multivariate point processes (as in, a superposition of several univariate point processes) being stored with one vector of mark history per dimension
• Multivariate point processes (as in, a process with vector-valued marks) being stored with a matrix instead of a vector of vectors

But we'd need to benchmark to see exactly what is to be gained

[jucheval]

I will follow the current implementation for now. Then, I will try some benchmarks later on...

[jucheval]

FYI, I just remembered the reason I wanted to add ndims. For instance, if you have an history where the higher dimension does not have any point, you cannot infer the number of dimensions from the history. However, I think that it is too specific (and too rare) to justify the addition of the ndims field.

[gdalle]

Yeah, but that's rather inevitable. If you take it to the extreme, a history that is too short will always contain zero events. In such cases, you need to rely on some external information stored in the "reference model" to enable nontrivial fitting (like a prior)