Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Kraskov calculators to ensure they use actual k in joint space than assumed k #8

Closed
GoogleCodeExporter opened this issue Jul 23, 2015 · 3 comments

Comments

@GoogleCodeExporter
Copy link

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.

Original issue reported on code.google.com by joseph.lizier on 7 Sep 2012 at 5:47

@GoogleCodeExporter
Copy link
Author

Hat tip to Michael Wibral for finding this one

Original comment by joseph.lizier on 7 Sep 2012 at 7:31

@GoogleCodeExporter
Copy link
Author

Kraskov type 1 may find 0 in the joint space here in fact (because it uses < 
instead of <=) - it should throw an exception in this case

Original comment by joseph.lizier on 12 Sep 2012 at 12:16

@jlizier
Copy link
Owner

jlizier commented Nov 28, 2017

With the inclusion of adding noise to the values by default, we can safely assume that we won't be getting these <= cases anymore for the main KSG estimators. This may still effect the Conditional MI mixed discrete-continuous KSG calculator, which is the only one which does not add noise to the (continuous) data yet. That needs to be fixed regardless, I've opened issue #63 to work on that specifically, rather than continuing under the more general title here.

@jlizier jlizier closed this as completed Nov 28, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants