Ниже представлена ​​модель сплава, в которой набор чисел должен быть положительным и четным. Я показываю два способа (два предиката) для реализации ограничений. Я считаю, что эти два способа эквивалентны (наборы, которые производят оба предиката, одинаковы).

Чтобы проверить эквивалентность двух предикатов, я создал одно утверждение, в котором говорится следующее:

defining_property => generate_set_members

Проверка этого утверждения не дала никаких контрпримеров.

Затем я создал утверждение, в котором говорится следующее:

generate_set_members => defining_property

Проверка этого утверждения также не дала никаких контрпримеров.

Наконец, я создал утверждение, используя iff:

defining_property iff generate_set_members

Проверка показала контрпример. Контрпример - это набор чисел, содержащих как положительные, так и отрицательные четные числа.

А?

Как могут A => B и B => A быть истинными, а A iff B - ложными?

one sig PositiveEven {
     elements: set Int 
}

/*
    To be in the set, a member must have these two properties:
    - it must be be positive 
    - it must be even
*/
pred defining_property {
    PositiveEven.elements = {i: Int | i >= 0 and (rem[i,2] = 0)}
}

/*
    0 is in the set
    If i is in the set, then i+2 is in the set
    Nothing else is in the set
*/
pred generate_set_members {
    0 in PositiveEven.elements
    all i: PositiveEven.elements - 0 | i.minus[2] in PositiveEven.elements
    // Create a complete set of positive even elements
    all i: Int | i.minus[2] in PositiveEven.elements => i in PositiveEven.elements
}

assert equivalent_constraints {
    //defining_property iff generate_set_members
    //defining_property => generate_set_members
    generate_set_members => defining_property
}

assert only_positive_even_numbers {
  //generate_set_members => 
  defining_property => 
    all i: Int | i in PositiveEven.elements <=> i >= 0 and i.rem[2] = 0
}

run defining_property
run generate_set_members
check equivalent_constraints
check only_positive_even_numbers
1
Roger Costello 2 Дек 2017 в 18:23

1 ответ

Лучший ответ

Я воспроизвел это в 4.2_2015-02-22, но не в 4.2. Насколько я могу судить, это ошибка в том, как 4.2_2015 переводит представление Kodkod в проблему SAT. Вы можете воспроизвести это, изменив решатель SAT на «вывод CNF в файл» и запустив ту же спецификацию как для 4.2, так и для 4.2_2015, а затем запустив SAT4J для обоих файлов .cnf. 4.2 будет содержать 72 пункта и быть выполнимым (обнаруживает ошибку), тогда как 4.2_2015 cnf будет содержать 66 пунктов и будет неудовлетворительным. 4.2 - это стабильная версия, а 4.2_2015 - экспериментальная, так что переключение на предыдущую версию должно пока исправить.

1
Hovercouch 3 Дек 2017 в 00:46