Is that possible to wrap NDArrayEx's functions in NDArray?

[SuperMaskv]

So, user can use NDArrayEx's api transparently instead of calling NDArray#getNDArrayInternal first.

[zachgk]

The main reason we use the NDArrayEx is to have functions which will not clutter up the main NDArray API but still have special handling by the different engines for a particular type of NDArray. Each of them will also have a user facing call somewhere else in the DJL API that should be used instead (in Activation, Loss, optimizers, blocks, etc.). The main use case for the NDArrayEx is for internal use by DJL and DJL engine implementations.

Of course, you can still call array.getNDArrayInternal().internalCall() if you really want to

[SuperMaskv]

@zachgk Got it, thx for replying. But how to determine which a function belongs to? The comments on NDArrayEx say:

An internal interface that encapsulates engine specific operations.

But I can also find unsupported operations in PtNDArray, how to understand the difference between NDArrayEx and NDArray? I'm now trying to contribute a crf block, understanding your design conception would be a great help.

[zachgk]

Basically, different engines all support various ndarray operations. If we want to expose one of them, then we would have to create a function either in NDArray or NDArrayEx. Sometimes they have a Java implementation which we treat as the default overriden by the engine specific one.

If it is a standard NDArray operation (like it can be found in numpy), then we would typically put it in NDArray. If we think a different organization of it would be better, we hide the base form in NDArrayEx and advise people to use the organized form.

For the crf block, if you plan to add an engine function for mxnet or pytorch, add it in NDArrayEx and call it from the block. If there is no direct engine function and you plan to implement it in Java, just put the implementation directly in the block.

[SuperMaskv]

Thx again, I will try to implement crf in java.