You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This could be very useful for implementing generic algorithms on different cell types.
Take this example:
struct E
{
[GraphEdge]
cellid neighbor;
[GraphEdgeWeight]
double weight;
}
cell V
{
[CompositeEdge]
List<E> edges;
}
Currently ICell.GetField<T> only accepts non-generic types, so user-defined composite edge types are not possible. If we implement a generic field, we can then write ICell.EnumerateValues<IField>("CompositeEdge") without worrying about the type. Then, an algorithm can proceed and inspect [GraphEdge] and [GraphEdgeWeight] from the generic field respectedly.
The text was updated successfully, but these errors were encountered:
@yatli I just saw this and yeah this would be a most excellent addition and suits my needs well. Right now I have all of this type of generic typing and graph exploration in code I hand write against the GE generated code. What do we need to do to get started on this?
This could be very useful for implementing generic algorithms on different cell types.
Take this example:
Currently
ICell.GetField<T>
only accepts non-generic types, so user-defined composite edge types are not possible. If we implement a generic field, we can then writeICell.EnumerateValues<IField>("CompositeEdge")
without worrying about the type. Then, an algorithm can proceed and inspect[GraphEdge]
and[GraphEdgeWeight]
from the generic field respectedly.The text was updated successfully, but these errors were encountered: