OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Вторник, 19 Март, 2024 10:08

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




Начать новую тему Ответить на тему  [ Сообщений: 145 ]  На страницу Пред.  1 ... 3, 4, 5, 6, 7, 8  След.
Автор Сообщение
СообщениеДобавлено: Вторник, 16 Февраль, 2010 12:27 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 18:55
Сообщения: 2272
Откуда: Россия, Нижний Новгород
Илья Ермаков писал(а):
Касательно приведённой конструкции - она не нова, где-то была, в каких-то языках...
Эта конструкция есть в языке Ада.

Илья Ермаков писал(а):
вон REPEAT и тот отмер практически
Не отмер.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 16 Февраль, 2010 14:29 

Зарегистрирован: Среда, 30 Сентябрь, 2009 14:45
Сообщения: 147
Илья Ермаков писал(а):
Это чем же там простейший WHILE не угодил?

Извиняюсь, щщас модератор отцепит от ветки и отправит мое сообщение в "Третий раз про выход из середины цикла" :D
Повтор кода. С возможностью ошибиться.
Код:
Read(a);
WHILE ReadOk DO Q(a); Read(a) END

по сравнению с
Код:
LOOP
Read(a);
EXITIF ~ReadOK;
Q(a)
ENDLOOP 

Паттерн: прочитал, проверил, использовал (веня видел вицю - (С) Цезарь :D )


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 16 Февраль, 2010 15:09 

Зарегистрирован: Вторник, 11 Август, 2009 11:44
Сообщения: 516
Откуда: Бердск
Илья Ермаков писал(а):
Человек, не совсем поднаторевший в работе с формальными текстами (или не видящий в этом самом по себе "кайфа", как физики) , будет тянуться к организации своей работы с ними (что поменьше тратить на это времени). Подбирать и применять приёмы структурирования, и т.п
Хм...
Мне думается, что физики испытывают "кайф" от понимания сути вещей. Даже если это не соответствует некому формализму (работа у них такая, создавать новые формализмы по причине несоответствия старым). Арихитектура - вполне может являтся существом задуманного. Вполне...
И еще физики испытывают "кайф", когда заставили математиков адаптировать некие формализмы именно под суть вещей.
Например, ну аллергия у Вас на исключения, потому-что есть выход из структурной единицы "не там где положено" :lol:
Ну так измените свою теорию :!:
Измените, все станет на свои места, и физик испытает "кайф" :D

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 16 Февраль, 2010 15:29 

Зарегистрирован: Вторник, 11 Август, 2009 11:44
Сообщения: 516
Откуда: Бердск
Info21 писал(а):
Galkov писал(а):
Думаете, Ваша "новая группа" поверила Вам за пол-пары ??? :D НЕ ВЕРЮ
Студенты препода в несколько другом режиме слушают -- в режиме "это надо учить", и не так упорно сопротивляются, как уже-профессионалы.

(Тут утверждение статистическое по ансамблю студентов.)
Ну возможно, возможно...
Но, все-таки - сопротивляются :)
Тут, в принципе, и у меня барьер есть.
Читаю про инварианты и постусловия, все правильно, все хорошо. Один вопрос без ответа остается - нафига все это надо.
Примеры же даются элементарные !!! Где все прозрачно и без этих заморочек.
Вполне возможная реакция: "да это математики с ума сходят, им за это зарплату платят..."
Ну вот скажем, есть у нас на форуме примеры, где совершены ошибки. Не специально - а потому-что так устроена жизнь.

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


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

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8500
Откуда: Троицк, Москва
Galkov писал(а):
Тут, в принципе, и у меня барьер есть.
Эти вещи не так часто стреляют, но когда стреляют, сразу становится ясно, зачем их нужно было выучить.


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

Зарегистрирован: Пятница, 24 Апрель, 2009 16:28
Сообщения: 563
Откуда: Москва
Galkov писал(а):
Ну вот скажем, есть у нас на форуме примеры, где совершены ошибки. Не специально - а потому-что так устроена жизнь.

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


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

Зарегистрирован: Пятница, 25 Ноябрь, 2005 18:55
Сообщения: 2272
Откуда: Россия, Нижний Новгород
Galkov писал(а):
Если человек говорит: "Да, все правильно, потому-что так и есть на самом деле" - он физик.
А если начинает сомневаться в каждой строчке (их всего три) - он математик.
А если человек говорит, что теорема Пифагора вовсе не теорема, а одна из аксиом евклидовой геометрии?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 16 Февраль, 2010 20:25 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Виктор О писал(а):
Повтор кода. С возможностью ошибиться.
Код:
Read(a);
WHILE ReadOk DO Q(a); Read(a) END



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

http://oberoncore.ru/wiki/паттерны_циклов
Цитата:
Очевидно, что попыток чтения и должно быть на одну больше, чем оборотов цикла с полезным действием. И «дублирование» как раз по этой причине возникает, и любые попытки его «убрать» не приведут к прояснению ситуации, а только к запутыванию и потере прозрачности.

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


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

Зарегистрирован: Суббота, 19 Ноябрь, 2005 15:59
Сообщения: 803
Откуда: Зеленоград
Info21 писал(а):
Рад видеть снова, Алексей Вячеславович.


Взаимно, Федор Васильевич.

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


А где нарушение структурности?
Недостатки синтаксической привязки RETURN к концу процедуры-функции.
1) Введение вспомогательной переменной. (Ср. рекурсивную функцию поиска/вставки в дерево в PIM и в PIO.)
1a) Это неэффективно (прежде всего для виртовских компиляторов; для оптимизирующих компиляторов это необязательно так).
1b) Это вызывает излишнюю умственную работу при чтении исходного текста функции. Результат функции в конкретной ветке алгоритма уже вычислен, но приходится читать дальше и гадать, не будет ли он "перевычислен" до конца функции.
2) Очевидный "синтаксический оверхед". Проще было бы понять возврат к паскалевскому варианту (вообще без RETURN).


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

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Да, тут есть некая "вилка" между вопросом досрочного выхода и вопросом возврата значения.

В принципе, в практике я склоняюсь к тому, чтобы записать два-три RETURN, если они последние в процедуре (т.е. описание в стиле функции):

IF ... THEN
RETURN
ELSIF ... THEN
RETURN
END

При выделении жирностью RETURN, как это у нас принято, смотрится вполне как подобает кусочному определению функции.


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

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
А вот и тест на сформированность "структурного чтения" нарисовался :)

видите ли Вы принципиальную разницу между записью:

IF ... THEN RETURN A END;
IF ... THEN RETURN B END;
RETURN C

и
IF ... THEN RETURN A
ELSIF ... THEN RETURN B
ELSE RETURN C
END.

Т.е. коробит ли от первой из них? :)


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

Зарегистрирован: Четверг, 17 Ноябрь, 2005 11:51
Сообщения: 2935
Откуда: г. Ярославль
Меня вот не коробит, потому что в первом случае - три разные структуры, выполняющие три разные задачи. Во втором случае, одна структура (IF ... ELSIF ... END) и я понимаю, что перед ней стоит какая-то своя задача :)

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 17 Февраль, 2010 00:31 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Иван Кузьмицкий писал(а):
Меня вот не коробит, потому что в первом случае - три разные структуры, выполняющие три разные задачи.


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


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

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8500
Откуда: Троицк, Москва
AVC писал(а):
А где нарушение структурности?
Ну, можно же забыть RETURN. (Или это не по части структурности?)

AVC писал(а):
Недостатки синтаксической привязки RETURN к концу процедуры-функции.
В синтаксичности привязки уже есть некое благо. Вроде.

AVC писал(а):
1) Введение вспомогательной переменной.
Можно сказать и так, что старый вариант -- пример преждевременной оптимизации.

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

Вот mr.Aleph цикл свой сделал -- наверняка на уровне непосредственно над циклом плохо программа структурирована.
Если бы у него был только жестокий ЦД, так ему автоматом пришлось бы бороться с плохой структурой своей программы, а не с отладкой дурацкого цикла.

Кстати, как насчет привязки LOOP+BREAK + множественный RETURN к IMPORT SYSTEM?
По-моему, если пренебречь усложнением компилятора, было бы самое то.


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

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3261
Откуда: Астрахань
Мне думается, "структурное мышление" - это примерно как грамотность. Грамотный же человек о правилах не думает, он пишет грамотно. Так и со структурным мышлением. Илья прав - этому нужно УЧИТЬ! Как грамотности!
И отсюда: очевидно, должен быть период начале жизни "примата", когда структурное мышление осваивается самым оптимальным образом. Не успел во время этого периода освоить - дальше будут проблемы.


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

Зарегистрирован: Пятница, 25 Ноябрь, 2005 18:55
Сообщения: 2272
Откуда: Россия, Нижний Новгород
AVC писал(а):
1a) Это неэффективно (прежде всего для виртовских компиляторов; для оптимизирующих компиляторов это необязательно так).
Почему неэффективно? Вроде в Виртовских языках функция возвращает значение в регистре (отсюда и ограничение на скалярность типа возвращаемого значения). Если значение лежало в другом регистре, то "неэффективность" проявится лишь в копировании значения из одного регистра в другой. Это максимум 1 такт, а при конвеерной работе процессора за этот же такт будут выполнены ещё какие-то другие инструкции. Если значение лежало в памяти, то "неэффективность" поглощается загрузкой значения из памяти в нужный регистр.

AVC писал(а):
1b) Это вызывает излишнюю умственную работу при чтении исходного текста функции. Результат функции в конкретной ветке алгоритма уже вычислен, но приходится читать дальше и гадать, не будет ли он "перевычислен" до конца функции.
Наоборот, излишняя умственная работа требуется если в недрах процедуры внезапно замечен RETURN. После испытанного из-за этого ужаса, весь код процедуры приходится пересматривать заново, уже с другой точки зрения.

Илья Ермаков писал(а):
В принципе, в практике я склоняюсь к тому, чтобы записать два-три RETURN, если они последние в процедуре (т.е. описание в стиле функции)
Теперь осталось только сократить эти два-три RETURN до одного :D


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

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8500
Откуда: Троицк, Москва
Сергей Губанов писал(а):
Почему неэффективно? ...
Теперь осталось только сократить эти два-три RETURN до одного :D
Еще бы статистику учесть: сколько функций имеют один RETURN, так сказать, естественным образом. По-моему, много.


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

Зарегистрирован: Среда, 30 Сентябрь, 2009 14:45
Сообщения: 147
Илья Ермаков писал(а):
Давно же разжёвано. Действие перед циклом - добавочное. Оно выполняется на один раз больше, чем оборачивается цикл.

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 18 Февраль, 2010 00:23 
Аватара пользователя

Зарегистрирован: Суббота, 19 Ноябрь, 2005 15:59
Сообщения: 803
Откуда: Зеленоград
Сергей Губанов писал(а):
Почему неэффективно? Вроде в Виртовских языках функция возвращает значение в регистре (отсюда и ограничение на скалярность типа возвращаемого значения). Если значение лежало в другом регистре, то "неэффективность" проявится лишь в копировании значения из одного регистра в другой. Это максимум 1 такт, а при конвеерной работе процессора за этот же такт будут выполнены ещё какие-то другие инструкции. Если значение лежало в памяти, то "неэффективность" поглощается загрузкой значения из памяти в нужный регистр.

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

Сергей Губанов писал(а):
Наоборот, излишняя умственная работа требуется если в недрах процедуры внезапно замечен RETURN.

IMHO, трудно представить, что RETURN будет замечен внезапно, если вспомнить принятое в BB соглашение об оформлении исходного кода.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 18 Февраль, 2010 01:22 
Аватара пользователя

Зарегистрирован: Суббота, 19 Ноябрь, 2005 15:59
Сообщения: 803
Откуда: Зеленоград
Info21 писал(а):
Ну, можно же забыть RETURN. (Или это не по части структурности?)

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

Info21 писал(а):
В синтаксичности привязки уже есть некое благо. Вроде.

Не чувствуется уверенности. :)

Info21 писал(а):
Можно сказать и так, что старый вариант -- пример преждевременной оптимизации.

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

Вот mr.Aleph цикл свой сделал -- наверняка на уровне непосредственно над циклом плохо программа структурирована.
Если бы у него был только жестокий ЦД, так ему автоматом пришлось бы бороться с плохой структурой своей программы, а не с отладкой дурацкого цикла.

Кстати, как насчет привязки LOOP+BREAK + множественный RETURN к IMPORT SYSTEM?
По-моему, если пренебречь усложнением компилятора, было бы самое то.

В основном, согласен. (Кроме привязки EXIT и множественного RETURN именно к IMPORT SYSTEM. Все-таки назначение SYSTEM другое. Можно какую-нибудь другую "опцию" использовать.)


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

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


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

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


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

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