DRAKON.SU

Текущее время: Среда, 20 Июнь, 2018 23:37

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 112 ]  На страницу Пред.  1, 2, 3, 4, 5, 6  След.
Автор Сообщение
СообщениеДобавлено: Пятница, 16 Февраль, 2018 21:39 

Зарегистрирован: Среда, 03 Май, 2017 09:55
Сообщения: 151
TAU писал(а):
И это не "псевдоакадемическая чушь" - а истина. К коей я пытаюсь по мере сил стремиться.
Отличия эти вполне принципиальны, на что указывал еще сам Тьюринг, описавший "машину выбора"

У Тьюринга про время ничего не говорилось. И в английской Wikipedia тоже ни слова.
Ни о каком принципиальном значении времени Тьюринг не писал.

TAU писал(а):
Семантика управляющего алгоритма реального времени не может адекватно быть описана без часов.

А что такое "часы"?

"часы" ничем не отличаются от "тактового входа".


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 17 Февраль, 2018 11:10 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 951
Откуда: Россия, Чебоксары
PSV100 писал(а):
Alexey_Donskoy писал(а):
принципиальной разницы нет.
Но почему же нет разницы?
:lol:

Цитата:
Да, фактически, можно сказать, что имеющаяся в литературе (или в IT в целом) классификация алгоритмики и есть уточнение частных случаев общей формулы, вами ранее указанной: S[n+1]=f(X[n],S[n]).
Именно. И не только можно, а нужно сказать.
Это как раз принципиально.

Цитата:
Однако, к примеру, выше Владимир Шелехов представил свою статью о классификации программ.
Почему же "однако"? Он ложных принципиальностей не вводит, а вполне корректно классифицирует.

Цитата:
он же первично глобально выделяет или разделяет программирование на логическое и прочее
Согласен с таким подходом.
Он как минимум целесообразен.
И опять же, Шелехов хотя и говорит про "водораздел", но квантора всеобщности всё же избегает. Он не называет этот водораздел принципиальным.

Вообще я зря пропустил эту интересную тему, оказывается...
Владимир Шелехов писал(а):
Подавляющее большинство реальных задач невозможно решить методами логического программирования.
Вот тоже хорошая иллюстрация к теме.
Да, невозможно.
А почему?
Академист может сказать, что из-за принципиального различия.
Различия чего? Теории?
Фиг.
Различие только в исполнителе.
Ну, кривой исполнитель в логическом программировании. Заточенный на узкий круг задач и непригодный к решению других.
Тем не менее, общее S[n+1]=f(X[n],S[n]) справедливо даже для логического программирования, как ни покажется это удивительным!

Думается, что большинство проблем в понимании данной темы вызвано попытками выдать вопрос выбора адекватного инструмента за принципиальные теоретические положения.

PSV100 писал(а):
Конечно, можно "придраться" и указать на то, что логические декларации трансформируются в императивные для машины вывода, и "нет никакой разницы"
Думаю, это ошибочное построение. Не трансформируются логические декларации в императивные. Исполнитель для нас является чёрным ящиком.
Но определённые выходные сигналы таки однозначно преобразуются этим исполнителем в выходные - следовательно, исполнитель реализует не что иное, как функцию.

Цитата:
должна же быть какая-то наука об алгоритмизации...
Да пожалуйста.
Только обсуждение в моей старой теме "Что же такое алгоритм?" так и не привело к консенсусу, что этим алгоритмом следует считать, а что нет.
Предлагаете по пятому кругу обсуждение вести? :wink:
Тогда вопросы: следует ли считать алгоритмом любую функцию f(X[n],S[n])?
Следует ли считать данные X[n], подаваемые на вход логической машины, программой? :wink:
Я на оба вопроса отвечаю утвердительно, кстати.

Цитата:
И базовая операция "ожидание" есть основа для пунктов выше (вне зависимости от природы исполнителя и реализации операции).
Да. Это семантика.
Но ожидание не аксиоматически существует в базисе, а реализуется строго теми же базовыми примитивами императивного программирования.


TAU писал(а):
Попробуйте воспринять конструктивно - а не переходя на личности оборотами вроде "детский сад"
Ещё того веселее: свои переходы на личности можно и подкорректировать, пока никто не заметил, а у оппонента можно что угодно выдёргивать из контекста, да? А посмотрите-ка на свой тезис, который удостоился этой ремарки.

Между тем, я свои тезисы подробно аргументирую и иллюстрирую разнообразными примерами - это, разумеется, от большого невежества (как вы сказали в этом сообщении, а потом потёрли).
Вы же продолжаете повторять одни и те же заклинания вообще без всяких аргументов, только со ссылками на авторитеты (которых, к тому же, цитируете тенденциозно, в чём вас постоянно уличает тот же Ситников). Наверное, так принято в академических кругах? :wink:

Цитата:
Время - не просто "еще один аргумент в векторе входных параметров". ПРОЦЕСС - это не "мгновенно, вне времени" вычисляемая ФУНКЦИЯ.
Не замечаете, что первый тезис никак со вторым не связан?
Не замечаете, что во втором вы сваливаете в одну кучу объект и его модель (возможно, приписывая мне непонимание разницы между ними)?
Не хотите замечать, что я всё время говорю о процессах и только о процессах - и о том, как функцию применить к управлению этими процессами? А ведь я все возможные варианты подробно расписал в этой задаче!

Резюме: второй тезис в этой цитате отражает серьёзный изъян в вашем понимании предмета дискуссии, а первый просто ошибочен.
Аргументами, как обычно, ни тот, ни другой тезис не сопровождаются, кроме безапелляционного утверждения:
Цитата:
это ... истина.
(где тут смайлик с фейспалмом?)

Цитата:
Семантика управляющего алгоритма реального времени не может адекватно быть описана без часов.
Естественно. Зачем вы ломитесь в открытую дверь?

Цитата:
Семантика управляющего алгоритма вообще не может адекватно быть описана с помощью функций.
А вот это неверно. Ибо f(t) - вполне себе функция.
И при этом время таки есть именно "просто еще один аргумент в векторе входных параметров".
Собственно, любая физическая модель использует такой подход. Почему ваше "академическое понятие алгоритма" должно быть каким-то особенным образом отделено от физического мира и его познания?

Поймите, пожалуйста, одну простую штуку: покуда вы будете возмущаться слабыми знаниями работников в этой области, классифицировать алгоритмические подходы и предлагать полезные решения - вы найдёте мою горячую поддержку.
Но как только вылезают (и агрессивно повторяются) "ПРИНЦИПИАЛЬНО", "НЕСВОДИМО" и прочие безапелляционные эпитеты - это уже "псевдоакадемизм" и даже лженаука, которым не место ни в учебнике, ни в форумной дискуссии.
Это единственная претензия к оппоненту, прошу понять правильно.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 17 Февраль, 2018 16:55 
Аватара пользователя

Зарегистрирован: Вторник, 04 Октябрь, 2011 17:45
Сообщения: 465
Что ж, победителем спора выходит Alexey_Donskoy.
Каков критерий?
У кого длинней посты, тот и прав.
А почему так?
Потому что к этому располагает формат: текстовые сообщения.
Если это беседа в одном помещении, то выигрывает тот, кто кричит громче.

А теперь серьёзно. Вот позиция В.И. Шелехова:
https://drakon-editor.com/ide/doc/examples/126
Вложение:
20180217145338.png
20180217145338.png [ 137.55 КБ | Просмотров: 438 ]


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 17 Февраль, 2018 19:07 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 951
Откуда: Россия, Чебоксары
Степан Митькин писал(а):
располагает формат: текстовые сообщения.
Дракон-схема разбавила текст разнообразием, но не решила ничего и ничего понятнее не сделала. :(

Кстати, что касается "языкового процессора", то это "программа-процесс" чистой воды: обрабатывает сплошной поток входных данных заранее неизвестного содержания.
Забавно, что в этом входном потоке время приобретает совсем непривычные формы - позиции во входном файле. :wink:

И со встречной стороны - посмотрим, например, на логику работы релейной защиты и автоматики (которые есть стопроцентные "управляющий алгоритм"). А ведь это не что иное, как тот же языковой процессор! Ибо там распознаётся (по признакам аварии) соответствующая "синтаксическая конструкция" и производятся соответствующие действия.

В общем, гиблое это дело - искать принципиальные отличия.
Искать наиболее подходящие для конкретного случая методы - другое дело.
Тут классификация полезна.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 17 Февраль, 2018 23:02 

Зарегистрирован: Воскресенье, 09 Март, 2008 22:38
Сообщения: 336
Степан Митькин писал(а):
Что ж, победителем спора выходит Alexey_Donskoy

Да ничего подобного.

Против правды можно много говорить, изрыгать тыщи букофф...

Все равно она останется истиной.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 17 Февраль, 2018 23:19 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 951
Откуда: Россия, Чебоксары
TAU писал(а):
Все равно она останется истиной.
Правильно.
Истина в том, что вычислительный алгоритм есть вырожденный частный случай управляющего.
Истина в том, что время входит во входной вектор X в обобщённой формуле S[n+1]=f(X[n],S[n]).

Истина также в том, что введение времени в вектор X существенно затрудняет анализ алгоритма формальными методами по сравнению с вырожденным частным случаем.
Однако это не повод называть разницу между вычислительными и интерактивными алгоритмами принципиальной.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 19 Февраль, 2018 09:10 

Зарегистрирован: Суббота, 16 Февраль, 2008 07:58
Сообщения: 230
Откуда: Россия, Стерлитамак
Вот еще бы чОткую инструкцию приложили, как разрабатывать программы-функции, и как управляющие )


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 19 Февраль, 2018 11:49 
Аватара пользователя

Зарегистрирован: Вторник, 04 Октябрь, 2011 17:45
Сообщения: 465
adva писал(а):
Вот еще бы чОткую инструкцию приложили, как разрабатывать программы-функции, и как управляющие )

:)
В смысле, учебник по программированию пересказать?
А вообще я согласен с adva: программистское дело надо бы упорядочить. Требуются инструкции.
Некоторые скажут: программирование требует мышления, а не тупого повторения процедур.
Отвечу: мышление дорого стоит. Процедуры (правила программирования) помогут избежать думания там, где оно не нужно.

Экономь мышления бюджет
для задач творческих!


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 19 Февраль, 2018 20:08 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 174
Alexey_Donskoy писал(а):
Цитата:
Подавляющее большинство реальных задач невозможно решить методами логического программирования.

Вот тоже хорошая иллюстрация к теме.
Да, невозможно.
А почему?
Академист может сказать, что из-за принципиального различия.
Различия чего? Теории?
Фиг.
Различие только в исполнителе.
Ну, кривой исполнитель в логическом программировании. Заточенный на узкий круг задач и непригодный к решению других.

Всё-таки, необходимо уточнить. Теория как раз и формирует "репертуар" исполнителя. И в данном случае рассматривается проблематика именно логического программирования, т.е. представление предметки как базы знаний/фактов и применение к ней операций соответствующего вывода.
А в целом, исполнители Пролог-подобного "pattern matching"-а отнюдь не кривые, позволяют реализовать произвольную императивщину. Достаточно взглянуть на Эрланг, фактически, потомка Пролога с подкорректированным синтаксисом, где сохранился даже стиль именования переменных с большой буквы. Или в качестве примера -- проект Bloom (фреймворк для верификации/анализа распределенных условно монотонных вычислений), где вычислительные модели представляются на диалекте Пролога (точнее DataLog-а). Для тех, кому страшен "хардкордный" DataLog, предлагают "попсовый" Ruby-подобный язык, который потом трансформируется в DataLog.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 19 Февраль, 2018 20:12 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 174
Alexey_Donskoy писал(а):
Истина в том, что вычислительный алгоритм есть вырожденный частный случай управляющего.
Истина в том, что время входит во входной вектор X в обобщённой формуле S[n+1]=f(X[n],S[n]).

Истина также в том, что введение времени в вектор X существенно затрудняет анализ алгоритма формальными методами по сравнению с вырожденным частным случаем.
Однако это не повод называть разницу между вычислительными и интерактивными алгоритмами принципиальной.

Совершенно верно, сам факт введения условного времени на входе алгоритма не даёт повода классифицировать алгоритм именно как реагирующий/управляющий. Интерактивный алгоритм может вообще не иметь входа.
Alexey_Donskoy писал(а):
Цитата:
И базовая операция "ожидание" есть основа для пунктов выше (вне зависимости от природы исполнителя и реализации операции).

Да. Это семантика.
Но ожидание не аксиоматически существует в базисе, а реализуется строго теми же базовыми примитивами императивного программирования.

Это та семантика, которая не может быть внутри вычислительного алгоритма. Если быть корректным, то Закревский (по ссылкам ранее) указывает в базисе управляющего алгоритма две операции: "ожидание" и "действие". Действия имеются и в вычислительных алгоритмах (математические действия), но с особенностями, о них далее (требуется разбор полётов с понятием алгоритма).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 19 Февраль, 2018 20:20 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 174
Alexey_Donskoy писал(а):
Цитата:
должна же быть какая-то наука об алгоритмизации...

Да пожалуйста.
Только обсуждение в моей старой теме "Что же такое алгоритм?" так и не привело к консенсусу, что этим алгоритмом следует считать, а что нет.
Предлагаете по пятому кругу обсуждение вести? :wink:
Тогда вопросы: следует ли считать алгоритмом любую функцию f(X[n],S[n])?
Следует ли считать данные X[n], подаваемые на вход логической машины, программой? :wink:
Я на оба вопроса отвечаю утвердительно, кстати.

Похоже, "пятого" круга не избежать :). Да, вспоминается та тема:
http://forum.drakon.su/viewtopic.php?p=14996#p14996
Но, насколько я помню, позже неоднократно здесь на форуме ссылались на информатику в изложениях Г.Н. Зверева, который максимально межпредметно обобщил базис, и, вроде как, никакой "разгромной" критики не было. Процитирую ключевые моменты (громоздко, но вся терминология как раз в данную тему форума, кому-то может пригодиться) -- из "Зверев Г.Н. Теоретическая информатика и ее основания." Т.1., гл.7 (материалы доступны и в прошлой редакции "Теоретическая и фундаментальная информатика" (гл.7) на сайте автора):
Цитата:
7.5. Алгоритмика процессов и управляющие структуры

Процесс, состояние, событие, действие. От описания структуры
системы произвольной природы перейдем теперь к изучению структур
разнообразных процессов, происходящих в системе и ее объектах на
разных иерархических уровнях, к построению структурных моделей
процессов и других характеристик динамической системы. В наиболее
общем виде понятие процесса определяется как упорядоченная во
времени последовательность состояний, событий, действий,
взаимообусловленных причинными и целевыми связями прообъектов системы
и внешнего окружения. Последовательность есть линейно
упорядоченное множество прообъектов, которые можно занумеровать целыми или
натуральными числами в соответствии с текущими моментами времени
так, что если номер п> т, то время tn >= tm. Понятие состояния
уточним чуть позже, а событие понимается как ощутимое, выше порога
различимости, изменение состояний, скажем, |S1 — S2| > delta(Sr), которое
можно привязать к определенному моменту или интервалу
времени, либо достижение системой целевого, либо выделенного состояния
S0 = S(t), иначе, событие есть совместное бытие S и S0.
В психологии, в бихевиористике, в технике действие есть
проявление какой-либо активности, силы, энергии со стороны человека,
машины или природных сил, поступок, шаг предопределенного
процесса. В физике действие есть произведение разности кинетической
и потенциальной энергии на время действия. В системологии
понятие действия трактуется весьма широко как элементарный или более
укрупненный составной шаг целенаправленного поведения активного
субъекта, человека или машины, вызывающий изменения состояний
системы.
Приведенные рассуждения показывают, что исходным понятием
в определении процесса является состояние. В системологии понятие
состояния стоит в ряду базисных категорий вместе с такими понятиями
как различимость, прообъект, система, процесс. Прежде всего,
представление о состоянии чего-либо ассоциируется с выражением в
определенных значениях каких-то постоянных или переменных парамет-
ров системы. При формализации системы в ней выделяют известные
и неизвестные объекты и связи между ними, их различимые и
неразличимые свойства, неизменные и меняющиеся объекты, их
характеристики, соответственно части системы разделяются на постоянные
и переменные. Последние включают статичные объекты,
неподвижные, но изменяющиеся по свойствам и связям, и потоковые,
подвижные объекты, образующие материальные и информационные
потоки
прообъектов, называемых транзактами. Потоки, как и отдельные
объекты в потоке, характеризуются наборами числовых и нечисловых
параметров, объединенных в сигнаты, S-объекты, которые и описывают
потенциально изменчивые состояния системы.
Итак, описание состояния системы — это описание свойств ее
объектов и связей между ними в виде набора констант и
переменных, их значений, т.е. параметров, характеристик, количественных
и качественных признаков, принимающих определенные или размытые
значения в некоторый момент времени t. Чаще всего состояние системы
описывается сигнатными переменными, S-объектами, но в общем слу-
чае переменные, выражающие состояния, могут быть и функциональ-
ными и реляционными переменными, F-объектами и R-объектами из
соответствующих классов — доменов этих переменных. Переменные,
описывающие изменчивые состояния, могут быть известными либо
неизвестными, элементарными, базисными из FSR-базиса, либо
составными в виде набора, вектора переменных или структуры. В системах
с постоянной структурой, наиболее изученных, имеющих развитый
математический аппарат, функциональные и реляционные состояния
остаются неизменными, а если изменяются, то эти изменения соответ-
ствующим образом параметризуются, и определенные таким способом
параметры включаются в S-объекты, тогда полное состояние — статус
системы — представлен набором S-объектов, и процессы в системе
представляются сигнатными процессами — функциями преобразования
состояний, зависящих от времени. В системах с переменной структурой
возникают дискретно-непрерывные процессы структурных
преобразовании реляционных и функциональных объектов.

История, поведение, алгоритм процесса. Последовательность во
времени состояний системы, зависящих от внешних и внутренних
воздействий, называется поведением системы или траекторией, фа-
зовой траекторией и выражает историческое описание или историю
процесса или системы
. Состояние системы и состояние внешней сре-
ды в определенный момент времени определяют текущую ситуацию,
а последовательность ситуаций есть история надсистемы. Другое
название ситуации — сцена, а история надсистемы есть сценарий,
описывающий последовательность ситуаций в определенном временном
интервале. Историческое описание процесса может быть полным либо
частичным. Избыточное описание процесса можно сократить без
потери точности и подробности характеризации процесса, представить его
в «свернутом» виде, используя функциональные связи и естественную
причинную ориентацию. Подобное представление процесса называется
алгоритмом процесса, по нему можно получить развернутое описание
в виде истории системы либо в виде траектории состояний объектов
в полном фазовом пространстве системы и надсистемы.
Представляя функционирование информационно-материальных систем
различной природы, выделяют объектные и операционные
истории. Объектная история характеризует последовательность
возникновения в системе (генерации) FSR-объектов, изменения их состояний,
движения в виде транзактов, начиная с появления на входных полюсах
системы и кончая выходом из системы через соответствующие
выходные полюса системы либо исчезновением, гибелью, аннигиляцией,
стиранием из памяти, «разбором» на составные компоненты внутри
системы, размазыванием и т.п. Операционная история описывает
последовательности преобразовании объектов системы и их состояний,
начиная с генерации, рождения и последующих превращений, преоб-
разований, гибели или удаления из системы. Операционная история
определяет последовательности работы F-объектов системы и являет-
ся функциональным описанием алгоритма процесса в виде линейно
или частично упорядоченных этапов реализации процесса. Для
процессов, происходящих в системах с постоянной структурой, с
неизменными функциональными и реляционными объектами,
операционная история выражает последовательности преобразований S-объектов
s -> s' = f(s). В системах с переменной структурой операционная
история описывает процессы возникновения и всевозможные превращения
FSR-объектов в виде взаимообратных переходов s <-> f, s <-> r, f <-> r,
f -> f', r -> r', s -> s'. Наличие тех или иных типов преобразований
определяет и тип процесса в целом.

Классификация процессов. [...]

Траектории состояний. Математический и технологический
алгоритм процесса.
Модели и характеристики процессов весьма
разнообразны по форме задания, степени абстрагирования и полноты
описания. Чтобы определить процесс, необходимо задать не только
систему, но и законы изменения состояний во времени от внутренних
и внешних воздействий (источников и стоков), вычислить
промежуточные и финишные состояния, определить обобщенные характеристики
процесса. Мы ограничимся двумя видами представления произвольно-
го информационно-материального процесса: свернутым представлением
в виде алгоритма процесса и развернутым представлением в виде
траектории системы в пространстве состояний, которая выше была
названа историей системы или процессов в ней.
Описание процесса в виде последовательности преобразований,
линейной либо разветвленной (для параллельного процесса), не является
алгоритмом. Основное семантическое различие истории и алгоритма
процесса состоит в различии описательной, декларативной формы
информации, содержащейся в истории, и конструктивной
императивной формы представления алгоритма. Это различие нашло отражение
в теоретическом программировании в виде формального
представления декларативной и процедурной (функциональной, императивной)
семантики. В других областях науки и техники императивная
функция информации была формализована понятием управления, его мы
рассмотрим чуть позже. Алгоритм реализации процесса по существу
совпадает с понятием алгоритма функционирования системы. Понятие
алгоритма возникло в математике как способ однозначного описания
преобразований математических объектов. С развитием кибернетики-
информатики абстрактное понятие алгоритма наполнилось более
конкретным и более широким содержанием, которое охватило помимо
математических систем и процессов всю человеческую деятельность,
поддающуюся формализации и строгому знаковому описанию. В связи
с этим математическое понятие алгоритма должно быть уточнено при
переходе к произвольным системам и процессам.
В теории алгоритмов понятие математического алгоритма
отождествляется с понятием рекурсивной или эффективно вычислимой
функции, определенной в классе конструктивных объектов, а само
определение алгоритма формулируется так: «точное предписание,
которое задает вычислительный процесс (называемый в этом случае
алгоритмическим), начинающийся с произвольного исходного данного (из
некоторой совокупности возможных для данного алгоритма исходных
данных) и направленный на получение полностью определяемого этим
исходным данным результата» [84]. Это и подобные ему определения
считаются априори понятными математическому субъекту на уровне
интуиции, и при углубленном анализе понятие алгоритма в конечном
счете математики относят к неопределенным базисным понятиям,
таким как множество или число. В теоретической информатике,
напротив, стараются заменить не вполне ясную математическую интуицию
внешними по отношению к формализованному (объективированному)
субъекту конструктивными объектами и процессами.
При подобном переходе и расширении семантики понятие
математического алгоритма заменяется произвольным технологическим
(информационно-материальным) алгоритмом, в котором описаны не
только знаковые, информационные процессоры и преобразуемые
объекты, но и материальные преобразователи, системы, процессы в них,
и описание отсылает систему, реализующую
материально-информационный процесс, к внутренним дентам и контам соответствующих
знаков и понятий, внешним, материальным дентам, сенсорам, рефорам
и эффекторам, связанным с материальными объектами и процессами.
Итак, технологический алгоритм задается в
материально-информационном FSR-базисе, содержащем конечное число допустимых
материальных и информационных объектов. Так, S-базис содержит перечень
допустимых статусных (сигнатных) объектов и форм их представления:
вещества, детали, изделия, виды энергии, сигналы, базы данных и
другие знаки; функциональный базис содержит перечень станков,
технологического оборудования, информационных процессоров; реляционный
базис определяет типы R-объектов: условия, ограничения, требования,
связи и т. п. Математический алгоритм материально-информационного
процесса есть приближенная абстрактная модель технологического ал-
горитма.
Чтобы отделить технологические алгоритмы, частичные или всюду
определенные в заданном классе объектов предметики, от квазиал-
горитмов, необходимо фиксировать FSR-базис и систему, в которой
этот базис реализуется, а также определить алгоритмический или,
точнее сказать, технологический язык алгоритмики — язык
реализации информационных и материальных процессов и технологий, на
котором будет определено управление реализацией алгоритмического
процесса в заданном базисе. На технологическом языке по строго
формализованным правилам задается последовательность шагов
процесса с указанием FSR-объектов для каждого этапа процесса, входные
и выходные объекты, данные F-объекта, предусловия и постусловия
и действия при их нарушении, что и составляет программу процесса,
т. е. точную инструкцию на технологическом языке без предположений
о «догадливой, изобретательной и умной» системе, которая сама решит,
домыслит, что делать, если описание алгоритма неполное.
Реализацию математического алгоритма, записанного на логико-
математическом языке, выполняет математический процессор
объективированного субъекта. Реализация технологического алгоритма может
быть выполнена в информационно-материальной системе —
технологическом процессоре, если он имеет в своем составе все
необходимые функциональные объекты, правильно воспринимающие команды
технологического алгоритма и способные обеспечить информационный
процесс контроля и управления ходом протекания воплощаемого
информационно-материального технологического процесса, поэтому в
открытых системах важную функцию несет подсистема управления.
[...]


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 19 Февраль, 2018 20:29 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 174
Alexey_Donskoy писал(а):
Цитата:
ПРОЦЕСС - это НЕ ФУНКЦИЯ.

Конечно, нет. Для чего это тривиальное утверждение?
Функция используется для преобразования процессов.

Alexey_Donskoy писал(а):
Цитата:
Математической основой всего перечисленного, как правило, служат графовые модели - системы переходов (конечные автоматы, сети Петри).

Графы - да, но они отнюдь не сводятся к сетям Петри и даже к конечным автоматам.
Например, графами описываются дифференциальные уравнения, которые в управляющих алгоритмах играют отнюдь не последнюю роль.
...

Alexey_Donskoy писал(а):
Не хотите замечать, что я всё время говорю о процессах и только о процессах - и о том, как функцию применить к управлению этими процессами? А ведь я все возможные варианты подробно расписал в этой задаче!

Всё-таки, не все варианты (как минимум, входные данные откуда-то берутся, же). Понятие функции отнюдь не тривиальное.

Если функция понимается в терминологии, близкой к философии (или системологии, теории систем) -- предназначение, исполняемая объектом роль в системе (функциональность) -- F-объект по Звереву выше -- то в таком случае функция подразумевается как процесс ("как упорядоченная во времени последовательность состояний, событий, действий ..."). Соответственно, формализм алгоритма процесса -- управляющего, реагирующего, интерактивного -- должен предусматривать понятие состояния, выражение последовательности (причём упорядоченной -- с учётом возможности параллельного или совместного исполнения процессов), операции выявления событий ("ощутимое, выше порога различимости, изменение состояний") и действия ("шаг целенаправленного поведения активного субъекта ..., вызывающий изменения состояний системы").

Если функция понимается как математическая -- подразумевается вычислительный алгоритм ("вычислительный процесс") -- с чего исторически начиналась формализация алгоритмики. Природа вычислительного алгоритма исходит из самого понятия мат. функции, как отображения одних элементов множества на другие. Особенности:
- алгоритм не может выполнить "действие" над входными объектами, вызывающее изменение их состояния, иначе никакого "отображения/сопоставления" не будет;
- по этой же причине алгоритм не может "добывать" для себя новые входные математические объекты (к примеру, мол "считывать" показания времени) -- все внешние объекты должны быть заданы исключительно на входе, перед исполнением (соответственно, нет возможности выполнить действие и над "сторонними" объектами).

Формализм репертуара математического процессора не может "напрямую" выполнять "вкл./выкл.", "запуск/останов", или изменять свойства/состояния ("математический алгоритм материально-информационного процесса есть приближенная абстрактная модель технологического алгоритма"). Он может лишь вернуть "S-объект" (статусный, сигнатный), который используется другим (внешним, материально-информационным) процессором (который в т.ч. подготавливает и входные данные для вычислительного алгоритма). Соответственно, "выявление события" в таком формализме также невозможно, поскольку определив "различимое изменение состояния" нет возможности выполнить "действие" -- инициировать реакцию.

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

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

Пожалуй, в характеристиках вычислительных и реагирующих алгоритмов есть важное отличие: реагирующий/управляющий алгоритм может исполняться бесконечно (пока существует системный объект), что не есть нарушение правильности, вычислительный же -- обязательно конечный.

И "водораздел" на вычислительные алгоритмы и прочие "невычислительные" процессы в программировании мы все наглядно наблюдаем (ну, в тех краях, где более-менее придерживаются математических устоев) -- разделение на "программные функции" ("чистые", комбинаторные функции) и "функции с побочными эффектами" ("процедуры" и прочие "task"-и, "node", "actor"-ы с "process"-ами и т.п.). Штука важная, что позволяет, к примеру, не делать лишнюю работу, воспользоваться результатами пред. вычислений, если данные для аргументов функции не изменялись (такие трюки безопасны, конечно, если система типов отслеживает все эффекты, а не просто существуют "устные соглашения"), не говоря о прочих защитах от непреднамеренного изменения данных.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 19 Февраль, 2018 21:02 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 3702
Откуда: Москва
PSV100, большое Вам спасибо за обширные цитаты и подробные комментарии.

Отдельное спасибо за ссылку на книгу Закревского.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 19 Февраль, 2018 23:24 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 951
Откуда: Россия, Чебоксары
PSV100 писал(а):
Теория как раз и формирует "репертуар" исполнителя.
Само собой.
Но не рискуем ли мы тут свалиться в проблему "курица-яйцо"? :wink:

Цитата:
А в целом, исполнители Пролог-подобного "pattern matching"-а отнюдь не кривые, позволяют реализовать произвольную императивщину.
Возможно. Почему бы нет.

Но есть забавные свойства у систем разного класса и назначения.
Может быть простой исполнитель - тогда программа для него будет сложной.
А может быть специализированный сложный исполнитель, который берёт на себя очень много - а программы для него просты. Это, к примеру, системы моделирования со своими DSL, или та же Пролог-машина.
И есть особенность таких систем: чем уже специализация, тем сложнее программы, реализующие функциональность за пределами специализации...

Цитата:
Это та семантика, которая не может быть внутри вычислительного алгоритма.
Этот тезис плохо звучит и странно пахнет.
Примерно как: "В вырожденном частном случае не может быть семантики более общего".
Ну так он на то и есть частный случай, да ещё и вырожденный. :wink:

Цитата:
указывает в базисе управляющего алгоритма две операции: "ожидание" и "действие"
Повторно обращаю внимание, что ожидание не обязано быть в базисе ИСПОЛНИТЕЛЯ. Оно реализуется при помощи тех же действий.
Другими словами, если действие и условный переход составляют базис императивного исполнителя, то ожидание туда не входит - оно может являться там банальным макроопределением.

Цитата:
Процитирую ключевые моменты (громоздко, но вся терминология как раз в данную тему форума, кому-то может пригодиться) -- из "Зверев Г.Н. Теоретическая информатика и ее основания."
Всё вроде правильно изложено, да.
Однако же юмор всей ситуации в том, что хотя рассмотрение всего этого многообразия действительно полезно, всё это описанное многообразие не выходит за рамки обобщённого S[n+1]=f(X[n],S[n]) ! :wink:

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

Цитата:
Всё-таки, не все варианты (как минимум, входные данные откуда-то берутся, же).
Вот этого не понял. Какая разница, откуда они берутся, если перечислены все возможные варианты их свойств: процессы, константы, отсутствие.

Цитата:
Если функция понимается как математическая -- подразумевается вычислительный алгоритм
Да пожалуйста, сколько угодно.
Но пользы-то именно от этой классификации немного.
И там, и там, действия выполняются одними и теми же командами исполнителя.
Наложите ряд ограничений на тактику использования команд - получите "вычислительный алгоритм".
Вопрос - зачем?

Цитата:
Пожалуй, в характеристиках вычислительных и реагирующих алгоритмов есть важное отличие: реагирующий/управляющий алгоритм может исполняться бесконечно (пока существует системный объект), что не есть нарушение правильности, вычислительный же -- обязательно конечный.
Конечно.
Однако ж это вовсе не отменяет того, что одно есть частный случай другого!

Цитата:
Штука важная, что позволяет, к примеру, не делать лишнюю работу, воспользоваться результатами пред. вычислений, если данные для аргументов функции не изменялись (такие трюки безопасны, конечно, если система типов отслеживает все эффекты, а не просто существуют "устные соглашения"), не говоря о прочих защитах от непреднамеренного изменения данных.
Пожалуй, это единственная прикладная польза от рассматриваемой классификации...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 20 Февраль, 2018 00:33 

Зарегистрирован: Воскресенье, 09 Март, 2008 22:38
Сообщения: 336
Alexey_Donskoy писал(а):
Другими словами, если действие и условный переход составляют базис императивного исполнителя, то ожидание туда не входит - оно может являться там банальным макроопределением

Алексей Донской, признайте свое поражение в споре


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 20 Февраль, 2018 09:36 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 951
Откуда: Россия, Чебоксары
TAU писал(а):
Алексей Донской, признайте свое поражение в споре
Какой спор? В чём поражение?
Мои тезисы пока что никто и близко не опроверг:
Цитата:
- Вычислительный алгоритм есть вырожденный частный случай управляющего.
- Время входит во входной вектор X в обобщённой формуле S[n+1]=f(X[n],S[n]).

Введение времени в вектор X (наряду с другими сигналами из внешнего мира) существенно затрудняет анализ алгоритма формальными методами по сравнению с вырожденным частным случаем.
Однако это не повод называть разницу между вычислительными и управляющими (интерактивными) алгоритмами принципиальной.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 20 Февраль, 2018 10:50 
Аватара пользователя

Зарегистрирован: Вторник, 04 Октябрь, 2011 17:45
Сообщения: 465
TAU писал(а):
Алексей Донской, признайте свое поражение в споре

Уже частично признал:
Цитата:
- Вычислительный алгоритм есть вырожденный частный случай управляющего.

Насчёт слова принципиально.
Между дубиной и пулемётом принципиальной разницы тоже нет. Это разные виды оружия. Главное — решимость бойца.
Но ТТХ пулемёта другие...
Так же и здесь.
У нас в датацентре в январе произошёл сбой. Разбор полётов показал: причина в ошибке в программе, которая мониторит сервера.
Виновный программист, скорее всего, даже не знал, что пишет алгоритм управления. Поэтому у него не было шансов с самого начала.
Если бы тот программист понимал, что разрабатывает "программу-процесс", то он бы (по Шелехову) применил бы соответствующие "методы программной инженерии". Но он не знал и не применил. Итог печален.
Слава богу, у нас не авионика и не атомная станция.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 20 Февраль, 2018 11:35 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 951
Откуда: Россия, Чебоксары
Степан Митькин писал(а):
Уже частично признал
Вообще-то этот тезис я с самого начала писал, если кто вдруг забыл.

Цитата:
Между дубиной и пулемётом принципиальной разницы тоже нет. Это разные виды оружия. Но ТТХ пулемёта другие...
Любителям пустопорожней классификации замечу, что здесь разница именно в базовых свойствах.
А управляющие и вычислительные алгоритмы имеют в основе один и тот же базис (и отличаются только уровнем организационной сложности).
У оппонентов были выше попытки расширить базис операцией ожидания, но попытки эти, строго говоря, некорректны, т.к. ожидание сводится к тем же базовым операциям "действие" и "условный переход".

Цитата:
У нас в датацентре в январе произошёл сбой. Разбор полётов показал: причина в ошибке в программе, которая мониторит сервера.
Виновный программист, скорее всего, даже не знал, что пишет алгоритм управления. Поэтому у него не было шансов с самого начала.
Если бы тот программист понимал, что разрабатывает "программу-процесс", то он бы (по Шелехову) применил бы соответствующие "методы программной инженерии". Но он не знал и не применил. Итог печален.
Вы должны чётко осознавать, что виновен не программист, а менеджер, который поставил на задачу неквалифицированного исполнителя.
Всё. Больше в этом примере говорить не о чем.
Разве что добавить, что "программист, не понимающий, что пишет алгоритм управления", на мой взгляд, вообще программистом не является.
Избаловали вас там "разделением труда" - кодеры, аналитики, архитекторы... А итог печален.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 20 Февраль, 2018 20:37 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 174
Alexey_Donskoy писал(а):
PSV100 писал(а):
Процитирую ключевые моменты (громоздко, но вся терминология как раз в данную тему форума, кому-то может пригодиться) -- из "Зверев Г.Н. Теоретическая информатика и ее основания."

Всё вроде правильно изложено, да.

Очень хорошо, если теперь можно говорить на одном языке, надеюсь. :wink:
Alexey_Donskoy писал(а):
PSV100 писал(а):
Если функция понимается как математическая -- подразумевается вычислительный алгоритм

Да пожалуйста, сколько угодно.
Но пользы-то именно от этой классификации немного.
И там, и там, действия выполняются одними и теми же командами исполнителя.
Наложите ряд ограничений на тактику использования команд - получите "вычислительный алгоритм".
Вопрос - зачем?

В данном случае речь о математических формализмах, а не о реализации технологического алгоритма. И понятие вычислительного алгоритма или вычислительного процесса устоявшееся, определенное.
Alexey_Donskoy писал(а):
PSV100 писал(а):
указывает в базисе управляющего алгоритма две операции: "ожидание" и "действие"

Повторно обращаю внимание, что ожидание не обязано быть в базисе ИСПОЛНИТЕЛЯ. Оно реализуется при помощи тех же действий.
Другими словами, если действие и условный переход составляют базис императивного исполнителя, то ожидание туда не входит - оно может являться там банальным макроопределением.

Ключевое не в том, как именно реализуются операции "ожидания" и "действия". Формализм алгоритма процесса обязан иметь средства для выражения "упорядоченной во времени последовательности состояний, событий, действий". Иначе нет такой предметки как "процесс" (реагирующий/управляющий).
Alexey_Donskoy писал(а):
Однако же юмор всей ситуации в том, что хотя рассмотрение всего этого многообразия действительно полезно, всё это описанное многообразие не выходит за рамки обобщённого S[n+1]=f(X[n],S[n]) ! :wink:

Процитирую вашу обобщённую модель:
Alexey_Donskoy писал(а):
Возьмём общее определение алгоритма: S[n+1]=f(X[n],S[n]), где S - пространство состояний исполнителя, X - вектор входных данных, f - собственно алгоритм как функция преобразования пространства состояний.
Имеем следующие частные случаи:

1) X - пустое множество. Тогда алгоритм можно назвать чисто вычислительным - он что-то считает по определённым правилам из предопределённого в нём же самом исходного пространства состояний. Например, осуществляет полный перебор шахматной задачи, или вычисляет корни трансцендентного уравнения с заданными коэффициентами, или рисует картинку на экране и т.п.

2) X - const. Тогда алгоритм однократно принимает исходные данные и заданным образом их преобразует. Например, анализирует введённую шахматную позицию, или вычисляет корни уравнения по введённым коэффициентам, или трансформирует заданный графический файл и т.п.

3) X=X(t), то есть меняется во времени. Это уже из той области, что выше названо "управляющим алгоритмом" - процесс в реальном (или модельном, неважно) времени и в меняющейся внешней среде. Например, игра в шахматы с человеком, или автоматическое управление технологическим процессом, или динамическое управление детализацией рендеринга в шутере (не говоря уж об игровых персонажах), и т.д. и т.п.

Ну и где принципиальная-то разница?
Зато характерные частные случаи налицо (вплоть до полностью вырожденного).

Итак, f - математическая функция, которая не имеет права выполнять "действие" (выше в теме указано, почему). "Рисовать картинку", "трансформировать заданный графический файл" и пр. f-функция лишь может "попросить" у внешнего информационного (материального) процессора, реализующий алгоритм процесса, вернув для него в качестве результата (внутри S[n+1] или отдельно, неважно) некий сигнатный объект, понимаемый процессором. Пусть процессором будет человек, или ... неважно, в общем то, ключевое -- он есть, со своим формализмом. Функция f может, если необходимо, "заказывать" для своего исполнения необходимые моменты времени (такты автомата), и прочее "просить" для себя, всё что необходимо (опять же, через рультаты работы). Этому процессору в помощь можно сформировать целый набор вспомогательных функций для управления f-функцией: функция выбора действия, состояния, моментов времени и пр.

Если f изначально определить как "функциональность" -- не функция -- формализм процесса, в каком-то там виде, будет введён в нашу "теорию процессов" сразу, не косвенно (ну, сигнатура "f-процедуры", скорее всего, будет иной, неважно).

В качестве примера можно воспользоваться формализмами упомянутого здесь в теме Esterel, как раз на основе реагирующих автоматов (на Оберкоре есть отдельная тема). Или у Зюбина:
http://forum.drakon.su/viewtopic.php?f=143&t=6160&start=20#p100964

, где результаты упомянутого здесь Закревского адаптированы под "программистский" стиль и расширены понимаем автомата как "гиперпроцесса" ("функция-состояние" (но не функция), совокупность функций-состояний и переключение между ними).
Alexey_Donskoy писал(а):
PSV100 писал(а):
Всё-таки, не все варианты (как минимум, входные данные откуда-то берутся, же).

Вот этого не понял. Какая разница, откуда они берутся, если перечислены все возможные варианты их свойств: процессы, константы, отсутствие.

В данном случае лишь следующая ремарка. При моделировании систем выразить геноры и агеноры (источники данных, не имеющих входа, и стоки, не имеющих выхода) на основе формализма функции невозможно, в смысле "в лоб" -- функция всегда должна иметь вход/выход (в т.ч. и для пустого множества). Конечно, функции применять можно, но они должны предварительно "договориться" с формализмом процесса.


Итого, изначально в данной теме речь шла о математических формализмах. Выразить формализм процесса (реагирующего, управляющего) через формализм математической функции невозможно (использовать функции в помощь -- сколько угодно). Этот формализм, новый, необходимо вводить явно, "с нуля" или на основе чего-то. И, если вдруг есть желание, построить "мостик" -- некий частный случай как вычислительный процесс на основе управляющего.
Отсюда, функция и процесс -- различные математические формализмы. Является ли такой факт "мелким техническим вопросом" или "принципиальной разницей" -- я судить не берусь. Пусть об этом говорят настоящие "носители логико-математического языка". :wink:

Если говорить о формализации технологических алгоритмов -- то здесь, конечно, от "никакой разницы" до наворотов "аспектно-ориентированного программирования", где "выявление событий" и "реакции-действия" -- целая "парадигма". :wink:

Кстати, здесь на форуме где-то относительно недавно ссылались на реализацию корутин/потоков в Kotlin -- потихоньку в мейнстрим протаскиваются здравые техники, имею в виду сам принцип:
https://github.com/Kotlin/kotlinx.coroutines/blob/master/coroutines-guide.md#composing-suspending-functions

где "ожидающие" suspend-функции работают как процессы по Закревскому/Зюбину ("замирают" до события), а компилятор сам перекручивает код для реализации автоматов (вместо ручного ада -- ибо на основе callback-ов, как альтернатива разворота процедур на стеке и переключений контекста), подробнее:
https://github.com/Kotlin/kotlin-coroutines/blob/master/kotlin-coroutines-informal.md


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 20 Февраль, 2018 22:54 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 951
Откуда: Россия, Чебоксары
PSV100 писал(а):
Очень хорошо, если теперь можно говорить на одном языке, надеюсь.
А что, были другие предложения?

Цитата:
В данном случае речь о математических формализмах, а не о реализации технологического алгоритма.
Дык это-то понятно. Вопрос - зачем?

Цитата:
Формализм алгоритма процесса обязан иметь средства для выражения "упорядоченной во времени последовательности состояний, событий, действий".
Согласен, это удобно.

Цитата:
Ключевое не в том, как именно реализуются операции "ожидания" и "действия".
А вот и нет.
Вы же сами хотите формализмов.
Так вот возможность реализации сложных формализмов через базовые примитивы как раз и доказывает отсутствие принципиальной разницы между рассматриваемыми формализмами.

Цитата:
Итак, f - математическая функция, которая не имеет права выполнять "действие"
Простите, но почему я должен принимать эти взятые с потолка правила? Для чего мне следует ограничиться так называемым вычислительным алгоритмом, если таких задач вокруг нет и не предвидится (а если и предвидится, то мне ничто не мешает подобрать наиболее удобные инструменты)?
В общем, мне эта игра не особо интересна, а с практической точки зрения и вовсе бесполезна.

Цитата:
выше в теме указано, почему
Выше в теме буквально указано: "потому что гладиолус".
То есть потому, что так некогда сформулировали математики, не предполагавшие наличия более интересного общего случая. И какой сейчас в этом интерес, кроме исторического?

Нет, ну в самом деле, почему некие стародавние математики запрещают мне говорить о пространстве состояний и его изменении?!
Ведь, в конце концов, это требование по существу незаконно: при вычислении даже чистейших математических функций имеют место промежуточные результаты (переменные). То, что они локальны, не даёт нам право на ханжеский пуризм.

Цитата:
Выразить формализм процесса (реагирующего, управляющего) через формализм математической функции невозможно
Да вот ведь опять двадцать пять.
С чего невозможно-то?!
Если алгоритмический формализм выражается через базовые примитивы, которые вполне себе можно считать функциями, то как бы и дело в шляпе!

Цитата:
функция и процесс -- различные математические формализмы
Ну я вас умоляю.
Ну повесили мы ярлык на некий формализм, назвали его "циклом", к примеру.
Да, он отличается от формализма "условный переход".
А как отличается? Да как множество отличается от составляющих его элементов.
Так есть бесконечное количество возможных комбинаций базовых элементов - на все эти варианты вы ж почему-то не вешаете ярлык нового формализма?
А почему не вешаете?
Да потому что оно вам нафиг не нужно.
А цикл - нужен. Вы считаете, что он удобен, с ним будет проще.
Вот, собственно, и весь вопрос. :wink:


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 112 ]  На страницу Пред.  1, 2, 3, 4, 5, 6  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
cron
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2008-2018, участники конференции «DRAKON.SU», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB