On 02/09/2013 07:00 PM, Tiago de Paula Peixoto wrote: > On 02/09/2013 06:02 PM, tcb wrote: >> Hi, >> >> I am trying to read the graphml output of graph-tool's graphml using >> networkx. >> >> https://github.com/networkx/networkx/issues/843 >> >> Unfortunately this does not work with any of the vector_* type property maps >> which graph-tool uses. Have you encountered this issue before? > > Yes, this is expected, because the graphml specification only defines > the following types: boolean, int, long, float, double, or string > If you want another type, you are out of luck. > >> It seems the right thing to do might be to extend your graphml to hold the >> vector_* attributes as detailed: >> >> http://graphml.graphdrawing.org/primer/graphml-primer.html#EXT >> >> Is there some reason why it was done the way it is? How do you manage >> read/writing graphml data to other tools? > > Extending it this way would be the strictly "correct" approach. However, > it has two downsides: Firstly, it is much more cumbersome to > implement. Essentially, the reader must be aware of this whole xml > schema extension stuff, which currently it simply ignores. Secondly, it > does not really fix the problem of interoperability, it only punts > it. Two pieces of software would still need to agree and know about the > extension for it to work. In other words, you still would not be able to > make networkx read the vector types, unless the they modify their > reader. It seems to me that simply adding a nonstandard type is much > more straightforward, albeit "unclean" from the point of view of XML > validity. > > Regarding reading data from other tools, there is no issue, since the > standard types are fully supported. If the user wants to feed graphml > data produced with graph-tool to other programs, then only the standard > types should be used. > >> In the meantime, it might be possible to hack some read support for >> graph-tool's xml into networkx. To this end, could you please advise how to >> parse the 'key1' data (should be two floats) >> >> <node id="n1"> >> <data key="key0">6</data> >> <data key="key1">0x1.5c71d0cb8d943p+3, 0x1.70db7f4083655p+3</data> >> </node> > > The delimiter is a comma, and spaces should be ignored. The individual > values are encoded according to the %a format from C99. This is to > ensure exact binary representation. From the printf manpage: > > a, A (C99; not in SUSv2) For a conversion, the double argument is > converted to > hexadecimal notation (using the letters abcdef) in the style > [-]0xh.hhhhp±; > for A conversion the prefix 0X, the letters ABCDEF, and the > exponent separa‐ > tor P is used. There is one hexadecimal digit before the decimal > point, and > the number of digits after it is equal to the precision. The > default preci‐ > sion suffices for an exact representation of the value if an exact > represen‐ > tation in base 2 exists and otherwise is sufficiently large to > distinguish > values of type double. The digit before the decimal point is > unspecified for > nonnormalized numbers, and nonzero but otherwise unspecified for > normalized > numbers. > > I'm not sure there is any python function which can read this > automatically. You can do it with ctypes: > > >>> from ctypes import * > >>> libc = cdll.LoadLibrary("libc.so.6") > >>> d = c_double() > >>> libc.sscanf(b"0x1.5c71d0cb8d943p+3", b"%a", byref(d)) > 1 > >>> print(d) > c_double(5.402846293e-315)
This should have been:
>>> libc.sscanf(b"0x1.5c71d0cb8d943p+3", b"%la", byref(d))
1
>>> print(d)
c_double(10.888893506588493)
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
