Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

make random event generator generate "min_events_per_user..=max_events_per_user" number of events #834

Merged
merged 4 commits into from
Nov 8, 2023

Conversation

taikiy
Copy link
Contributor

@taikiy taikiy commented Nov 6, 2023

OPRF steps depend on the maximum number of rows of all given users. In order to generate steps for the Compact gate, we need to be able to specify exactly how many user(s) and events we want to generate from the EventGenerator.

The current EventGenerator randomly generates events between [1..=max_events_per_user] per user, for up to max_user_id users (the name is confusing. I renamed it to user_count). It allows us to control the total number of events to generate, but not the number of events per user.

This is a quick change to fixate the number of events users can produce. We lose the randomness, but for the testing purpose I don't think that is a big deal as the randomness doesn't follow a real-world distribution anyway. Ideally, callers of the generator should be able to pass in a distribution of events-per-user.

This fixes other issues mentioned in #830. There's another issue with the generated timestamps exceeding the current 20 bits limit. I'll make another PR for that.

akoshelev and others added 2 commits November 6, 2023 18:00
* Add OPRF root step to compact

was getting an error running OPRF IPA with compact steps enabled

```
cannot narrow from the invalid step oprf_ipa
stack trace:
```

* Fix a compile bug inside compact map

* Reorder constants and fix the step number for OPRF
@akoshelev
Copy link
Collaborator

Can you support both use cases by adding min_events_per_user? I don't want to give up on IPA functionality just yet, where having different number of events per user matter. It is likely the case for OPRF too.

@taikiy taikiy changed the title random event generator generates exactly "max_events_per_user" number of events random event generator generates "min_events_per_user..=max_events_per_user" number of events Nov 7, 2023
@taikiy taikiy changed the title random event generator generates "min_events_per_user..=max_events_per_user" number of events make random event generator generate "min_events_per_user..=max_events_per_user" number of events Nov 7, 2023
Comment on lines +119 to +122
NonZeroU64::new(1).unwrap(),
NonZeroU32::new(64).unwrap(),
NonZeroU32::new(64).unwrap(),
64,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One cannot tell by looking at this how these numbers are used, and what they mean.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you tell me which part is unclear? I think the tuple variable names are self-explanatory and the comment describes why we need 1 and 64. Maybe change the integer literals to constants?

Copy link
Collaborator

@benjaminsavage benjaminsavage left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks pretty good to me.

max_events_per_user: NonZeroU32::try_from(max_events_per_user).unwrap(),
report_filter: ReportFilter::All,
conversion_probability: None,
}
}

fn max_user_id(&self) -> usize {
usize::try_from(self.max_user_id.get()).unwrap()
fn user_count(&self) -> usize {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I still find "user_count" confusing. Can you add a comment here to describe what it means?

@benjaminsavage benjaminsavage merged commit cb0fe9e into private-attribution:main Nov 8, 2023
3 of 4 checks passed
@taikiy taikiy deleted the event_rng branch November 8, 2023 07:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants