DRAKON.SU

"Нет! Нет! Не дам!"(с)Билли Бонс.

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

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

Уважаемый Рэйлвэй Каген!

Предлагаю Вашеу вниманию доработанную 11 главу (бывшая 10), которую я готовлю для нового издания книги.
Быть может, материал этой главы позволит сблизить наши позиции.
Glava11LogicText..doc

Процедура пишется для достижения цели, поэтому, когда цель достигнута, то и процедура должна бы кончится. : )

Уважаемый Владимир Даниелович!
Я всеми руками-ногами "ЗА" преобразование, показанное на рис 113. В дебрях логики почти всегда приходится искать физический смысл производимых действий. А правая часть рис.113 - это то, что надо!

Что касается глубоких декомпозиций логических выражений в Драконе, то я бы их показывал для иллюстрации "как делать не надо". Да, текст из правой части рисунка непосредственно не транслируется в код, нужны некоторые дополнения. Стоит ли их делать в Драконе? Повторюсь, в Драконе нет и быть не может быть графических правил для проверки, минимизации логических выражений. Это должно быть решение с подключаемым модулем.

Можно ли как-нибудь графически привести левый алгоритм к правому? Минимизировать логическую функцию? Вопрос не праздный, поскольку мало кто из программистов сильно задумывается над длинными if'ами.Если да, то я признаю поражение и необходимость иметь НЕфиксированные выходы развилки.
Если нет, то лучше не вводить подобные техники отображения. Сделать с ними уже ничего нельзя будет. Найти физический смысл - не легче, чем по логическому выражению.

Уважаемый Рэйлвэй Каген!

Я отвечаю: да, можно. Как именно?
Мой ответ показан на рис. 119, 120, 121.
На рис. 119 введена процедура "Формирование.признака".
Как ее сформировать?
Я предпагаю два разных ответа (рис.120 и рис. 121).

Ответ 1. На рис. 120 формирование упомянутого признака делается с помощью "рамочного логического выражения".

Ответ 2. На рис. 121 формирование упомянутого признака делается с помощью "визуального логического выражения".

Какой ответ выбрать? Такой, какой больше нравится разработчику.

Какой ответ он выберет -- не так уж важно. Важно, что будет достигнута цель, которую Вы поставили в виде вопроса:



Повторяю: да, можно. причем двумя способами.
Способ 1 показан на рис. 120.
Способ 2 показан на рис. 121.

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

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

Вопрос конечно интересный, но утверждение эквивалентные логические функции ошибочное.
При a=1, b=1, c=0, d=0 : a'd'+c'd+bd'=1, a'+b'c'=0.
Надо другой пример.

Уважаемый Рэйлвэй Каген!

Сожалею, что я неправильно Вас понял. Я действительно перепутал две разные вещи:
1) левую и правую части моего рисунка 113;
2)левую и правую части Вашего рисунка.
Приношу свои извинения.

Подтверждаю еще раз, что я уже писал Вам:

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

Подтверждаю: я не знаю, как графически преобразовать левую часть Вашего рисунка в правую.

Вместе с тем для меня осталось неясным: как Вы оцениваете мои рассуждения о моих рисунках 119, 120 и 121. Вы считаете, что в них предлагается неудовлетворительное решение? Почему?

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

Да, каюсь, сам не проверил, отрисовал только. Ляпнул из гугла.. Придётся отработать.
Пример со светофором из 11 главы, как оказалось, минимизируется. Но без исключения переменных. Не очень наглядно получается.

Обозначения:
a - зелёный.сигнал.светофора,
b - желтый.сигнал.светофора,
c - красный.сигнал.светофора,
d - помехи.для.движения,
e - робот.выехал.на.перекрёсток;

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

Да, это именно таблица решений...

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

Много хотите. Графическая форма не для этого предназначена
Вообще-то всё это поддаётся автоматизации (оптимизации); человек, смотрящий на графику тут ни при чём...

Уважаемый Владимир Даниелович!
Я поддерживаю вынос перегруженных деталями частей алгоритма в отдельную процедуру, на отдельный лист, в отдельный примитив, на другой слой. Это существенно облегчит восприятие основного алгоритма. Укрупненные формулировки, как на рис.113 справа, я тоже приветствую. Но рис.121 - ни в какие ворота.
Как по нему сделать полную проверку логики? Бродить по маршрутам с карандашиком, попутно отписывая на клочке бумаги, что открыжили, а что - нет? Сомнительное развлечение.
Я бы предпочёл на месте кучи развилок таблицу истинности. По принципу рамочного выражения, только в рамке - таблица. У рамки пара выходов - прямой и инверсный. Кто-то другой предпочтёт задание в терминах матлогики. Смысл в том, что с такими представлениями уже можно работать дальше - можно преобразовывать из одного представления в другое(к сожалению не на базе дракон-правил), можно оптимизировать. И всё это быстрее, легче и нагляднее, чем в поразвилочной разблюдовке.
Правда последняя всегда будет понятна людям, умеющим только читать и водить пальцем. Им, надеюсь, понадобится только выходной результат - максимально понятная дракон-схема. Вовлекать такой контингент в процесс разработки, предоставлять им какие-то дополнительные инструменты проектирования скорее всего не придётся. Лучше позаботиться об эргономичном совмещении наработанных технологий представления для квалифицированных специалистов.

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

И это совершенно справедливо!

Ответ. Ничего особенного. Раньше было 3 введения, что выглядит коряво. См. здесь
http://drakon.pbwiki.com/
Что я сделал? Объединил 1 и 2 введение в одно. А третье введение превратил в главу 1. Поэтому нумерация глав сдвинулась.

Ответ. Вы пишете: "Для эргономики такой объект не является предметом рассмотрения".
Это не совсем так. См. Как улучшить работу ума рис. 19, 20, 25, и в особенности 26 и 27 и т. д.
Кроме того, глава 19 посвящена вопросу: "Возможна ли эргномизация мтематики?" Так что математические объекты вполне могут быть предметом эргономического рассмотрения.

Ответ 2. Это самое обычные комментарии, которые повсюду используются и в пограммировании и в алгоритмах.

Ответ 3. Пишите, как считаете правильным. Что касатся меня, то я, увы, уже не могу отступать от введенной мной терминологии, так как подобный разнобой вызовет недоумение у читателей.
Кстати, в сети часто используют термин "дружелюбный интерфейс". Чтобы убедиться в этом, сделайте в Гугле запрос "дружелюбный интерфейс". Вы получите множество ответов.

Ответ 4. Постараюсь учесть ваше замечание. Если у Вас есть подсказка, как это сделать, подскажите мне.

Уважаемый Алексей Донской!

Ваша фраза (которую я выделил красным) содержит неточность.

1. Порядок рисования БЛОК-СХЕМ (в части да и нет) не регламентирован никаким руководящим документом. Во всяком случае мне такие документы неизвестны.

Приведу пример (о блок-схемах) из книги
"М.Д. Князева. Алгоритмика. От алгоритма к программе. М.: КУДИЦ-ОБРАЗ, 2006".

На стр. 162 выход из цикла с постусловием идет через "нет".
А на стр. 124 выход из цикла с постусловием идет через "да".
На стр. 26 выход из цикла с предусловием идет через "нет".

А как обстоит дело в настоящих программах на паскале?
Именно так, как я писал в предыдущем сообщении:

в языке Паскаль в цикле while-do выход из цикла соответствует значению false, а в цикле repeat-until применяется диаметрально противоположный принцип: выход из цикла производится, когда логическое выражение принимает значение true.

Если есть сомнения, вот точная цитата:

"Работает цикл с постусловием следующим образом: "тело цикла повторяется до тех пор, пока логическое выражение не станет истинным". Обратите внимание, что, в отличие от while, цикл repeat в Паскале работает, пока условие ложно".

http://www.ref.uz/download.php?id=15618
см. стр.25

Таким образом, Ваш вывод: "Что, в общем-то, ещё раз иллюстрирует моё предложение!" является неубедительным.

С глубоким уважением к Вашей позиции
несогласный с Вами Владимир Паронджанов

Да Вы, сударь, опять шутить изволите! Циклы в Паскале выглядят именно так, как Вы и процитировали. Обратите внимание на выходы развилок, при помощи которых делаются эти циклы: