Здравствуйте, joker6413, Вы писали:
J> Работающие методологии к которым IT пришли за последние несколько десятилетий — строят процесс разработки как раз наоборот (сниву вверх, от частного к общему). Единственное утешение — выработаны некоторые типичные способы решения задач, например архитектуры и шаблоны....
Не согласен, не знаю как будет по научному. Но процесс разработки состоит из двух частей:
— Создание типа
— Эксплуатация типа
В первом опираемся на частности, выделяя общее (как человек во время сна оптимизирует накопленный опыт). Во втором берем абстракцию и доопределяем по конкреный контекст (это скорее бодрствование Но оба процесса состовляют круговой цикл.
Здравствуйте, joker6413, Вы писали:
J>Интересная получилась штука, напоминает попытки математиков получить полную теорию чисел, но Гедель же ясно дал понять что это не возможно.
Скорее так: Если создавать всеобъемлющую систему, то придется отталкиватся от таких понятий как сигнал, граница сигнала, выделение сущности из потока информации (причем разного происхождения) и как бы еще не пришлось добиратся до атомов и электронов.
Если этого не делать, то это будет частный случай, если все таки пытатся, то придется ставить оооогромное количество "заглушек".
Здравствуйте, mihailik, Вы писали:
M>Мне кажется, такое доказательство можно легко построить на контрпримере. Что-нибудь с датчиком случайных чисел.
Этого не надо. Достаточно постулировать бесконечность пространства состояний "виртуальной машины".
Любой алгоритм в машине представим своим протоколом, т.е. последовательностью состояний машины.
Доказать, является ли протокол конечным, т.е. доходит ли он до состояния stop, невозможно.
Например, классический бесконечный цикл легко разруливается — состояние не меняется, оно не равно stop — значит, программа не даст результат ни за какое конечное время.
Если пространство состояний конечно, то отсутствие циклов (повторных посещений одного и того же состояния) гарантирует финитность, а их наличие гарантирует обратное.
Для бесконечного пространства состояний программа может ни разу не посетить ни одно из предыдущих состояний, но при этом так и не дойти до состояния stop. У нас нет критерия, при котором мы бы могли сказать "Все, программа не дошла до stop, значит — она не получит решения за конечное время". Это из области ожидания девушки — если она пришла, то а) известно, что она не прокосячила свидание б) известно, на сколько она опоздала. Если уже прошло время T с момента назначенной встречи, то неизвестно ничего. Мы еще не можем отличить ситуацию "она вообще не пришла" от "она опоздала на T' > T".
... << RSDN@Home 1.0 beta 6 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S> Для бесконечного пространства состояний программа может ни разу не посетить ни одно из предыдущих состояний, но при этом так и не дойти до состояния stop. У нас нет критерия, при котором мы бы могли сказать "Все, программа не дошла до stop, значит — она не получит решения за конечное время".
Ну, пока это не доказательство. Возьмём функцию: состояние "машины" за Y, а момент времени за X. Задача стоит — найти область определения функции, правильно?
И как же это связано с дискретностью в твоём случае?
S> Это из области ожидания девушки — если она пришла, то а) известно, что она не прокосячила свидание б) известно, на сколько она опоздала. Если уже прошло время T с момента назначенной встречи, то неизвестно ничего. Мы еще не можем отличить ситуацию "она вообще не пришла" от "она опоздала на T' > T".
Да, но алгоритм-то нам известен, поэтому это не просто "девушка". Если нам известен алгоритм, мы про эту девушку можем всё сказать.
P.S. А вообще, вся эта алгоритмическая теория, насколько я помню, основывается на детерминированных автоматах. То есть, строго говоря, неприменима к теперешним компьютерам с датчиком случайных чисел.
Здравствуйте, mihailik, Вы писали:
M>Ну, пока это не доказательство. Возьмём функцию: состояние "машины" за Y, а момент времени за X. Задача стоит — найти область определения функции, правильно?
Верно. Это идея доказательства. M>И как же это связано с дискретностью в твоём случае?
Никак. Дискретность здесь совершенно ни при чем. Множество натуральных чисел дискретно, но бесконечно. Множество чисел в Int32 — конечно. Поэтому обсуждаемая теорема неприменима к, например, Wintel-машине, не включенной в сеть. Ибо на ней возможно реализовать "проверку" любого алгоритма на зацикливание за конечное время.
M>Да, но алгоритм-то нам известен, поэтому это не просто "девушка". Если нам известен алгоритм, мы про эту девушку можем всё сказать.
Хм. Что такое "алгоритм известен"??? Можно поподробнее. Только с учетом того, что у компьютера, в отличие от человека, нет понятия "очевидности". Поэтому должен быть математический критерий для отличия
10 GOTO 10
от
05 LET I = 1
10 GOTO 20
20 LET I = I + 1
30 IF I < 10 GOTO 10
M>P.S. А вообще, вся эта алгоритмическая теория, насколько я помню, основывается на детерминированных автоматах. То есть, строго говоря, неприменима к теперешним компьютерам с датчиком случайных чисел.
Строго говоря, в теперешних компьютерах нет датчика случайных чисел.
... << RSDN@Home 1.0 beta 6a >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
M>>Да, но алгоритм-то нам известен, поэтому это не просто "девушка". Если нам известен алгоритм, мы про эту девушку можем всё сказать.
S>Хм. Что такое "алгоритм известен"???
Трудно сказать. Как минимум, мы можем "пройти" по нему пошагово. А если строго...
Ну хорошо, пусть алгоритм задаётся в системе команд какого-нибудь процессора.
S> Только с учетом того, что у компьютера, в отличие от человека, нет понятия "очевидности". Поэтому должен быть математический критерий для отличия <skip>
Понятно, понятно. Но всё равно доказательство остаётся нестрогим. У тебя одна из посылок — то, что мы не можем определить состояние машины за любой заранее ограниченное время. Ты этого не доказал.
M>>P.S. А вообще, вся эта алгоритмическая теория, насколько я помню, основывается на детерминированных автоматах. То есть, строго говоря, неприменима к теперешним компьютерам с датчиком случайных чисел. S>Строго говоря, в теперешних компьютерах нет датчика случайных чисел.
Да? А почему ты так думаешь?
Как я понимаю, используется время от запуска компьютера. Этот параметр достаточно колеблется от нестабильности тактового генератора и других тепловых влияний. А тепловые влияния в конечном счёте оборачиваются квантовыми законами неопределённости.
Здравствуйте, Sinclair! M>> Да, но алгоритм-то нам известен, поэтому это не просто "девушка". M>> Если нам известен алгоритм, мы про эту девушку можем всё сказать. S> Хм. Что такое "алгоритм известен"??? Можно поподробнее. Только с S> учетом того, что у компьютера, в отличие от человека, нет понятия S> "очевидности". Поэтому должен быть математический критерий для S> отличия
S> 10 GOTO 10
S> от
S> 05 LET I = 1
S> 10 GOTO 20
S> 20 LET I = I + 1
S> 30 IF I < 10 GOTO 10
1. GOTO 20 -- переход на следующую инструкцию, поэтому выбрасываем.
2. IF I < 20 GOTO 10 -- условный переход, если I < 20. В строке 05 определено, что I = 1 (т.е. в начале I < 10), а в строке 20 I увеличивается на единицу, откуда следует, что через несколько итераций I станет равно 10.
05 LET I = 1
10 LET I = I + 1
20 IF I < 10 GOTO 10
или:
10 FOR I = 1 TO 9
20 NEXT I
2. Строим дерево условий. Этот пункт не нужен, если программа была предварительно оптимизирована, так как постоянно выполняющиеся условия уже были удалены (остались только сами действия, без условий).
В данном примере запоминаем условие IF I < 10
3. Читаем программу сначала, чтобы проверить на не постоянное выполнение условий.
Находим:
05 LET I = 1
10 LET I = I + 1
Начальное состояние: I = 1
Условие: IF I < 10
Действия: I = I + 1
Откуда заключаем, что программа не зациклена. Анализируем поблочно.
На RND и прочие функции с неопределенным результатом, если они входят в условие или действия, выдаем предупреждения.
Буду рад конструктивным возражениям, особенно примерам программ.
Здравствуйте, limax, Вы писали: L>Изучаю UML и прочие языки/системы метамоделирования. Впечатления самые грустные: те же яйца, вид сбоку. L>Те же деления на уровни, куча ограничений и прочее. L>Есть ли что-нибудь более гибкое?
Частично вышел из спячки (вынырнул из завалов работы), перечитываю свои планы
Интересно, изменилось ли что-нибудь в мире за 4 года, окромя появления многоядерных процессоров, под которые до сих пор мало кто пишет (в смысле распараллеливания работы обычных программ)...
Здравствуйте, limax, Вы писали:
L>==============8<=========================== L>Цель: построить мета-язык описания любых процессов (в частности программирования, ввода-вывода), более сложные функции которого выражаются ТОЛЬКО через набор базовых. L>В UML такое отсутствует: сложные конструкции обрабатываются частным образом, а не с помощью базовых, отсюда — слишком много первоначальных определений (в машинном языке). К тому же чётко фиксированы мета-уровни: объект может быть экземпляром класса только соседнего уровня (3M->2M, 2M->Model, Model->Object).
вот описание процесса работы на компьютере
//RAISE SPECIFICATION LANGUAGE
-- compile
/*
круговорот бит в природе
/---------\
/>---------------->|keyboard |>------------------>\
| | | |
|>---------------->|mouse |>------------------>|
| | | |
|>---------------->|screen |>------------------>|
| \---------/ |
\--< USER <-\ /---< SYSTEM <--/-\
| /---------\ | |
brain |<----<|screen |<--<|>----> DB >------/
| | | |
\<----<|printer |<--</
\---------/
*/
scheme WORD = class -- вначале было слово
type
Input, Output, DataBase --, Memory
channel
keyboard, mouse, screenI: Input,
-- special kind of screen like screen of palmPilot
printer, screenO : Output
variable
db : DataBase
-- brain : Memory = для симметричности картинки userу
-- можно приписать мозги. Но часто их нет. Будем рассчитвывть на
-- худший случай
value
USER: Unit -> in printer, screenO out keyboard, mouse, screenI Unit,
SYSTEM : Unit -> in keyboard, mouse, screenI out printer, screenO Unit,
userWork : Output -> Input,
systemWork : Input -> write db Output
axiom
USER() is -- пусть v -результат чтения пользователем екрана компьютера
let v = screenO? in ( -- screen0? - ввод с екрана в мозги пользователя
keyboard! userWork(v) |^| -- вывод рез.работы на клавиатуру
-- |^| операция внутреннего выбора
-- пользователь сам выбирает чем двигать
-- мышкой или клавой или экраном
mouse! userWork(v) |^| -- или кликнул мышкой
screenI! userWork(v) -- или тыцнул в экран
)
end |=| -- операция внешнего выбора
let v = printer? in ( -- копьютер заставляет пользователя
keyboard! userWork(v) |^| -- читать, то куда он вывел
mouse! userWork(v) |^|
screenI! userWork(v)
)
end
; USER()
,
SYSTEM() is
let v = keyboard? in ( -- пусть v - результат опроса копьютером клавы
screenO! systemWork(v) |^| -- результаты своей работы
printer! systemWork(v) -- вывел на экран или принтер
)
end |=| -- тут пользователь заставляет
-- компьютер читать его команды
let v = mouse? in (
screenO! systemWork(v) |^|
printer! systemWork(v)
)
end |=|
let v = screenI? in (
screenO! systemWork(v) |^|
printer! systemWork(v)
)
end
; SYSTEM()
end
Но оба процесса состовляют круговой цикл.
А еще точнее сюда:
