wkcn edited a comment on issue #15921: [WIP] dynamic custom operator support URL: https://github.com/apache/incubator-mxnet/pull/15921#issuecomment-526407709 @samskalicky I see. Could we add a prefix name to avoid name conflict? For example, Library1 has {opA, opC, opD} Library2 has {opB, opC, opE} Firstly, we load lib1. They are registered as 1_opA, 1_opC, 1_opD. Then we load lib2, and lib2 registers 1_opB, *2_opC*, 1_opE. If we load lib2 again, they are called 2_opB, 3_opC, 2_opE. There is not any name conflict in nnvm. In the front end, we can map them to original names in specific namespace. e.g. lib1 = mx.library.load(“lib1.so”, namespace=“lib1”) op = mx.nd.lib1.opA(...) op2 = lib1.nd.opA(...) mx.library.load(“lib1.so”, namespace=“lib1.nn”) mx.nd.lib1.nn.opA(...) mx.library.load(“lib1.so”) # no namespace mx.nd.opA mx.library.load(“lib1.so”) # raise an exception since mx.nd.opA has been registered. I prefer ‘mx.nd.lib1.opA’ because users may use the CustomOp in Gluon, and call them by F.lib1.opA.
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] With regards, Apache Git Services
