05.07.2012 23:35, Artem Chuprina пишет: > Артём Н. -> debian-russian@lists.debian.org @ Thu, 05 Jul 2012 21:10:14 > +0400: > > >> что выполняется закон сохранения импульса. Кстати, законы рассуждений, > >> используемые в Прологе, не эквивалентны тем, которым нас учат в школе и > >> даже в вузе. > АН> В смысле? Там есть что-то новое? :-) Это же обычная "машина вывода", как > и > АН> логика самая "обычная. > "обычная" логика непригодна для машинного вывода. Любая система > машинного или человеко-машинного вывода пользуется тем или иным > вариантом, а чисто машинного - подмножеством, конструктивной логики, > которая, на мой взгляд, много лучше классической, но уж во всяком случае > не эквивалентна - она способна доказать меньше утверждений. > > >> >> >> А вот как соотносится твоя модель, > >> >> >> выраженная в нелогических аксиомах, с реальностью - это уже не к > >> >> >> Прологу. > >> >> АН> Но в точности тоже самое возможно сказать и о других языках. А > >> >> АН> тесты нужны именно для того, чтобы проверить соответствие модели > и > >> >> АН> реальности. Там тоже самое, даже такие же побочные эффекты могут > >> >> АН> быть. И программа, на нём написанная не является правильной > только > >> >> АН> потому, что она написана на Пролог. Просто тестами надо покрывать > >> >> АН> факты и правила, а не функции и процедуры или я не прав? > >> >> > >> >> В выводе - да, прав. Но надо учитывать, что большинство наших тестов > >> >> для других языков таки работают внутри модели, а не проверяют ее > >> >> соответствие реальности. То есть для прологовской программы не имеют > >> >> смысла. Природа тестов для прологовской программы должна быть > >> >> существенно иной, нежели привычно. > >> АН> Хм... А как тест может работать не внутри модели? Программа - > >> АН> модель. Даже, если тест получает данные извне, он всё-равно > >> АН> работает в данной модели. > >> > >> Не обязательно в данной. Это существенно. Скажем, тест, который > >> получает сигнал с реального датчика, сует его в программу, получает из > >> программы команду на управление реальным железом, выдает ее в железо, и > >> потом измеряет угол его поворота, например, другим датчиком, таки > >> выходит за пределы той же модели. > АН> Ну да. Разве что так. Но причём здесь Пролог? > > При том, что для него только эти тесты и имеют ценность. Тесты с > эмулятором способны отловить только опечатки. Содержательные ошибки - > не способны, потому что строятся на той же модели. Эээ... Но, опять же, не обязательно опечатки: несоответствия ожиданиям. А проблемы могут быть в логике. Тест, даже юнит-тест, и есть эмулятор, ведь так? Ведь не принципиально на чём он может быть реализован? Нет разницы, вынесен он из Пролог системы и сделан отдельной программой или, если это возможно, реализован "внутри"? А проблема того, что не будут отловлены ошибки модели внутри данной модели (ну, это само собой, прямое следствие из теоремы о неполноте), не относится к императивным языкам и даже к программе на Пролог... Просто, в таком случае, надо, чтобы модель, используемая эмулятором точнее соответствовала реальной системе.
Разве эта проблема относится к императивным языкам, например? И Пролог тут может что-то новое внести? Априори, в программах, написанных на нём, не может быть семантических ошибок (не ошибок в проектировании модели среды, а ошибок, связанных с получением и обработкой данных)? > >> И его работа уже существенно ближе к реальности, чем модель, в которой > >> написана программа. > АН> Но, кажется, это две стадии тестирования? > АН> И нельзя тестированием с реальным датчиком заменить тестирование с > АН> "эмулятором". > Как раз в эту сторону теоретически можно. Правда, практически может > оказаться слишком дорого. Наоборот нельзя. Это понятно: в итоге всё должно проверяться там, где оно должно работать. > >> АН> Чем тут отличается Пролог от императивного языка, например? Здесь > >> АН> я просто вижу те же самые ошибки человека: неверное задание правил > >> АН> (неполнота, неточность или ошибочность) и неверное задание фактов. > >> АН> Что и должны покрывать тесты. Ведь так? > >> Так. А теперь внимание: что значит словосочетание "верное задание > >> фактов"? Скорее всего, тестировать соответствие этого задания опять же > >> модели не очень практично - дешевле доказать, что оно соответствует. > >> Потому что от модели до фактов - это всего лишь перевод с одного языка > >> на другой, причем перевод весьма формальный, тут доказательство > >> оказывается довольно простым. Интересно проверять соответствие задания > >> фактов реальности, считая, что набор фактов - это и есть модель. А это > >> уже формулируется не "написать тест", а "построить тест". В железе, > >> ага. > АН> Но, обычно, не всегда это возможно. Да и чем отличается "железный" > АН> генератор (не датчик, а именно генератор состояний датчика) от > АН> программного? > Если говорить, например, о датчике случайных чисел, то, натурально, > случайностью. Железный выдает случайные числа, программный - > закономерные, но статистически до той или иной степени похожие на > случайные. Но разве это не плюс? Ведь возможно поменять закономерность и получить большее количество вариантов для теста... А с "железным" датчиком всегда будет один вариант (ну, плюс типовые, к примеру, в случае выхода датчика из строя), т.е. гибкость меньше? -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ff85f57.4050...@yandex.ru