DRAKON.SU

Текущее время: Воскресенье, 22 Апрель, 2018 19:29

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




Начать новую тему Ответить на тему  [ Сообщений: 81 ]  На страницу 1, 2, 3, 4, 5  След.
Автор Сообщение
 Заголовок сообщения: Философия ДРАКОН-конструктора
СообщениеДобавлено: Суббота, 04 Август, 2012 12:01 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 3622
Откуда: Москва
ЧТО ТАКОЕ ДРАКОН-КОНСТРУКТОР?

Я использую термин «дракон-конструктор» по следующим причинам.

Во-первых, потому что он используется в книге
Цитата:
Паронджанов В. Д. Учись писать, читать и понимать алгоритмы. Алгоритмы для правильного мышления. Основы алгоритмизации. – М.: ДМК Пресс, 2012. – 520 с.: ил. 272


Во-вторых, чтобы иметь общий термин для ИС Дракон Геннадия Тышова и дракон-редактора Степана Митькина.

ПРИГЛАШЕНИЕ К ДИСКУССИИ

В данной теме хочу изложить свое мнение по принципам построения дракон-конструктора. Возможно, мое мнение ошибочное. Прошу критиковать.

БЛАГОДАРНОСТЬ ТЫШОВУ И МИТЬКИНУ

Я испытываю чувство глубокого уважения и огромной благодарности за грандиозный труд по созданию реальных, практически работающих дракон-конструкторов.

Если бы не было этих замечательных инструментов, которые уже нашли своих пользователей, язык ДРАКОН был бы туманной абстракцией. Или, как говорят, «сферическим конем в вакууме».

Огромное спасибо Геннадию Николаевичу и Степану Борисовичу, замечательным творцам и первопроходцам, которые решили сделать смелый шаг в Неизведанное.

Низкий Вам поклон.

А ТЕПЕРЬ КРИТИКА

По моему мнению, решения, положенные в основу обоих дракон-конструкторов, не являются оптимальными.

ПРИНЦИП ЛЕОНИДА ЭЙСЫМОНТА

Между тем, существует дракон-редактор, разработанный еще в 1992 году под руководством Леонида Эйсымонта из Института прикладной математики им. Келдыша РАН.

Мое мнение таково.

За основу построения дракон-конструктора следует взять принцип работы, использованный в редакторе Леонида Эйсымонта. (Я имею в виду именно принцип, а не детали реализации).

Все остальное, что захотят внести разработчики (Геннадий Тышов и Степан Митькин) можно реализовать в виде надстройки над редактором, обеспечивающим «принцип» Леонида Эйсымонта.

По сути, я не говорю ничего нового. Мой взгляд на построение дракон-конструктора, описанный в книге «Учись писать, читать и понимать алгоритмы», полностью соответствует Принципу Леонида Эйсымонта.

ПРИМЕР

У Геннадия Тышова этот принцип, к сожалению, не соблюдается.
Цитата:
- В настоящее время результат раскладки схем не всегда удовлетворительный, т.е. возникают пересечения, требуется ручная корректировка.
- Алгоритм не найден, можете предлагать свои соображения.
viewtopic.php?p=22669#p22669

Недостаток (Алгоритм не найден) сразу устраняется, если соблюдать Принцип Леонида Эйсымонта. Данный принцип снимает проблему и исключает пересечения.

ГДЕ СКАЧАТЬ РЕДАКТОР ЭЙСЫМОНТА

http://drakon.su/instrumenty/eysymont

Это устаревший, но работающий редактор (под MS DOS) Все желающие могут его пощупать и уяснить принцип его работы.

ВЫВОДЫ

1. Принцип Леонида Эйсымонта задает МИНИМАЛЬНЫЙ набор требований к редактору.

2. Этот принцип никак не ограниивает свободу действий разработчика дракон-конструктора. Разработчик может реализовать любые свои задумки, идеи и творческие планы.

3. Любые идеи, задумки и творческие планы можно реализовать в виде надстройки над принципом Леонида Эйсымонта. То есть в виде реализации дополнительных функций, добавляемых к основному каркасу редактора, обеспечивающего выполнение МИНИМАЛЬНОГО набора требований.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Философия ДРАКОН-конструктора
СообщениеДобавлено: Суббота, 04 Август, 2012 14:06 

Зарегистрирован: Понедельник, 09 Ноябрь, 2009 17:29
Сообщения: 904
Откуда: Россия, Питер
Владимир Паронджанов писал(а):
За основу построения дракон-конструктора следует взять принцип работы, использованный в редакторе Леонида Эйсымонта.
...
Мой взгляд на построение дракон-конструктора, описанный в книге «Учись писать, читать и понимать алгоритмы», полностью соответствует Принципу Леонида Эйсымонта.
...
У Геннадия Тышова этот принцип, к сожалению, не соблюдается.
...
Недостаток (Алгоритм не найден) сразу устраняется, если соблюдать Принцип Леонида Эйсымонта. Данный принцип снимает проблему и исключает пересечения.
...
1. Принцип Леонида Эйсымонта задает МИНИМАЛЬНЫЙ набор требований к редактору.
...
2. Этот принцип никак не ограниивает свободу действий разработчика дракон-конструктора. Разработчик может реализовать любые свои задумки, идеи и творческие планы.

3. Любые идеи, задумки и творческие планы можно реализовать в виде надстройки над принципом Леонида Эйсымонта.


Я так и не смог уловить, что из себя представляет "принцип Леонида Эйсымонта". И чем принципиально отличается работа в редакторе Леонида Эйсымонта от работы в ИС Дракон Геннадия Тышова.

Проверить отсутствие пересечений не получилось. Не нашёл как вставить цикл, который со стрелочкой : (
В граф меню его нет, а на все попытки переключить лиану редактор ругается : ) А ведь петля цикла и даёт все проблемы с пересечениями.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Философия ДРАКОН-конструктора
СообщениеДобавлено: Суббота, 04 Август, 2012 15:34 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 3622
Откуда: Москва
Ильченко Эдуард писал(а):
Я так и не смог уловить, что из себя представляет "принцип Леонида Эйсымонта".


Вы правы. Надо сформулировать его ЯВНО. Я сделаю это позже, через день-другой. А пока посмотрите мое описание дракон-конструктора в книге "Учись" здесь
http://drakon.su/_media/biblioteka/chas ... isanie.pdf


Ильченко Эдуард писал(а):
Проверить отсутствие пересечений не получилось. Не нашёл как вставить цикл, который со стрелочкой
Здесь слабое место у Эйсымонта. Такого цикла у него нет (не доделано).


Ильченко Эдуард писал(а):
В графическом меню его нет, а на все попытки переключить лиану редактор ругается
И правильно делает.

Ильченко Эдуард писал(а):
А ведь петля цикла и даёт все проблемы с пересечениями.
Подобные проблемы возникают только тогда, когда пользователь по незнанию совершает запрещенное действие, а именно: пытается оторвать стрелку цикла и присоединить ее в другое место.

Это должно быть категорически запрещено.

Стрелку цикла (в обычном цикле) — НЕЛЬЗЯ ОТСОЕДИНЯТЬ от своего места. Она прикреплена к этому месту НАВЕЧНО. Точку соединения стрелки и линии вообще нельзя трогать. Тогда не будет никаких проблем.


Последний раз редактировалось Владимир Паронджанов Суббота, 04 Август, 2012 16:05, всего редактировалось 2 раз(а).

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Философия ДРАКОН-конструктора
СообщениеДобавлено: Суббота, 04 Август, 2012 15:52 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 3622
Откуда: Москва
Эдуард, обратите внимание:
Цитата:
Тезис 26. Лиана – часть дракон-схемы, имеющая один вход сверху и один
выход снизу, именуемые «началом лианы» и «концом лианы» соот-
ветственно. Началом лианы может быть любой выход икон «вопрос» и
«вариант», если он (выход) не является петлей цикла. Концом лианы
считается точка слияния, в которой нижняя часть лианы соединяется
с другой линией (концом лианы не может быть неразветвленный вход
иконы).
http://drakon.su/_media/biblioteka/chas ... isanie.pdf

Я выделил красным важное утверждение. Отсюда следует, что Петля цикла — это не лиана.
Нельзя обращаться с петлей цикла, как с лианой. Это категорически запрещено.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Философия ДРАКОН-конструктора
СообщениеДобавлено: Суббота, 04 Август, 2012 17:02 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1442
Я так понимаю, что логика работы в ЛЭ-редакторе была основой определения языка и метода ещё в "Как улучшить..." (Гл. 14,15)?.. Т.е. вставляем атомы из меню, пункты которого представлены графическими кнопками, и работаем с лианами, какие можем оторвать в текущей конфигурации схемы?..


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Философия ДРАКОН-конструктора
СообщениеДобавлено: Суббота, 04 Август, 2012 17:21 

Зарегистрирован: Понедельник, 09 Ноябрь, 2009 17:29
Сообщения: 904
Откуда: Россия, Питер
Владимир Паронджанов писал(а):
Нельзя обращаться с петлей цикла, как с лианой. Это категорически запрещено.

~ 3 года назад (!) : ) мы с Вами уже вели диалог на подобную тему. Ни тогда, ни сейчас Вы не приводили аргументов почему этого нельзя делать кроме как "Мне кажется, что мой способ лучше чем Ваш".

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Философия ДРАКОН-конструктора
СообщениеДобавлено: Суббота, 04 Август, 2012 18:11 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 3622
Откуда: Москва
Ильченко Эдуард писал(а):
~ 3 года назад (!) : ) мы с Вами уже вели диалог на подобную тему. Ни тогда, ни сейчас Вы не приводили аргументов почему этого нельзя делать кроме как "Мне кажется, что мой способ лучше чем Ваш".

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

Ваш аргумент (в пользу Вашего варианта). Так удобнее.
Вполне возможно, спорить не буду.

Мой аргумент (в пользу моего варианта). Так уменьшается вероятность ошибки.

Я вполне допускаю, что опытный пользователь никогда не сделает в этом месте ошибку.

Но! Цикл — это потенциально опасное место. Поэтому другие пользователи (например, неопытные, слабые и т.д.) могут ошибиться.
Мой вариант гарантирует защиту от подобных ошибок (конечно, не от всех, а от части ошибок). Ваш — не гарантирует.

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

Предлагаемое Вами разрешение пользователю втыкать стрелку в разные места по своему усмотрению — это неоправданный риск, который при неблагоприятных условиях может привести к ошибке.
Именно поэтому я против.


Последний раз редактировалось Владимир Паронджанов Четверг, 09 Август, 2012 14:28, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Философия ДРАКОН-конструктора
СообщениеДобавлено: Суббота, 04 Август, 2012 22:35 

Зарегистрирован: Понедельник, 09 Ноябрь, 2009 17:29
Сообщения: 904
Откуда: Россия, Питер
Владимир Паронджанов писал(а):
Мой аргумент (в пользу моего варианта). Так уменьшается вероятность ошибки.
...
Я вполне допускаю, что опытный пользователь никогда не сделает в этом месте ошибку.
...
Предлагаемое Вами разрешение пользователю втыкать стрелку в разные места по своему усмотрению — это неоправданный риск, который при неблагоприятных условиях может привести к ошибке.
Именно поэтому я против.

Спасибо. Ваш аргумент понятен.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Философия ДРАКОН-конструктора
СообщениеДобавлено: Воскресенье, 05 Август, 2012 07:07 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 949
Откуда: Россия, Чебоксары
Владимир Паронджанов писал(а):
Цикл — это потенциально опасное место...
Мой вариант гарантирует защиту от подобных ошибок...
Предлагаемое Вами разрешение пользователю втыкать стрелку в разные места по своему усмотрению — это неоправданный риск, который при неблагоприятных условиях может привести к ошибке.
Именно поэтому я против.
Как насчёт веточного цикла? :D


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Философия ДРАКОН-конструктора
СообщениеДобавлено: Воскресенье, 05 Август, 2012 09:50 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 3622
Откуда: Москва
Ильченко Эдуард писал(а):
Владимир Паронджанов писал(а):
...

Спасибо. Ваш аргумент понятен.
Вопрос очень важный. Поэтому уместно привести дополнительные аргументы и соображения.
Ниже приведены последние два параграфа из "Главы 34. ИСЧИСЛЕНИЕ ИКОН" в книге
Цитата:
Паронджанов В. Д. Учись писать, читать и понимать алгоритмы. Алгоритмы для правильного мышления. Основы алгоритмизации. – М.: ДМК Пресс, 2012. – 520 с.: ил. 272
В этих параграфах подводится итог главы 34. ИСЧИСЛЕНИЕ ИКОН.
Цитата:
§10. ДОКАЗАТЕЛЬСТВО ПРАВИЛЬНОСТИ АЛГОРИТМОВ

Роберт Андерсон подчеркивает: «целью многих исследований в области доказательства правильности программ является... механизация таких доказательств» [8]. Дэвид Грис указывает, что «доказательство должно опережать построение программы» [9].

Объединив оба требования, получим, что автоматическое доказательство правильности должно опережать построение алгоритма. Нетрудно убедиться, что предлагаемый метод обеспечивает частичное выполнение этого требования.

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

Дракон-конструктор осуществляет 100%-е автоматическое доказательство правильности шампур-схем, гарантируя принципиальную невозможность ошибок визуального синтаксиса.

В начале главы мы задали смешной вопрос: если шампур-схемы – это теоремы, кто должен их доказывать? Ответ прост. Их никто не должен доказывать, так как все они раз и навсегда доказаны. Потому что работа дракон-конструктора построена как реализация исчисления икон.

А теперь добавим ложку дегтя в бочку меда. К сожалению, данный метод позволяет доказать правильность шампур-схемы и только. Это составляет лишь часть от общего объема работы, которую нужно выполнить, чтобы доказать правильность алгоритма на 100%. Здесь необходима оговорка.

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

§11. ВЫВОДЫ

1. Построено визуальное логическое исчисление, которое мы назвали «исчислением икон».

2. Данное исчисление можно рассматривать как раздел нового направления – визуальной математической логики.

3. Показано, что графический синтаксис языка ДРАКОН представляет собой исчисление икон.

4. Исчисление икон является теоретическим обоснованием языка ДРАКОН.

5. Исчисление икон полностью реализовано во внутренних алгоритмах работы дракон-конструктора.

6. Дракон-конструктор осуществляет 100%-е автоматическое доказательство правильности шампур-схем, гарантируя принципиальную невозможность ошибок визуального синтаксиса

http://drakon.su/_media/biblioteka/chas ... drakon.pdf
стр. 433, 434

ЗАЧЕМ Я ПРИВЕЛ ЭТИ ЦИТАТЫ?

Чтобы подчеркнуть одну из важнейших или даже наиболее важную задачу дракон-конструктора.

1. Главной задачей дракон-конструктура является содействие безошибочному проектированию алгоритмов.

2. Понятно, что дракон-конструктор не может предотвратить ошибки в тексте алгоритма.

3. Но! Дракон-конструктор может и должен предотвращать и исключать ошибки в графике алгоритмов (ошибки графического синтаксиса). Эти ошибки должны быть исключены на 100%. Исключены автоматически. Не человеком, а автоматом, то есть дракон-конструктором.

4. Автомат должен немедленно пресекать попытку пользователя сделать ошибку. Давить ее в зародыше. Это означает, что дракон-конструктор не должен потакать пользователю, который по неразумению пытается совершить ошибочные действия. Автомат должен запрещать такие действия.

5. Существующие дракон-конструкторы не в полной мере решают свою главную задачу.

6. Главная задача должна рассматриваться как стратегическая цель.
Эта цель вполне достижима. И к ней следует настойчиво двигаться.

7. Пользователям нужен дракон-конструктор, который гарантирует безошибочную графику дракон-схем. Графику, безошибочную на 100%.

8. Требование удобства (то есть требование эргономичности) само собой. Для многих оно на первом месте. И об этом тоже нельзя забывать.
_________________________________________________

Уважаемый Эдуард Ильченко!

Я глубоко признателен Вам за то, что Вы своевременно выявили, поставили и сформулировали важный вопрос. Вы направили на него яркий луч прожектора и потребовали внести ясность.

Благодаря Вам внимание было привлечено к важнейшему вопросу теории и практики дракон-конструктора.

Вы совершенно правы: этот вопрос около трех лет находился как бы в тени. Он не находился в центре внимания. Он не подвергался глубокому анализу в рамках данного форума.

Огромное Вам спасибо.


Последний раз редактировалось Владимир Паронджанов Воскресенье, 05 Август, 2012 15:26, всего редактировалось 3 раз(а).

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Философия ДРАКОН-конструктора
СообщениеДобавлено: Воскресенье, 05 Август, 2012 13:05 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1442
Alexey_Donskoy писал(а):
Владимир Паронджанов писал(а):
Цикл — это потенциально опасное место...
Мой вариант гарантирует защиту от подобных ошибок...
Предлагаемое Вами разрешение пользователю втыкать стрелку в разные места по своему усмотрению — это неоправданный риск, который при неблагоприятных условиях может привести к ошибке.
Именно поэтому я против.
Как насчёт веточного цикла? :D
Оно да... ибо, с одной стороны, можно сказать, что сочинитель в силуэте может "втыкать стрелку" (разадресовывая заземлённые лианы против шампура) не по своему усмотрению, а того, кто разделил силуэт на ветки... но с другой-то - Алексей может заметить, что это уже не есть приём доказательного программирования... и будет по-своему прав... кстати, и Эдуард показывал, как произвольной разадресацией можно создавать, скажем, более одного входа в цикл... :)

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

Но. В той же ветке, куда обратился Эдуард, Алексей сформулировал важное ограничение на сей счёт:
Alexey_Donskoy в viewtopic.php?p=39806#p39806 писал(а):
...
Смысл-то ведь проще некуда - в процессе выполнения действия (в том числе редактирования текста) система может находиться в несогласованном состоянии, но по завершении действия обязана иметь корректное и согласованное состояние.

В простейшем случае транзакция редактирования вырождается в атомарное действие редактора (например, вставка блока в схему).

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

Предсказуем вопрос - так какое же эргономичное послабление дать при сохранении жёсткой структуры циклов? Скажу по своему опыту. По-прежнему рисую схемы по офисной технологии - где в общем-то можно всё. Но. Когда надо изменить наполнение цикла - содержательное действие у меня естественное не перенос конца петли - а перемещение шампур-блоков. Потом уже подгоняешь положение линий, конечно - но это тогда уже действие компоновочное. Которое можно и не делать, если редактор сам перечерчивает схему...

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

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

Но и тут надо помнить - не зря и Прохоренко говорил о необходимости "недюжинных компоновочных способностей" при работе со сложными схемами. Эта задача - в общем случае оптимизационная, и всё на редактор мы вряд ли сможем переложить. Здесь тоже надо следовать сказанному Алексеем - стараться автоматизировать те вещи, которые существенно трудны для человека. По моему впечатлению, пока это лучше получается у Степана. Тут ведь очень существенна динамичность минимальных размеров вершин, определяемых размерами текущего их содержания...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Философия ДРАКОН-конструктора
СообщениеДобавлено: Воскресенье, 05 Август, 2012 15:21 

Зарегистрирован: Понедельник, 09 Ноябрь, 2009 17:29
Сообщения: 904
Откуда: Россия, Питер
Владимир Паронджанов писал(а):
Цитата:
...любая правильно построенная шампур-схема является строго доказанной теоремой.

Вот правильная схема, построенная с помощью некоего Дракон-конструктора
Вложение:
q1.png
q1.png [ 7.66 КБ | Просмотров: 9094 ]

Какая именно теорема доказана в данном случае?

Какое влияние на этот окончательный вид схемы имеет её предыстория (выращена она из цикла или построена переключением лианы бывшей развилки)?

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


Владимир Паронджанов писал(а):
Цитата:
§10. ДОКАЗАТЕЛЬСТВО ПРАВИЛЬНОСТИ АЛГОРИТМОВ

Роберт Андерсон подчеркивает: «целью многих исследований в области доказательства правильности программ является... механизация таких доказательств» [8]. Дэвид Грис указывает, что «доказательство должно опережать построение программы» [9].

Дракон-конструктор осуществляет 100%-е автоматическое доказательство правильности шампур-схем, гарантируя принципиальную невозможность ошибок визуального синтаксиса.


На форуме часто упоминается «доказательство алгоритмов», но нет конкретных примеров как это делать и что конкретно доказывается в каждом случае. Было бы очень интересно разобрать пример такого доказательства.

Так же, было бы интересно при упоминании возможных ошибок визуального синтаксиса, визуально видеть эти ошибки, чтобы знать от чего гарантирует Дракон-конструктор и, вообще, хорошо бы прояснить как соотносятся ошибки визуального синтаксиса с ошибками алгоритма как такового.

Владимир Паронджанов писал(а):
Предлагаемое Вами разрешение пользователю втыкать стрелку в разные места по своему усмотрению — это неоправданный риск, который при неблагоприятных условиях может привести к ошибке.


Вроде бы я нигде не предлагал втыкать стрелку куда попало : )
Как раз наоборот, меня интересует определение точек в которые можно втыкать стрелку. Собственно, как определять такие точки уже понятно, в т.ч. благодаря обсуждениям на форуме.

Ну и не понятно почему Вы против втыкания стрелки куда попало в обычном цикле, и наоборот, рекомендуете её втыкать куда попало в веточном цикле (посредством икон Адрес и Имя ветки).
Получается, что в одном случае доказательство алгоритма (чтобы это не означало) стоит во главе угла, а в другом — безразлично. Диссонанс однако ...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Философия ДРАКОН-конструктора
СообщениеДобавлено: Воскресенье, 05 Август, 2012 15:57 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 3622
Откуда: Москва
Ильченко Эдуард писал(а):
Владимир Паронджанов писал(а):
Цитата:
...любая правильно построенная шампур-схема является строго доказанной теоремой.

Вот правильная схема, построенная с помощью некоего Дракон-конструктора
Вложение:
q1.png

Какая именно теорема доказана в данном случае?


Эдуард, теорема у Вас перед глазами. Но, судя по всему, Вы ее просто не видите.

Какую теорему Вы хотели увидеть? Вы хотели увидеть сочетание букв, превращенное в связный текст? Например, квадрат гипотенузы равен сумме квадратов катетов"?

Такой (текстовой) теоремы Вы здесь не увидите.

Потому что нарисованная Вами дракон-схема (из которой полностью убран текст) — это и есть искомая теорема.

Причем теорема строго доказанная.

Эдуард, в данном случае имеет место один из трех вариантов:

— либо Вы невнимательно прочитали главу 34. Исчисление икон.

— либо Вы подзабыли основы математической логики;

— либо Вы испытываете трудности при переводе понятий и теорем традиционной (текстовой) математической логики на визуальный (графический) язык.

На всякий случай напомню Вам азы (основные положения):

Цитата:
§4. ОБЩЕИЗВЕСТНЫЕ СВЕДЕНИЯ О МАТЕМАТИЧЕСКОЙ ЛОГИКЕ

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

• явной формулировкой исходных положений (аксиом) развиваемой теории (формальной системы);

• явной формулировкой правил логического вывода, с помощью которых из аксиом выводятся теоремы теории;

• использованием формальных языков для изложения теорем рассматриваемой теории [1].

Основным объектом изучения в математической логике являются логические исчисления. В понятие исчисления входят:

а) формальный язык, который задается с помощью алфавита и синтаксиса,

б) аксиомы,

в) правила вывода [1].

– Какие же это аксиомы? – вправе удивиться читатель.

– Ведь это просто картинки-слепыши! А шампур-схемы вовсе не похожи на теоремы! Кто и зачем их должен доказывать? Наверно, это шутка или метафора.

– Вовсе нет, отнюдь не метафора. Ниже будет показано, что визуальный синтаксис ДРАКОНа построен как логическое исчисление (назовем его «исчисление икон»). Данное исчисление можно рассматривать как раздел визуальной математической логики.

Таким образом, исчисление позволяет, зная аксиомы и правила вывода, получить (то есть вывести, доказать) все теоремы теории. Причем теоремы, как и аксиомы, записываются на формальном языке.

Напомним, что в рамках математической логики следующие термины можно рассматривать как синонимы:

• логическое исчисление,
• формальная система
• теория.

Следовательно, теоремы исчисления, теоремы формальной системы и теоремы теории – одно и то же.


В исчислении икон две аксиомы:

— заготовка-примитив;
— заготовка-силуэт.

Цитата:
• Множество А визуальных аксиом включает всего два элемента: за-
готовку-примитив и заготовку-силуэт (рис. 232). Далее будем на-
зывать их аксиома-примитив и аксиома-силуэт.


Из этих двух аксиом с помощью правил вывода выводятся (доказываются) все теоремы исчисления икон. Этими теоремами являются правильно построенные дракон-схемы.


Цитата:
• Множество Т, охватывающее все видеотеоремы исчисления V, есть
не что иное как множество шампур-схем (абстрактных дракон-
схем). Заметим, что множество Т не включает аксиомы, так как пос-
ледние содержат незаполненные критические точки и, следователь-
но, эквивалентны пустым операторам.

Множество Т распадается на две части:

множество примитивов Т1

и множество силуэтов Т2.


Доказывать эти теоремы не нужно, потому что все теоремы получены с помощью ПРАВИЛ ВЫВОДА исчисления икон.


А что такое ПРАВИЛА ВЫВОДА исчисления икон?

Цитата:
• Множество F правил видеовывода также делится на две части F1
и F2.

Множество F1 позволяет выводить все теоремы-примитивы,
принадлежащие множеству Т1, из единственной аксиомы-прими-
тива.

Оно содержит пять правил вывода:

ввод атома,

добавление варианта,

пересадка лианы,

боковое присоединение,

удаление конца примитива.

Эти правила описаны в тезисах 10, 21, 28, 30, 31, 34 главы 33.

• Множество F2 дает возможность выводить все теоремы-силуэты множества Т2 из единственной аксиомы-силуэта.

Оно содержит восемь правил вывода:

ввод атома,

добавление варианта,

добавление ветки,

пересадка лианы,

заземление лианы,

боковое присоединение,

удаление последней ветки,

дополнительный вход.

Правила вывода для силуэта описаны в тезисах 10, 21, 28–33, 35 главы 33.

Все цитаты данного сообщения взяты из "главы 34. Исчисление икон"
http://drakon.su/_media/biblioteka/chas ... drakon.pdf
стр. 427—435


Последний раз редактировалось Владимир Паронджанов Воскресенье, 05 Август, 2012 18:43, всего редактировалось 7 раз(а).

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Философия ДРАКОН-конструктора
СообщениеДобавлено: Воскресенье, 05 Август, 2012 16:07 
Аватара пользователя

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Философия ДРАКОН-конструктора
СообщениеДобавлено: Воскресенье, 05 Август, 2012 16:11 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1442
Короче, те теоремы, к доказательству которых мы привыкли в школе, есть частные случаи общего формально-логического понятия "теорема"... именно это хотел сказать Владимир Даниелович... А графы, выведенные путём исчисления - другой частный случай... :)
Ильченко Эдуард писал(а):
...
Как раз наоборот, меня интересует определение точек в которые можно втыкать стрелку. Собственно, как определять такие точки уже понятно, в т.ч. благодаря обсуждениям на форуме.

Ну и не понятно почему Вы против втыкания стрелки куда попало в обычном цикле, и наоборот, рекомендуете её втыкать куда попало в веточном цикле (посредством икон Адрес и Имя ветки).
Получается, что в одном случае доказательство алгоритма (чтобы это не означало) стоит во главе угла, а в другом — безразлично. Диссонанс однако ...
Не совсем так - просто в ШМ-исходнике есть на этот счёт запрет на второй вход в цикл в тексте тезисов. И предполагалось, что он достаточен для исполнителя... даже когда он создаёт такой вход вводом текста в вершины "Адрес ветки" (ну или как теперь - просто "Адрес"). Т.е. выходя за предмет исходника - где текста нет...
Для исполнителя-человека это и вправду можно считать достаточным... правда, тривиальный путь выполнить - это "примитивизировать" каждую сомнительную схему, как это сделали Вы. А для исполнителя-"автомата" (про который мы всё знаем, как он работает - по Тьюрингу, Черчу, Маркову) - уже недостаточно. Ему надо задать алгоритмически разрешимые способы проверки схемы на основе численно-геометрических характеристик. Пример такого способа и был приведён здесь: viewtopic.php?p=70770#p70770.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Философия ДРАКОН-конструктора
СообщениеДобавлено: Воскресенье, 05 Август, 2012 16:19 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1442
В развитие поста А. Донского чё я хочу сказать? Чтобы ответить на Ваш вопрос, Эдуард, доказывать для неразмеченного графа недостаточно. Но сие не значит, что принципы "исчисления слепышей" окажутся ошибочны. Пока по всем вопросам выявляется в основном, что их надо дополнить... кое-где введя иные классификации объектов исчисления, но это тоже пока оказывается возможным... (вроде выделения гребёнок, с участием которых уже полно и непротиворечиво строятся кроссы и составных атомов, и "непримитивных" схем)...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Философия ДРАКОН-конструктора
СообщениеДобавлено: Воскресенье, 05 Август, 2012 16:32 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1442
Владислав Жаринов писал(а):
...
Но. В той же ветке, куда обратился Эдуард, Алексей сформулировал важное ограничение на сей счёт:
Alexey_Donskoy в viewtopic.php?p=39806#p39806 писал(а):
...
Смысл-то ведь проще некуда - в процессе выполнения действия (в том числе редактирования текста) система может находиться в несогласованном состоянии, но по завершении действия обязана иметь корректное и согласованное состояние.

В простейшем случае транзакция редактирования вырождается в атомарное действие редактора (например, вставка блока в схему).

Сводить всё к последовательности (неизбежно жёсткой) атомарных действий - неэргономично.
Давать максимальную свободу (без внутренней самодисциплины юзера) - в конечном счёте тоже неэргономично.

...
Кстати, о транзакциях. Тут Усов напомнил (уже не нам, увы :wink:) о различных подходах к согласованию состояний:
...
Блокировочная СУБД меняет данные по месту их хранения, затирая старые данные новыми значениями. Но в момент изменения данных никто не знает того, как завершится транзакция (да, и завершится ли она вообще). Поэтому, на случай отката (rollback) или сбоя, старые данные из записи переносятся в журнал транзакций. К новым данным другие (читающие и пишущие) транзакции доступа не имеют (поскольку эти данные ещё могут "откатить"). Доступ к новым/обновлённым данным открывают только после фиксации (commit) транзакции. Это создаёт большое количество проблем...
Версионная СУБД для меняемых данных создаёт новую версию (в случае добавления записи новая запись первоначально пуста; при изменении старой записи, она копируется в новую область), и в этой новой области происходит редактирование записи. Старая запись не меняется никогда! Поэтому переносить её в журнал для возможного отката нет никакой необходимости, а значит и нет никакого журнала транзакций (для целей отката). Каждая запись имеет маркер той транзакции, которая её создала/изменила. Если меняющая транзакция завершается фиксацией, то актуальна новая запись, если завершается откатом, то актуальной остаётся старая запись. Старая запись не удаляется даже после того, как изменившая её транзакция была зафиксирована, поскольку могут быть транзакции, которые в ней заинтересованы (это те транзакции, которые стартовали раньше, чем меняющая транзакция и имеющие высокие уровни изолированности repeatable read и выше (хотя у версионных СУБД иные уровни изолированности, отличные от блокировочных)). Удаление старых записей возможно только тогда, когда не существует заинтересованных в них транзакций. Такая (версионная) форма изоляции транзакций позволяет пишущей/меняющей транзакции не блокировать данные от читающих транзакций. В существующих версионных СУБД, куда теперь относится и MS SQL пишущие/меняющие одну и ту же запись транзакции блокируются. Но возможен вариант полноверсионной СУБД, когда даже пишущие одну и ту же запись транзакции не блокируют друг друга. Это открывает интересные возможности, прежде всего... в системах принятия решений... Но это уже совсем другая тема.
...
Из того, что я только что написал, д.б. понятно, что философия конструктора существенно зависит от того, на каком уровне моделирования/формализации находится принятый нами исполнитель философствований... :) Так что надо при определении машинно реализуемого исчисления подумать и о выборе одной из этих моделей... или проработать обе...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Философия ДРАКОН-конструктора
СообщениеДобавлено: Воскресенье, 05 Август, 2012 17:01 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 3622
Откуда: Москва
Ильченко Эдуард писал(а):
Какое влияние на этот окончательный вид схемы имеет её предыстория (выращена она из цикла или построена переключением лианы бывшей развилки)?


Разница огромная.

Если схема "выращена из цикла", то есть выведена из аксиомы (из заготовки-примитив) с помощью правил логического вывода, то это значит, что схема строго доказана математически (так как она получена с помощью правил вывода математической логики).

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

ИТАК, В ЧЕМ ЖЕ РАЗНИЦА?

В первом случае используется доказательное программирование. Имеем гарантированно правильный результат.

Во втором случае про доказательное программирование надо забыть. Про гарантии правильности тоже.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Философия ДРАКОН-конструктора
СообщениеДобавлено: Воскресенье, 05 Август, 2012 17:50 
Аватара пользователя

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Философия ДРАКОН-конструктора
СообщениеДобавлено: Воскресенье, 05 Август, 2012 17:54 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1442
Имеется в виду, нешампур-блок нельзя?.. ведь у шампур-блока по-любому вход и выход наружу торчат... :)
Владимир Паронджанов писал(а):
...
Если же схема построена переключением лианы, то мы отбрасываем математическую логику в сторону. При этом пользователь остается один на один с проблемой и принимает бремя доказательства на себя. Может быть, пользователь разработает собственное доказательство.
...
Вообще-то надо бы уточнить: "произвольным переключением"... хотя упоминание "собственного доказательства" как-то на это намекает...
Об том и речь, что должна... а для этого доказательства тоже нужно провести заранее и использовать в формулировке исчисления, реализуемого в среде...


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

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


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

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


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

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