-
Notifications
You must be signed in to change notification settings - Fork 91
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
Add more convenience constructors #131
Comments
Is it a bug though? Not rather a new feature? I fully agree with your first point, there is also an older issue for that:: #98 About the second part, I feel like we have too many constructors as it might start to get confusing, so I am in favor of also creating factory functions with different names, such as But we probably should also support tuples more. Then one could also write |
sorry, I accidentally clicked on the "bug" button when opening an issue and now I cannot remove the label.
SimpleGraph(src::AbstractVector{<:Integer}, dst::AbstractVector{<:Integer}) is pretty natural and semantically unambiguous. It is something that you can find out by yourself without digging in the documentation. SimpleGraph((src, dest)::Tuple{AbstractVector{<:Integer}, AbstractVector{<:Integer}}) is another option |
PR #301 tackles the first part of your request, can you take a look @CarloLucibello? |
The type
GNNGraph
from GraphNeuralNetworks.jl is aGraphs.AbstractGraphs
and implements the corresponding interface, therefore it would be nice to make the following code work by providing an appropriate constructor:Moreover, we could also have the following constructor:
which is more concise and discoverable than
The text was updated successfully, but these errors were encountered: