realrate / causing Goto Github PK

This might be useful in the long run.

Details at https://moocaholic.medium.com/jax-a13e83f49897

Migrated from https://realrate.atlassian.net/browse/CAUSING-84

Check the numerical output of the simple example model and the wage example.

Check if the current Causing implementation 2.x can handle cyclic models.

These ideas are imported from:

• https://github.com/realrate/RealRate-Private/issues/483#issuecomment-1187096621
  I reviewed the literature on causal effects in cyclic systems. See Pearl (2011), p. 5 "On the Statistical Interpretation of Structural Equations". 2011 Pearl On the Statistical Interpretation of Structural Equations.pdf
  This will apply for node and edge in our IME graphs:

Cyclic example model:

1. Y1 <- Y2
2. Y2 <- Y1

Effect of Y2 on Y1: As in the acyclic case, simply intervene on Y2 and compute Y1_new:
effect = Y1_new - Y1_old
So do not cyclicly converge.

• Check if consistent with our closed formula (should be)

• https://github.com/realrate/RealRate-Private/pull/610#issuecomment-1190694946
  "Beispiel 6 Zyklisches System" from the PDF documentation. I am not sure whether this example is implemented in Causing, but once it was.

Because of an historical notation, see https://realrate.ai/download/publications/RealRate%20Kausalanalyse%20mit%20NN.pdf, we use names and variable names that are too complicated from our point of view today. See See Sections 3.3 Exogene finale Effekte, 3.4 Endogene finale Effekte, and 4.3 Partieller, totaler und finaler Graph. So we should rename the variables in the public Causing repository https://github.com/realrate/Causing like this:

Node effects

exj_indiv -> xnodeeffect
eyj_indiv -> ynodeeffect

exj_indivs -> xnodeeffects
eyj_indivs -> ynodeeffects

Edge effects

eyx_indiv -> xedgeeffect
eyy_indiv -> yedgeeffect

eyx_indivs -> xedgeeffects
eyy_indivs -> yedgeeffects

Also, please check, if we use those names in the RealRate-Private repository.

We want to update our PyPI Causing release whenever we made meaningful changes to Causing. This should happen automatically whenever we create a release on github. PyPI secrets have already been saved in the Causing github repo.

• Create a github workflow to upload to PyPI (see https://packaging.python.org/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows/)
• Only upload to test.pypy.org until PR is approved.
• Trigger workflow on release (other triggers are ok while debugging)
• Get a successful upload
• Get PR reviewed and merged
• Test the workflow by creating a release
• Switch to real pypy.org

Instead of using the identification matrices idx and idy - we should use mx and my with None where there is no edge. Then we have all the information available without redundancies.
I wil create an issue for that.

The identification matrices have already been eliminated in the generation of the dot file #19 but without making use of None yet

Because yvars have vastly different scales, the bias terms which are generated during the estimation also do. This makes it hard to decide if the biases are unusually high or not.

• normalize bias by dividing by the yvars stddev (yielding a so called statistical t-value)
• highlight high normalized biases in the output with t-values being larger than 2 in absolute value (and maybe hide less important/less unusual output)

To make Causing usable by people outside of RealRate, we provide documentation at

• https://github.com/realrate/Causing/blob/develop/README.md
• https://github.com/realrate/Causing/blob/develop/docs/education.md

This documentation has been written a while ago and has only been updated sporadically. Read the documentation and look for the following problems (on the develop branch):

• Is it understandable to new users (being able to use it is sufficient, no deep math understanding required)?
• Is it up to date with the code base (general content should be ok, but check code samples and code references)?
• Does the code yield the same results as shown in the documentation?

The estimated SSE of the simple linear model must be lower than the model's SSE. Otherwise, no suggestions can be read from the NN's results.