CloudStyleStudio / aic-expresso

Automatically exported from code.google.com/p/aic-expresso
0 stars 0 forks source link

Throw exception from R_card if called for quantified cases and no domain size information is available #7

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
{{{
Thanks, Ciaran, I get it.

Seems like we can move them to testCardinalityKnownSizesRequired then, right?

Yes, it seems like a failure message for quantified cases without domain size 
information would be handy.

Thanks!

Rodrigo

On 8/7/2012 4:05 PM, Ciaran O'Reilly wrote:
> Hi Rodrigo,
>
> I know why its hanging when you paste the tricky tests in testCardinality and 
not when run from within testCardinalityTrickyCases. Basically, these tests 
require a source for the size of the variable domains to be setup. In 
testCardinalityTrickyCases this always happens irrespective of the setting of 
the ASSUME flag. However, in testCardinality the first of the two calls to the 
rewrite method does not setup a source for the count information (i.e. I'm 
testing don't know in this case). The countsDeclaration.setup(process) call is 
what performs this registration, and you'll see its absent before the first 
rewrite call (which is the intended setup for this set of tests). Based on 
this, I think it best to keep these tests in testCardinalityTrickyCases().
>
> Note, the R_card logic is currently not able to handle the quantified case 
when no source of domain sizes is available (we discussed this in earlier 
emails, being something we'll address at a later date), though it would be nice 
if it at least exited with a failure. Would you like me to investigate further 
as to why its hanging in this situation?
>
> Thanks
>
> Ciaran
>
> On 8/7/2012 3:51 PM, Rodrigo de Salvo Braz wrote:
>> Thanks!
>>
>> Rodrigo
>>
>> On 8/7/2012 3:41 PM, Ciaran O'Reilly wrote:
>>> Hi Rodrigo,
>>>
>>> Sorry, I'd misunderstood your setup, what I ran was
>>> testCardinalityTrickyCases(). I've done as you said and pasted the
>>> tests into testCardinality() and am seeing the issue you are - I'll
>>> see what I can figure out.
>>>
>>> Ciaran
>>>
>>> On 8/7/2012 3:31 PM, Rodrigo de Salvo Braz wrote:
>>>> On 8/7/2012 3:04 PM, Ciaran O'Reilly wrote:
>>>>> Hi Rodrigo,
>>>>>
>>>>> On 8/7/2012 2:44 PM, Rodrigo de Salvo Braz wrote:
>>>>>> Hi Ciaran,
>>>>>>
>>>>>> Regarding the tricky cases again, when I simply copy and paste them
>>>>>> inside testCardinality, they again take extremely long to run. This
>>>>>> happens when the ASSUME flag is off. So there are a couple of
>>>>>> points to
>>>>>> consider:
>>>>>>
>>>>>> - given that the domain size is given in these cases, the flag should
>>>>>> have no effect. Seems like we took two different meanings for the
>>>>>> flag.
>>>>>> I will take a look at the pseudo-code and see if it needs to be
>>>>>> revised.
>>>>>
>>>>> Ok, let me know when you've had a chance to look at this.
>>>>>
>>>>>> - even if the domain sizes were not given, it seems like it shouldn't
>>>>>> take this long anyway (by use of the flag). Let me know if you would
>>>>>> like to take a look or prefer me to do so.
>>>>>
>>>>> Ok, I've run this test twice first with these arguments passed to the
>>>>> JVM:
>>>>
>>>> When you say "this test", do you mean testCardinality? That's the one I
>>>> am running. I get no differences either when I run
>>>> testCardinalityTrickyCases with the flag on or off. But when I copy and
>>>> paste the same tests in testCardinality, it never (at least, after many
>>>> minutes) finishes, even after turning UI off with the setting
>>>>
>>>> -Dgrinder.display.tree.util.ui=false
>>>> -Dgrinder.wait.until.ui.closed.enabled=false
>>>> -Dtrace.level=false
>>>> -Djustification.level=off
>>>>
>>>> This persists even if I comment out all other tests in the method. Very
>>>> puzzling!
>>>>
>>>> Thanks,
>>>>
>>>> Rodrigo
>>>>
>>>>>
>>>>> -Dgrinder.cardinalilty.assume.domains.always.large=false
>>>>> -Dgrinder.display.tree.util.ui=false
>>>>> -Dgrinder.wait.until.ui.closed.enabled=false
>>>>> -Dtrace.level=false
>>>>> -Djustification.level=off
>>>>>
>>>>> and see this (with an additional output to ensure the flag is set):
>>>>> isAssumeDomainsAlwaysLarge=false
>>>>> tests[0 rewrote in 520ms]:{ ( on X1, Y1, X2, Y2, Y3 ) tuple(X1, Y1,
>>>>> X2, Y2, Y3) | there exists X1 : there exists X2 : there exists Y1 :
>>>>> there exists Y2 : there exists Y3 : X1 = a1 or Y1 = b1 or X2 = a2 or
>>>>> Y2 = b2 or Y3 = b3 }
>>>>> --->
>>>>> 100000
>>>>> isAssumeDomainsAlwaysLarge=false
>>>>> tests[1 rewrote in 631ms]:{ ( on X1, Y1, X2, Y2, Y3 ) tuple(X1, Y1,
>>>>> X2, Y2, Y3) | for all X1 : for all X2 : for all Y1 : for all Y2 : for
>>>>> all Y3 : X1 != a1 or Y1 != b1 or X2 != a2 or Y2 != b2 or Y3 != b3 }
>>>>> --->
>>>>> 0
>>>>>
>>>>>
>>>>> Note: the times are output.
>>>>>
>>>>> I then call with the flag set to true:
>>>>>
>>>>> -Dgrinder.cardinalilty.assume.domains.always.large=true
>>>>> -Dgrinder.display.tree.util.ui=false
>>>>> -Dgrinder.wait.until.ui.closed.enabled=false
>>>>> -Dtrace.level=false
>>>>> -Djustification.level=off
>>>>>
>>>>> and see:
>>>>>
>>>>> isAssumeDomainsAlwaysLarge=true
>>>>> tests[0 rewrote in 512ms]:{ ( on X1, Y1, X2, Y2, Y3 ) tuple(X1, Y1,
>>>>> X2, Y2, Y3) | there exists X1 : there exists X2 : there exists Y1 :
>>>>> there exists Y2 : there exists Y3 : X1 = a1 or Y1 = b1 or X2 = a2 or
>>>>> Y2 = b2 or Y3 = b3 }
>>>>> --->
>>>>> 100000
>>>>> isAssumeDomainsAlwaysLarge=true
>>>>> tests[1 rewrote in 617ms]:{ ( on X1, Y1, X2, Y2, Y3 ) tuple(X1, Y1,
>>>>> X2, Y2, Y3) | for all X1 : for all X2 : for all Y1 : for all Y2 : for
>>>>> all Y3 : X1 != a1 or Y1 != b1 or X2 != a2 or Y2 != b2 or Y3 != b3 }
>>>>> --->
>>>>> 0
>>>>>
>>>>> as you can see, no real difference. What are the differences in the
>>>>> timings that you are seeing?
>>>>>
>>>>> Ciaran
>>>>>
>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Rodrigo
>>>>>
>>>
}}}

Original issue reported on code.google.com by ctjoreilly@gmail.com on 11 Apr 2013 at 12:09