-
Notifications
You must be signed in to change notification settings - Fork 17
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
Remove dependence on PyCall #18
Comments
No, EarthMoversDistance.jl is a poor wrapper of an even poorer implementation from last century; I've tried it, it crashes every other time and is very slow. Python code works without hiccups. |
I'd like to keep this issue open, since removing the dependence on PyCall would significantly reduce the build/development time-- even if that means translating python's wasserstein_distance |
Yeah, I mean, we could just rewrite that piece in Julia -- but it's very unlikely to be fixed in the nearest future (: I'm happy with python for now, since it works really well and fast. |
I know I am late to the party here, but SKlearn also involves python calls. And GaussianProcesses.jl is again very slow (regards to optimization of hyperparameters) for when I tried this, so for now this will remain in the code too. |
Agreed, I think this is more of a long term issue to resolve (if possible/feasible) |
I wonder if GaussianProcesses has matured somewhat in the meantime, is there a good comparative performance benchmark to try? |
It looks like PyCall is only used to for the wasserstein_distance. It looks like we can call it from EarthMoversDistance.jl
The text was updated successfully, but these errors were encountered: