![>](style_images/1/nav_m.gif)
![]() |
Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
|
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[3.145.183.243] |
![]() |
|
Страницы: (10) 1 [2] 3 4 ... 9 10 все ( Перейти к последнему сообщению ) |
Сообщ.
#16
,
|
|
|
Цитата Pavia @ Мы разбиваем задачу до тех пор пока задачи не станут настолько простыми что исключат саму возможность ошибки. Но их количество при этом становится столь велико, что вероятность ошибки растет. Недаром же есть закон Бритвы Оккама: "не плоди лишние сущности" Добавлено Цитата Pavia @ Так почему способ декомпозиции не поручить машине? Человек пользуется около 10 правил. Всех их можно записать и поручить поиск оптиума машине. Функция минимизации известна. Чем меньше не классифицированных IF тем лучше декомпозиция. При равном числе стоит руководствоваться, известностью способом разделения. Под известностью понимается частота встречи у других программистов. О чем и речь: Цитата Исмаил Прокопенко @ Вот не хочу я сразу до конца продумывать все ветвления и всю структуру программы. Я хочу, чтобы "легким движением руки" можно было перекраивать структуру программы причем на любых уровнях абстракции и обобщения и при этом чтобы основная идея не рушилась благодаря тому, что дружественная среда следит за этим Цитата Исмаил Прокопенко @ "Разрезать" говорите? И "распихать"? Так ведь это тоже не тривиальная задача. Почему бы её компилятору не поручить? А если Вы сами "режете" то компилятор должен отслеживать целостность программы и её логики при всех Ваших экспериментах. **************************** Кстати. Раз уж Вы заговориле о нем. Я слышал что в UML и MatCad-е система умеет сама генерить СИ-шный код по нарисованной блок-схеме. Это так? Добавлено Pavia Ведь в чем опасность классической "правильной и строгой" разработки: пока ты возишься с деталями и придумываешь как обозвать ту или иную переменную или пытаешься записать условие ветвления ты можешь потерять "нить рассуждений" более высокого плана (уровня абстракции) погрязнув в деталях. |
Сообщ.
#17
,
|
|
|
Цитата Исмаил Прокопенко @ Но их количество при этом становится столь велико, что вероятность ошибки растет. Недаром же есть закон Бритвы Оккама: "не плоди лишние сущности" Я давно играю в ГО. И давно понимаю что это одно правило. Разделяй и властвуй. Вместе мы сила. Помните сказочку про прутик и веточку. Попробуй сломать веточку и прутик. Так вот общие правило звучит так. Слабые места надо объединять. Трудные разрезать. Да бритва Оккамы говорит не плоди лишних сущностей. Но это относится к ТЗ. А когда надо написать программы вы пишете уже по готовому ТЗ. А теория моделирования нас учит, что все правила исходят из задания. Т.е из ТЗ. Они уже есть и все сущности там есть. Цитата Исмаил Прокопенко @ Я слышал что в UML и MatCad-е система умеет сама генерить СИ-шный код по нарисованной блок-схеме. Это так? Мы в вузе это делали. Только не MathCad, а MathLab. Код из UML представления приводился в MathCAD. А затем собирали бинарник. Есть инструменты для перевода UML в СИ. Но на самом деле стоит понимать что UML это рекомендации, а не строгие правила. Он создан с целью стандартиризации общения между людьми. Что-бы один человек мог написать а другой прочитать и правильно понять. А то иначе, будет как в Школе Клоунов. Так что в код можно перевести только определённые UML реализации. И то не все разновидности схем. |
Сообщ.
#18
,
|
|
|
чем не естественный язык?
![]() Добавлено Цитата Исмаил Прокопенко @ Т.е. сначала на некоем метаязыке описать "правила игры" и суть идеи. А уж потом "играться" с собственно языком программирования https://ru.wikipedia.org/wiki/%D0%94%D0%A0%...%9A%D0%9E%D0%9D Добавлено писал я недавно статью об этом чуде. так вот там все далеко не так однозначно как бы хотелось. одно действие может изображаться разными блоками. плюс к тому все это дело слабо формализовано т.к. эта схема предназначена описывать бизнес процессы в относительно укрупненном виде. и да, только для понимания человеком. |
Сообщ.
#19
,
|
|
|
Исмаил Прокопенко
Цитата Исмаил Прокопенко @ Ведь в чем опасность классической "правильной и строгой" разработки: пока ты возишься с деталями и придумываешь как обозвать ту или иную переменную или пытаешься записать условие ветвления ты можешь потерять "нить рассуждений" более высокого плана (уровня абстракции) погрязнув в деталях. Верно. ГО учит мыслить и побеждать. В игре все имеют равные шансы выиграть. Но почему-то более сильный игрок всегда побеждает более слабого. Нужно делать наиболее срочный ход. Разумеется вы будете забывать и ошибаться. Все программы поставляются AS IS(как есть). Но у вас есть возможность после исправиться и устранить ошибку. Существует очень трудная задача говорят что ей придумал Альберт Эйнштейна и предлагал всем желающим решить её в уме без использования бумаги. Цитата Задача А. Эйнштейна: С другой стороны улицы подряд стоят пять домов, каждый — своего цвета. В каждом живёт человек, все пять — разных национальностей. Каждый человек предпочитает уникальную марку сигарет, напиток и домашнее животное. Кроме того: 1. Норвежец живёт в первом доме. 2. Англичанин живёт в красном доме. 3. Зелёный дом находится слева от белого. 4. Датчанин пьет чай. 5. Тот, кто курит Marlboro, живёт рядом с тем, кто выращивает кошек. 6. Тот, кто живёт в жёлтом доме, курит Dunhill. 7. Немец курит Ротманс. 8. Тот, кто живёт в центре, пьет молоко. 9. Сосед того, кто курит Marlboro, пьет воду. 10. Тот, кто курит Pall Mall, выращивает птиц. 11. Швед выращивает собак. 12. Норвежец живёт рядом с синим домом. 13. Тот, кто выращивает лошадей, живёт в синем доме. 14. Тот, кто курит Winfield, пьет пиво. 15. В зелёном доме пьют кофе. Вопрос: кто разводит рыбок? Только 2% людей могут решить эту задачу правильно. Но стоит нарисовать табличку и задача становится довольно простой. |
Сообщ.
#20
,
|
|
|
Цитата Pavia @ Только 2% людей могут решить эту задачу правильно. Но стоит нарисовать табличку и задача становится довольно простой. Я постоянно об этом твержу. Важность формы представления задачи трудно переоценить. Иногда чтобы решить задачу достаточно выбрать правильную форму её представления и решение станет очевидным. Поэтому то так важно, чтобы разрабатываемую программу можно было представить в компактной, наглядной и удобной для анализа форме. PLAIN-текст такой формой не является ни с какой стороны. Цитата Исмаил Прокопенко @ сложность программирования объясняется <НЕУДАЧНО> выбранной формой представления программы. |
Сообщ.
#21
,
|
|
|
Цитата Исмаил Прокопенко @ Поэтому то так важно, чтобы разрабатываемую программу можно было представить в компактной, наглядной и удобной для анализа форме. PLAIN-текст такой формой не является ни с какой стороны. Тут прочитал анекдот. ![]() ![]() Искусство рождается только в ограничении. Так вот плоский-текст и есть ограничение. Если человек не может написать нормально в текстовом представлении, то он не сможет сделать это при помощи схем. Вот тут можно посмотреть на машину состояний. Большинство программистов делают её неправильно, а именно не структурируют свой код. http://habrahabr.ru/post/241941/ Кстати в статье тоже есть ошибки, автор падает в другую крайность делать всё табличкой. Когда как удобно комбинировать. PS. Ссылку вначале не ту дал. Потом долго искал правильную. Вставил. |
Сообщ.
#22
,
|
|
|
Цитата Исмаил Прокопенко @ не знаю о чем Вы. я яву не знаю но навскидку она не очень то и отличается от любого другого алгоритмического языка. ну кроме неслабых аппетитов аппаратного обеспеченияНо ведь в свое время изобрели же ЯВУ, которые позволяют сжать/упаковать десятки миллионов строк АСМ-кода в единицы миллионов строк на ЯВУ и написание целого ряда ветвлений поручить компилятору. на нечеткую инструкцию компилятор нечетко и отреагирует) Цитата Исмаил Прокопенко @ по моему такие технологии еще не реализованны на платформе обычной персоналки. банально не хватит скорости работы. а про правильность интерпретации я вообще молчу Хотелось бы все таки чтобы компиляторы поддерживали нечеткую логику и образно-ассоциативную модель мышления человека. Ведь человек в жизни мысли образами и нечетко. И не продумывает задачу сразу всю до мелочей. И постоянно перескакивает с одной задачи на другую даже не закончив до конца первую. |
Сообщ.
#23
,
|
|
|
p486
ЯВУ - это сокращение от слов: Язык Высокого Уровня. |
Сообщ.
#24
,
|
|
|
Цитата Хотелось бы все таки чтобы компиляторы поддерживали нечеткую логику и образно-ассоциативную модель мышления человека. Ведь человек в жизни мысли образами и нечетко. И не продумывает задачу сразу всю до мелочей. И постоянно перескакивает с одной задачи на другую даже не закончив до конца первую. Чтобы было не как в IF..THEN..ELSE было только "Да" или "Нет" Чтобы можно было написать "Возможно", "Скорей всего", "Маловероятно", "Наверное так". Нечеткие формулировки годятся в редких случаях, когда же речь заходит о вычислительных задачах, даже простейших, как дважды два - никаких "возможно" или "маловероятно" быть не может. И даже в этих редких случаях человек может выполнять нечеткую "программу" лишь потому, что у него в мозгу уже есть гигантская "программа", с кучей библиотек, с распознаванием образов и коррекцией ошибок. Современные системы по интеллектуальным возможностям стоят не выше насекомых, "программы" которых очень легко ломаются. Например, ночной мотылек может принять лампу за луну и сбиться с курса, муравьи, движущиеся колонной, могут образовать бесконечный цикл смерти, летающие насекомые уже который десяток миллионов лет попадаются в паутину. Можно ли доверить такому ненадежному устройству расшифровку туманных человеческих хотелок? Я лично считаю, что нет. |
Сообщ.
#25
,
|
|
|
Цитата Pavia @ Так вот плоский-текст и есть ограничение. Если человек не может написать нормально в текстовом представлении, то он не сможет сделать это при помощи схем. Ограничением выступает время и сложность задачи. При некотором уровне сложности задачи Вы используя лишь текст, Notepad и компилятор командной строки для написания кода Вы не решите задачу НЕ ЗА КАКОЕ ВРЕМЯ Добавлено Цитата Pavia @ Тут прочитал анекдот. ![]() У меня дежавю? Потому что мне кажется, что именно я это писал Добавлено Цитата AVA12 @ Нечеткие формулировки годятся в редких случаях, когда же речь заходит о вычислительных задачах, даже простейших Нечеткая логика для простейших задач не годится. Только для сверхсложных и объемных от неё будет пруфит Добавлено Цитата AVA12 @ "программы" которых очень легко ломаются. Вот вот. Одно неловкое движение и вся программа рушится как карточный домик. А все потому что нет нормальной среды поддержки программирования, которая бы отслеживала корректность вносимых изменений не только на уровне синтаксиса, но и но более высоких уровнях абстракции |
Сообщ.
#26
,
|
|
|
Цитата А все потому что нет нормальной среды поддержки программирования, которая бы отслеживала корректность вносимых изменений не только на уровне синтаксиса, но и но более высоких уровнях абстракции Еще раз: Цитата Можно ли доверить такому ненадежному устройству расшифровку туманных человеческих хотелок? |
Сообщ.
#27
,
|
|
|
Почитал. Это очень близко к моему мировоззрению: Цитата Проблема сложности Важной проблемой является сложность программирования и поиск путей её преодоления. По мнению кандидата технических наук, доцента Евгения Пышкина, изучение структурного программирования исключительно как инструмента разработки текстов программ, построенных на базе основной «структурной триады» (линейная последовательность, ветвление и цикл), является недостаточным и, по сути дела, сводит на нет анализ преимуществ структурного подхода[29]. В процессе преодоления существенной сложности программного обеспечения важнейшим инструментом является визуализация проектирования и программирования[29]. Визуализация как инструмент преодоления сложности лежит в основе языка ДРАКОН. |
Сообщ.
#28
,
|
|
|
Цитата Исмаил Прокопенко @ Нечеткая логика для простейших задач не годится. почему же не годится? все замечательно работает. но вот достаточно ли точны такие методы, чтобы строить на них компилятор? в этом я очень сомневаюсь Добавлено https://www.youtube.com/watch?v=cOu4BkuvBM0 |
Сообщ.
#29
,
|
|
|
Цитата Исмаил Прокопенко @ Ты тексты сообщений полностью читаешь читаешь, или "увидел знакомое слово - написал ответ"?Вот вот. Одно неловкое движение и вся программа рушится как карточный домик. Там речь о интеллекте насекомых, а не о написании программ. На сегодня исследования в области ИИ недалеко продвинулись от интеллекта насекомых. А главное, обучив ту же нейронную сеть, никогда не знаешь, чему же ты её, собственно, обучил. |
Сообщ.
#30
,
|
|
|
Цитата Исмаил Прокопенко @ А можно ли придумать какую-то форму представления программы, в которой бы не надо этого было делать? Ну или хотя бы чтобы часть "IF..THEN..ELSE" и функций среда разработки генерировала сама. Какие это могут быть формы? Можно. Вы получите язык, близкий к функциональной парадигме. Там нет IF/THEN/ELSE. Там есть pattern matching. |