Carry model counting

[ssardina]

Hi @axelahmer

I am suprised and confused by the way you carry the number of models:

Why is it a list (of 1 number?) and why you didnt use just model.number ?

I must be missing something here..

[axelahmer]

Oh goodness how embarassing - I didn't expect you to be poking through the py code. It's a mess!

I spent a few hrs on it, and most of the time was invested in the ASP - more fun!

I am intrigued if you want to take the project further, let me know. Potentially multishot or clingcon etc. if you are interested. I am still dissapointed in it's performance, considering I want to use clingo as a general purpose optimizer in the future.

I'll revisit the py code and smooth out all the gross code at some point :) Thanks @ssardina - I am unsure if model.number would work if we are using yield.

[ssardina]

OK I thought I was going crazy.. :wink:

Yes I am interested, but I think we would need to move significantly: I tried several configurations of base clingo and it is still way behind.

I was doing some testing. GUROBI yields optimal answer to instance 1 in 492 seconds; cost 2087 (2 unscheduled games, and cost 87 for closed games). They run the IP program in parallel on 8 cores.

We however get worse in that time:

Config	Unscheduled	Closed Games	Type configuration
auto	2	305	Select configuration based on problem type
trendy	2	243	Use defaults geared towards industrial problems
jumpy	2	213	Use aggressive defaults
many	2	282	Use default portfolio to configure solver(s)
handy	2	242	Use defaults geared towards large problems

The question is: is this so bad/poor? We are optimal in terms of games schedules but more teams play closer, but is it sooo bad? See we are comparing with industrial, paid, Gurobi

I am interested to see whether if we jump to a different framework (multishot or clingocon) we see a significant change. I would probably first try cligocon

[axelahmer]

@ssardina The paper mentions that they get optimal solns from the COIN solver too, which is open source.

I had a play with clingcon on some dummy examples - https://github.com/potassco/clingcon/tree/master/examples

Seems interesting. Quite a bit of thought would have to go into how variables are defined however - such that their domains can be set nicely. Failing to see how this could be bootstrapped onto the current base system, would need to redesign from the top I believe?

Any simple ideas of how to model like this? Would we be trying to just implement the IP constraints from the paper? If so, it seems like using an actual MIPs solver makes more sense? What is your intuition here?

Random aside news: Interesting I discovered that clingcon cannot enumerate optimal models when asked - instead you need to control it using the python API and print all solns with a certain bound. My example program that showed this:

&dom {0..1} = x.
&dom {0..1} = y.
&distinct { x ; y }.
&minimize { x ; y }.

It should obviously give two minimums: x=1,y=0 and x=0,y=1.

The issue is discussed in https://github.com/potassco/clingcon/issues/78 if you are interested. Took me a little while to find it.