pgtap/mincut/compare.test.sql test data is flawed

Open
  • Is something wrong?
#2,583 3 comments 1 reaction 0 assignees View on GitHub

Maintainers usually reply within 3 days

Nobody has claimed this yet.

  • #3104 by @prashsti29 — closed without merging

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
65/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Quiet
Tech stack
cpp, postgresql, sql
Domain
databases, testing

Research direction

The issue is in the test file pgtap/mincut/compare.test.sql. First, examine the flawed test data for tests 5 and 6, understanding the graph structure and the Stoer-Wagner algorithm requirements. Review the pgr_stoerWagner function's implementation and the Boost library version impact. Create a valid test graph with non-negative costs and undirected edges, then update the test SQL with correct expected results. Run the TAP tests to verify the fix.

Written by the indexing model from the issue text.

Description

bug mincut pgtap

Problem
The two functionality tests in pgtap/mincut/compare.test.sql use graphs that are either vacuous or invalid, and the expected return values are not guaranteed.

This test case would benefit from being rewritten to use a graph designed for min-cut testing, but I am raising this issue because changes to Boost can cause it to fail.

To Reproduce
Compiling the test against Boost 1.80 or later (which uses a different implementation of Stoer-Wagner than earlier versions) causes failures.

Test 5

The graph for unit test "5: Mincut of edge 17" uses a graph with two nodes and one edge. Evaluating the inner query of the PREPARE stoerWagner6 statement (the one being passed to pgr_stoerWagner()) gives the following:

 id | source | target | cost | reverse_cost 
----+--------+--------+------+--------------
 17 |     14 |     15 |    1 |            1
(1 row)

Obviously this is the exact same graph as generated by the simpler stoerWagner5 subquery; in both cases the mincut is trivially to cut the only existing edge, so the comparison of stoerWagner5 and stoerWagner6 tests only that pgr_stoerWagner generates the same output given the same input, which was probably not what was intended.

Test 6

The subquery being passed to pgr_stoerWagner7 for the test "6: Compare the mincut of subgraph with actual result" results in the following graph:

 id | source | target | cost | reverse_cost 
----+--------+--------+------+--------------
  1 |      1 |      2 |    1 |            1
  2 |      2 |      3 |   -1 |            1
  3 |      3 |      4 |   -1 |            1
  4 |      2 |      5 |    1 |            1
  5 |      3 |      6 |    1 |           -1
  6 |      7 |      8 |    1 |            1
  7 |      8 |      5 |    1 |            1
  8 |      5 |      6 |    1 |            1
  9 |      6 |      9 |    1 |            1
 10 |      5 |     10 |    1 |            1
 11 |      6 |     11 |    1 |           -1
 12 |     10 |     11 |    1 |           -1
 13 |     11 |     12 |    1 |           -1
 14 |     10 |     13 |    1 |            1
 15 |      9 |     12 |    1 |            1
 16 |      4 |      9 |    1 |            1
(16 rows)

And expects that the mincut result is to cut the single edge with id 1.

There are three flaws with this test:

  1. The Stoer-Wagner algorithm requires all edges have non-negative costs, but edges 2 and 3 violate this.
  2. The Stoer-Wagner algorithm requires an undirected graph, but edges 2, 3, 5, 11, 12, and 13 have different costs in different directions.
  3. There are four distinct edges of equal weight that, each on its own, can be removed to partition the graph: edges 1, 6, 7, and 14. (Notice that nodes 1, 7, and 13 only have a single connection to the graph, and node 8 lies between node 7 and the rest of the graph.)

The test query for 6 asserts that the algorithm will select edge 1, but 6, 7, and 14 are valid (and edge 14 is selected when built against more modern versions of Boost).

Dominant language
C++
Stars
1.4k
Forks
397
Avg merge
2d 16h
Merged PRs (30d)
8

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from pgRouting/pgrouting

All issues in pgRouting/pgrouting

Similar issues

More C++ issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.