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

PyGSP #37

Open
mdeff opened this issue Mar 14, 2019 · 1 comment
Open

PyGSP #37

mdeff opened this issue Mar 14, 2019 · 1 comment

Comments

@mdeff
Copy link

mdeff commented Mar 14, 2019

Hi guys, I'm the maintainer of the PyGSP (which you obviously know about). I'm wondering: what is your vision for graphtools? How does it relate to the PyGSP (e.g., different goals, additional features, etc.)? If there's enough common interest, we should maybe consider to join forces. :)

Quickly going over the code and docs it seems that you are quite interested in building graphs from high-dimensional data, which is something we are pretty interested in as well (see e.g., epfl-lts2/pygsp#43).

No problem if you simply prefer to develop your own tools, I'm just being curious. Anyway, thanks for using our work, and for your contributions!

@scottgigante
Copy link
Contributor

Hi @mdeff , thanks for getting in touch! We definitely appreciate your contributions to PyGSP and this opportunity to chat about goals / direction.

graphtools was quite simply born out of the realisation that multiple projects of ours were duplicating code in building graphs from data. In terms of the vision for graphtools, you've more or less hit the nail on the head: our primary goal is building graphs from high-dimensional data, with a focus on computational biology. In its current form, graphtools implements the alpha-decay kernel and landmark operator from PHATE, and the mutual nearest neighbors kernel from MELD.

There are definitely some shared goals here, and I think we can benefit from sharing some of the routines we implement for our graphs (e.g. BaseGraph.shortest_path). However I'm not sure that the specific kernels we are building are necessarily widely-used enough in the GSP community to warrant including them in PyGSP, at least for now.

Happy to hear your thoughts on this, as well as @dburkhardt and @stanleyjs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants