Great, we should definitely add this to the 1.0 release in order to allow for more expressivity in our DML, and to allow for the cleanup of existing DML that has had to code around this, such as the `nn` library.
I will add a JIRA (or search for one) and tag it for 1.0. -- Mike Dusenberry GitHub: github.com/dusenberrymw LinkedIn: linkedin.com/in/mikedusenberry Sent from my iPhone. > On Mar 29, 2017, at 4:18 PM, Matthias Boehm <mboe...@googlemail.com> wrote: > > Well, this would indeed be a very useful extension - I've actually seen > many use cases, where new users ran into issues with simple expressions > like X[i,i] = foo(). In the general case, the problem with UDFs is that > they can have - in contrast to builtin functions - multiple returns. These > multiple returns would translate to HOPs with multiple outputs, which in > turn cannot be represented with our current HOP DAG representation because > a HOP represents an operation and the characteristics of a single output, > but potentially with many consumers. This is also the reason why builtin > functions with multiple outputs (i.e., lu, eigen, qr) are internally mapped > to FunctionOps with the same restrictions. > > However, we could actually allow UDFs with a single output in expressions. > This would require a generalization of how results variables are bound but > should not take too much effort. Additional it would require a full pass > through the compiler to remove any assumptions that FunctionOps always > appear as DAG root nodes. Bottom line: We could realistically add it to our > feature list for the 1.0 release. > > Regards, > Matthias > >> On Wed, Mar 29, 2017 at 3:55 PM, <dusenberr...@gmail.com> wrote: >> >> Currently, it is not possible to use UDFs within an expression. I.e. I'd >> like to be able to use something like `out = (-1/2) * >> util::my_function(x)`. This would of course extend to more elaborate >> expressions. Also, note that we *are* able to use built-in functions >> within expressions. >> >> I think it would be good to allow for this. Are there any issues that >> would make this difficult? >> >> -Mike >> >> -- >> >> Mike Dusenberry >> GitHub: github.com/dusenberrymw >> LinkedIn: linkedin.com/in/mikedusenberry >> >> Sent from my iPhone. >> >>
