PRIMO merge requestshttps://gitlab.ub.uni-bielefeld.de/scs/PRIMO/-/merge_requests2017-10-09T15:50:37+02:00https://gitlab.ub.uni-bielefeld.de/scs/PRIMO/-/merge_requests/23Make PRIMO compatible to networkx 22017-10-09T15:50:37+02:00Jan PöppelMake PRIMO compatible to networkx 2*Created by: jpoeppel*
This PR makes some small changes to the use of networkx so that the new version 2 works while still supporting networkx 1.x (only tested the latest 1.11).
All tests pass with these changes.
I also added a smal...*Created by: jpoeppel*
This PR makes some small changes to the use of networkx so that the new version 2 works while still supporting networkx 1.x (only tested the latest 1.11).
All tests pass with these changes.
I also added a small monkey patch in case 1.x is used since the backward compatible function calls use the list-versions of functions in networkx 1.x while the iterator versions have become standard in 2.0. The monkey patch will override the function names to the iterator versions for 1.x so that we do not have higher memory consumption in this case.
This PR fixes #20 https://gitlab.ub.uni-bielefeld.de/scs/PRIMO/-/merge_requests/22Only add edges in factor Tree when node is connected in BN2017-10-10T09:52:06+02:00Jan PöppelOnly add edges in factor Tree when node is connected in BN*Created by: jpoeppel*
This PR fixes a small error that nodes that have not been connected in the BN (therefore useless nodes) where still connected to the resulting factortree. While this did not really cause an issue when that node co...*Created by: jpoeppel*
This PR fixes a small error that nodes that have not been connected in the BN (therefore useless nodes) where still connected to the resulting factortree. While this did not really cause an issue when that node contained a valid CPT, it did cause a ```FloatingPointError: divide by zero encountered in true_divide``` error, when the CPT of the unconnected node was not set upon setting evidence/message passing.
Fixes #21
https://gitlab.ub.uni-bielefeld.de/scs/PRIMO/-/merge_requests/16Change node name2017-10-10T09:52:36+02:00Jan PöppelChange node name*Created by: jpoeppel*
The GUI allows changing the name of nodes (especially when creating new graphs from scratch) which needs to be supported by Primo. As Primo internally uses actual node objects and their names interchangeably, spec...*Created by: jpoeppel*
The GUI allows changing the name of nodes (especially when creating new graphs from scratch) which needs to be supported by Primo. As Primo internally uses actual node objects and their names interchangeably, special care needs to be taken when changing a node. This PR hopefully changes all relevant parts on the network side. Any inference structures (especially factor tree!) will obviously have to be recreated after changing a name.https://gitlab.ub.uni-bielefeld.de/scs/PRIMO/-/merge_requests/15Changing values of nodes2017-10-10T09:51:43+02:00Jan PöppelChanging values of nodes*Created by: jpoeppel*
This PR adds the function "set_values" to the DiscreteNode class as well as "change_node_values" to the BayesianNetwork class. The former updates the values of a node, updating the dimensions of it's cpt and inval...*Created by: jpoeppel*
This PR adds the function "set_values" to the DiscreteNode class as well as "change_node_values" to the BayesianNetwork class. The former updates the values of a node, updating the dimensions of it's cpt and invalidating it in the process as one cannot assume that the old cpt is still valid. The latter does the same, but will also update the dimensions and invalidates all children of the changed node and should be preferred in general.https://gitlab.ub.uni-bielefeld.de/scs/PRIMO/-/merge_requests/14Allow relativ loading of dbn networks from conf2017-10-10T09:51:19+02:00Jan PöppelAllow relativ loading of dbn networks from conf*Created by: jpoeppel*
DBNSpec currently assumes that the network xbif-files for b0 and 2tbn are located in the working directory. This fix will always search for those files relative to the directory of the conf-file.*Created by: jpoeppel*
DBNSpec currently assumes that the network xbif-files for b0 and 2tbn are located in the working directory. This fix will always search for those files relative to the directory of the conf-file.https://gitlab.ub.uni-bielefeld.de/scs/PRIMO/-/merge_requests/13Added support for properties as meta-data2017-09-12T16:52:50+02:00Jan PöppelAdded support for properties as meta-data*Created by: jpoeppel*
XBIF supports the PROPERTY tag for meta-data on the network, the variable, and the definition level. These changes add an optional flag to the io-methods parse/write called ignoreProperties, which will ignore thos...*Created by: jpoeppel*
XBIF supports the PROPERTY tag for meta-data on the network, the variable, and the definition level. These changes add an optional flag to the io-methods parse/write called ignoreProperties, which will ignore those fields by default (old behaviour) but which can be set to False, which will result in the properties for the network and for the variables to be stored in a new "meta" attribute. When writing these fields will again be ignored unless otherwise specified.
Since the PROPERTY tag has no structure, we are only storing the plain strings in a list in the meta attributes.https://gitlab.ub.uni-bielefeld.de/scs/PRIMO/-/merge_requests/10Create Marginal class as common return type for inference methods2017-03-06T10:25:38+01:00Jan PöppelCreate Marginal class as common return type for inference methods*Created by: jpoeppel*
This is a work in progress. So far I've started creating fundamental tests for the different use cases that we have considered. They still need to be expanded upon with more complex marginals as well as other conv...*Created by: jpoeppel*
This is a work in progress. So far I've started creating fundamental tests for the different use cases that we have considered. They still need to be expanded upon with more complex marginals as well as other convenience functions.
The reason I am already opening the PR is to discuss the proposed interface, which is already quite flexible, but I am not too sure about the dictionary return yet.
Currently I handle a request like `m.get_probabilities({"A":["True","False"]}, returnDict=True})` for a marginal containing the binary variables A and B like so:
`{"True": np.array([P(A=True, B=True), P(A=True, B=False)]), "False": np.array([P(A=False, B=True), P(A=False, B=False)])}.`
A request such as: `m.get_probabilities({"A":["True", "False"], "B": "False"}, returnDict=True})` [note that you do not have to insert single instantiations in lists, but can just specify them as values directly] yields:
`{A: {"True": np.array([P(A=True, B=False)]), "False":np.array(P(A=False,B=False))}, B: {"False": np.array([P(A=True,B=False)])}}`
since the request desires the probability for this combination. When returnDict=False this method basically behaves as Factor.get_potential with the additional convencience of not having to specify single instantiations in lists as well as allowing things like "get_probabilities("A")".