On 02/09/2013 08:37 PM, tcb wrote: > > OK, I think with the strictly correct approach to graphml it might be > possible to read the attributes (if you also write a schema)- but you are > right that it is a lot of added complexity for the fairly simple extensions > you are using (especially perhaps for reading). On the other hand, other > tools then have to write custom readers, which kind of defeats one of the > major benefits of graphml- but others seems to have taken this approach too.
Do you know of any current graphml readers which understand schemas as
well? It seems that reader modification would be unavoidable.
> The modifications to read the vector_* types might be easy enough to make on
> the networkx side- we'll see how it goes.
Given the very adequate fromhex() function you found, a trivial reader for
the (double, float, long double) vector properties would be something like:
>>> prop = '0x1.0000000000000p+1, 0x1.8000000000000p+1'
>>> vec = [float.fromhex(x) for x in prop.split(",")]
>>> print(vec)
[2.0, 3.0]
> Alternatively, I suppose I could get by without modifying anything by making
> two 'float' property maps (pos.x and pos.y)- then combine them again on the
> networkx side- but this is a bit cumbersome.
This would be a way to ensure a strictly valid graphml file, and is
feasible for users which require it. Another alternative would be to
encode it as a string, and decode at the other end.
It is important to note however that in graph-tool regular float/double
properties (not vectors) are also stored in hex format. I'm not sure if
this is a violation of the standard, since I don't know if they specify
exactly how a float is represented, but this may cause problems with
interoperability as well (possibly networkx would also choke). I made
this choice because for my own uses, it is very important that no
information is lost during encoding.
> The other thing is that I have no idea how to write a graphml file from
> networkx that graph-tool could understand.
To simply write a vector type, it would suffice to do the following for
a float type:
>>> prop = ", ".join(float.hex(x) for x in vec)
>>> print(prop)
'0x1.0000000000000p+1, 0x1.8000000000000p+1'
This should be completely readable by graph-tool.
More work would be required to support the python::object properties, if
so desired, but not much. It is just a base64 encoding of a pickled
object.
> It would be nice if there was some format which could be easily used to work
> between graph-tool and networkx (and possible other tools aswell). Do you
> have any suggestions on what would be a better fit?
I think graphml is still better than anything else out there. GML, for
instance, has an even cruder type system (basically only string and
float), and in dot everything is a string.
In the end, I'm obviously biased towards the way it is implemented in
graph-tool (graphml + custom types), since it is easy enough to
implement, and one can guarantee perfect representation of the graph and
its properties.
Cheers,
Tiago
--
Tiago de Paula Peixoto <[email protected]>
signature.asc
Description: OpenPGP digital signature
_______________________________________________ graph-tool mailing list [email protected] http://lists.skewed.de/mailman/listinfo/graph-tool
