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

Slow installation due to the underlying dependencies #18

Closed
yzhao062 opened this issue Sep 3, 2018 · 3 comments
Closed

Slow installation due to the underlying dependencies #18

yzhao062 opened this issue Sep 3, 2018 · 3 comments

Comments

@yzhao062
Copy link
Owner

yzhao062 commented Sep 3, 2018

It is noted that PyOD depends on a few libraries, including:

  • keras
  • matplotlib (optional, required for running examples)
  • nose
  • numpy>=1.13
  • numba>=0.35
  • scipy>=0.19.1
  • scikit_learn>=0.19.1
  • tensorflow (optional, required if calling AutoEncoder, other backend also works)

It is getting more serious when we started introducing deep learning models into PyOD which is implemented in Keras (and of course with some backend libraries, e.g., TensorFlow).

In addition, for improving the efficiency, we started using JIT in PyOD, specifically Numba, for accelerating the execution, which uses LLVM compiler to overcome the overhead of Python.

In long run, I am also interested in bringing GPU support for PyOD, which could be done through CUDA programming. However, it will clearly make the installation and maintenance a mess due to the complexity.

Therefore, I would like to gather some ideas regarding comprehensiveness vs efficiency vs complexity for the development of PyOD. What is your opinion? Will the current installation too cumbersome for you?

@pixelsquared
Copy link

What about using docker so that all the dependencies would be contained easily with one command?

@evanmiller29
Copy link

I think that the list of requirements for the project should be as simple as possible to make development as easy as possible. Could we possibly separate out the DL models into their own package (like tensorflow CPU/GPU)?

The other dependencies are probably fine though.

Just saying that because to enable that functionality it does take a bit of work on the users end, and if it was separate then we could help them through the process a bit more easily.

@yzhao062
Copy link
Owner Author

closed the thread as we have separated dl related libraries out as suggested by Evan.

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

3 participants