-
Notifications
You must be signed in to change notification settings - Fork 21
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
Create MinerRegistry and Evaluation Pipelines #334
Conversation
|
||
required_files_extensions = ["cpt", "log"] | ||
|
||
self.pdb_location = pdb_location |
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.
Should move towards class designs that don't change states as we use them? ie, not assigning new class variables in functions, all of them should be defined in the init function etc.
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.
idea with these evaluators is that we would have many instances of them (one for each miner). But if we don't want to do that, then I agree with you
folding/rewards/miner_registry.py
Outdated
for miner_uid in miner_uids: | ||
self.registry[miner_uid] = {} | ||
for task in self.tasks: | ||
self.registry[miner_uid][task] = { |
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.
Should we make this a pydantic class?
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.
lgtm
MinerRegistry
to keep track of generic tasks w/ updates that includes miner credibilities and aggregation functionalitiesEvaluationRegistry
that holds all the eval pipelines for different tasksRewardBase
and reward stacks for different tasks inside of the evaluation registry