Determine if any of the following formats are worth providing an export feature for expression trees.

ONNX
NNEF

Test Python bindings for interoperability with SymPy.

Is there value in providing storage support in phylanx or hpx for SPDK?

This should allow for accessing columns/rows relative to the end of the array instead of relative to the beginning.

If we go to the generate_tree.cpp:

And change the expected values in the following code:

    test_generate_tree("A + B", patterns, variables, 42.0);
    test_generate_tree("A + (B + C)", patterns, variables, 55.0);
    test_generate_tree("A + (B + A)", patterns, variables, 83.0);
    test_generate_tree("(A + B) + C", patterns, variables, 55.0);

to something that should obviously fail such as :

    test_generate_tree("A + B", patterns, variables, 142.0);
    test_generate_tree("A + (B + C)", patterns, variables, 155.0);
    test_generate_tree("A + (B + A)", patterns, variables, 183.0);
    test_generate_tree("(A + B) + C", patterns, variables, 515.0);

where, A= 41.0, B=1.0 and C=13.0, the test still passes.

Tested with current master as of today. Commit 13b8f64
GCC 6.4

As a first step towards implementing Logistic Regression in Phylanx, below is a simple implementation of the logistic regression algorithm in Python.

# From: https://gist.github.com/justwagle/0a75572e7b34252916dc9a5c894a4ef0
import numpy as np
from sklearn.linear_model import LogisticRegression
from sklearn import datasets

data=datasets.load_breast_cancer()
X = data.data[:,:2]
Y = data.target

def sigmoid(x):
    return 1.0 / (1.0 + np.exp(-x))

def MyLogisticRegression(x, y, iterations, alpha):
    w = np.zeros(x.shape[1])
    Transx = x.transpose()
    for step in range(iterations):
        g = np.dot(x, w)
        pred = sigmoid(g)
        error = pred - y
        gradient = np.dot(Transx, error)
        w = w - alpha * gradient
    return w

sklearnlr = LogisticRegression(fit_intercept=False)
sklearnlr.fit(X, Y)

print ("From SKLEARN:")
print (sklearnlr.coef_)

weights = MyLogisticRegression(X, Y, iterations = 750, alpha = 1e-5)
print ("From ours:")
print (weights)

Primitives required for the above algorithm are as follows :

• N Dimensional Array
• Transpose Operation
• Dot Operation
• + , - , * , / Operations
• assignment (store())
• Exponential Calculation
• zero-initialized arrays (or initialized with any value)

At some future point, Investigate potential Phylanx/HPX integration opportunities in NNVM/TVM.

http://tvmlang.org/2017/08/17/tvm-release-announcement.html
http://tvmlang.org/

Migrate Phylanx data primitives from Eigen to Blaze.

• Update the CMake scripts to find Blaze - PR #71
• The big sweep - PR #78
  • Serialization
  • node_data
  • Update primitives
  • Port tests to Blaze
• Update the CI System
  • @khuck's buildbot
  • AppVeyor
  • Circle-CI
• Update build instructions on wiki
• Integrate HPX into Blaze for parallelizing matrix operations
  • PR on Blaze project: https://bitbucket.org/blaze-lib/blaze/pull-requests/15

The Release and RelWithDebInfo builds of Phylanx crash when the phylanx module is imported into Python.

This was caused by __argc and __argv not getting set correctly before passing them to HPX.

phylanxrun.py and the compiled Phylanx Python-C module (phylanx.cpython-*.so) currently do not install into the CMAKE_INSTALL_PREFIX directory. The files are installed into the CMake build directory.

In the Python-C module's case, it does not install into the default PYTHONPATH. Strongly encourage some type of cmake-setup.py solution. This documentation looks like a useful guide.

The Phylanx Python-C module should install into a directory like $INSTALL_DIR/lib/pythonX/site-packages/phylanx/ where X is the correct version of Python - setup.py will do this automatically. The Python module also needs an __init__.py file.

Set up a buildbot system at UO for building HPX, APEX, Phylanx and executing tests.

Systems:

• x86_64 linux delphi.nic.uoregon.edu
  • gcc
• Power8 Linux (minotaur,centaur).nic.uoregon.edu
  • xlc, clang?
• KNL Linux grover.nic.uoregon.edu
  • gcc
  • intel
• Windows, if possible (Monil's machine)
  • msvc

The buildbot master configurations will be as simple as possible, and most of the complexity will reside in scripts that are in the Phylanx repository. That way, the configure/build/test cycle can be executed outside of the buildbot environment for fixing failed tests.

For portability (i.e. windows support), should be scripts be in Python instead of bash? Or does Windows support bash scripting (do we require the windows subsystem for linux)?

The build support will include the ability to specify the git branch for each of HPX, APEX, Phylanx.

Todo:

• set up buildbot service on ktau (allows external clients to connect)
• install buildbot clients on delphi, centaur, grover, windows
• basic script for x86_64 linux
• port to knl
• port to power8
• port to windows (covered by AppVeyor)

Execution primitives

• Provide a Phylanx 'context' in users create variables. This should make execution easier to manage for end users.
• Determine if contexts should be managed without user interaction (default behavior)
  • Create a "stack-machine" for creating contexts and manipulating contexts
  • Users push/pop contexts in a fashion similar to OpenGL or determine if contexts can be exposed to users without stack-machine interfaces
    • Users create contexts and tell phylanx to execute them.

Data Primitives

• Scalar
  • bool
  • int
  • double
  • float
  • complex
• N-dimensional arrays (bool, int, double, float, complex)
• N-dimensional array initialized by 0, 1, or a random value (Gaussian random should be fine)
• N-dimensional array layout by row and column
• N-dimensional array layout by space filling curves (Peano, z-order, Moore, Hilbert).
  • Array tiles/blocks stored on a node are arranged in-memory using a space filling curve.
  • Space-filling curves create a "cache oblivious" effect.
  • Example: https://link.springer.com/chapter/10.1007/11752578_126
• N-dimensional array storage using 'resilient' (NoSQL/cloud) data structures
• Sparse N-dimensional array

Operation Primitives

• The 5 basic operations:
  • map (#307), parallel_map (#371)
  • filter (#308)
  • fold (#309)
  • scan
  • join_update
• N-dimensional array operation "get shape"
• N-dimensional indexing
• DAG node to represent numpy-style 'broadcast' for operations
• Element-wise addition
• Element-wise subtraction
• Matrix multiplication (@Hapoo, see #38)
• Element-wise division (@hkaiser, see #49)
• Element-wise power/square root (@parsa, see #100 )
• Exponential function (@justwagle, see #45)
• Consider creating special nodes for HPX's linear algebra/BLAS wrapper
• SpMV (Sparse Matrix-Vector Multiply)
• SDDMM (Sampled Dense-Dense Matrix Product)
• MTTKRP (Matricized Tensor Times Kharti-Rao Product)
• Matrix transposition
• Matrix inversion
• Matrix determinant
• Axis operations (set, swap, ...)
• Slicing - returns a view
• Joining (joins matrices) (see #170)
• Diagonal slicing - Return an array or matrix (dense/sparse) slice
• Triangular indexing - Get the upper or lower triangle of an array
• Project product operation (dot product)
• Vector product operation (cross product) (@parsa, see #99)
• Checkpoint operation for a node
• Scalar, nd-array, and matrix types should either have a method to create a 'randomize' node or there should be a function provided by phylanx that randomizes input primitives
• Support expressing linear algebra operations
• Retrieve the index set of an nd-array, vector, or matrix
• Use the index set of an nd-array, vector, or matrix for masks/logical assignment
  • i.e. A[ A.indices() % 2 == 0 ] = 1.0

I/O Primitives

• Store operation to variable nodes (@Hapoo)
• Read and write results from/to disk (@hkaiser, see #27)
• Write results to Uri/url
• Write results to standard output (@hkaiser, see #103)

Control Structure Primitives

• Conditional operators (==, !=, <, >, <=, >=) (@hkaiser, see #49)
• Boolean operations (&&, ||) (@hkaiser, see #49)
• Unary operations (!, -) (@hkaiser, see #52)
• if(cond, true_case, false_case) (@aserio, see #74)
• while(cond, body) repeat evaluating body until cond becomes false (@hkaiser, see #49)
• block(...): sequentially evaluate all given arguments (@hkaiser, see #54)
• parallel_block(...): concurrently evaluate all given arguments (@hkaiser, see #54)

The following use case may break things:

hpx::future<phylanx::expression_tree::primitive_result_type> f;
{
    phylanx::execution_tree::pattern_list patterns = {
        phylanx::execution_tree::primitives::add_operation::match_data
    };

    phylanx::execution_tree::variables variables = {
        {"A", create_literal_value(41.0)},
        {"B", create_literal_value(1.0)}
    };

    phylanx::execution_tree::primitive p =
        phylanx::execution_tree::generate_tree(
            "A + B", patterns, variables);       

    f = p.eval();

    // let primitive (expression tree) go out of scope
}

f.get();   // wait for result to be computed

We need to adapt all primitives to keep itself alive until evaluation has finished.

Negative values passed to primitives results in the following exception :

{function}: phylanx::execution_tree::compiler::operator()()
{file}: /home/bibek/Dropbox/GitHub/phylanx/src/execution_tree/compiler/compiler.cpp
{line}: 376

{what}: couldn't fully pattern-match the given expression: -1: HPX(bad_parameter)

terminate called after throwing an instance of 'hpx::detail::exception_with_info<hpx::exception>'
  what():  couldn't fully pattern-match the given expression: -1: HPX(bad_parameter)

Reproduction

Change any of the parameters in the slicing primitive in the lra_csv example from the repository to -1.

e.g. Changing slice(file_read_csv(filepath), 0, 569, 0, 30) to slice(file_read_csv(filepath), 0, 569, -1, 30) as seen in the code snippet below.

char const* const read_x_code = R"(block(
    //
    // Read X-data from given CSV file
    //
    define(read_x, filepath,
        slice(file_read_csv(filepath), 0, 569, -1, 30)
    ),
    read_x
))";

Currently, the matching of expressions against patterns relies on add-hoc matching patterns to be provided. We should let the primitives themselves expose an appropriate pattern.

A possible way would be to expose the pattern as a constexpr member variable of the primitive, for instance:

namespace phylanx { namespace execution_tree { namespace primitives
{
    class HPX_COMPONENT_EXPORT add_operation
        : public base_primitive
        , public hpx::components::component_base<add_operation>
    {
    public:
        constexpr static char const* const match_pattern = "_1 + __2";

        // ...
    };
}}}

We need something that is opposite of slicing i.e. joining matrices. Also, It would be useful to have primitives that provides similar functionality as hstack and vstack in numpy.

It would be better if we could have a primitive that performs file read as well as slicing.
Currently, we have two primitives, one for slicing and one for reading file.

This should be done in a way that all primitives almost automatically have performance counters associated with each of them. We should at least create two performance counters for each of the primitives:

/phylanx{locality#N/<primitive-name>}/invocation-count
/phylanx{locality#N/<primitive-name>}/execution-time

Our CMake configuration is stripping all builds, release, relwithdebinfo, debug all the time when building the install target. This is only supposed to happen with the install/strip target, not install.

I am using CMake 3.9.3

Required primitives:

• Scalar-matrix multiplication
• Matrix transpose
• Matrix multiplication
• Matrix addition / subtraction
• Slicing
• Dot product
• Identity matrix similar to numpy.identity (#146)
• Elementwise comparison similar to numpy (#187)
• Return a matrix with the input vector on its diagonal, similar to numpy.diag (#186)

Some tests fail when I issue make tests command after CMake configuration but pass if first do the make and then make tests. The tests are:

• tests.unit.execution_tree.generate_tree
• tests.unit.primitives.invoke_operation
• tests.unit.python.ast.generate_ast
• tests.unit.python.ast.node
• tests.unit.python.ast.traverse_ast
• tests.unit.python.ast.python_builds_ast

In order to match the two supported use cases of if (i.e. if(cond, true_case, false_case) and if(cond, true_case) ) we currently use if(_1, __2). This will not warn the user that she is passing too many arguments to if once she exceeds three.

A novel way to express this use case or the ability to describe multiple map conditions is desired.

BLAS is required by some Blaze functions we use in Phylanx. e.g. matrix inversion and matrix determinant

Needs CMake support.

Building Pybind on KNL with Intel 18 (with 6.3 glibc/glibc++) fails:

/var/lib/buildbot/slaves/phylanx/knl-icc18-release/build/tools/buildbot/src/pybind11-2.2.0/include/pybind11/numpy.h(1449): error: no instance of function template "pybind11::detail::vectorize_helper<Func, Return, Args...>::run [with Func=double (*)(int, float, double), Return=double, Args=<int, float, double>]" matches the argument list
            argument types are: (pybind11::detail::conditional_t<true, pybind11::array_t<pybind11::detail::remove_cv_t<pybind11::detail::remove_reference_t<int>>, 16>, int>, pybind11::detail::conditional_t<true, pybind11::array_t<pybind11::detail::remove_cv_t<pybind11::detail::remove_reference_t<float>>, 16>, float>, pybind11::detail::conditional_t<true, pybind11::array_t<pybind11::detail::remove_cv_t<pybind11::detail::remove_reference_t<double>>, 16>, double>,
                      pybind11::detail::make_index_sequence<3UL>, pybind11::detail::select_indices<true, true, true>, pybind11::detail::make_index_sequence<3UL>)
          return run(args...,
                 ^
/var/lib/buildbot/slaves/phylanx/knl-icc18-release/build/tools/buildbot/src/pybind11-2.2.0/include/pybind11/numpy.h(1467): note: this candidate was rejected because arguments do not match
      template <size_t... Index, size_t... VIndex, size_t... BIndex> object run(
                                                                            ^

See http://ktau.nic.uoregon.edu:8020/builders/knl-icc18-release/builds/133/steps/Compile%20Pybind/logs/stdio for details.

Literature review papers/implementations of tree transducers for expression tree optimization.

• Make a state transition table type for storing expression tree transducers. The table captures:
  • The current state of a tree traversal
  • A proposed next state to transition to
  • An input symbol to match
  • An output symbol to "generate" (the state or type that is assigned to a child node in the tree being traversed)
  • A double (the likelihood of a transition/symbol production - default value is 1.0).
• The input symbol could be a function that is used to test for a boolean decision on the state and it's input symbol that's being matched.
• The tabular representation will allow for additive composition operations over sets of transducers
  • Pseudo-code: transducer = + reduce [ transducer_set ... ]).
• This should also make the transducer operation fairly straight forward. each visit in the tree, the state transition table is carried by reference and used to look up what the transducer should do in it's current state (input symbol), and generate the new output value then move the transducer into the next state.

Currently, the literal_value has the following drawbacks:

• It has a bad name, variable would be better
• It has to be constructed differently compared to all the other primitives (its constructor expects a node_data instance)
• It should be able to store a primitive_result_value (nil, bool, std::int64_t, std::string, or node_data)

A source code review of SymPy recovered this gem. The class 'DummyNumber', on line 22, has a description of the class requirements necessary for providing a SymPy 'Number'. This ticket will be expanded to include additional examples or requirements necessary for SymPy integration.

• A 'Number' type

As a reminder...

Currently our node_data data container may cause excessive memory operations. We have to make sure this does not cause additional overheads.

Submitted bug to Blaze:
https://bitbucket.org/blaze-lib/blaze/issues/154/compilation-error-on-knl-with-march-knl

Essentially, because Phylanx uses -Werror, converting the bit value to a _MM_PERM_ENUM value is not allowed.

Without this fix, KNL can't build with -march=knl (which enables AVX 512 vector instructions). With it, the KNL build finishes and tests just fine.

I get the following error when building on Mac:

clang: error: invalid argument '-current_version 0.0.1' only allowed with '-dynamiclib'
make[2]: *** [bin/_phylanxd.cpython-36m-darwin.so] Error 1
make[1]: *** [python/src/CMakeFiles/phylanx_py.dir/all] Error 2
make: *** [all] Error 2

It seems CMake expects _phylanxd.cpython-36m-darwin.so to be only loaded but not linked. For more info please see https://goo.gl/BQqJ6X

Dirty fix to work around this:
Replace -bundle with -dynamiclib in {BUILD_DIR}/python/src/CMakeFiles/phylanx_py.dir/link.txt once the configuration is done.

When HPX and Phylanx are built with JEMalloc 5.0, three of the tests fail:

11/15 Test #11: tests.unit.python.ast.generate_ast ........***Failed    0.11 sec
Couldn't load _phylanx(d) extension module:  /usr/local/jemalloc/5.0.1/lib/libjemalloc.so.2: cannot allocate memory in static TLS block
sys.path:  ['/var/lib/buildbot/slaves/phylanx/ktau-debug/build/tests/unit/python/ast', '/var/lib/buildbot/slaves/phylanx/ktau-debug/build/buildbot/build-ktau-x86_64-Linux-gcc/phylanx-Debug/python/build/lib.linux-x86_64-3.5', '/usr/lib/python35.zip', '/usr/lib/python3.5', '/usr/lib/python3.5/plat-x86_64-linux-gnu', '/usr/lib/python3.5/lib-dynload', '/usr/local/lib/python3.5/dist-packages', '/usr/lib/python3/dist-packages', '/var/lib/buildbot/slaves/phylanx/ktau-debug/build/buildbot/build-ktau-x86_64-Linux-gcc/phylanx-Debug/python/build/lib.linux-x86_64-3.5/phylanx']
os.environ['PATH']:  /var/lib/buildbot/slaves/phylanx/ktau-debug/build/buildbot/build-ktau-x86_64-Linux-gcc/hpx-Debug/lib:/var/lib/buildbot/slaves/phylanx/ktau-debug/build/buildbot/build-ktau-x86_64-Linux-gcc/phylanx-Debug/lib:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/snap/bin:/usr/local/java/jdk1.8.0_11/bin
phylanx_bindir:  /var/lib/buildbot/slaves/phylanx/ktau-debug/build/buildbot/build-ktau-x86_64-Linux-gcc/phylanx-Debug/lib
hpx_bindir:  /var/lib/buildbot/slaves/phylanx/ktau-debug/build/buildbot/build-ktau-x86_64-Linux-gcc/hpx-Debug/lib

      Start 12: tests.unit.python.ast.node
12/15 Test #12: tests.unit.python.ast.node ................***Failed    0.09 sec
Couldn't load _phylanx(d) extension module:  /usr/local/jemalloc/5.0.1/lib/libjemalloc.so.2: cannot allocate memory in static TLS block
sys.path:  ['/var/lib/buildbot/slaves/phylanx/ktau-debug/build/tests/unit/python/ast', '/var/lib/buildbot/slaves/phylanx/ktau-debug/build/buildbot/build-ktau-x86_64-Linux-gcc/phylanx-Debug/python/build/lib.linux-x86_64-3.5', '/usr/lib/python35.zip', '/usr/lib/python3.5', '/usr/lib/python3.5/plat-x86_64-linux-gnu', '/usr/lib/python3.5/lib-dynload', '/usr/local/lib/python3.5/dist-packages', '/usr/lib/python3/dist-packages', '/var/lib/buildbot/slaves/phylanx/ktau-debug/build/buildbot/build-ktau-x86_64-Linux-gcc/phylanx-Debug/python/build/lib.linux-x86_64-3.5/phylanx']
os.environ['PATH']:  /var/lib/buildbot/slaves/phylanx/ktau-debug/build/buildbot/build-ktau-x86_64-Linux-gcc/hpx-Debug/lib:/var/lib/buildbot/slaves/phylanx/ktau-debug/build/buildbot/build-ktau-x86_64-Linux-gcc/phylanx-Debug/lib:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/snap/bin:/usr/local/java/jdk1.8.0_11/bin
phylanx_bindir:  /var/lib/buildbot/slaves/phylanx/ktau-debug/build/buildbot/build-ktau-x86_64-Linux-gcc/phylanx-Debug/lib
hpx_bindir:  /var/lib/buildbot/slaves/phylanx/ktau-debug/build/buildbot/build-ktau-x86_64-Linux-gcc/hpx-Debug/lib

      Start 13: tests.unit.python.ast.traverse_ast
13/15 Test #13: tests.unit.python.ast.traverse_ast ........***Failed    0.07 sec
Couldn't load _phylanx(d) extension module:  /usr/local/jemalloc/5.0.1/lib/libjemalloc.so.2: cannot allocate memory in static TLS block
sys.path:  ['/var/lib/buildbot/slaves/phylanx/ktau-debug/build/tests/unit/python/ast', '/var/lib/buildbot/slaves/phylanx/ktau-debug/build/buildbot/build-ktau-x86_64-Linux-gcc/phylanx-Debug/python/build/lib.linux-x86_64-3.5', '/usr/lib/python35.zip', '/usr/lib/python3.5', '/usr/lib/python3.5/plat-x86_64-linux-gnu', '/usr/lib/python3.5/lib-dynload', '/usr/local/lib/python3.5/dist-packages', '/usr/lib/python3/dist-packages', '/var/lib/buildbot/slaves/phylanx/ktau-debug/build/buildbot/build-ktau-x86_64-Linux-gcc/phylanx-Debug/python/build/lib.linux-x86_64-3.5/phylanx']
os.environ['PATH']:  /var/lib/buildbot/slaves/phylanx/ktau-debug/build/buildbot/build-ktau-x86_64-Linux-gcc/hpx-Debug/lib:/var/lib/buildbot/slaves/phylanx/ktau-debug/build/buildbot/build-ktau-x86_64-Linux-gcc/phylanx-Debug/lib:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/snap/bin:/usr/local/java/jdk1.8.0_11/bin
phylanx_bindir:  /var/lib/buildbot/slaves/phylanx/ktau-debug/build/buildbot/build-ktau-x86_64-Linux-gcc/phylanx-Debug/lib
hpx_bindir:  /var/lib/buildbot/slaves/phylanx/ktau-debug/build/buildbot/build-ktau-x86_64-Linux-gcc/hpx-Debug/lib

These tests execute fine with the system allocator and with tcmalloc from gperftools 2.5. Apparently there is a problem when dlopen() is used to open the libjemalloc.so library from inside the python interpreter. This error does not happen if the libjemalloc.so library is preloaded before executing python.

All primitives expose their functionality through their eval (or eval_direct) action. By default those are invoked asynchronously, i.e. run on a new HPX thread. For certain operations this creates too much overhead and could be optimized by invoking the corresponding direct action instead (eval_direct). In general it is not always possible to make the decision at compile time which of those actions to invoke.

This ticket is asking for two functionalities

• add compile-time heuristics to make that decision at compile time, if possible (for instance for constant values or simple mathematical expressions)
• add a means of making this decision at runtime (this most probably involves instrumentation using APEX - @khuck)

In both cases this decision has to be made on a case by case basis, i.e. for each action invocation.

Provide customized file readers for the following formats to assist with algorithm debugging. This is an arbitrary ordering.

• Comma-Separated Values (CSVs) (done via #93)
• Matrix Market
• NumPy text storage format
• NumPy binary storage format
• HDF5
• C++ Hypertable library

Review these formats and assess the level of effort and potential prioritization. Note, some might not be worth the effort implementing. May need to contact some projects to assess partnership opportunities.

• Review scikit-learn formats, select candidates
  • http://scikit-learn.org/stable/datasets/index.html
• Pandas dataframe formats
  • https://pandas.pydata.org/pandas-docs/stable/io.html
• Pandas dataframe frame type description
  • https://pandas.pydata.org/pandas-docs/stable/generated/pandas.DataFrame.html
• Apache Arrow
  • https://arrow.apache.org
• Apache Parquet
  • https://parquet.apache.org
• SVM-Light
  • http://svmlight.joachims.org/
• Attribute-Relation File Format (ARFF)
  • https://weka.wikispaces.com/ARFF
  • https://www.cs.waikato.ac.nz/ml/weka/arff.html

This is meant to be a sketch of an idea how we could visualize the evaluation of an execution tree. Let's assume we have a simple expression store(A, add(B, C)), then the following visualization allows to quickly understand what part of the expression evaluation took how long:

An implementation of such a visualization would require to add some functionalities:

• associate a name with every instantiated primitive (possibly derived from the source code line the primitive was created from) (see #126)
• Generate topology of execution tree in a commonly used string format (see #148, #154)
• (optionally) measure the execution counts and times for each primitive (instrument primitive::eval and primitive::eval_direct actions), this could be done using performance counters (see #96)

@kisaacs, @khuck please add more tasks to this list from your perspective

Later on, the infrastructure built for this may be used to adaptively change the evaluation of parts of the execution tree by dynamically switching to direct execution in cases where the asynchronous (default) execution may impose too much overheads (see #121).

The add primitive misses tests for certain supported use cases (matrix + scalar, etc.).

Phylanx DAGs should be exportable to a JSON formatted file for analysis and visualization purposes. preference is to support JSON processing offered by NetworkX.

Potential (free and open) data sets that are available for study and experimentation.

Popular Places for Data

• UC Irvine Machine Learning Repository
• UC Irvine KDD data sets
• MNIST
• ImageNet
• COCO dataset part1
• COCO overview
• COCO related
• Python NLTK
• NLTK github
• GRAIL data
• Photo Tourism data set
• Local image descriptors
• Kinect Gesture Data
• B3DO: Berkeley 3-D Object Dataset
• IROS 2011 Paper Kinect Dataset
• RGB-D SLAM Dataset
• NYU Depth
• RGB-D Object Dataset
• LabelMe

Medical Data

• Cancer Imaging Archive
• National Cancer Institute
• Cancer Genomics
• NCI repository
• OpenFMRI data
• Alzheimer's data
• Open Neuroscience data links
• Wikipedia listing

Graph Data

• Sparse matrix data sets
• SNAP

Compilations of data

• MLData repository
• Deeplearning listing
• BigML listing
• Wikipedia listing

Secondary - maybe considered small?

• http://www.cs.toronto.edu/~delve/data/datasets.html
• http://cdb.ics.uci.edu/cgibin/LearningDatasetsWeb.py
• http://www.cs.ox.ac.uk/activities/machinelearning/applications.html

I am getting these errors when building on x86_64 with python 3.3.4 and gcc 7.1:

running build
running build_py
creating build
creating build/lib.linux-x86_64-3.3
creating build/lib.linux-x86_64-3.3/phylanx
copying /home/users/khuck/src/phylanx/src/phylanx/python/phylanx/__init__.py -> build/lib.linux-x86_64-3.3/phylanx
creating build/lib.linux-x86_64-3.3/phylanx/ast
copying /home/users/khuck/src/phylanx/src/phylanx/python/phylanx/ast/__init__.py -> build/lib.linux-x86_64-3.3/phylanx/ast
creating build/lib.linux-x86_64-3.3/phylanx/util
copying /home/users/khuck/src/phylanx/src/phylanx/python/phylanx/util/__init__.py -> build/lib.linux-x86_64-3.3/phylanx/util
running build_ext
copying /home/users/khuck/src/phylanx/build-delphi-x86_64-Linux-gcc/phylanx-Debug/bin/_phylanxd.cpython-33m.so -> /storage/users/khuck/src/phylanx/build-delphi-x86_64-Linux-gcc/phylanx-Debug/python/build/lib.linux-x86_64-3.3/phylanx
error: /home/users/khuck/src/phylanx/build-delphi-x86_64-Linux-gcc/phylanx-Debug/bin/_phylanxd.cpython-33m.so: No such file or directory
make[2]: *** [python/build/timestamp] Error 1
make[1]: *** [python/CMakeFiles/python_setup.dir/all] Error 2
make: *** [all] Error 2

When I look in that directory, I see _phylanxd.so, but not _phylanxd.cpython-33m.so. I have no idea where this is coming from in the CMake infrastructure...

The dimensions used/returned from node_data have inconsistent ordering (partially [rows, columns], partially [column, rows]). This is confusing and error prone and needs fixing.

Below are a couple of capabilities that could be added or extended to the ast-matcher that will be useful for testing. The capabilities can be used to perform ast/ir DAG analysis and optimization. The capabilities provide a reasonable way to get performance improvements (stochastic and/or heuristic) into the DAG analyzer/optimizer.

The capabilities will be useful when the data layout cost modeling is completed. The capabilities can provide further optimization mechanisms when the APEX and visualization technologies are available.

The capabilities are:

• Provide a "finite-state-machine styled" mechanism to create a set of ast/ir DAGs that can be used to perform exact matches against given an input ast/ir DAG.
• Provide a finite-state-transducer (weighted and un-weighted) that modifies or creates a new ast/ir DAG given an input ast/ir DAG. The transducer can be used to create, store, and apply stochastic and/or heuristic optimizations.
• Provide a hidden-markov-model or conditional random field styled mechanism that modifies or creates a new ast/ir DAG given an input ast/ir DAG. This technology is typically found in spelling correction systems and could be reapplied in this domain to create, store, and apply stochastic and/or heuristic optimizations.
• Provide serialization support (load/store) for each capability.
• Expose an api to python in order to simplify or facilitate fast phylanx fsms, fsts, hmms, or crf creation.

An existing open source technology that reflects a reasonable and extensive implementation of these capabilities can be found in the OpenFST project. The transducer and hmm capabilities can be considered a "machine learning" optimization capability. reference material

Tests need to run for Release as well as Debug. Currently, Debug works and Release segfaults.
--Steve

Define is not working as expected.
An example of this would be the one seen in the LRA example where defines inside the body of the loop were not getting executed more than once and each subsequent iteration of the loop was using old values.

When the attached Dockerfile is used to build Phylanx on Fedora, the resulting Python library does not run.

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/root/.local/lib/python3.6/site-packages/phylanx-0.0.1-py3.6-linux-x86_64.egg/phylanx/__init__.py", line 65, in <module>
    init_hpx_runtime()
RuntimeError: partitioner::add_resource: Creation of 2 threads requested by the resource partitioner, but only 1 provided on the command-line.
[root@9d0aeb8d4ab0 build]#

PhylanxReleaseDockerfile.txt

Currently, node_data performs a deep-copy operation on each assignment. Changing this to a shallow-copy operation might help reducing overheads. This has to be done very carefully, though as it may have implications for concurrent data access.

See here for details:

• Issue 38 - Introduce custom operations for vectors and matrices - BitBucket
• Vector and Matrix Customization/The map() Functions - Blaze Documentation - BitBucket

At some future point, examine the ONNX (Open Neural Network Exchange) initiative to see if there's an integration point or value in providing an integration point. Note, it's an application (or rather, domain) specific capability.

https://github.com/onnx/onnx

other options:
NNEF

Implement Morton-order (Z-curve), Peano curve, and Hilbert curve access operations to Blaze matrices.

Use pybind11 to create the python module bindings for phylanx::ast structures.

We should add inspect tool to Phylanx like the one we have for HPX.