воспроизвести мелодию на 90S2313

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From Russian to

Threaded View

   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> Сэмплы все равно не влезут.

 Могут и влезть. Хинт - если правильно сформировать атаку звука (она
очень короткая), послезвучание можно выдавать чуть искажённым синусом,
задавая только форму огибающей...


                                                   Георгий


Re: воспроизвести мелодию на 90S2313
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.



Re: воспроизвести мелодию на 90S2313
Hемедленно нажми на RESET, George Shepelev!



 SM>> Может быть. Hе спорю. Мне формальное описание алгоритма говорит
 SM>> больше, чем комментарии.
 GS>  О чём говорит? О том, _как_ делать. А сперва рекомендуется понять
 GS> _что_ делать. Hе раз сталкивался с ситуацией, когда массу усилий

  Всё наоборот. Комментарий это по-определению лишь пояснения к уже
сделанному.

 SM>> Если быстродействия хватает, синус я сгенерирую как-нибудь попроще.
 GS>  Во-первых, сомнительно, что в слабеньком контроллере быстродействия
 GS> хватит, во-вторых, не факт, что существенно память сэкономишь...

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



воспроизвести мелодию на 90S2313

   Kirill, ты ещё здесь сидишь?


Пятница Октябрь 01 2004 08:09, Kirill Frolov wrote to George Shepelev:

 SM>>> Может быть. Hе спорю. Мне формальное описание алгоритма говорит
 SM>>> больше, чем комментарии.
 GS>> О чём говорит? О том, _как_ делать. А сперва рекомендуется
 GS>> понять _что_ делать. Hе раз сталкивался с ситуацией, когда массу
 GS>> усилий
 KF>   Всё наоборот. Комментарий это по-определению лишь пояснения к уже
 KF> сделанному.

 Hет ;)

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



                                                   Георгий


Re: воспроизвести мелодию на 90S2313

   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> Я понимаю. Уточни хотя бы название алгоритма.

 Я просил нетмейлом.


                                                   Георгий


Re: воспроизвести мелодию на 90S2313
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.



Re: воспроизвести мелодию на 90S2313
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.



Site Timeline