You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now we only have a small set of built-in meters. It would be nice to allow people to define their own meters, I think. I could be wrong though? I'm not actually sure what the use cases for this would be, so it'd be nice to see some. But my initial idea was that we'd allow people to pass meters=[...], and then the max_* kwargs would just be convenience shorthands for adding some commonly used meters to this list.
There's some machinery to support this already (e.g. the split between "meters" and "meter states"), but I decided not to expose it yet because (a) use cases could be clearer, (b) not at all certain that we've got the meter API done correctly. In particular, I suspect that keyed meters (#8) will require some changes.
The text was updated successfully, but these errors were encountered:
Right now we only have a small set of built-in meters. It would be nice to allow people to define their own meters, I think. I could be wrong though? I'm not actually sure what the use cases for this would be, so it'd be nice to see some. But my initial idea was that we'd allow people to pass
meters=[...]
, and then themax_*
kwargs would just be convenience shorthands for adding some commonly used meters to this list.There's some machinery to support this already (e.g. the split between "meters" and "meter states"), but I decided not to expose it yet because (a) use cases could be clearer, (b) not at all certain that we've got the meter API done correctly. In particular, I suspect that keyed meters (#8) will require some changes.
The text was updated successfully, but these errors were encountered: