home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / theory / 2772 < prev    next >
Encoding:
Text File  |  1992-12-31  |  14.0 KB  |  383 lines

  1. Newsgroups: comp.theory
  2. Path: sparky!uunet!munnari.oz.au!metro!mama!naylor
  3. From: naylor@research.canon.oz.au (William Naylor)
  4. Subject: randomized-hash graph-iso algorithm - more discussion
  5. Message-ID: <C0402I.L7p@research.canon.oz.au>
  6. Sender: news@research.canon.oz.au
  7. Organization: Canon Information Systems Research Australia
  8. Date: Thu, 31 Dec 1992 05:47:06 GMT
  9. Lines: 372
  10.  
  11. A month ago I posted details of a randomized algorithm to attack the
  12. graph isomorphism problem, based on hashing both graphs with a 
  13. carefully, but randomly constructed hash function.  
  14. I argued that the success of this algorithm
  15. in solving very large practical problems suggests that graph isomorphism
  16. is probably in P.  Then I argued that existence of a P algorithm for 
  17. graph isomorphism probably implies the existence of a P algorithm 
  18. for graph sub-isomorphism.  My conclusion was that the Gismondi-Swart 
  19. strategy for proving P=NP has a reasonable chance of success, 
  20. even if their details are wrong.
  21.  
  22. My post is repeated below, for convenience of the reader.
  23.  
  24. Several people responded to my post; I summarize the responses here, and
  25. then give a detailed discussion of a particular response below.
  26.  
  27. To summarize:
  28.  
  29.   1)  [1] states that graph-iso is in NP, but not known to be in P and not 
  30.       known to be NP-complete.  
  31.       As far as I know, this is still the state of knowledge
  32.       (before the Gismondi- Swart work).
  33.   
  34.       I had claimed that graph-iso is known to be in NP ^ co-NP but 
  35.       NOT NP-complete.  This was based on a hasty (incorrect) reading of [1]. 
  36.       Thank you all for correcting me on this point.
  37.  
  38.   2)  bdm@cs.anu.edu.au (Brendan McKay) claims that P algorithms for
  39.       graph-iso are already known for
  40.  
  41.       a)  graphs with bounded vertex degree
  42.       b)  graphs of bounded genus
  43.  
  44.       He has given no references to substantiate his claim.
  45.  
  46.       Could somebody out there help substantiate or refute his claim
  47.       (preferably with references).
  48.  
  49.   3)  bdm@cs.anu.edu.au (Brendan McKay) claims that my algorithm does
  50.       not work properly on large classes of graphs which are of interest in
  51.       various mathematical work.  If what he says is true, this
  52.       weakens my argument in favor of the Gismondi-Swart strategy.
  53.  
  54.       Clearly, the algorithm I gave does not work on graphs where
  55.       all vertices have the same degree.  This problem can be easily patched
  56.       (see below).  
  57.  
  58.       Can somebody out there point out some classes of graphs
  59.       for which my algorithm usually fails, which cannot be easily patched?  
  60.  
  61.   4)  My original argument still seems correct.
  62.  
  63.  
  64. ====================================================================
  65.                       MY ORIGINAL POST
  66. ====================================================================
  67.  
  68. I have some experience in writing programs to attack the graph isomorphism
  69. problem in practice.  The application is from electrical CAD:  determine
  70. if 2 circuits, represented by 2 netlists with the wires and part instances
  71. unlabeled, represent the same actual circuit.   I have used a (well known?)
  72. randomized algorithm quite successfully, which usually runs in time n*log(n).
  73. I present the details of the algorithm below.
  74.  
  75. The relevance of my algorithm to the discussion of the paper of 
  76. Swart et. al. is this:
  77. the existence of this successful randomized algorithm for graph isomorphism, 
  78. together with the fact that graph isomorphism is known to be in
  79. NP ^ co-NP but NOT NP-complete, is strong evidence that graph isomorphism is
  80. an easy problem, probably in P.  It would be very odd indeed if this
  81. problem could be solved by a randomized algorithm in time n*log(n) or n^3,
  82. but by a deterministic algorithm in time no better than exponential.
  83.  
  84. It is my experience that most problems which are in P can be phrased as
  85. linear programming problems (this is often not the most effective 
  86. procedure for solving them, but it is still polynomial). 
  87. Since graph isomorphism is very likely in P, it can probably be attacked
  88. with linear programming.  It seems very plausible to me that a 
  89. linear programming attack on graph isomorphism can be generalized to
  90. graph sub-isomorphism, which would, of course, prove P=NP.
  91.  
  92. My point is this:  whether or not the Swart algorithm and proof are
  93. correct in detail, I think that the strategy of their attack has a good
  94. chance of success.  We in network-land should not dismiss their work
  95. at the first appearance of an error or inconsistency, but instead
  96. try to patch their proof and their algorithm.  If this proves hopeless,
  97. we should try to invent another attack based on their strategy:
  98. use linear programming to attack graph isomorphism, then generalize
  99. to graph sub-isomorphism.
  100.  
  101. Comments?
  102.  
  103.  
  104. ------------------------------------------------------------------------
  105.  
  106.      DESCRIPTION of a RANDOMIZED GRAPH ISOMORPHISM ALGORITHM
  107.  
  108. The idea is to hash both graphs with a carefully, but randomly
  109. constructed hash function.
  110. If the hashes are different, this proves that the graphs are different.
  111. If the hashes are the same, this suggests, but does not prove, that
  112. the graphs are the same.  By using a wider hash word, and by applying
  113. successive hash functions that involve successively larger macroscopic
  114. properties of the graph, it is possible to drive the probability
  115. of random aliasing toward 0 (exponentially, with the amount of computation).
  116.  
  117. In detail, the algorithm is:
  118.  
  119.  
  120. bool graphs_isomorphic(g1,g2)
  121. graph g1,g2;
  122. {
  123.   int hash_radius,hash1,hash2;
  124.  
  125.   for(hash_radius=0;hash_radius<RADIUS_LIMIT;++hash_radius)
  126.   {
  127.     randomize_hash_function();  /* consult a random oracle to determine
  128.                    hash function details */
  129.  
  130.     hash1 = hash_graph(g1,hash_radius);
  131.     hash2 = hash_graph(g2,hash_radius);
  132.  
  133.     if(hash1 != hash2)
  134.     {
  135.       return(FALSE);   /* proved not isomorphic */
  136.     }
  137.   }
  138.  
  139.   return(TRUE);        /* seem isomorphic, but not proved */
  140. }
  141.  
  142. int hash_graph(g,hash_radius)
  143. graph g;
  144. int hash_radius;
  145. {
  146.   int hash,i;
  147.   node n;
  148.   edge e;
  149.  
  150.   /* initialize node hash values */
  151.   for_all_nodes_of_graph(g,n)
  152.   {
  153.     n->old_node_hash = node_degree(n);
  154.   }
  155.  
  156.   /* hash the nodes with neighbors */
  157.   for(i=0;i<hash_radius;++i)
  158.   {
  159.     for_all_nodes_of_graph(g,n)
  160.     {
  161.       n->new_node_hash = n->old_node_hash;
  162.  
  163.       for_all_edges_of_node(n,e)
  164.       {
  165.     n->new_node_hash = n->new_node_hash + 
  166.                 hash(other_node_of_edge(e,n)->old_node_hash); 
  167.       }
  168.     }
  169.  
  170.     for_all_nodes_of_graph(g,n)
  171.     {
  172.       n->old_node_hash = n->new_node_hash;
  173.     }
  174.   }
  175.  
  176.   hash = 0;
  177.  
  178.   /* compute a summary hash value */
  179.   for_all_nodes_of_graph(g,n)
  180.   {
  181.     hash = hash + n->old_node_hash;
  182.   }
  183.  
  184.   return(hash);
  185. }
  186.  
  187.  
  188. Notice that this algorithm can be systematically fooled into thinking
  189. that certain degenerate graphs are the same when they are not;
  190. but these cases never seem to come up in practice.  I believe 
  191. most or all if these degeneracies can be fixed by a slightly more complicated
  192. algorithm which runs slower.
  193.  
  194. I first learned of this algorithm from Paul Filseth.
  195.  
  196. I can think of no way to generalize this algorithm to solve 
  197. graph sub-isomorphism (which is NP-complete).
  198.  
  199.  
  200. ====================================================================
  201.       DISCUSSION of a POST by bdm@cs.anu.edu.au (Brendan McKay)
  202. ====================================================================
  203.  
  204. In article 5857 of comp.theory, bdm@cs.anu.edu.au (Brendan McKay) wrote
  205. a detailed response to my post.  I have attempted to clarify several
  206. points with him by e-mail, but I have received no reply.  Therefore,
  207. I must discuss his post without benefit of discussion with him.
  208.  
  209. In article 5857 of comp.theory, bdm@cs.anu.edu.au (Brendan McKay) writes:
  210.  
  211. >In article G88@research.canon.oz.au, naylor@research.canon.oz.au (William Naylor) writes:
  212. >>I have some experience in writing programs to attack the graph isomorphism
  213. >>problem in practice.  The application is from electrical CAD:  determine
  214. >>if 2 circuits, represented by 2 netlists with the wires and part instances
  215. >>unlabeled, represent the same actual circuit.   I have used a (well known?)
  216. >>randomized algorithm quite successfully, which usually runs in time n*log(n).
  217. >>I present the details of the algorithm below.
  218. >
  219. >First off is that your space of sample graphs is highly biased towards
  220. >easy graphs.  Graphs made from circuits nearly always have a low genus
  221. >and only have vertices of low degree.  
  222.  
  223. My algorithm does not rely on the graphs having low genus or low degree.
  224.  
  225. >Isomorphism for graphs of 
  226. >bounded genus or bounded degree is already known to be in P.  
  227.  
  228. Could somebody out there help substantiate or refute this claim
  229. (preferably with references).
  230.  
  231. >These graphs are also highly likely to have vertices with a mixture
  232. >of degrees, and vertices easily distinguishable from other vertices.
  233.  
  234. The algorithm I presented relies on "enough" vertices having different
  235. degrees.  How much is enough?  This problem can be patched (see below).
  236.  
  237. >By the way, your algorithm is O(# edges), which is more than
  238. >O(n log n) for dense graphs.
  239.  
  240. If n is the amount of data presented to the algorithm, rather than the
  241. number of vertices, it is O(n*log(n))
  242.  
  243. >>The relevance of my algorithm to the discussion of the paper of 
  244. >>Swart et. al. is this:
  245. >>the existence of this successful randomized algorithm for graph isomorphism, 
  246. >
  247. >There is no evidence for such an algorithm.  Yours only works for
  248. >restricted classes of graphs.
  249.  
  250. The original algorithm I presented fails to distinguish graphs of the 
  251. same order with vertices all having the same degree.  This is
  252. a very small fraction of all possible graphs.  Anyway, this problem can 
  253. be patched (see below). 
  254.  
  255. Does anybody out there see any classes of graphs that can fool my
  256. (patched) algorithm?
  257.  
  258. >>together with the fact that graph isomorphism is known to be in
  259. >>NP ^ co-NP but NOT NP-complete, is strong evidence that graph isomorphism is
  260. >
  261. >Graph isomorphism is not known to be in co-NP, as far as I know.
  262.  
  263. Thanks for the correction.
  264.  
  265. ...
  266.  
  267. >Two comments:
  268. >(a) Just by looking at the number of nonisomorphic graphs ( about
  269. >    2^(n(n-1)/2)/n! ) you can see that your hash words need to be
  270. >    at least about n(n-1)/2 bits long before you have a chance of
  271. >    distinguishing all pairs of graphs.
  272.  
  273. Remember, this is a randomized algorithm, not a deterministic algorithm.  
  274. The objective is NOT to
  275. get an answer which is definitely correct, but rather to get an
  276. answer which is incorrect with probability <= P for each and every pair of
  277. graphs, where P is some constant < 1 (like 0.5).  The algorithm
  278. can be run multiple times to reduce the probability of error.  
  279.  
  280. If we use a hash word of 32 bits, the probability of error due to
  281. aliasing is
  282.  
  283.   P = 2^-32
  284.  
  285. regardless of the size of the graphs involved.  This is sufficiently
  286. small for most purposes.
  287.  
  288. Nothing like this is possible with a deterministic algorithm.  If a
  289. deterministic algorithm
  290. ever fails for a pair of graphs, it always fails for that pair (P=1).
  291. My randomized algorithm constructs its hash function by consultation
  292. with a random oracle.  A pair that fails in one call to my algorithm 
  293. may succeed on the next call because of different random numbers.  
  294. The hope is that for each and every pair, the probability of failure
  295. can be <= P.
  296.  
  297. >(b) As far as I can see, this fails to distinguish any two regular 
  298. >    graphs of the same order and degree.  
  299.  
  300. See the patch below for a fix to this "bug".
  301.  
  302. >    Probably many other pairs
  303. >    also.
  304.  
  305. Could somebody post such pairs?
  306.  
  307. >>Notice that this algorithm can be systematically fooled into thinking
  308. >>that certain degenerate graphs are the same when they are not;
  309. >>but these cases never seem to come up in practice. 
  310. >
  311. >Maybe not in your practice, but people who use graph isomorphism tests
  312. >in mathematical work (especially in coding and design theory) will find
  313. >that your method fails to work on almost every example.
  314.  
  315. Can somebody please post some failure cases for the patched algorithm given
  316. below?
  317.  
  318. >>I believe 
  319. >>most or all if these degeneracies can be fixed by a slightly more complicated
  320. >>algorithm which runs slower.
  321. >
  322. >I would be very pleased if this is true, but frankly I doubt it.
  323.  
  324. The original algorithm I presented fails to distinguish graphs of the 
  325. same order with vertices all having the same degree.  This can be patched
  326. as follows:
  327.  
  328.   1)  Construct N different hashes (as described below) for both graphs, 
  329.       where N is the number of vertices.  
  330.       
  331.   2)  Try to find a matching between the N hashes from one graph to the 
  332.       N hashes of the other (this can be done in N*log(N) time).  
  333.       If a matching does not exist, this proves
  334.       that the graphs are different.  If a matching exists, this suggests,
  335.       but does not prove, that the graphs are identical.
  336.       
  337.   3)  Construct the hashes as in "hash_graph" above, with these changes:
  338.  
  339.      a)  Always use hash_radius = N, with N = number of vertices
  340.  
  341.      b)  Rather than initializing all node hash values with the 
  342.      node degree, initialize a selected node with 
  343.  
  344.        hash(node_degree(node))
  345.  
  346.          and all others as before, with
  347.        
  348.        node_degree(node).
  349.  
  350.      This introduces an artificial initial distinction between the
  351.      graph vertices, which propagates throughout the graph during
  352.      the hash process.
  353.  
  354.      Select each possible node as "special" for the N hash values.
  355.       
  356. This certainly fixes the degeneracy described above.  I cannot
  357. think of any pairs of graphs which can consistently fool this algorithm.
  358. If anybody can see such a pair, could you please post it?
  359.  
  360. >Methods that are as strong or stronger date back to the 1960s.
  361. >Modern approaches supplement invariant computations with backtracking.
  362. >Several programs exist that can handle thousands of vertices
  363. >(one is mine, enquiries welcome).
  364.  
  365. Could somebody post some references to these algorithms?
  366.  
  367. My (unpatched) program can work on graphs with 50,000 vertices in 5-10 minutes.
  368.  
  369. I have been aware of this patch for several years, but I have never 
  370. found it necessary to implement it for my application.
  371.  
  372.  
  373. REFERENCES
  374.  
  375. [1]  Garey & Johnson:  Computers and Intractibility -- A Guide to the
  376.                Theory of NP-Completeness, page 155
  377.  
  378. -- 
  379. Will Naylor               net:  naylor@research.canon.oz.au
  380.                           mail: Canon Information Systems Research Australia  
  381. phone: (61-2) 805-2921          P.O. Box 313 North Ryde, NSW 2113 
  382. fax:   (61-2) 805-2929          Australia
  383.