systemml-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthias Boehm <mboe...@googlemail.com>
Subject Re: Namespace handling w/ imports
Date Tue, 14 Feb 2017 00:09:43 GMT
thanks for the clarifications - given that we don't support creating
namespaces other than through imports, I think we can leave this for now
(potentially along with a note in our future explain documentation).

@Mike: Indeed, it should have been mnist_lenet instead of .defaultNS,
referring to the bound namespace (but not the filename).

Regards,
Matthias


On Mon, Feb 13, 2017 at 10:56 AM, <dusenberrymw@gmail.com> wrote:

> Thanks, Matthias for bringing this up.  As Glenn pointed out, the full
> file path as the namespace is needed so that we can effectively build
> libraries/packages for SystemML, rather than just single-file scripts.  If
> you truncate the namespace down to just the name of the specific file, then
> you prevent the ability to build a library in which the same file name is
> used in multiple folders.
>
> Another note with the example presented.  Assuming that you are running
> the `mnist_lenet-train.dml` script, the `train` and `predict` functions are
> defined in `mnist_lenet.dml`, which is imported, so those functions would
> not be in the default namespace.
>
> -Mike
>
> --
>
> Mike Dusenberry
> GitHub: github.com/dusenberrymw
> LinkedIn: linkedin.com/in/mikedusenberry
>
> Sent from my iPhone.
>
>
> > On Feb 12, 2017, at 10:15 PM, Glenn Weidner <gweidner@us.ibm.com> wrote:
> >
> > Use of source filenames instead of default namespace helped address
> various issues and tasks under https://issues.apache.org/
> jira/browse/SYSTEMML-590 that were encountered when creating the
> SystemML-NN script library. Unit tests were also added to cover different
> import scenarios. As I recall, function name conflicts could potentially
> occur between independent source files when global default namespace used.
> It also helped simplify calling dml-bodied functions when a file was
> imported by another.
> >
> > Thanks,
> > Glenn
> >
> >
> > Matthias Boehm ---02/12/2017 12:30:35 AM---While debugging our
> mnist_lenet script, I encountered an issue with our namespace handling with
> imp
> >
> > From: Matthias Boehm <mboehm7@googlemail.com>
> > To: dev@systemml.incubator.apache.org
> > Date: 02/12/2017 12:30 AM
> > Subject: Namespace handling w/ imports
> >
> >
> >
> >
> > While debugging our mnist_lenet script, I encountered an issue with our
> > namespace handling with imports. Here is the related function call graph
> > (after inlining):
> >
> > ----FUNCTION CALL GRAPH
> > ------MAIN PROGRAM
> > --------.\mnist_lenet.dml::train
> > ----------.\nn/layers/dropout.dml::forward
> > ----------.\mnist_lenet.dml::predict
> >
> > but it should read as follows
> >
> > ----FUNCTION CALL GRAPH
> > ------MAIN PROGRAM
> > --------.defaultNS::train
> > ----------dropout::forward
> > ----------.defaultNS::predict
> >
> > The namespace handling was changed a while ago. So my question is: was
> > there a necessity to encode the filenames in the namespace or is this
> > just a bug?
> >
> >
> > Regards,
> > Matthias
> >
> >
> >
> >
>

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