systemml-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Janardhan (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (SYSTEMML-1785) Call UDFs inline in the expressions without variables
Date Wed, 19 Jul 2017 12:20:00 GMT

     [ https://issues.apache.org/jira/browse/SYSTEMML-1785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Janardhan updated SYSTEMML-1785:
--------------------------------
    Description: 
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 the builtin-op of
any sort on the same line, an error is thrown. This is confusing for users and leads to  a
messy code involving temporary variables.

example: {code:none} out = my_udf_func(x) + 4{code}
  
The UDFs should be treated like any other Op.

*Quick background: *The 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, function calls were 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.
# 3. Allow FunctionOps with single outputs in expressions. (yet to be completed.)

*Solution:*
It would essentially entail modification to the passes(language validate, IPA, rewrites for
splitting, Hop DAGs for recompilation, Hop-Lop translation, Lop instruction generation.)

  was:
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 the builtin-op of
any sort on the same line, an error is thrown. This is confusing for users and leads to  a
messy code involving temporary variables.

example: {code:none} out = my_udf_func(x) + 4{code}
  
The UDFs should be treated like any other Op.

Quick background: The 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, function calls were 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.
# 3. Allow FunctionOps with single outputs in expressions. (yet to be completed.)

Solution:
It would essentially entail modification to the passes(language validate, IPA, rewrites for
splitting, Hop DAGs for recompilation, Hop-Lop translation, Lop instruction generation.)


> Call UDFs inline in the expressions without variables
> -----------------------------------------------------
>
>                 Key: SYSTEMML-1785
>                 URL: https://issues.apache.org/jira/browse/SYSTEMML-1785
>             Project: SystemML
>          Issue Type: Improvement
>            Reporter: Janardhan
>
> 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 the builtin-op of
any sort on the same line, an error is thrown. This is confusing for users and leads to  a
messy code involving temporary variables.
> example: {code:none} out = my_udf_func(x) + 4{code}
>   
> The UDFs should be treated like any other Op.
> *Quick background: *The 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, function calls were 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.
> # 3. Allow FunctionOps with single outputs in expressions. (yet to be completed.)
> *Solution:*
> It would essentially entail modification to the passes(language validate, IPA, rewrites
for splitting, Hop DAGs for recompilation, Hop-Lop translation, Lop instruction generation.)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Mime
View raw message