-
Notifications
You must be signed in to change notification settings - Fork 25
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
Conversation
* 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
Can you support both use cases by adding |
…umber of events a user can generate
NonZeroU64::new(1).unwrap(), | ||
NonZeroU32::new(64).unwrap(), | ||
NonZeroU32::new(64).unwrap(), | ||
64, |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this 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 { |
There was a problem hiding this comment.
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?
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 theEventGenerator
.The current
EventGenerator
randomly generates events between[1..=max_events_per_user]
per user, for up tomax_user_id
users (the name is confusing. I renamed it touser_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.