jlizier / jidt Goto Github PK

Figure 2 plot -- the empirical results no longer match the analytic -- I seem 
to have broken something in the conditional TE discrete calculator.

Need to fix this before the v1.1 release.

This has been done for Java, Matlab and Python; replicate for these 
environments.

This simply needs to be done.

Conversion between native octave types and java types is not always working 
correctly in octaveToJavaDoubleArray, octaveToJavaDoubleMatrix, 
octaveToJavaIntArray and octaveToJavaIntMatrix, as identified by Christoph 
Hartmann:

"The bug seems to be in the octaveToJavaDoubleMatrix.m. Whenever the Java 
Matrix is created there with javaObject('org.octave.Matrix',...), it sometimes 
returns an int matrix and sometimes a double matrix. Whenever an int-matrix is 
returned, the .asDoubleMatrix() returns null, which leads to the NullPointer 
Exception. I suspect that this happens because the int-constructor is called 
instead of the double-constructor [2], but different forms of casting the 
values to double or the dimensions to int did not help."

The issue appears to be that octave is somehow not identifying the correct 
method signature in org.octave.Matrix. This bug is repeatable in 
octave/example6, which should load an array of doubles from a file, but somehow 
these are read into octave as integers. It is unclear why.

Solution appears to be to make the typing explicit in the method signatures, 
rather than to let octave decide it for us,

The normalise option exists in MutualInfoCalculatorMultiVariateKraskov and 
others, but for some reason I didn't put it here.
It should be there for the Kraskov technique to work as documented.

Needed for CA demo

As per the changes made for the Conditional MI in Issue 15.

Add these as an option that can be turned on in properties.

See description by Turney and Pantel (2010), which is cited in our 2014 
Frontiers paper on Local Active Info Storage

Found this when running from Matlab -- am not sure why this is

You know what needs doing here ... have matlab run this.

Add conditional entropy estimators for continuous data

blah

As discussed on email

We only need to implement the compute significance methods for this.

Add a GUI -- possibly in python -- to take a data set, tell it which columns to 
compute TE between, select calculator, supply parameters, and compute TE or 
compute TE for a range of parameters and plot them

At the moment, our Kraskov calculators assume that they have k values within 
epsilon in the full joint space. Where the distribution is composed of delta 
functions (i.e. somewhat discretised) this won't be the case - there could be 
many more than k. As such, it may be more correct to use the actual k for each 
observation in contributing digamma(k) - 1/k, then averaging, rather than 
assume the parameter k.
This may add significantly to the runtime however so we could either:
- just issue a warning were this to occur, or
- track the actual k values in an array, then compute digamma(k) - 1/k once for 
each distinct value and add these in to the result.

This will require constructing a kernel conditional MI calculator -- this 
should largely be done from the multivariate TE kernel.
This will allow other parameters to be set, e.g. source history length.

Mimic the usage of underlying mutual information calculators by active 
information storage calculators.
Implement for Gaussian, kernel and KSG estimation.

Large numbers of identical data cause problems for the Kraskov estimator (since 
they violate its underlying assumptions).
Kraskov's toolkit MILCA adds in a small amount of random noise to address this.

We should add a property to do this to all Kraskov calculators.
This has been done for the Kraskov MI calculator in r305, but we still need to 
add it to conditional MI calculators and check that it works ok for TE and AIS.

Just do it

Do it

Follow Wibral et al. approach to automating selection of embedding parameters 
and source-dest delay selection in TE calculators and AIS

And redistribute this jar in a library

Can only do this once the multivariate TE classes have been replaced by one 
directly using a conditional TE calculator (since they depend on this class at 
the moment).

Add an example which calls the jar from NetLogo (I think this is possible)

Duplicate what has been done for MI calculators in issue 31. Thus will 
immediately apply to Kraskov transfer entropy

Fix this in the ant file -- make the dist target compile these and retain them 
for the distribution.

I had left noise addition out by default so that results were repeatable. But 
with a small value of noise this should still be ok. Adding noise will stop us 
from getting crazy errors when systems converge to fixed attractors and we get 
lots of the same data points coming in. This has happened with Rose I think in 
2014, and on email to Sussex in 2015.
Consider this to make sure I'm not missing any good reason not to do it; then 
do it.

Reported by Ipek Özdemir in distribution 0.1.3 for 
infodynamics.measures.continuous.kraskov.MutualInfoCalculatorMultiVariateKraskov
 identified in unit test 
infodynamics.measures.continuous.kraskov.MutualInfoMultiVariateTester.testLocals
AverageCorrectly with a different number of time steps (10000).

This has been already fixed in later releases.

This will improve accuracy of the estimator

As per the summary

This can easily be done for single-time series estimations, by changing the 
code which avoids the same time step to avoid multiple time steps around that.
Presumably we should actually alter the psi(N) here too I think, since we don't 
have a full set of N points going into every neighbourhood count then.

To implement this for the ensemble method would be tricky, and I don't think we 
should try this in the first pass.

Line 559 of TransferEntropyCalculatorMultiVariateKernel should be divided by 
Math.log(2.0)

--joe

Some tips on using aparapi for java here (suggested by Michael Wibral):

http://blogs.amd.com/developer/2011/09/14/i-dont-always-write-gpu-code-in-java-b
ut-when-i-do-i-like-to-use-aparapi/

The ChannelCalculators talk about reordering the source variable to evaluate 
the statistical significance, but the 
MutualInfoCalculatorMultiVariate.computeAverageLocalOfObservations(int[] 
newOrdering) method reorders the second variable (which is now the 
destination). This is because it used to have source variable as the second 
argument.

Should reorganise this code so that it follows a consistent interpretation 
(reordering the source variable - the first variable). This will necessitate 
shuffling the arguments around in the Kraskov calculators. They are currently 
consistent (MI gives right result, TE calculator uses the variables in the 
correct order) but I want this finalised.

Enhancement. Will open separate issues for the conditional MI and 
multi-information calculators.

Currently we just throw vanilla Exceptions for everything.
1. Should we have specific Exception types?
2. Should we think about whether just throwing them or doing something 
different is the best strategy?

Just do it.

Create a mailing list or google group

Following discussion between Wibral, Priesemann and Lizier today, we realised 
that it would be more appropriate for the TE calculator to return specific 
results in different cases where an exception is raised by the Cholesky 
Decomposition (non-positive definite matrices).
These cases are:
1. Non-positive definite covariance matrix between dest past and source -> 
return zero
2. Non-positive definite covariance matrix between dest past and next value -> 
return zero
3. Non-positive definite between all values: a. if others were positive 
definite -> return infinity, else should not come to this point.

What steps will reproduce the problem?
1. Set k_HISTORY property to 0.
2. Compute

This should function but instead crashes.

Can be fixed by implementing an underlying MI calculation if k = 0 is to be 
used. Could change this in the underlying conditional MI calculator in fact.

The actualValue field is populated by the computed info theoretic value * 
observations, which is fine for a chiSquare distribution, but is not correct 
for TE or MI clients. (Should be just the computed info theoretic value)

This depends on either the JavaCall package providing such support, or another 
workaround being found.

Rework multi-information to follow design of mutual information classes and 
hierarchy