About "esotic" operations

[bhack]

Migrating from https://github.com/stellaraccident/mlir-npcomp/issues/1

I am just curious if It could be tested at some point some operation that It Is not trivial on how it could be expressed in numpy like distance transform or connected components.

I don't know if it can have any interesting implications in this
exploration as custom ops are going to be very problematic to maintain.

If you take a look at tensorflow/addons#1752 (comment) is related only to activations but it is quite common to have these kind of issues on more "esotic custom operations" that could frequently land to be proposed in Addons and other SIGs repos as the barrier is lower than TF core.

[stellaraccident]

That's not a bad intermediate test case, but will require a fair bit of basics to be right (but I don't see any fundamental issues).

My next step is to model the numpy ufunc abstraction in the numpy MLIR dialect. There are a few ways to do it, but I'm thinking of having a ufunc_call op which references a module level ufunc (which could be of a few different types) that holds the metadata about the operation.

Since the ufunc is such a core abstraction within numpy, and since it covers so many of the fundamental operations, it makes sense to me to spend some time to get it modeled isomorphic to how numpy reasons about it (at least modeling a proper subset of cases).

Beyond that, for your example, we would need:

• Indexing/slicing ops
• Some 'constructor ops' (zeros, etc)
• where
• dot

I'm trying to model it as isomorphic to numpy as is reasonable, since that is part of the MLIR philosophy and makes the tracer/ast-importer really-really thin, leaving the hard work to the compiler infra, which (in theory) is where we have the best tooling.

I'm going to try to get a first draft of the numpy dialect ~this week. I've been thinking on the design of it, but the limited time I've had to actually work on it has been swallowed up by setup/build issues (which I think I'm past now).

[bhack]

Probably we could reply to this stackoverflow question one of these days. 😉

[stellaraccident]

Not touching the question of what TensorFlow should be doing, getting this modeled right is a big driver of my work here. Lacking this functionality has been a drag on research adjacent to me for quite some time.

[bhack]

Of course, but I hope it will have repercussions elsewhere.