40 я назвал по памяти. Сейчас посмотрел в первоисточнике, там говорится о приближениях 24, 43 или 53.
Создание логарифмически равномерной двенадцатитоновой музыкальной шкалы явилось итогом длительного развития музыки и математики. Естественно, что она не могла появиться раньше создания алгебры иррациональных величин и логарифмов, а всем этим арсеналом математических средств ученые стали свободно владеть лишь в XVII веке. А около 1700 года немецкий ученый и музыкант Андреас Веркмейстер предложил описанную здесь шкалу и изготовил фортепиано, настроенное в соответствии с ней. До того времени музыкальные инструменты настраивались по принципу чистых интервалов (квинт, терций и др.), что неизбежно приводило к затруднениям в использовании других тональностей и шероховатостям в модуляциях (переходах из одной тональности в другую) и тем ставило пределы развитию музыки. Далеко не все музыканты сразу приняли шкалу Веркмейстера; например, известный французский философ и музыкат Дидро был ее противником; он считал, что шкала без чистых интервалов не может лежать в основе музыки. Но крупнейший немецкий композитор XVIII века Иоганн Себастьян Бах делом доказал жизнеспособность новой системы; он сочинил два тома музыкальных произведений под общим названием «Хорошо темперированный клавир» (1722—1744). Каждый из этих томов содержал по 24 пьесы (прелюдии и фуги): по одной на каждую из 12 мажорных и 12 минорных тональностей. Сочинения Баха составили эпоху в развитии новой музыки; все последующие композиторы создавали свою музыку в этой системе. К настоящему времени возможности ее представляются все еще неисчерпаемыми. Искажения чистых «народных» интервалов в шкале Веркмейстера заметны только опытному уху, и наличие их с лихвой окупается свободой выбора тональностей и естественностью модуляций. В нашем веке появились предложения об увеличении числа ступеней в октаве до 24, 43 или 53 с тем, чтобы получить в пределах октавы интервалы, более близкие к чистым, и даже были изготовлены экспериментальные инструменты, но в музыкальную практику они не вошли.
Первые две подходящие дроби явно слишком грубы. Третья, k/m = 3/5 = 0,600, дает уже сравнительно небольшую ошибку, 0,015, по сравнению с интересующей нас величиной log2(3/2) = 0,585; но эта ошибка все же превосходит желательную 0,004 в четыре раза. Кроме того, если мы рассмотрим соответствующую шкалу из чисел, кратных 1/5, т.е. из чисел 1/5, 2/5, 3/5, 4/5, 1, то мы увидим, что некоторые интересующие нас числа, именно log2(5/3) = 0,727 и log2(9/8) = 0,169, лежат далеко от ее делений.
12 полутонов — не случайное число. Это наилучшее приближение к чистым интервалам. Следующее наилучшее приближение — 40 полутонов (вроде бы) — но 40 нот слишком сложно, поэтому прижились 12. В основе всего этого лежит теория дробей специального вида. Эта теория позволяет находить дроби, наиболее точно приближенные к произвольным вещественным числам. Кому интересно — есть такая тоненькая советская книга — «Устройство музыкальной шкалы».
Вы правы. Можно даже сделать просто конвертер из уже существующих форматов, и использовать уже существующие редакторы. А JavaScript превратится в промежуточное звено, типа PostScript. Ведь PostScript — полноценный язык программирования, но об этом сейчас уже почти никто не вспоминает, а используют его, как промежуточный формат.
Я имел в виду, что определить количество правильных многогранников можно следующим образом:
для наглядности считаю в градусах, а не в радианах:
Начнем с треугольных граней (угол между ребрами 60 градусов):
В вершине сходятся три равносторонних треугольника (3*60=180 < 360) — многогранник возможен (тетраэдр)
Возьмем 4 треугольника (4*60=240 < 360) — многогранник возможен (это октаэдр).
Возьмем 5 треугольников (5*60=300 <360) — многогранник возможен (это икосаэдр).
Возьмем 6 треугольников (5*60=300 = 360) — многогранник выраждается в плоскость (не возможен).
Квадратные грани (угол между ребрами 90 градусов)
Возьмем 3 квадрата — это куб (3*90 = 270 < 360).
4 квадрата (4*90 = 360) — многогранник вырождается в плоскость.
Пятиугольник — угол между ребрами 108 градусов
Возможен также только один случай (108 * 3 = 324 < 360) (додекаэдр).
Нетрудно видеть (как любят говорить математики в особо трудных местах доказательств:), что других вариантов нет.
Конечно, данные выкладки математически экивалентны приведенным в статье.
За статью спасибо — она предлагает более общий взгляд на вроде бы простые вещи.
Дурацкий вопрос дилетанта: А нельзя, просто сложить все углы при вершине? Если меньше 360 градусов то многогранник физически возможен, если нет, то невозможен?
Как заставить человека работать 24 часа в сутки, заставить забыть про друзей, любовь, красоту науки и жажду творчества? Очень просто — надо давать им время от времени почитать подобные посты, замешанные на алчности, мерящие личный успех суммой на банковском счете. Все это — очередная американская бихевиористическая чушь, очевидно кем-то вдолбленная автору на очередном бизнес-тренинге.
Думаю, что по RS-485 и подобным протоколам XML передавать слишком накладно. Но должны быть железки, потключаемые прямо по TCP/IP. У них тогда и настроечною морду можно сделать на HTTP. Что-то вроде того, как роутеры сейчас работают. Ну и полный стек Web-сервисов с XML можно организовать.
В более-менее крупной организации, имеющей промышленные здания, необходимо контролировать потребляемые энергоресурсы. На практике это выливается в десятки счетчиков (электроэнергия, газ, отопление, холодная и горячая вода, стоки). Система, о которой идет речь в этой статье, помогает главному энергетику оперативно учитывать расход энергоресурсов, не бегая при этом по подвалам.
С НОРЭМ я не сталкивался, но думаю, что модуль, подобный тому, которыя я разработал пригодился бы и в глабальных системах контроля энергоресурсов.
У Филлипа Дика есть роман (по моему, роман Убик). Начинается он с того, что вся техника (включая даже входную дверь) работала As Service. Нужно сварить кофе — плати кофеварке, нужно погладить брюки — плати утюгу. Дверь за каждое открытие и закрытие списывала со счета деньги… Жуть. Гениальный Филлип Дик еще много лет назад увидел, куда катится мир.
В целом — согласен. IDE-отладчиками тоже иногда пользуюсь, но у них есть некоторые недостатки:
— Нужен IDE.
— Не все можно посмотреть, а особенно вычислить (особенно в компилируемых средах).
— Когда происходит останов по брекпоинту, трудно сразу понять в какой именно вызов процедуры это произошло (нужно поднимать стек и прочий контекст), а если функция вызывается постоянно из многих частей программы — то выловить нужный вызов — большое искусство.
— При отладке циклов — не так то легко добраться до ошибочной итерации — приходится на брекпоинты вешать условия, и заниматься прочими танцами с бубнами.
— Бывают случаи, когда важно все выполнить в реальном времени
С другой стороны, точно и грамотно поставленные вызовы трассировки на разных уровнях формируют протокол, по которому сразу становится ясной ПОЛНАЯ картина происходящего в системе. На трассировку можно ставить условия, вызывать ее в циклах, добираться до всего до чего можно дотянуться — в общем развлекаться как хочешь. Кроме того, вся работа в отладчике после отладки исчезает, не оставляя следов. Вызовы же трассировки можно либо оставлять (заглушая саму функцию трассировки), либо комментировать. В любом случае — остаются некие результаты.
Действительно, каюсь, что всех собак спустил на прикладных программистов. Должно достаться также и системным программистам (которые проектируют операционки с нерегламентируемым временем реакции на системные вызовы) и сетевикам (проектирующим гигабайтные сети с внезапными задержками) и сайтостроителям с непредсказуемо-тормозными страницами и сервисами (в основном из-за неоптимизированных запросов к БД). Как говорится, вот дом, который построил Джек Мы.
И все-таки, думаю, вы согласитесь, что о прогресс-баре редко кто задумывается по серьезному. В инсталляторах вообще ничего специально не делают — пользуются стандартным функционалом. При сетевом обмене — не меряют скорость соединения, при вычислениях — производительность системы, при обработке файлов — считают количество файлов, но не учитывают размер, скорость чтения-записи не учитывают. Самое простое — разделить на какие-то этапы, и плюсовать в цикле, не задумываясь о реальном времени. Прогресс бар на положении Золушки. Вроде есть, чего-то делает и на том спасибо.
Отрывок из книги «Устройство музыкальной шкалы»
для наглядности считаю в градусах, а не в радианах:
Начнем с треугольных граней (угол между ребрами 60 градусов):
В вершине сходятся три равносторонних треугольника (3*60=180 < 360) — многогранник возможен (тетраэдр)
Возьмем 4 треугольника (4*60=240 < 360) — многогранник возможен (это октаэдр).
Возьмем 5 треугольников (5*60=300 <360) — многогранник возможен (это икосаэдр).
Возьмем 6 треугольников (5*60=300 = 360) — многогранник выраждается в плоскость (не возможен).
Квадратные грани (угол между ребрами 90 градусов)
Возьмем 3 квадрата — это куб (3*90 = 270 < 360).
4 квадрата (4*90 = 360) — многогранник вырождается в плоскость.
Пятиугольник — угол между ребрами 108 градусов
Возможен также только один случай (108 * 3 = 324 < 360) (додекаэдр).
Нетрудно видеть (как любят говорить математики в особо трудных местах доказательств:), что других вариантов нет.
Конечно, данные выкладки математически экивалентны приведенным в статье.
За статью спасибо — она предлагает более общий взгляд на вроде бы простые вещи.
С НОРЭМ я не сталкивался, но думаю, что модуль, подобный тому, которыя я разработал пригодился бы и в глабальных системах контроля энергоресурсов.
— Нужен IDE.
— Не все можно посмотреть, а особенно вычислить (особенно в компилируемых средах).
— Когда происходит останов по брекпоинту, трудно сразу понять в какой именно вызов процедуры это произошло (нужно поднимать стек и прочий контекст), а если функция вызывается постоянно из многих частей программы — то выловить нужный вызов — большое искусство.
— При отладке циклов — не так то легко добраться до ошибочной итерации — приходится на брекпоинты вешать условия, и заниматься прочими танцами с бубнами.
— Бывают случаи, когда важно все выполнить в реальном времени
С другой стороны, точно и грамотно поставленные вызовы трассировки на разных уровнях формируют протокол, по которому сразу становится ясной ПОЛНАЯ картина происходящего в системе. На трассировку можно ставить условия, вызывать ее в циклах, добираться до всего до чего можно дотянуться — в общем развлекаться как хочешь. Кроме того, вся работа в отладчике после отладки исчезает, не оставляя следов. Вызовы же трассировки можно либо оставлять (заглушая саму функцию трассировки), либо комментировать. В любом случае — остаются некие результаты.
Регулярно так делаю (правда не print, а trace), и не знаю, чем заменить.
ДжекМы.И все-таки, думаю, вы согласитесь, что о прогресс-баре редко кто задумывается по серьезному. В инсталляторах вообще ничего специально не делают — пользуются стандартным функционалом. При сетевом обмене — не меряют скорость соединения, при вычислениях — производительность системы, при обработке файлов — считают количество файлов, но не учитывают размер, скорость чтения-записи не учитывают. Самое простое — разделить на какие-то этапы, и плюсовать в цикле, не задумываясь о реальном времени. Прогресс бар на положении Золушки. Вроде есть, чего-то делает и на том спасибо.