[EM] Smith,Minmax(margins) mono-add-top failure example

[Kristofer Munsterhjelm]

Kevin Venzke wrote:
> Hi Kristofer,
> 
> Here's an attempt at a more concrete example:
> 
> A     3
> ABCD  13
> ACBD  1
> ACDB  5
> ADBC  5
> BACD  16
> B     3
> BCDA  5
> CDAB  20
> DBCA  24
> total 95

(...)

> A does have two tied margins; I'm unsure if they make a difference, or
> if it can be easily fixed if they do. But it doesn't seem like they
> should make a difference (i.e. for checking Ext-Minmax) because those
> margins are relatively weak.

I just checked it with my Ext-Minmax implementation, and it still works 
(that is, fails the criterion). The debug data I get from Ext-Minmax is:

For the first scenario:

After sorting: 0	6   6   1
After sorting: 1	16   0   0
After sorting: 3	31   0   0
After sorting: 2	40   0   0

For the second scenario:

After sorting: 0	8   0   0
After sorting: 1	9   0   0
After sorting: 3	31   1   0
After sorting: 2	47   1   0

Plain Minmax consistently elects A here, which is no problem for plain 
Minmax (or Ext-Minmax for that matter), but the Smith restriction causes 
trouble.

Back to the drawing board, I guess! Do you think the compliance could be 
salvaged by using Smith,Minmax(PO) instead -- or, more strictly, by 
disallowing trunaction? Either might lead closer to a method that passes 
Smith and mono-add-top...

Worse is the fact that my program didn't find a compliance disproof even 
though I now know there to be one. I'll have to find out why; one 
possibility is that the failures are exceedingly uncommon and it simply 
can't stumble upon one by brute force.