Предикат заказа невыполним

Кажется, я чего-то не понимаю в первой ветви предиката упорядочения в ff_next этой модели сплава.

open util/ordering[Exposure]
open util/ordering[Tile]
open util/ordering[Point]

sig Exposure {}

sig Tile {}

sig Point {
    ex: one Exposure,
    tl: one Tile
} fact {
    // Uncommenting the line below makes the model unsatisfiable
    // Point.ex = Exposure  
    Point.tl = Tile
}

pred ff_next[p, p': Point] {
    (p.tl = last) => (p'.ex = next[p.ex] and p'.tl = first)
    else (p'.ex = p.ex and p'.tl = next[p.tl])
}

fact ff_ordering {
    first.ex = first
    first.tl = first
    all p: Point - last | ff_next[p, next[p]]
}

run {}

Интуиция здесь такова, что у меня есть несколько экспозиций, каждую из которых я хочу выполнить на нескольких позициях плитки. Подумайте о том, чтобы делать панорамные изображения, а затем сшивать их вместе, но делать это несколько раз с разными настройками камеры.

С отмеченной строкой, закомментированной, первый экземпляр, который я получаю, таков:

Один проход по панораме

Это эквивалентно одному проходу по панораме с одной экспозицией, а затем опусканию остальных экспозиций на пол.

Кажется, проблема в первой ветке после => в ff_next, но я не понимаю, что не так. Никогда не устраивала та ветвь, которая переходила бы к следующей экспозиции и началу панорамы. Если я раскомментирую строку Point.ex = Exposure, модель станет неудовлетворительной, потому что для нее требуется эта ветвь.

Любая помощь в том, почему эта ветвь не удовлетворяет?


person asm    schedule 09.08.2019    source источник
comment
Один трюк с качеством кода: вы можете писать предикаты в синтаксисе приемника: вместо next[p.tl] вы можете написать p.tl.next.   -  person Hovercouch    schedule 10.08.2019
comment
Спасибо, на самом деле я предпочитаю синтаксис функции :)   -  person asm    schedule 10.08.2019


Ответы (1)


Похоже, вы пытаетесь выразить «каждая плитка должна соответствовать точке с текущей экспозицией, прежде чем мы перейдем к следующей экспозиции». Проблема заключается в серьезной ловушке с ordering: она заставляет подпись быть точной. Если вы пишете

run {} for 6 but 3 Tile, 2 Exposure

Тогда это работает так, как ожидалось. Есть только модели когда #Point = #Exposure * #Tile. Вы можете написать собственную сокращенную версию ordering, если для вас это проблема.

person Hovercouch    schedule 10.08.2019
comment
Ах! Я подозревал что-то подобное, но только увеличивал возможности для Пойнта, так что это было больше, чем необходимо! Я полагаю, что в более общем виде вы говорите следующее: если модель требует изоморфизма между двумя наборами (в данном случае Point и Expression X Tile), но настройки области не совсем совпадают | S1 | = |S2| (|Point| = |Expression X Tile|), то модель всегда будет неудовлетворительной? Таким образом, нет возможности установить прицел только от 0 до 20 точек по мере необходимости? - person asm; 10.08.2019
comment
Я полагаю, что для того, чтобы сделать эту модель полезной, мне нужно определить отношение между Point и Expression X Tile таким образом, чтобы некоторые Points могли болтаться. А потом выставить размах для Point такой, чтобы всегда хватало. Я полагаю, действительно, мне нужно сделать то же самое для Exposure и Tile. В противном случае я тестирую только один случай, вплоть до изоморфизма. Так что мне фактически нужно изобрести распределитель арены для этих трех подписей? Предполагая, что я хочу, чтобы одна модель анализировала несколько комбинаций мощностей Tile и Exposure. - person asm; 10.08.2019