Ваша задача — разработать три новых управляющих правила, которые организуют работу правил clash, start и finish.

I) Правило fixstart будет активизироваться в случае, если предложения, сформированные всеми прочими правилами для подцели start, будут нарушать ограничения. Это новое правило выделяет вектор schedule для задачи и присваивает его полю start значение, которое хранится в слоте latest элемента errand.

II) Измените существующее правило unstart таким образом, чтобы оно заменяло подцель в выражении goal с start на fix вместо прежней замены start на finish.

III) Разработайте правило unfix, которое будет заменять подцель в выражении goal с fix на finish.

Затем выполните следующее.

IV) Протестируйте программу и убедитесь, что она справляется с проблемой на наборе исходных данных, установленном в упр. 5.

V) Эвристика, использованная в правиле clash, не может справиться со всеми возможными случаями. Постарайтесь найти такой вариант исходных данных, который поставит программу "в тупик", несмотря на то, что построить расписание возможно.

7. В программе составления расписания используется единственный вид ограничений — ограничения по времени, запрещающие наложение мероприятий. Давайте добавим в нее пару ограничений, специфических для мероприятий определенного вида, — это будут своего рода специфические знания о предметной области. Например, логично ввести ограничение, отражающее тот факт, что для выполнения покупки или посещения какого-либо заведения сети обслуживания нужно располагать некоторой суммой денег. Следовательно, перед тем как отправляться за покупками, нужно зайти в банк.

I) В шаблон мероприятия errand добавьте поле kind (вид). Допустимые значения этого поля — одна из трех символических констант: goods (вещи), service (обслуживание), visit (визит). Такие мероприятия, как посещение банка или врача, относятся к группе visit, посещение парикмахерской (haircut) или ресторана (lunch) — к группе service, а поход в овощную лавку (groceries) или музыкальный салон (guitar-shopping) — к группе goods.

II) Включите в число возможных предложений в процессе решения проблемы новую фазу (подцель) tune, которая должна следовать за подцелью start перед fix. Таким образом, можно будет проанализировать введенные специфические ограничения перед тем, как браться за корректировку расписания (подцель fix). При изменении программы вам придется модифицировать правила, манипулирующие лексемами подцели.

III) Добавьте правило money, которое будет активизироваться только в том случае, когда -текущей подцелью в рабочей памяти является tune. Правило должно распознавать ситуацию, в которой мероприятие, требующее присутствия определенной наличности в бумажнике, оказывается в расписании раньше, чем посещение банка. Правило должно корректировать расписание, сдвигая в нем такое мероприятие на позднее время, т.е. на время после посещения банка. Если такая коррекция приведет к возникновению конфликтной ситуации в расписании, она будет устранена правилом fix.

IV) Протестируйте скорректированную программу на следующем наборе входных данных (фактов):

(deffacts the-facts

(goal (subgoal start))

(errand (name hospital)

(kind visit) (earliest 930)

(latest 930) (duration 200)

(priority 1)) (errand (name lunch)

(kind service) (earliest 1130)

(latest 1430) (duration 100)

(priority 2)) (errand

(name guitar-shop) (kind goods)

(earliest 1000) (latest 1700) (duration 100)

(priority 3)) (errand (name haircut)

(kind service) (earliest 900)

(latest 1700) (duration 30)

(priority 4)) (errand (name groceries)

(kind goods) (earliest 900)

(latest 1800) (duration 130) (priority 5))

(errand (name bank) (kind visit)

(earliest 930) (latest 1530)

(duration 30) (priority 2))

)

8. Как вы оцениваете методику последовательного уточнения программы, которая была использована при выполнении упр. 4-7? Какие, по-вашему, существуют доводы за и против использования такой методики разработки?