A single way to handle ids of elements in dictionaries about mdf HOT 6 CLOSED

The one concern I have with removing lists is that we don't currently have a way of specifying the order of functions (and to a lesser degree, ports, but I think that may just be a psyneulink-specific issue and one we can work around fairly easily with some pnl-specific parameters). In this example, it's not clear how linear_1 and logistic_1 interact. With lists, [{linear_1 ...}, {logistic_1 ..}] gives an explicit ordering. It could be as simple as a comma-separated string of function names, somewhere, but it's not clear to me where a good place for this is. I think the alternative of enforcing one node = one function would be problematic for psyneulink as well.

from mdf.

@kmantel There are 2 separate issues here, as obviously the json/yaml serialisation has an existing ordering for list or dict entries when written to a text file.

1. Does the new dict format allow preservation of the order when loaded in to Python? In this case it does, through the use of Ordered dicts, so: for f in functions (or nodes, parameters, etc.) will return the function (keys) in the same order as the file, and the elements will be serialised in the same order again if not changed.
2. Does the order of the functions define the order in which they have to be evaluated? In this case I'd say no. We should give the user the freedom to write them in any way, as long as they're consistent, and the reading application should solve the order. So (assuming a is another parameter) 'x = sin(y); y=sin(a)' and 'y=sin(a); x = sin(y)' should both be allowed, and the parser sorts them to the correct evaluation order (or used symbolic manipulation to optimise).

from mdf.

@pgleeson I think the native python handler for JSON can be specified to respect ordering in a JSON file, but the JSON spec states the key/value pairs are unordered. For YAML, the spec also says key/value pairs are unordered. Additionally, the closest-to-native python implementation (pyyaml) does not respect ordering, though it seems like some others have written parsers that do respect it. I think it would be better to be explicit and not rely on non-spec orders for cases it's not clear.

2. This is a fair point. I suppose if the spec is defined as having a clear ordering detectable from the variables inside each function, it works. Additionally, it seems to require the function to always be explicitly written out rather than just listed, if part of any predefined bank of functions. That is, two linear functions would have to be written as something like

{
    "linear_1": {
        "type": "linear",
        "slope": 1
    },
    "linear_2": {
        "type": "linear",
        "slope": 2
    },
    "primary": {
        "<?>": "y = linear_1(linear_2(x))"
    }
}

or just in full symbolic form. After considering this, if we are assuming that every environment can handle generic function parsing, it seems that there shouldn't be a problem with a lack of ordering.

from mdf.

Re your point on 1, yes, that's true, we can't rely that any given parser will read in the dicts in the correct order. My priority with getting the existing api to do it was mainly to help preserve readability of the json (as long as the elements were added in a sensible order) and make sure what gets read in is written identically.

In agreement with your point on 2, that the correct order should be determinable from the expressions themselves, this should be true in general, i.e. if nodes A->B, we shouldn't throw an error if B is defined before A, the order of execution should be determined by the edges. As and where lists are really required we can use them, but I don't believe they are in this case.

Another reason for avoiding lists if possible is that it makes the accessing/parsing of elements fo the graph more uniform (in Python and other potential languages), e.g. graphs['simple'].nodes['input_nodes'] and graphs['simple'].nodes['processing_nodes'].functions['linear_1'] as opposed to iterating over the list and matching ids.

from mdf.

Will be closed by #59

from mdf.

This is standard now in the code.

from mdf.