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
Would it be useful to tag objects and make them available for retrieval?
The package contains neural networks and custom layers.
If we think, yes, then the "how" is the next question. Some thoughts:
torch objects do not mutate their init args, so they would be compliant with skbase, which brings its own tagging and retrieval system. Though I am not entirely sure whether we have compatibility, or whether we want to "weigh down" the torch objects.
alternatively, we could add records that are BaseObjects that point to the torch object. That may be safer, as the torch objects themselves would not inherit non-torch logic, which might be safer for upwards compatibility with torch. The idea here is a barebones BaseObject with tags, an __init__ with same params as the object, and with a build method that constructs the object instead.
The text was updated successfully, but these errors were encountered:
Related to this issue: #1582
Would it be useful to tag objects and make them available for retrieval?
The package contains neural networks and custom layers.
If we think, yes, then the "how" is the next question. Some thoughts:
torch
objects do not mutate their init args, so they would be compliant withskbase
, which brings its own tagging and retrieval system. Though I am not entirely sure whether we have compatibility, or whether we want to "weigh down" the torch objects.BaseObjects
that point to thetorch
object. That may be safer, as the torch objects themselves would not inherit non-torch logic, which might be safer for upwards compatibility withtorch
. The idea here is a barebonesBaseObject
with tags, an__init__
with same params as the object, and with abuild
method that constructs the object instead.The text was updated successfully, but these errors were encountered: