Kirill, ты ещё здесь сидишь?
Пятница Сентябрь 24 2004 00:19, Kirill Frolov wrote to George Shepelev:
SM>>> единственная нога контроллера с большой частотой переключается SM>>> между этими тремя меандрами. GS>> Ох и грязный метод... В результирующем сигнале появятся куча GS>> паразитных частот... KF> А в ШИМ их не появится, да?
Hет, конечно. Каждый импульс ШИМ будет отрабатывать арифметическую сумму генерируемых сигналов на данный момент...
Георгий
Kirill, ты ещё здесь сидишь?
Пятница Сентябрь 24 2004 00:24, Kirill Frolov wrote to Sergey Mudry:
KF> Трёхканальный меандр + три канала шума + огибающая громкости + KF> ХОРОШИЙ МУЗЫКАHТ несравнимо ни с каким FM-синтезом. Если оценивать KF> именно музыку, а не плавность изгибов синуса и наличие паразитных KF> гармоник. Один (два, три канала) синус действительно не звучит.
Терменвокс - почти чистый синус. Под руками хорошего музыканта звучит потрясающе...
Георгий
Hello, George! You wrote to Sergey Mudry on Fri, 24 Sep 2004 22:25:53 +0400:
SM>> А по мне - лучше красиво этот алгоритм переписать на C, GS> Сначала его надо _понять_. О чем и речь. Иначе красиво не напишешь.
GS> А для этого крайне удобно вписывать осмысленный комментарий. Не факт, что комментарий поможет.
GS> Во всяком случае при постинге исходника в эху хорошим тоном будет GS> использовать достаточно подробный комментарий. Hезависимо от языка GS> программирования... Может быть. Не спорю. Мне формальное описание алгоритма говорит больше, чем комментарии.
SM>> Все равно на слух приятнее, чем один голый меандр. GS> Аудиофилы с тобой не согласятся. "Голый меандр" не содержит "левых" GS> компонент, может звучать слишком резко, но не грязно. Ну я же для себя делаю, а не для аудиофилов :)
SM>> Синус слишком бедно звучит. GS> Обычно этот синус формируется из таблички. Какую форму хочешь, GS> такую и зашивай. АгаБлинЩас! Мне жалко памяти на табличку. Если быстродействия хватает, синус я сгенерирую как-нибудь попроще.
GS> А зачем использовать паршивый динамик? ;) Найди мне хороший динамик в габаритах спичечного коробка. С ценой, сравнимой с ценой микроконтроллера.
GS> Hе наступай на больной мозоль ;) То, что издают нынешние мобильники, GS> очень раздражает. И не только меня... Аааа... ну да :)
GS> Перебор. Для приемлимо звучащего звука вполне хватает 4-8 килобайт Это с каким алгоритмом? Сэмплы все равно не влезут.
With best regards, Serg.
Sergey, ты ещё здесь сидишь?
Понедельник Сентябрь 27 2004 10:59, Sergey Mudry wrote to George Shepelev:
SM>>> А по мне - лучше красиво этот алгоритм переписать на C, GS>> Сначала его надо _понять_. SM> О чем и речь. Иначе красиво не напишешь.
Очень хорошо, движемся дальше. Алгоритмы рекомендуется _понимать_ на естественном языке. Hу, так получилось, что человек мыслит на нём, а не на C ;)
GS>> А для этого крайне удобно вписывать осмысленный комментарий. SM> Hе факт, что комментарий поможет.
Очень помогает. Ошибка сразу проявляется тем, что комментарий расходится либо с желаемым действием, либо с исходным кодом.
GS>> Во всяком случае при постинге исходника в эху хорошим тоном GS>> будет использовать достаточно подробный комментарий. Hезависимо GS>> от языка программирования... SM> Может быть. Hе спорю. Мне формальное описание алгоритма говорит SM> больше, чем комментарии.
О чём говорит? О том, _как_ делать. А сперва рекомендуется понять _что_ делать. Hе раз сталкивался с ситуацией, когда массу усилий тратили впустую. Потому что всё можно было сделать гораздо проще, но для этого надо было понять, какой нужен конечный результат, а не как именно выполнить определённые действия...
"Сначала выливаем из чайника воду, после этого задача свелась к уже решённой" (c) анекдот
SM>>> Синус слишком бедно звучит. GS>> Обычно этот синус формируется из таблички. Какую форму хочешь, GS>> такую и зашивай. SM> АгаБлинЩас! Мне жалко памяти на табличку.
256, а то и 128 байт жалко? Можно и меньше табличку сделать, но это может заметно повлиять на быстродействие или качество сигнала.SM> Если быстродействия хватает, синус я сгенерирую как-нибудь попроще.
Во-первых, сомнительно, что в слабеньком контроллере быстродействия хватит, во-вторых, не факт, что существенно память сэкономишь...
GS>> А зачем использовать паршивый динамик? ;) SM> Hайди мне хороший динамик в габаритах спичечного коробка. SM> С ценой, сравнимой с ценой микроконтроллера.
Умеешь ты задачки задавать... Впрочем, выковырянные из некоторых "китайских телефонов" динамички звучат куда лучше совковых бумажных поделок, а цена их наверняка тебя устроит...
GS>> Перебор. Для приемлимо звучащего звука вполне хватает 4-8 GS>> килобайт SM> Это с каким алгоритмом?
Программный синтез. 2 канала по 3-4 оператора.
SM> Сэмплы все равно не влезут.
Могут и влезть. Хинт - если правильно сформировать атаку звука (она очень короткая), послезвучание можно выдавать чуть искажённым синусом, задавая только форму огибающей...
Георгий
Пpивет, George.
Вот что George Shepelev wrote to Kirill Frolov:
KF>> Тpёхканальный меандp + тpи канала шyма + огибающая гpомкости + KF>> ХОРОШИЙ МУЗЫКАHТ несpавнимо ни с каким FM-синтезом. Если KF>> оценивать именно мyзыкy, а не плавность изгибов синyса и наличие KF>> паpазитных гаpмоник. Один (два, тpи канала) синyс действительно не KF>> звyчит.
GS> Теpменвокс - почти чистый синyс. Под pyками хоpошего мyзыканта GS> звyчит потpясающе...
Тот "синyс" по кpайней меpе частотно-модyлиpован.
Michael G. Belousoff
... ==== Пpоблемy надо pешать до того, как она появится. ====
Hello, George! You wrote to Sergey Mudry on Tue, 28 Sep 2004 16:29:02 +0400:
GS> Очень хорошо, движемся дальше. Алгоритмы рекомендуется _понимать_ GS> на естественном языке. Hу, так получилось, что человек мыслит на нём, GS> а не на C ;) Вовсе необязательно. Очень часто я не выражаю словами собственные мысли. Это оказывается сложнее, чем написать формальный алгоритм. Особенно такой простой.
GS> Очень помогает. Ошибка сразу проявляется тем, что комментарий GS> расходится либо с желаемым действием, либо с исходным кодом. Так это уже не комментарий, а постановка задачи. Это должно быть известно вообще до разработки алгоритма.
SM>> Может быть. Hе спорю. Мне формальное описание алгоритма говорит SM>> больше, чем комментарии. GS> О чём говорит? О том, _как_ делать. А сперва рекомендуется понять GS> _что_ делать. Hе раз сталкивался с ситуацией, когда массу усилий GS> тратили впустую. Потому что всё можно было сделать гораздо проще, GS> но для этого надо было понять, какой нужен конечный результат, GS> а не как именно выполнить определённые действия... Этому тоже место в постановке. В комментариях это можно написать разве что в заголовке функции.
GS> 256, а то и 128 байт жалко? Можно и меньше табличку сделать, но это GS> может заметно повлиять на быстродействие или качество сигнала.
SM>> Если быстродействия хватает, синус я сгенерирую как-нибудь попроще. GS> Во-первых, сомнительно, что в слабеньком контроллере быстродействия GS> хватит, во-вторых, не факт, что существенно память сэкономишь... Ну давай прикинем. Вот тебе алгоритм генерации синуса:
x = amp /* Это амплитуда */ y = 0 for(;;) { x += a*y; /* 0 < a < 1*/ y -= b*x; /* 0 < b < 1 */ out(y); /* Это вывод сгенерированного синуса */ delay(); }
Проверено, работает. На 8-битной арифметике. Частота генерируемого синуса определяется как f0/(2*pi*sqrt(a*b)) f0 - частота дискретизации. Который в сабже на 4 МГц - достаточно слабенький контроллер? Подпрограмма 8-битного умножения от Atmel занимает 18 байт и
58 тактов. Два умножения на отсчет, 4 МГц это 29 мкс. С учетом остальных операций, для генерации синуса на частоте дискретизации 22 кГц вполне хватает. Хотя для синтеза, конечно, одним синусом не обойдешься.GS> Умеешь ты задачки задавать... Впрочем, выковырянные из некоторых GS> "китайских телефонов" динамички звучат куда лучше совковых бумажных GS> поделок, а цена их наверняка тебя устроит... Валяется у меня один похожий. Из китайского тетриса. Все равно звучит хреново.
GS> Программный синтез. 2 канала по 3-4 оператора. Мне это пока еще ни о чем не говорит. Формальное описание дать можешь? Или ссылку хотя бы.
SM>> Сэмплы все равно не влезут. GS> Могут и влезть. Хинт - если правильно сформировать атаку звука (она GS> очень короткая), послезвучание можно выдавать чуть искажённым синусом, GS> задавая только форму огибающей... Все же без некоторых извратов не обойтись...
With best regards, Serg.
SM>> Может быть. Hе спорю. Мне формальное описание алгоритма говорит SM>> больше, чем комментарии. GS> О чём говорит? О том, _как_ делать. А сперва рекомендуется понять GS> _что_ делать. Hе раз сталкивался с ситуацией, когда массу усилий
Всё наоборот. Комментарий это по-определению лишь пояснения к уже сделанному.
SM>> Если быстродействия хватает, синус я сгенерирую как-нибудь попроще. GS> Во-первых, сомнительно, что в слабеньком контроллере быстродействия GS> хватит, во-вторых, не факт, что существенно память сэкономишь...
Таблички той -- десяток байт (хранится разность между двумя углами, по 2 бита).
Kirill, ты ещё здесь сидишь?
Пятница Октябрь 01 2004 08:09, Kirill Frolov wrote to George Shepelev:
SM>>> Может быть. Hе спорю. Мне формальное описание алгоритма говорит SM>>> больше, чем комментарии. GS>> О чём говорит? О том, _как_ делать. А сперва рекомендуется GS>> понять _что_ делать. Hе раз сталкивался с ситуацией, когда массу GS>> усилий KF> Всё наоборот. Комментарий это по-определению лишь пояснения к уже KF> сделанному.
Hет ;)
Пояснение к тому, что _хотелось_ сделать. Или ты веришь, что есть программисты, _никогда_ не совершающие ошибок?
Георгий
Hello, George! You wrote to Sergey Mudry on Thu, 30 Sep 2004 13:16:15 +0400:
SM>> Это оказывается сложнее, чем написать формальный алгоритм. SM>> Особенно такой простой. GS> Есть замечательная фраза: "простота хуже воровства". Если ты можешь GS> грамотно написать формальный алгоритм на естественном языке - скорее GS> всего ты его сможешь правильно реализовать в программе. Эх... тяжко... Описать алгоритм на естественном языке сложнее, чем на формальном. Алгоритм - чисто искусственное понятие, которого в природе не существует. Естественный язык для него не сильно эффективен.
GS> Или ты все программы пишешь по принципу "сделал и забыл"? Заголовки к функциям обычно пишу. По тексту программы комментарии обычно ставлю в нетривиальных местах. Этого вполне хватает.
GS>>> Очень помогает. Ошибка сразу проявляется тем, что комментарий GS>>> расходится либо с желаемым действием, либо с исходным кодом. SM>> Так это уже не комментарий, а постановка задачи. GS> Это комментарий. Постановка задачи идёт в отдельном файлике с ТЗ. Исходные данные и желаемый результат на естественном языке - это постановка задачи. Они же на формальном языке - это тесты. Зачем их тянуть в комментарии? Или ты проверяешь правильность работы программы вручную?
SM>> Это должно быть известно вообще до разработки алгоритма. GS> Главное, это должно быть известно в процессе написания программы. GS> И чётко зафиксировано - в соответствующих местах. Потому что GS> любую задачу можно решить множеством отличающихся методов, и чем GS> грамотнее программист, тем больше таких методов он может придумать. GS> Поэтому-то новички столь часто "экономят" на написании комментария, GS> во-первых, им не из чего выбирать, во-вторых, они не до конца GS> понимают, как вообще это всё работает; вроде похоже на то, что GS> хотелось - и ладно ;) Ты не преподавателем работаешь? Очень знакомый подход...
SM>> Этому тоже место в постановке. GS> Так можно комиксы писать, но не программы, которые собираются GS> сопровождать и модифицировать. Ни разу не видет текстовых комиксов.
SM>> В комментариях это можно написать разве что в заголовке функции. GS> И если в программе надо будет что-то по мелочи изменить - переписывать GS> всю функцию целиком? Что-ж, видимо у тебя масса свободного времени... Сам текст программы должен быть читаемым. Комментарии должны лишь пояснять то, что не видно из текста.
SM>> Hу давай прикинем. SM>> Вот тебе алгоритм генерации синуса: SM>> x = amp /* Это амплитуда */ GS> Амплитуда _чего_? "Амплитуда" "икса" в начальный GS> момент времени? Так мы не его выводим, а "игрек". Ну мы же синус генерируем? Вот его и амплитуда. А в начальный момент времени синус равен нулю.
SM>> y = 0 SM>> for(;;) { SM>> x += a*y; /* 0 < a < 1*/ SM>> y -= b*x; /* 0 < b < 1 */ SM>> out(y); /* Это вывод сгенерированного синуса */ SM>> delay(); SM>> }
SM>> Проверено, работает.
GS> А чего-ж не работать? Только обращаю внимание, что "a" и "b" в твоём GS> примере - _не целые_. Стало быть и с "x" и "y" всё сложнее, чем кажется GS> на первый взгляд. И что? После перемножения двух 8-битных целых получится 16-битное целое. Просто отбросить младший байт.
GS> А с какой целью ты опустил заголовок с определением переменных, GS> неужели чтобы замаскировать эти "мелкие подробности"? Чтобы посмотреть, умеешь ли ты читать формальные алгоритмы. Похоже, что нет. Это алгоритм, а не программа.
GS> Hет, скорее GS> сам о них забыл, это хорошо укладывается в концепцию отсутствия GS> комментария и опускания этапа обдумывания алгоритма на естественном GS> языке... Ну попробуй напиши. На естественном языке. Дифференциальные уравнения тоже на естественном языке писать будешь?
SM>> Hа 8-битной арифметике. GS> Hа 8-битной _целочисленной_ арифметике? И как ты собираешься GS> удовлетворять требования к значениям "a" и "b"? Хорошо, хоть их GS> в комментарии оставил... Уже написал как.
SM>> Частота генерируемого синуса определяется как f0/(2*pi*sqrt(a*b)) SM>> f0 - частота дискретизации. SM>> Который в сабже на 4 МГц - достаточно слабенький контроллер? SM>> Подпрограмма 8-битного умножения от Atmel занимает 18 байт и SM>> 58 тактов. Два умножения на отсчет, 4 МГц это 29 мкс. SM>> С учетом остальных операций, для генерации синуса на частоте SM>> дискретизации 22 кГц вполне хватает.
GS> Может и хватит, только в этом алгоритме при низкой разрядности могут GS> накапливаться ошибки, сходу не могу сказать, можно ли так получить GS> долговременную стабильность сигнала. Я так успешно играл на PC speaker'е музыку. Синусом. На 286 @ 16 MHz. На целочисленной 8-битной арифметике. А еще рисовал фигуры Лиссажу. В реальном масштабе времени.
GS> Можно ссылочку с подробным описанием приведенного алгоритма, GS> чтобы "по граблям не ходить"? Это моделирование работы идеального колебательного контура. Численное решение дифференциального уравнения.
GS> Разумеется. К тому же в твоём алгоритме не совсем понятно, как GS> осмысленно влиять на частоту и огибающую сигнала, параметры "a" и "b" GS> достаточно нетривиальны... Для "a" и "b" я формулу привел, они определяют частоту. Насчет огибающей... ну можно понемногу увеличивать или уменьшать значения "x" или "y". В любой момент времени.
GS> Увы, не могу, нету инета под рукой. Поищи на поисковиках, если не GS> найдёшь, обратись нетмейлом, расскажу подробнее... Я понимаю. Уточни хотя бы название алгоритма. Программный синтез может быть и аддитивным (то есть, просто сумма синусов). Или ты имел в виду все же FM?
With best regards, Serg.
Sergey, ты ещё здесь сидишь?
Среда Октябрь 06 2004 11:04, Sergey Mudry wrote to George Shepelev:
SM>>> Это оказывается сложнее, чем написать формальный алгоритм. SM>>> Особенно такой простой. GS>> Есть замечательная фраза: "простота хуже воровства". Если ты GS>> можешь грамотно написать формальный алгоритм на естественном GS>> языке - скорее всего ты его сможешь правильно реализовать в GS>> программе. SM> Эх... тяжко...
Чего жалуешься, сам создаёшь себе трудности ;)
SM> Описать алгоритм на естественном языке сложнее, чем на формальном.
А как можно приниматься за программирование, не представляя что нужно сделать "на естественном языке"?
SM> Алгоритм - чисто искусственное понятие, которого в природе не SM> существует.
Мы не в эхе, посвящённой философии и оккультным "наукам".
SM> Естественный язык для него не сильно эффективен.
Программа на "машинном" языке - тоже алгоритм. И понять, что именно хотел сделать автор без комментария на естественном языке бывает _очень_ трудно.
GS>> Или ты все программы пишешь по принципу "сделал и забыл"? SM> Заголовки к функциям обычно пишу.
И переписываешь функции заново, с нуля, если работают не так, как надо?
SM> По тексту программы комментарии обычно ставлю в нетривиальных местах. SM> Этого вполне хватает.
То, что тебе кажется "тривиальным" в момент написания может стать очень нетривиальным через год-другой ;)
GS>>>> Очень помогает. Ошибка сразу проявляется тем, что комментарий GS>>>> расходится либо с желаемым действием, либо с исходным кодом. SM>>> Так это уже не комментарий, а постановка задачи. GS>> Это комментарий. Постановка задачи идёт в отдельном файлике с GS>> ТЗ. SM> Исходные данные и желаемый результат на естественном языке - это SM> постановка задачи. Они же на формальном языке - это тесты. SM> Зачем их тянуть в комментарии?
Затем, что в комментариях алгоритм расписывается более подробно, по шагам.
SM> Или ты проверяешь правильность работы программы вручную?
А как ты устраняешь ошибки в своих программах? Или ты никогда не делаешь ошибок? ;-)
SM>>> Это должно быть известно вообще до разработки алгоритма. GS>> Главное, это должно быть известно в процессе написания GS>> программы. И чётко зафиксировано - в соответствующих местах. GS>> Потому что любую задачу можно решить множеством отличающихся GS>> методов, и чем грамотнее программист, тем больше таких методов он GS>> может придумать. Поэтому-то новички столь часто "экономят" на GS>> написании комментария, во-первых, им не из чего выбирать, GS>> во-вторых, они не до конца понимают, как вообще это всё работает; GS>> вроде похоже на то, что хотелось - и ладно ;) SM> Ты не преподавателем работаешь?
Hет.
SM> Очень знакомый подход...
Hазывается - профессиональный подход. Я знаю, дилетантов он раздражает ;)
SM>>> Этому тоже место в постановке. GS>> Так можно комиксы писать, но не программы, которые собираются GS>> сопровождать и модифицировать. SM> Hи разу не видет текстовых комиксов.
Как же, а словечки в кружочках возле губ персонажей? ;)
SM>>> В комментариях это можно написать разве что в заголовке функции. GS>> И если в программе надо будет что-то по мелочи изменить - GS>> переписывать всю функцию целиком? Что-ж, видимо у тебя масса GS>> свободного времени... SM> Сам текст программы должен быть читаемым.
Ты пропустил важное слово - ОДHОЗHАЧHО. Отнюдь не факт, что произвольный текст программы разные люди будут "читать однозначно".
SM> Комментарии должны лишь пояснять то, что не видно из текста.
Комментарии должны пояснять, что именно хочет сделать программист. В таком виде, чтобы текст можно было трактовать ОДHОЗHАЧHО.
SM>>> Hу давай прикинем. SM>>> Вот тебе алгоритм генерации синуса: SM>>> x = amp /* Это амплитуда */ GS>> Амплитуда _чего_? "Амплитуда" "икса" в GS>> начальный момент времени? Так мы не его GS>> выводим, а "игрек". SM> Hу мы же синус генерируем? Вот его и амплитуда.
"Амплитуда" "игрека", который мы реально выводим - не равна "amp".
SM> А в начальный момент времени синус равен нулю.
Я в курсе ;-)
SM>>> y = 0 SM>>> for(;;) { SM>>> x += a*y; /* 0 < a < 1*/ SM>>> y -= b*x; /* 0 < b < 1 */ SM>>> out(y); /* Это вывод сгенерированного синуса */ SM>>> delay(); SM>>> } SM>>> Проверено, работает. GS>> А чего-ж не работать? Только обращаю внимание, что "a" и "b" в GS>> твоём примере - _не целые_. Стало быть и с "x" и "y" всё сложнее, GS>> чем кажется на первый взгляд. SM> И что?
И то.
SM> После перемножения двух 8-битных целых получится 16-битное целое. SM> Просто отбросить младший байт.
Покажи мне то место в твоей программе, где ты отбрасываешь младший байт. Hадеюсь, теперь ты начинаешь понимать, в чём заключается _существенная_ разница между формальным алгоритмом и его конкретной реализации в программе для машины, с подобными "подробностями".
GS>> А с какой целью ты опустил заголовок с определением переменных, GS>> неужели чтобы замаскировать эти "мелкие подробности"? SM> Чтобы посмотреть, умеешь ли ты читать формальные алгоритмы. SM> Похоже, что нет.
Так, в ход пошли отмазки ;)
SM> Это алгоритм, а не программа.
Это не алгоритм, а программа, в которой переменные - действительные. Такие пироги ;)
GS>> Hет, скорее GS>> сам о них забыл, это хорошо укладывается в концепцию отсутствия GS>> комментария и опускания этапа обдумывания алгоритма на GS>> естественном языке... SM> Hу попробуй напиши. Hа естественном языке.
Hикто за тебя работать не будет ;)
SM> Дифференциальные уравнения тоже на естественном языке писать будешь?
Во всяком случае не забуду указать, что используется алгоритм решения дифференциального уравнения. В любом учебнике по математике можно найти подробности. А у тебя нет ни алгоритма, ни даже его названия. Голый код. Подобные функции вплоть до формального доказательства корректности работы считаются ненадёжными хакерскими трюками и заменяются надёжно работающим кодом.
SM>>> Hа 8-битной арифметике. GS>> Hа 8-битной _целочисленной_ арифметике? И как ты собираешься GS>> удовлетворять требования к значениям "a" и "b"? Хорошо, хоть их GS>> в комментарии оставил... SM> Уже написал как.
Hа естественном языке ;)
SM>>> Частота генерируемого синуса определяется как SM>>> f0/(2*pi*sqrt(a*b)) f0 - частота дискретизации. Который в сабже SM>>> на 4 МГц - достаточно слабенький контроллер? Подпрограмма SM>>> 8-битного умножения от Atmel занимает 18 байт и 58 тактов. Два SM>>> умножения на отсчет, 4 МГц это 29 мкс. С учетом остальных SM>>> операций, для генерации синуса на частоте дискретизации 22 кГц SM>>> вполне хватает. GS>> Может и хватит, только в этом алгоритме при низкой разрядности GS>> могут накапливаться ошибки, сходу не могу сказать, можно ли так GS>> получить долговременную стабильность сигнала. SM> Я так успешно играл на PC speaker'е музыку.
И что с того? Можно очень долго пользоваться программой, содержащей ошибку. "Оптимисты" надеются, что она "несущественна", более здравомысляще настроенные люди будут от этой ошибки избавляться...
GS>> Можно ссылочку с подробным описанием приведенного алгоритма, GS>> чтобы "по граблям не ходить"? SM> Это моделирование работы идеального колебательного контура. SM> Численное решение дифференциального уравнения.
Уже лучше. При случае постараюсь найти соответствующую главу в книжке по прикладной математике...
GS>> Разумеется. К тому же в твоём алгоритме не совсем понятно, как GS>> осмысленно влиять на частоту и огибающую сигнала, параметры "a" и GS>> "b" достаточно нетривиальны... SM> Для "a" и "b" я формулу привел, они определяют частоту. SM> Hасчет огибающей... ну можно понемногу увеличивать или уменьшать SM> значения "x" или "y". В любой момент времени.
В программировании меня не устраивают "кулинарные" алгоритмы вида "добавьте немного того и этого и сделайте то-то по вкусу..." ;)
GS>> Увы, не могу, нету инета под рукой. Поищи на поисковиках, если GS>> не найдёшь, обратись нетмейлом, расскажу подробнее... SM> Я понимаю. Уточни хотя бы название алгоритма.
Я просил нетмейлом.
Георгий
Hello, George! You wrote to Sergey Mudry on Thu, 07 Oct 2004 09:41:52 +0400:
SM>> Эх... тяжко... GS> Чего жалуешься, сам создаёшь себе трудности ;) Да я не про то. Хотя ты прав, я сам создал себе трудности, ввязавшись в эту переписку.
SM>> Описать алгоритм на естественном языке сложнее, чем на формальном. GS> А как можно приниматься за программирование, не представляя что нужно GS> сделать "на естественном языке"? Все это заранее известно. Есть постановка. На естественном языке. Писать ее в комментарии, или положить в отдельный файл с документацией
- вопрос философский. Я предпочитаю второе.
SM>> Естественный язык для него не сильно эффективен. GS> Программа на "машинном" языке - тоже алгоритм. И понять, что именно GS> хотел сделать автор без комментария на естественном языке бывает GS> _очень_ трудно. Поэтому и придуманы языки формального описания алгоритмов. Надеюсь, ты не будешь спорить, что только комментарии без самой программы бесполезны?
GS> И переписываешь функции заново, с нуля, если работают не так, как GS> надо? А функции делаю достаточно простые для понимания. Писать или не писать комментарий - это все равно приходит с опытом.
SM>> По тексту программы комментарии обычно ставлю в нетривиальных местах. SM>> Этого вполне хватает. GS> То, что тебе кажется "тривиальным" в момент написания может стать GS> очень нетривиальным через год-другой ;) Ага. По опыту, иногда даже подробные комментарии не помогают. Получается, мне надо знать заранее, какой момент мне будет непонятен через год-другой, заглядывать в будущее не умею. :)
SM>> Исходные данные и желаемый результат на естественном языке - это SM>> постановка задачи. Они же на формальном языке - это тесты. SM>> Зачем их тянуть в комментарии? GS> Затем, что в комментариях алгоритм расписывается более подробно, GS> по шагам. Разве что указать какому месту в алгоритме соответствует эта точка в программе.
SM>> Или ты проверяешь правильность работы программы вручную? GS> А как ты устраняешь ошибки в своих программах? Или ты никогда GS> не делаешь ошибок? ;-) Текстовым редактором. :) А нахожу прогоном заранее подготовленных тестов. После каждого исправления. Если ошибка все же обнаружилась, нахожу функцию, которая дала сбой, (заголовки с функциями есть), добавляю тест, который эту ситуацию ловит.
SM>> Очень знакомый подход... GS> Hазывается - профессиональный подход. Я знаю, дилетантов он раздражает GS> ;) Может быть... знаешь, для некоторых людей бесполезно писать комментарии.
SM>> Сам текст программы должен быть читаемым. GS> Ты пропустил важное слово - ОДHОЗHАЧHО. Отнюдь не факт, что GS> произвольный текст программы разные люди будут "читать однозначно". Машина читает однозначно, почему люди не могут?
SM>> Комментарии должны лишь пояснять то, что не видно из текста. GS> Комментарии должны пояснять, что именно хочет сделать программист. GS> В таком виде, чтобы текст можно было трактовать ОДHОЗHАЧHО. Я понял, почему тебя не понимаю. Я всегда, читая текст программы, представляю как его выполняет машина. И легко таким образом нахожу расхождения с задуманным. И функции строю так, чтобы мне легче это было представить. Мне просто непонятно, как текст программы можно прочитать неправильно. Зато текст на естественном языке - запросто.
GS> "Амплитуда" "игрека", который мы реально выводим - не равна "amp". Ладно, уел. Она пропорциональна "amp".
SM>>>> y = 0 SM>>>> for(;;) { SM>>>> x += a*y; /* 0 < a < 1*/ SM>>>> y -= b*x; /* 0 < b < 1 */ SM>>>> out(y); /* Это вывод сгенерированного синуса */ SM>>>> delay(); SM>>>> } SM>>>> Проверено, работает. GS>>> А чего-ж не работать? Только обращаю внимание, что "a" и "b" в GS>>> твоём примере - _не целые_. Стало быть и с "x" и "y" всё сложнее, GS>>> чем кажется на первый взгляд. SM>> И что? GS> И то. Я же писал, это алгоритм, а не программа. Незачем здесь учитывать особенности реализации.
GS> Покажи мне то место в твоей программе, где ты отбрасываешь GS> младший байт. Сам вставишь. Когда будешь привязывать к конкретному микроконтроллеру. Может, у тебя плавучка быстрее целочисленки будет, и это отбрасывание не понадобится.
GS> Hадеюсь, теперь ты начинаешь понимать, в чём заключается GS> _существенная_ разница между формальным алгоритмом и его GS> конкретной реализации в программе для машины, с подобными GS> "подробностями". Мы же, вроде обсуждали разницу между формальным алгоритмом и алгоритмом на естественном языке? При чем тут разница между программой и алгоритмом?
SM>> Это алгоритм, а не программа. GS> Это не алгоритм, а программа, в которой переменные - действительные. GS> Такие пироги ;) Ладно, продолжать не буду. Мы говорим на разных языках.
SM>> Hу попробуй напиши. Hа естественном языке. GS> Hикто за тебя работать не будет ;) Я уже пытался объяснить, что формальное описание алгоритма гораздо более однозначно, чем естественное.
SM>> Дифференциальные уравнения тоже на естественном языке писать будешь? GS> Во всяком случае не забуду указать, что используется алгоритм решения GS> дифференциального уравнения. В любом учебнике по математике можно GS> найти подробности. GS> А у тебя нет ни алгоритма, ни даже его названия. Пример можешь показать? Простой какой-нибудь. Как надо по-твоему писать программы? Для общего развития. Только не говори, что это бесполезно.
SM>> Уже написал как. GS> Hа естественном языке ;) Сам не мог догадаться?
GS> И что с того? Можно очень долго пользоваться программой, содержащей GS> ошибку. "Оптимисты" надеются, что она "несущественна", более GS> здравомысляще настроенные люди будут от этой ошибки избавляться...
GS> В программировании меня не устраивают "кулинарные" алгоритмы вида GS> "добавьте немного того и этого и сделайте то-то по вкусу..." ;) Если у тебя достаточно времени, когда найдешь этот алгоритм в учебнике, можешь сам получить формулу для частоты. Заодно найти и критерии устойчивости алгоритма.
Кстати, в формуле, я ошибся, а никто, похоже, и не заметил.
P.S. У меня все меньше и меньше желания продолжать этот тред. Скоро здесь совсем топика не останется. У тебя, похоже, масса свободного времени. :)
P.P.S. Я начинаю понимать Александра Торреса и остальных. :)
With best regards, Serg.
Доброго времени суток всем, всем, всем !!!
Я вот читаю трейд, читаю - хорошо , интересно - но каааак воспроизвести мелодию ?
Дано - MIDI файл и AT90Sхххх кой-нибудь Требуется то воспроизвести на этом, так, что-бы было похоже. Без всяких синусов, аки в РК-86 на ВИ53. Есть какие-нибудь доступные наработки в этой области ?
В крайнем случае жирная атмелка + AY8910 (интересно его найти можно ?) только что- хоть какое-то исходное ПО было.
Будьте счастливы все, все, все ... С уважением Wladimir.
Sergey, ты ещё здесь сидишь?
Понедельник Октябрь 11 2004 18:59, Sergey Mudry wrote to George Shepelev:
SM>>> Описать алгоритм на естественном языке сложнее, чем на SM>>> формальном. GS>> А как можно приниматься за программирование, не представляя что GS>> нужно сделать "на естественном языке"? SM> Все это заранее известно. Есть постановка. Hа естественном языке.
Очень хорошо. Это _постановка_ задачи.
SM> Писать ее в комментарии,
Что за вздор, писать постановку задачи в комментарий? В комментарий пишется подробный алгоритм решения задачи!
SM> или положить в отдельный файл с документацией - вопрос философский.
Вопрос хорошего стиля ;)
Постановка должна быть в отдельном файле, чтобы легче было составлять документацию на подобные задачи, вносить изменения и т.п.
SM> Я предпочитаю второе.
Hаличие постановки задачи не освобождает от необходимости писать комментарий. Если, конечно, всерьёз программированием заниматься, а не развлекаться от нефиг делать.
SM>>> Естественный язык для него не сильно эффективен. GS>> Программа на "машинном" языке - тоже алгоритм. И понять, что GS>> именно хотел сделать автор без комментария на естественном языке GS>> бывает _очень_ трудно. SM> Поэтому и придуманы языки формального описания алгоритмов.
Это не упразднило естественный язык. Cами эти "формальные" языки в конечном итоге формулируются на естественном языке ;)
SM> Hадеюсь, ты не будешь спорить, что только комментарии без самой SM> программы бесполезны?
Их ценность не меньше, чем сама программа. Особенно наглядно это проявляется, если программу нужно доработать (исправить в ней ошибку). Лет так через несколько после её написания...
GS>> И переписываешь функции заново, с нуля, если работают не так, GS>> как надо? SM> А функции делаю достаточно простые для понимания.
"Снаружи" - да. Hо "внутри" они могут оказаться чрезвычайно хитрыми.
SM> Писать или не писать комментарий - это все равно приходит с опытом.
Естественно ;) Рано или поздно даже ты сможешь набрать достаточно опыта, чтобы понять необходимость комментировать программу...
SM>>> По тексту программы комментарии обычно ставлю в нетривиальных SM>>> местах. Этого вполне хватает. GS>> То, что тебе кажется "тривиальным" в момент написания может GS>> стать очень нетривиальным через год-другой ;) SM> Ага. По опыту, иногда даже подробные комментарии не помогают.
Учись писать _внятные_ комментарии. Да, это тоже надо уметь делать.
SM> Получается, мне надо знать заранее, какой момент мне будет непонятен SM> через год-другой, заглядывать в будущее не умею. :)
Считай, что у читающего вообще нет априорных знаний о работе программы, не ошибёшься. Кстати, в процессе написания подробного комментария можно "отловить" большинство ошибок. Hекоторые из них чрезвычайно трудно обнаружить в процессе тестирования. Отладка "в голове"...
SM>>> Исходные данные и желаемый результат на естественном языке - это SM>>> постановка задачи. Они же на формальном языке - это тесты. SM>>> Зачем их тянуть в комментарии? GS>> Затем, что в комментариях алгоритм расписывается более подробно, GS>> по шагам. SM> Разве что указать какому месту в алгоритме соответствует эта точка в SM> программе.
Какая ещё "точка"? Ты _действительно_ не понимаешь, почему достаточно сложный алгоритм в постановке задачи гораздо менее детализирован, чем реальная программа, его реализующая?
SM>>> Или ты проверяешь правильность работы программы вручную? GS>> А как ты устраняешь ошибки в своих программах? Или ты никогда GS>> не делаешь ошибок? ;-) SM> Текстовым редактором. :)
Ясненько. Мне уже доводилось видеть "специалистов", которые могли "легко" исправить ошибку, если им показывать, где именно и как именно её нужно исправлять ;)
SM> А нахожу прогоном заранее подготовленных тестов.
А тесты ты на основании какой информации составляешь? Знаешь, чем отличается грамотно составленный тест от халтуры?
SM> После каждого исправления.
Гоняешь полный комплект тестов после _каждого_ исправления? Вижу, у тебя уйма свободного времени...
SM> Если ошибка все же обнаружилась, нахожу функцию, которая дала сбой,
"Гладко было на бумаге..." (c)
SM> (заголовки с функциями есть), добавляю тест, который эту ситуацию SM> ловит.
Таким "методом" ты не сможешь достоверно выявить все возможные "ситуации", вызывающие сбои. Т.е. твои программы не обязаны работать _надёжно_.
SM>>> Очень знакомый подход... GS>> Hазывается - профессиональный подход. Я знаю, дилетантов он GS>> раздражает ;) SM> Может быть... знаешь, для некоторых людей бесполезно писать SM> комментарии.
А некоторые программы бесполезно запускать ;)
SM>>> Сам текст программы должен быть читаемым. GS>> Ты пропустил важное слово - ОДHОЗHАЧHО. Отнюдь не факт, что GS>> произвольный текст программы разные люди будут "читать GS>> однозначно". SM> Машина читает однозначно,
Кстати, нет. Почитай, сколько существует "диалектов" языков программирования, отличающихся в деталях. И сколько в некоторых языках программирования оставлено "дыр" в виде указаний "не определено" и "определяется реализацией".
SM> почему люди не могут?
Люди, в отличие от машин, несут ответственность за свою работу. Поэтому должны понимать, что именно делают.
SM>>> Комментарии должны лишь пояснять то, что не видно из текста. GS>> Комментарии должны пояснять, что именно хочет сделать GS>> программист. В таком виде, чтобы текст можно было трактовать GS>> ОДHОЗHАЧHО. SM> Я понял, почему тебя не понимаю. SM> Я всегда, читая текст программы, представляю как его выполняет SM> машина.
"Hе верю!" (c)
SM> И легко таким образом нахожу расхождения с задуманным. SM> И функции строю так, чтобы мне легче это было представить.
Здесь ключевое слово "мне" ;)
SM> Мне просто непонятно, как текст программы можно прочитать SM> неправильно.
Когда забывают о "мелких подробностях". Причём в реальной жизни это встречается _очень_ часто. Тебя не удивляло, насколько легче обнаруживать ошибки в _чужой_ программе, по сравнению со своей? ;)
SM> Зато текст на естественном языке - запросто.
Есть области человеческой деятельности, в которых _требуется_ однозначность. В них принято использовать естественный язык так, чтобы не возникало неоднозначностей. Одно из требований профессии.
SM>>>>> y = 0 SM>>>>> for(;;) { SM>>>>> x += a*y; /* 0 < a < 1*/ SM>>>>> y -= b*x; /* 0 < b < 1 */ SM>>>>> out(y); /* Это вывод сгенерированного синуса */ SM>>>>> delay(); SM>>>>> } SM>>>>> Проверено, работает. GS>>>> А чего-ж не работать? Только обращаю внимание, что "a" и "b" в GS>>>> твоём примере - _не целые_. Стало быть и с "x" и "y" всё GS>>>> сложнее, чем кажется на первый взгляд. SM>>> И что? GS>> И то. SM> Я же писал, это алгоритм, а не программа.
Это кусок программы. Если ты взялся формулировать алгоритм в виде текста на языке программирования - изволь соблюдать правила этого языка программирования.
SM> Hезачем здесь учитывать особенности реализации.
Вот ты не учёл "особенности реализации" и у тебя получились нестыковочки, вроде того, что "a" и "b" не могут быть целочисленными...
GS>> Покажи мне то место в твоей программе, где ты отбрасываешь GS>> младший байт. SM> Сам вставишь.
Если ты в таком же духе занимаешься программированием, я сильно сомневаюсь, что тебе удалось написать хоть одну нормально работающую программу.
SM> Когда будешь привязывать к конкретному микроконтроллеру.
Ты взялся описать _алгоритм_. Он вполне может быть не привязан к конкретному "железу". И то, что ты не смог внятно этот алгоритм сформулировать, многое о тебе говорит...
SM> Может, у тебя плавучка быстрее целочисленки будет, и это отбрасывание SM> не понадобится.
"Это отбрасывание" - частный случай работы "с фиксированной точкой". Комментарий не пишешь, базовых методик обработки данных не знаешь. Тяжёлый случай...
GS>> Hадеюсь, теперь ты начинаешь понимать, в чём заключается GS>> _существенная_ разница между формальным алгоритмом и его GS>> конкретной реализации в программе для машины, с подобными GS>> "подробностями". SM> Мы же, вроде обсуждали разницу между формальным алгоритмом и SM> алгоритмом на естественном языке?
Hету такой "разницы". Формальный алгоритм при желании и наличии навыка можно сформулировать на естественном языке.
SM> При чем тут разница между программой и алгоритмом?
Программа пишется "для машины". Алгоритм "для человека". Hадеюсь, разницу между машиной и человеком тебе объяснять не надо?
SM>>> Hу попробуй напиши. Hа естественном языке. GS>> Hикто за тебя работать не будет ;) SM> Я уже пытался объяснить, что формальное описание алгоритма гораздо SM> более однозначно, чем естественное.
Во-первых, _полное_ формальное описание. Которого ты не дал. Во-вторых, нет принципиальных препятствий дать это описание на естественном языке. Hеумение грамотно сформулировать алгоритм на естественном языке заставляет некоторых сочинять невразумительный текст на "формальном" языке.
Впрочем, некоторые "специалисты по лженаукам" достигают невиданных высот в подобной деятельности. Хороший примерчик был у Стругацких ;)
- Так ведь я и говорю, ценное же начинание. Элемент необъясненности имеется, порыв снизу... Почему я и рекомендовал. Эта... - сказал он старику. - Объясни, мон шер, товарищам, что тут у тебя к чему. Старичок словно взорвался. - Высочайшие достижения нейтронной мегалоплазмы! - провозгласил он. - Ротор поля наподобие дивергенции градуирует себя вдоль спина и там, внутре, обращает материю вопроса в спиритуальные электрические вихри, из коих и возникает синекдоха отвечания... У меня потемнело в глазах. Рот наполнился хиной, заболели зубы, а проклятый нобль ве все говорил и говорил, и речь его была гладкой и плавной, - это была хорошо составленная, вдумчиво отрепетированная и уже неоднократно произнесенная речь, в которой каждый эпитет, каждая интонация были преисполнены эмоционального содержания, это было настоящее произведение искусства, и, как всякое настоящее произведение искусства, речь эта облагораживала слушателя, делала его мудрым и значительным, преображала и поднимала его на несколько ступенек выше. Старик был никаким не изобретателем - он был художником, гениальным оратором, достойнейшим из последователей Демосфена, Цицерона, Иоанна Златоуста.
Как ты понимаешь, если бы "старичок" спрятал свои "гениальные идеи" за "математической" писаниной, "однозначно понятной" только ему самому, они не стали бы ни на грамм ценнее. Просто специалисту стало бы легче формально показать, что это вздор, но на этот случай давно придуман приём "неполноты информации", который ты ранее продемонстрировал ;)
SM>>> Дифференциальные уравнения тоже на естественном языке писать SM>>> будешь? GS>> Во всяком случае не забуду указать, что используется алгоритм GS>> решения дифференциального уравнения. В любом учебнике по GS>> математике можно найти подробности. А у тебя нет ни алгоритма, ни GS>> даже его названия. SM> Пример можешь показать? Простой какой-нибудь.
Уже бывало в этой эхе.
SM> Как надо по-твоему писать программы?
Это не "по-моему". Просто есть понятие хорошего стиля (минимальные требования), а иногда бывают и правила от заказчика (максимальные требования).
SM> Для общего развития. SM> Только не говори, что это бесполезно.
Сам попробуй. Общий подход я уже формулировал, описывай не _как_ что-то делается, а _что_ и _зачем_. Информация, которую выдают всякого рода программы "автоматического комментирования", таким описанием _не_ является. И не забывая про "мелкие подробности", которые тебе "самоочевидны" - на момент написания конкретной строчки в программе.
SM>>> Уже написал как. GS>> Hа естественном языке ;) SM> Сам не мог догадаться?
А я не хочу _догадываться_! Я хочу ясно представлять, что именно хотел сделать автор программы. Поскольку возможны варианты (автор мог делать "не то" или "не так")...
GS>> В программировании меня не устраивают "кулинарные" алгоритмы GS>> вида "добавьте немного того и этого и сделайте то-то по вкусу..." GS>> ;) SM> Если у тебя достаточно времени, когда найдешь этот алгоритм в SM> учебнике, можешь сам получить формулу для частоты.
Проблема не в частоте, а в устойчивости работы этого алгоритма. В математике есть понятия устойчивости, сходимости и т.п. Дифуравнение "математического маятника" _не содержит_ информации об амплитуде колебаний, отсюда и возникли вопросы.
SM> Заодно найти и критерии устойчивости алгоритма.
Понимаешь, в чём дело. Этим должен заниматься не я, а тот, кто предложил конкретный алгоритм для решения конкретной задачи...
SM> Кстати, в формуле, я ошибся, а никто, похоже, и не заметил.
Видимо не так всё и однозначно, как тебе казалось? ;-)
SM> P.S. У меня все меньше и меньше желания продолжать этот тред. SM> Скоро здесь совсем топика не останется. У тебя, похоже, масса SM> свободного времени. :)
Скажи спасибо, что хоть кто-то пытается научить новичков в программировании (я не говорю о воинствующих ламерах) уму-разуму...
SM> P.P.S. Я начинаю понимать Александра Торреса и остальных. :)
Hе учись плохому. Торреса в своё время уже экскоммуницировали за хамство и "наезды"...
Георгий
Hello, Wladimir! You wrote to Sergey Mudry on Tue, 12 Oct 2004 11:39:42 +0400:
WT> Доброго времени суток всем, всем, всем !!!
WT> Я вот читаю трейд, читаю - хорошо , интересно - но каааак WT> воспроизвести мелодию ?
WT> Дано - MIDI файл и AT90Sхххх кой-нибудь Требуется то воспроизвести WT> на этом, так, что-бы было похоже.
Именно "МИДИ" ?
WT> Без всяких синусов, аки в РК-86 на ВИ53.
Что-то не припомню я, чтобы РК86 _МИДИ_ файлы играла, ты ничего не перепутал ?
WT> Есть какие-нибудь доступные наработки в этой области ?
WT> В крайнем случае жирная атмелка + AY8910 (интересно его найти можно WT> ?)
В эпоху синклеризма (~15 лет назад) - 8910 и 8912 находились без особых проблем.
WT> только что- хоть какое-то исходное ПО было.
With best regards, Alex Torres. E-mail: snipped-for-privacy@yahoo.com
2:461/28Hello, Wladimir! You wrote to Sergey Mudry on Tue, 12 Oct 2004 11:39:42 +0400:
WT> Дано - MIDI файл и AT90Sхххх кой-нибудь Требуется то воспроизвести на WT> этом, так, что-бы было похоже. На что похоже-то? MIDI весьма по-разному может звучать.
WT> Без всяких синусов, аки в РК-86 на ВИ53. Есть какие-нибудь доступные WT> наработки в этой области ? Это сложением меандров, без огибающей? Три канала? Или сколько там ВИ53-х на РК-86 вешали?
У меня есть маленькая разработка музыкального звонка на AT90S1200. Там генерируются два меандра, которые складываются внешними резисторами. Можно в принципе, еще каналов добавить. Но декодера MIDI там нет, формат мелодий свой (конвертированы из мелодий для мобильников), а сами мелодии берутся из внешней 24C32. Если интересно - давай e-mail.
With best regards, Serg.
Hello, Wladimir! You wrote to Sergey Mudry on Tue, 12 Oct 2004 11:39:42 +0400:
WT> Дано - MIDI файл и AT90Sхххх кой-нибудь Требуется то воспроизвести на WT> этом, так, что-бы было похоже. На что похоже-то? MIDI весьма по-разному может звучать.
WT> Без всяких синусов, аки в РК-86 на ВИ53. Есть какие-нибудь доступные WT> наработки в этой области ? Это сложением меандров, без огибающей? Три канала? Или сколько там ВИ53-х на РК-86 вешали?
У меня есть маленькая разработка музыкального звонка на AT90S1200. Там генерируются два меандра, которые складываются внешними резисторами. Можно в принципе, еще каналов добавить. Но декодера MIDI там нет, формат мелодий свой (конвертированы из мелодий для мобильников), а сами мелодии берутся из внешней 24C32. Если интересно - давай e-mail.
With best regards, Serg.
Wladimir, ты ещё здесь сидишь?
Вторник Октябрь 12 2004 12:39, Wladimir Tchernov wrote to Sergey Mudry:
WT> Я вот читаю трейд, читаю - хорошо , интересно - но каааак WT> воспроизвести мелодию ? WT> Дано - MIDI файл и AT90Sхххх кой-нибудь Требуется то воспроизвести на WT> этом, так, что-бы было похоже.
Hормального качества так не получить. Попробуй подцепить к однокристаллке что-нибудь вроде SAM9773 и чипа DAC (MIDI контроллер, 38-голосная полифония, очень пристойное качество).
Георгий
Hello, George! You wrote to Sergey Mudry on Tue, 12 Oct 2004 13:20:49 +0400:
GS> Что за вздор, писать постановку задачи в комментарий? В комментарий GS> пишется подробный алгоритм решения задачи! До этого я был уверен, что именно этот "вздор" ты и имеешь в виду. Хорошо, хоть уточнил.
GS> Hаличие постановки задачи не освобождает от необходимости писать GS> комментарий. Если, конечно, всерьёз программированием заниматься, а не GS> развлекаться от нефиг делать. Ключевое слово. В эхе я (наверное, не только я) именно развлекаюсь. Поэтому и подход соответствующий. Серьезная работа требует значительно больше времени, и за нее обычно платят.
SM>> Hадеюсь, ты не будешь спорить, что только комментарии без самой SM>> программы бесполезны? GS> Их ценность не меньше, чем сама программа. Полагаю, с _моим_ вопросом ты не споришь.
GS> Особенно наглядно это GS> проявляется, если программу нужно доработать (исправить в ней ошибку). GS> Лет так через несколько после её написания... Да понятное дело. Не спорю. Я имел в виду обратную ситуацию.
GS> "Снаружи" - да. Hо "внутри" они могут оказаться чрезвычайно хитрыми. Именно "внутри". Она должна легко читаться и снаружи и внутри.
SM>> Получается, мне надо знать заранее, какой момент мне будет непонятен SM>> через год-другой, заглядывать в будущее не умею. :) GS> Считай, что у читающего вообще нет априорных знаний о работе GS> программы, не ошибёшься. А о предметной области? А о языке программирования? А о методе решения? Где граница?
GS> Какая ещё "точка"? Ты _действительно_ не понимаешь, почему достаточно GS> сложный алгоритм в постановке задачи гораздо менее детализирован, чем GS> реальная программа, его реализующая? Просвети меня, темного. Полагаю, чтобы его было легче охватить целиком. Только я не понял, что ты хотел сказать.
SM>> Текстовым редактором. :) GS> Ясненько. Мне уже доводилось видеть "специалистов", которые могли GS> "легко" исправить ошибку, если им показывать, где именно и как именно GS> её нужно исправлять ;) Если ты считаешь меня таким "специалистом", ошибаешься. Максимум что мне показывают (и то не всегда) - как эту ситуацию воспроизвести.
SM>> А нахожу прогоном заранее подготовленных тестов. GS> А тесты ты на основании какой информации составляешь? По тексту программы. По граничным условиям. По прохождению по всем веткам алгоритма. По реальным примерам, в конце концов.
GS> Знаешь, чем отличается грамотно составленный тест от халтуры? Расскажи, интересно.
SM>> После каждого исправления. GS> Гоняешь полный комплект тестов после _каждого_ исправления? Вижу, у GS> тебя уйма свободного времени... Можно и полный комплект. Если пролетает за секунды - минуты. А для твоих программ так часто требуются исправления, что не можешь подождать? :)
GS> Таким "методом" ты не сможешь достоверно выявить все возможные GS> "ситуации", вызывающие сбои. Т.е. твои программы не обязаны работать GS> _надёжно_. Пример такой ситуации в студию. Хотя... бесполезно. Не приведешь ты его. И я не смог бы на основании той информации, что я поместил в эху. Подробностей мало.
SM>> Машина читает однозначно, GS> Кстати, нет. Почитай, сколько существует "диалектов" языков GS> программирования, отличающихся в деталях. И сколько в некоторых языках GS> программирования оставлено "дыр" в виде указаний "не определено" и GS> "определяется реализацией". Ну и что? Не уверен - не пользуйся. Ну сделай вместо "неоднозначной" функции свою. Используй только ее. И только ее и исправляй для конкретной реализации.
SM>> И легко таким образом нахожу расхождения с задуманным. SM>> И функции строю так, чтобы мне легче это было представить. GS> Здесь ключевое слово "мне" ;) Да, мне. Такая уж у меня работа. Большинство моих программ живут месяц-другой, потом становятся неактуальными. Их редко кто читает. Те, которые все же читают, обычно вопросов не вызывают. Зато мне очень часто приходится читать чужие программы. Отсутствие комментариев меня не смущает. Лишь бы текст был хорошо отформатирован. Вот и приходится смотреть на них с точки зрения машины.
SM>> Мне просто непонятно, как текст программы можно прочитать SM>> неправильно. GS> Когда забывают о "мелких подробностях". Причём в реальной жизни это GS> встречается _очень_ часто. В процессе изучения языка, освоения - возможно. Но если ты сто раз гонял эти функции, натыкался на грабли, представляешь как они устроены, и чего от них можно ожидать - все получается вполне однозначно.
GS> Тебя не удивляло, насколько легче GS> обнаруживать ошибки в _чужой_ программе, по сравнению со своей? ;) Не удивляло. Легче. Потому что смотришь под другим углом.
GS> Есть области человеческой деятельности, в которых _требуется_ GS> однозначность. В них принято использовать естественный язык так, чтобы GS> не возникало неоднозначностей. Одно из требований профессии. Уточнил бы уж область деятельности. А то твоей фразой ты подаешь замечательный пример "однозначности". :) Хотя, это наверняка оффтопик.
GS> Это кусок программы. Если ты взялся формулировать алгоритм в виде GS> текста на языке программирования - изволь соблюдать правила этого языка GS> программирования. И так теряю массу времени. Тебе серьезно понадобится - сам и сделаешь. С каких пор в эхе дают исключительно готовые и адаптированные к заказчику решения?
GS> Ты взялся описать _алгоритм_. Он вполне может быть не привязан GS> к конкретному "железу". И то, что ты не смог внятно этот алгоритм GS> сформулировать, многое о тебе говорит... Понятно. Можно не продолжать. Выводы обо мне ты уже сделал.
GS> Hету такой "разницы". Формальный алгоритм при желании и наличии GS> навыка можно сформулировать на естественном языке. Слушай, ты такой знаток естественных языков! Может, у тебя и компилятор с естественного языка есть? И почему ты до сих пор не миллиардер?
GS> Программа пишется "для машины". Алгоритм "для человека". Hадеюсь, GS> разницу между машиной и человеком тебе объяснять не надо? Мне почти все равно на каком языке читать алгоритм. О самодокументированных программах слышал?
GS> Во-первых, _полное_ формальное описание. Которого ты не дал. Естественно. Я для этого алгоритма никогда его не писал, и ради тебя не собираюсь. Было бы готовое - выложил бы. Этот алгоритм я придумал лет 6 назад для лабораторной работы. Причем в работе требовалось вывести синус ШИМом на PC Speaker. Как именно генерить синус - без разницы. Я попробовал так. Вполне успешно. Чем и поделился.
GS> Уже бывало в этой эхе. Очень "однозначный" ответ. Ты в эту эху пишешь гораздо чаще, чем, к примеру я. Мне весь архив перерыть? Ссылку давай, ключевые слова, фразу хоть о чем шла речь. Чтобы google мог найти.
SM>> Заодно найти и критерии устойчивости алгоритма. GS> Понимаешь, в чём дело. Этим должен заниматься не я, а тот, кто GS> предложил конкретный алгоритм для решения конкретной задачи... Ты бы сам потратил на это время, чтобы использовать этот алгоритм в музыкальной игрушке? (С которой и начался этот тред) Хотя, и так понятно, что ты бы выбрал другой алгоритм. Более отработанный.
SM>> Кстати, в формуле, я ошибся, а никто, похоже, и не заметил. GS> Видимо не так всё и однозначно, как тебе казалось? ;-) С формулой как раз все однозначно. Я элементарно ошибся. А ты никогда не ошибаешься? Ежу понятно, что при увеличении "a" и "b", "x" и "y" начинают меняться быстрее, частота должна расти. В числителе они должны быть.
GS> Скажи спасибо, что хоть кто-то пытается научить новичков в GS> программировании (я не говорю о воинствующих ламерах) уму-разуму... Ну спасибо, что в ламеры не записал.
GS> Hе учись плохому. Торреса в своё время уже экскоммуницировали GS> за хамство и "наезды"... Не обольщайся. У тебя тоже награды были.
Больше часа на одно сообщение... и так поскипал половину. Ладно. Ни к чему мы не придем. Я хочу закрыть этот тред. Вот чем:
В килл-лист я принципиально не заношу никого. Но продолжать этот тред мне неинтересно.
With best regards, Serg.
Hello, Sergey!
GS>> Скажи спасибо, что хоть кто-то пытается научить новичков в GS>> программировании (я не говорю о воинствующих ламерах) уму-разуму... SM> Ну спасибо, что в ламеры не записал.
GS>> Hе учись плохому. Торреса в своё время уже экскоммуницировали за GS>> хамство и "наезды"...
Жора, хорош врать, за 13 лет в Фидо меня еще ниразу не "экскоммуницировали", зато тебе - "!" в эхах ставили пачками.
SM> Не обольщайся. У тебя тоже награды были.
Это точно - рано или поздно, Жору выгоняют на некоторое время со всех эх, до которых он может дотянуться.
With best regards, Alex Torres. E-mail: snipped-for-privacy@yahoo.com
2:461/28Hello, Aleksandr! You wrote to Sergey Mudry on Thu, 14 Oct 2004 20:30:45 +0400:
AK> Hello Sergey Mudry!
GS>>>> Скажи спасибо, что хоть кто-то пытается научить новичков в GS>>>> программировании (я не говорю о воинствующих ламерах) GS>>>> уму-разуму... SM>>> Hу спасибо, что в ламеры не записал.
GS>>>> Hе учись плохому. Торреса в своё время уже экскоммуницировали за GS>>>> хамство и "наезды"...
AT>> Жора, хорош врать, за 13 лет в Фидо меня еще ниразу не AT>> "экскоммуницировали", зато тебе - "!" в эхах ставили пачками.
AK> Для спpавки : по моим комплейнам с вышеупомянутым клиентом сие AK> случалось уже дважды. Hо, как вижу, клиент всё ещё не угомонился ... AK> ЖB}
Экскоммуникации небыло ниразу, вы видимо плохо себе представляете что это такое, а врать вы, господин выгнанный бывший здешний комодератор, ака бывший выгнанный "иерархический модератор", умеете не хуже чем Жора-хам.
SM>>> Hе обольщайся. У тебя тоже награды были.
AT>> Это точно - рано или поздно, Жору выгоняют на некоторое время со AT>> всех эх, до которых он может дотянуться.
AK> Ммм ... А кого же это не так давно с концами выпеpли из RU.MODERATOR AK> ? ЖB}}}
Дак из-за вас...
With best regards, Alex Torres. E-mail: snipped-for-privacy@yahoo.com
2:461/28ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.