conjure-cp / conjure

Conjure: The Automated Constraint Modelling Tool
Other
96 stars 24 forks source link

refine param with sets, factorial #179

Closed ozgurakgun closed 7 years ago

ozgurakgun commented 11 years ago

Originally reported by: Bilal Hussain (Bitbucket: Bilalh, GitHub: Bilalh)


refine param I think only eval number up to 10000

but this param

language Essence 1.3
letting nnodes be 7
letting nrings be 4
letting capacity be 4
letting demand be {{5, 3},
{3, 15},
{5, 4},
{7, 5},
{5, 1},
{6, 3},
{6, 1},
{6, 21}}

refined into a SetExplicitVarSize eprime contains 10! / 80640 which is 45. Should this be evaluated? Maybe eval division if the divisor is reasonably close to the numerator?

this happens with some of the param of prob129

conjure: refineParam
    Expecting integer literal, found: 10! / 80640
                                      binOp.operator := /
                                      binOp.left.unaryOp.factorial.value.literal := 10
                                      binOp.right.value.literal := 80640

ozgurakgun commented 11 years ago

Original comment by Bilal Hussain (Bitbucket: Bilalh, GitHub: Bilalh):


[savilerow] prob129.essence prob129-df/0001.eprime s2ring05.param
ERROR: Item 15 is not contained in domain of constant matrix demand_SetExplicitVarSize_tuple2_SetExplicit.
ERROR: Failed type checking after substituting in lettings.
ozgurakgun commented 11 years ago

Original comment by Özgür Akgün (Bitbucket: ozgurakgun, GitHub: ozgurakgun):


Can you give an example of an (eprime,param) pair which fails?

ozgurakgun commented 11 years ago

Original comment by Bilal Hussain (Bitbucket: Bilalh, GitHub: Bilalh):


also in prob129, in a few params like prob129-df/0012.eprime s1ring12.param

give this kind of error (always with SetExplicitVarSize)

ERROR: Item 15 is not contained in domain of constant matrix demand_SetExplicitVarSize_tuple2_SetExplicit.
ERROR: Failed type checking after substituting in lettings.

using the latest SR. not a big problem since most of them work

ozgurakgun commented 11 years ago

Original comment by Özgür Akgün (Bitbucket: ozgurakgun, GitHub: ozgurakgun):


Actually, you know what, I'll take away the restriction completely and let's see if anything weird happens.

ozgurakgun commented 11 years ago

Original comment by Özgür Akgün (Bitbucket: ozgurakgun, GitHub: ozgurakgun):


OK, I'll special case a factorial that is being divided by some other number (or another factorial).

I can take this restriction out, but then the rest of the toolchain might fail in unexpected ways. Happened to me before.

ozgurakgun commented 7 years ago

This seems to be related to SONET. There was some confusing about the numbering of SONET (129 & 56 were both referring to the same problem, etc)

All parameters seem to be getting refined without problems, so closing. See here.