systemml-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthias Boehm <>
Subject Re: Built-in functions and UDFs
Date Sat, 01 Jul 2017 01:46:51 GMT
yes, I absolutely agree - we should add special handling of functions with
single outputs.

Quick background: Functions are initially split into separate statement
blocks so they can bind their outputs (potentially many) directly to
logical variable names because Hop DAGs cannot represent multiple outputs,
just multiple consumers. Originally, function calls where not even
represented as hops but constructed as special instructions. Later we
defined a three phase transition for a seamless integration: (1) represent
function calls via FunctionOps in the Hop DAG, (2) allow arbitrary
expressions for inputs of FunctionOps, and (3) allow FunctionOps with
single outputs in expressions. Unfortunately, we only realized phase 1 and
2 but never came to 3. Note that even builtin functions with multiple
outputs like qr and eigen are currently mapped to exactly this function
call framework.

For anybody interested in taking this over, it would essentially entail
modifications to the parser (language validate, hop dag construction), and
optimizer (hop dag representation, inter-procedural analysis, rewrites for
splitting hop dags for recompilation, hop-lop translation, lop instruction


On Fri, Jun 30, 2017 at 12:18 PM, <> wrote:

> Hi all,
> Currently, the usage of UDFs is restricted to simply being able to call
> the UDF and assign the results to a variable.  If the user wishes to use
> the UDF as input to a built-in op of any sort on the same line, an error is
> thrown.  This is confusing for users, and leads to messy code involving
> temporary variables.
> Here is a simple example that does not work, yet should:
>     out = my_udf_func(x) + 4
> Can we please fix this?  UDFs should be treated like any other op.
> Thanks,
> - Mike
> --
> Mike Dusenberry
> GitHub:
> LinkedIn:
> Sent from my iPhone.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message