Constraining hyperevents with COND_SIZE_UHE_OBS

[David]

Dear all,

My goal is to constrain the hyperevents such that they always include at least one participant possessing a specific characteristic.

I initially thought I could achieve this by creating a hyperlevel attribute and then selecting the constraint "UHE has to be non-zero on attribute". However, I discovered that this option isn't available when using the COND_SIZE_UHE_OBS setting.

I'm using COND_SIZE_UHE_OBS because without it, the number of participants in the sampled hyperevents becomes unrealistically high.

Therefore, I was hoping to get some advice for how to ensure that each hyperevent has at least one participant with the required characteristic, while still using COND_SIZE_UHE_OBS. Or can I circumvent using the conditional size ?

Any ideas on how to deal with this would be very much appreciated.

Kind regards,

David

[juergen lerner]

Dear David,

I see the issue. It is possible to specify the option "node has to be non-zero on attribute" which, however, would require that all participating nodes have the characteristic - not just one and the others may or may not. 

I think that the setting "UHE has to be non-zero on attribute" would not solve the issue. With this setting all non-event hyperedges have to assume a value different from zero in the given attribute. It would not be sufficient that non-event hyperedges overlap with a given hyperedge (containing those nodes that have the property). We applied this setting in the 2019 preprint ("REM beyond dyads") to fit a model on repeated teams of coauthors. A hyperedge (team of authors) assumes a non-zero value in the attribute once they have published a paper together - and from then on they can be sampled in the model for repeated author teams. In your case you would have to set the hyperedge attribute for all possible sets (all sets of nodes containing at least one that has the characteristic). 

In fact, I can think of one work-around. You consider your events as directed hyperevents always having one source node (one of those that have the characteristic) and a varying number of target nodes (all others). The settings would would be "source has to be non-zero on attribute" (giving the attribute indicating which nodes have the characteristic) and the target nodes probably have no constraints (or at least a different one). However, I cannot oversee whether it will really work out. For directed hyperedges there are other effects available than for undirected ones. It the "logic" of your events is undirected you would probably choose settings for directed hyperedge statistics ignoring this direction. For example "undirected repetition" which is a DHE_REPETITION_STAT with direction=SYM and no endpoint specified. I guess that for the triadic / closure statistics it gets more complicated to mimic an undirected behavior. It may or may not work - depending on which effects you want to test.

Best wishes

   Juergen

[David]

Dear Juergen,

many thanks for your response!

Indeed, it seems I misunderstood how "UHE has to be non-zero on attribute" works, and I appreciate your clarification.

The suggested workaround is very clever. I have a concern about the conditional sizing of the directed events. Here it reads: "[...] conditional-size RHEM, that is, an observed hyperevent is only compared with non-event hyperedges that have the same number of receivers". 

Does this imply that the number of senders in the generated events would be unrestricted? Based on the rest of the text, it seems more likely that the condition applies to both the number of senders and receivers. Could you confirm whether this interpretation is correct?

As an alternative, I'm considering a more brute-force approach: filtering the generated events based on the condition in post-processing, assuming a sufficient number of events are generated per observation. 

I would greatly appreciate your thoughts on this.

Best regards,

David

[juergen lerner]

Dear David,

The COND_SIZE_DHE_OBS conditions actually conditions on both, the number of senders and the number of receivers. I think that I've pointed out only the condition on the number of receivers in the linked tutorial since in that application, the number of senders is always one. But this actually makes it even more important to also condition on the number of senders (which is done). The wording was indeed ambiguous and I've just changed it. 

Best wishes

  Juergen