wbreeze / davenport Goto Github PK

The compiler on the server complained with:

error: variable-sized object may not be initialized
   const int expected[node_ct] = {1, 3, 4, 2, 5, 6, 7, 8};

and

warning: excess elements in array initializer
   const int expected[node_ct] = {1, 3, 4, 2, 5, 6, 7, 8};

for each element

When building from a bare repository, the cmdline program won't build because the library is not available. The library won't build because the cmdline program won't build.

Use dot to make some pretty graph output from the tests and results. Add these to the documentation. Handy as diagnostics.

There are no instructions for installing, only for building. The build instructions leave out running autoconf --install before ./configure (because the configure command isn't checked-in and I'm not sure it should be). The install instructions should mention the need to run ldconfig on some systems. See this question on SO that was solved with ldconfig after installation of this library.

The current install with autoreconf --install requires that the cutter testing framework be installed. This is only needed to run tests. As such, it could be thought of as solely a development dependency.

Could it be possible to provide an install that only compiles the runtime code, not the tests, and doesn't have this dependency?

Write a command line program that takes a simple input format containing individual preferences, runs the algorithm, and outputs the aggregate preference solution.

Here is a simple input format. Separators are ">", "=", and newline. The newline separates individual preference rankings. The ">" signifies preference over what follows. The "=" signifies no preference.

9>2>3>8>5>7=1=4=0=6
4>9>0>6>3>2>5>1>7>8
5>3>2>4>8=7>1>9>0>6
1>4>7=2>5>0>8>6>9>3
4>5>8>1>6>3>0>2>9>7
5>1>0>8>2>4>7>3>9=6

Write some code that exercises the algorithm across a broad spectrum of problems, repeatably.

Use that to profile performance, identify hot spots, and write-up any potential performance improvements.

It's possible that use of the strong lower bound is a performance drain when components have very few alternatives. For example, with only three, it might be faster to simply try them vs. setting-up the flow network and computing the maximum flow. See if this is the case, and try to tune the minimum size of a component above which the strong lower bound is used.

By "true" majority graphs we mean generated from a preference graph that is generated from a list of declared preferences.

This requires:

• writing code to aggregate preference expressions into a preference graph
• writing code to generate a majority graph from a preference graph