AllenNeuralDynamics / aind-behavior-curriculum

Starter repository for behavior base primitives.
https://aind-behavior-curriculum.readthedocs.io
MIT License
1 stars 0 forks source link

add example task for dynamic foraging #12

Closed hanhou closed 4 months ago

hanhou commented 7 months ago
hanhou commented 7 months ago

Last Note!

Bruno wants the 'modifiable' fields in TaskParameters marked as modifiable. To do this, see here:

https://github.com/AllenNeuralDynamics/aind-behavior-curriculum/blob/0c19397650fa71f27b202bf366a5b7235f5e4398/examples/task_creation.py#L20

This introduces an 'allow_modification' flag into the schema. See here:

https://github.com/AllenNeuralDynamics/aind-behavior-curriculum/blob/0c19397650fa71f27b202bf366a5b7235f5e4398/examples/task_schema.json#L8

I'm a bit confused. Is allow_modification a custom field just for our own reference and has no effects on the schema validation? Why don't we just use Literal versus the native Field to indicate immutable vs mutable fields?

bruno-f-cruz commented 7 months ago

Last Note!

Bruno wants the 'modifiable' fields in TaskParameters marked as modifiable. To do this, see here:

https://github.com/AllenNeuralDynamics/aind-behavior-curriculum/blob/0c19397650fa71f27b202bf366a5b7235f5e4398/examples/task_creation.py#L20

This introduces an 'allow_modification' flag into the schema. See here:

https://github.com/AllenNeuralDynamics/aind-behavior-curriculum/blob/0c19397650fa71f27b202bf366a5b7235f5e4398/examples/task_schema.json#L8

I'm a bit confused. Is allow_modification a custom field just for our own reference and has no effects on the schema validation? Why don't we just use Literal versus the native Field to indicate immutable vs mutable fields?

Sorry, missed this. As I mentioned in #8, I am not against using the const. That being said I thought Han wanted to use this tag for something different. A const tag(which exists as part of OpenAPI and json-schema standards) means that the schema will not allow modifications (either via the curriculum or via manual intervention). This is a HARD check, since if a different value is entered, the validation will not let it pass. In other words, once const is applied to an object, it cannot be updated by the stage (EVEN AUTOMATICALLY!). I thought the modifiable tag was something to tag variables that could be modifiable outside the curriculum (e.g. manually by users) and still have the training be considered "on-curriculum". Again, to make this more clear. A ModifiableAttr is never a const, but a non-const doesn't necessarily imply that it is a ModifiableAttr (in the strict logical sense: Modifiable => not const and const => not modifiable, but the inverse is not true, i.e.: not modifiable => const, which is the linchpin of why we might need an additional attribute). Once again, I don't see myself using this feature, but if for everyone else being modifiable and being NOT const is the same, ignore the suggested attribute.

bruno-f-cruz commented 4 months ago

Cleaning up hanging PR. Closing this as it is very out of date. Lets make a new PR with examples in the upcoming demo session.