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

Ответить