Добавлю. Yamaha DX7 был очень популярен в музыке середины 80х - начала 90х. Его использовало множество профессиональных музыкантов. Также профессионалами были созданы богатые библиотеки тембров ("пресетов", "патчей") для DX7.
А поиск красивых тембров для FM-синтезатора - трудная задача, требующая развития особых навыков. Большинство музыкантов этим не занимались - не было времени, и научиться было трудно. Использовали, как правило, небольшой набор "заводских" тембров, разработанных специалистами Yamaha. Ну и еще можно было докупить картриджи с библиотеками тембров от других авторов, которые специализировались на создании тембров.
А на сегодняшний день имеются богатые коллекции патчей для DX7, которые можно скачать бесплатно. Пополнение этих библиотек продолжается энтузиастами. Так что эмуляция именно этого ретро-синтезатора дает музыканту больше всего возможностей.
Потрясающе, великолепный проект! FM-синтезатор DX7 - прародитель и старший брат знаменитых звуковых карт Adlib, Sound Blaster, а также 16-битных приставок Sega Genesis (Megadrive) и большинства аркадных машин (игровых автоматов) конца 80-х - начала 90х. Но при этом возможности DX7 в плане синтеза намного превышают возможности чипов OPL2, OPL3 и других, стоявших на звуковых картах и приставках. В звуке DX7 все еще слышится "теплое, ламповое" FM, но этот звук гораздо богаче и разнообразнее.
А как насчет достоверности эмулятора Dexed - достаточно ли точно он эмулирует звук DX7?
Я видел обзоры на ютубах, авторы сравнивали - на некоторых примерах звук существенно отличается.
В вашем случае сумма и манхэттенская метрика - это одно и то же. Разница только в том, что последняя - сумма модулей, но так как у вас нет векторов с отрицательными координатами - то сумма компонентов векторов совпадает с суммой модулей этих компонентов.
Принципиальное преимущество в том, что такая метрика, возможно, лучше отражает физическую реальность в вашей ситуации. Всегда следует использовать наиболее близкие к реальности модели.
Я просто из своих познаний о работе интерфейсов ввода-вывода (диск или ОЗУ) припоминаю, что эти интерфейсы (и сами носители информации) не являются полнодуплексными. Одновременное чтение и запись невозможны. В каждый момент времени происходит или только чтение, или только запись. Поэтому максимальная производительность устройства ввода-вывода достигается только при передаче информации в одном направлении. Попытка одновременных чтения и записи (реализованная путем быстрого чередования малых операций чтения и записи) приведет, как минимум, к уменьшению скорости обмена в каждом направлении в 2 раза.
Отсюда и идея использовать манхэттенскую метрику. Одновременное чтение 1 ед/с и запись 1 ед/с создают "расстояние от центра" (суммарную нагрузку) в 2 ед/с.
В случае RAID-5 дисков, а также SSD-накопителей также нужно учесть, что запись в них происходит намного медленнее считывания.
Спасибо. Есть еще вопросы по вашей метрике производительности.
1) Чем отличаются друг от друга N1 и N3? В описании я разницы не заметил. Возможно, вы допустили опечатку.
2) Что это за "блоки распределенной памяти", это не тот ли объем информации, который СУБД за единицу времени считывает с диска / записывает на диск? Но тогда результат ваших измерений более правильно было бы назвать "Нагрузкой на подсистему ввода-вывода", а не "Производительностью". Действительно, оптимизация БД, снижающая нагрузку на подсистему ввода-вывода (в вашем примере - введение индексов) не ухудшает, а улучшает работу БД с точки зрения пользователя.
А не будет ли логично измерять объем информации, принятый или переданный клиентам в ответ на их запросы за единицу времени? Или количество запросов, обслуженных за единицу времени? Или некоторую взвешенную сумму приведенных выше величин?
3) Почему вы вычисляете именно модуль вектора (N1,N2,N3) и как определен у вас этот "модуль"? Это именно модуль в Евклидовом пространстве = sqrt(N1^2+N2^2+N3^2) или что-то иное?
Если вы решили использовать Евклидову метрику - то она только тогда дает хорошие результаты, когда компоненты вектора взаимно перпендикулярны, т.е. ортогональны, т.е. не влияют друг на друга. Но я боюсь, что в вашей СУБД, скорее всего, присутствует взаимное влияние чтения и записи. Если вы измерите максимально достижимые скорости чтения и записи по отдельности, а потом одновременно - то вряд ли окажется, что чтение и запись можно вести одновременно на максимальной скорости. Или в вашей системе можно?
Если предположить, что максимальная скорость одновременных чтения/записи равна половине максимальной скорости чтения или записи по отдельности - тогда более подходящей будет не Евклидова, а Манхэттенская метрика для модуля векторов.
Спасибо за разъяснение. В приведенных в вашем комментарии графиках слишком мало данных - трудно увидеть на глаз какие-либо определенные закономерности. На первом графике несколько выпадающих точек, но какой закономерности они подчиняются, непонятно. На втором графике выпадающие точки как будто образуют линию. На третьем - опять непонятно.
А как у вас вообще определяется понятие "Производительность" и как проводится ее измерение?
Просто на правах абстрактного размышления. Вот вы получили из измерений какие-то данные. Например, измерили температуру всех пациентов в больнице. Если просто усреднить (средним или медианой) эти данные - то получите среднюю температуру по больнице - величину весьма бесполезную. Но если видно, что данные измерений имеют тенденцию кучковаться около нескольких "центров притяжения" - иными словами, образовывать кластеры - то есть смысл эти кластеры разделить.
Как правило, образованию кластеров способствуют изменения параметров наблюдаемого процесса. В случае больницы - тип заболевания. Если этот тип заранее известен (диагноз поставлен) - то можно измеренные температуры группировать в соответствии с диагнозом. Скорее всего, в каждой из групп после такого разделения больше не будет наблюдаться кластеризация.
Если же диагноз заранее неизвестен (например, ставится задача поставить диагноз по измеренной температуре) - то можно применить методы кластерного анализа для автоматического выявления кластеров и их разделения.
После анализа разделенных данных результаты всегда можно, если требуется, снова объединить. Например, если начальство интересует только средний процент выздоровления пациентов независимо от того, чем они болели. Но анализ разделенных данных обычно дает больше информации.
Особенно, если причины образования кластеров заранее неизвестны - то в ходе дальнейшего анализа данных и их исследования может появиться возможность выяснить эти причины и изучить их более подробно.
Здравствуйте. Я пришел сюда по ссылке из вашего предыдущего поста. Вопрос по графикам из раздела "Пример из жизни". На графиках исходных данных Эксперимента 1 видно как будто 2 кривых. Это что, данные одного и того же временного ряда имеют тенденцию группироваться так, как будто на графике две кривых? Для Эксперимента 2 происходит то же самое.
Если это данные одного временного ряда группируются в 2 явно выраженных кластера - то наилучшим подходом, на мой взгляд, было бы их сначала разделить на принадлежность к первому или второму кластеру, а потом обрабатывать по отдельности. Визуально, разделение возможно безошибочное: можно провести одну прямую, разделяющую формирующиеся на графиках кластеры.
Возможно, по теме "Кластерный анализ" найдутся подходящие методы.
Может ли быть такое, что на вашу БД приходит 2 разных вида запросов, и обработка одного вида длится стабильно дольше (или вызывает бОльшую нагрузку), чем второго? В таком случае имеет смысл при сборе исходных данных собирать не только данные по нагрузке, но и данные по поступающим видам запросов и впоследствии группировать данные измерений в соответствии с этим. Тогда не понадобится кластерный анализ. Ведь помимо сложностей с тем, чтобы с ним разобраться и наладить, всегда существует риск, что на некоторых видах исходных данных он выдаст неверные результаты.
Первый вопрос: какая ожидается зависимость, линейная или нелинейная?
Если линейная - то достаточно провести 2 измерения, с двумя разными значениями исследуемого параметра. Разделить изменение результата (delta Y) на изменение исследуемого параметра (delta X) - получится коэффициент пропорциональности.
Если зависимость нелинейная - то нужно провести измерения для нескольких значений параметра и построить график зависимости. По горизонтали - значение параметра; по вертикали - производительность. И дальше смотреть и думать, что наблюдается на графике и какой функцией можно пытаться это моделировать.
Я так подозреваю, что либо исследуемый параметр нельзя увеличивать до бесконечности и тем самым добиваться бесконечного роста производительности, так? Либо, начиная с некоторого значения, дальнейшее увеличение параметра не приводит к росту производительности. В последнем случае зависимость должна быть нелинейной. Впрочем, на начальном своем участке ее, вероятно, можно приближенно считать линейной.
Поэтому оценки на глаз очень не хотелось бы использовать... Еще бы обосновать критерий отброса данных
На начальном этапе можно отбрасывать как угодно, по душевному наитию. Потом, когда прояснится, насколько это помогает обработке данных; из-за чего часть данных приходится отбрасывать - тогда уже придумать и обосновать какой-нибудь критерий. При необходимости - провести измерения заново и выполнить анализ на чистовую, с соблюдением канонов статистической обработки данных, исключающих субъективность результатов.
Данные округляются, например, при расчете медианы
В приведенном заголовке функции я округления не заметил. Там на входе и выходе значения в double precision, если я правильно понял. Но могут быть округлены входные данные для этой функции, либо же в ходе вычислений применяется какое-нибудь явное округление.
Предлагаю проверить, как формируются входные данные до медианного сглаживания. Как они рассчитываются? Может ли так быть, что входные данные в ходе вычислений грубо округляются? Или по каким-то другим причинам принимают только значения из небольшого дискретного множества?
Ну, результаты неплохие. Тренда почти не осталось.
Видно, что разность всегда больше нуля, даже при своих минимальных значениях. Думаю, что если применить любой из критериев сравнения (Стьюдента или Вилкоксона) - то будет получен явно положительный результат, подтверждающий влияние исследуемого параметра на данные. Но при таких явных результатах применять какие-то критерии излишне. Разве только для отчета.
Как показывает мой опыт: статистика - это последняя надежда, которая может что-то спасти в ситуации, когда данные настолько плохие, что результат их анализа неочевиден и весьма сомнителен.
Вот если бы разность колебалась около нуля - тогда было бы непонятно, влияет ли исследуемый параметр на результаты. Тогда и нужно было бы применять все эти критерии Стьюдента. И тогда распределение входных данных играло бы существенную роль. Думаю, если составить выборку из данных приведенного вами графика - то нормального распределения не получилось бы. Также явно присутствует, хоть и небольшой, но тренд. И колебания - признак наличия в данных автокорреляции во времени. С этим всем пришлось бы бороться. Возможно, применение критерия Вилкоксона (который не требует нормального распределения) позволило бы отложить эти проблемы на время. Но все равно этот критерий требует некоррелированности данных и отсутствия тренда, так что в спорных случаях к этому вопросу пришлось бы вернуться.
Что значит обрезать? Почему обрезать 100, а не 150? Как решать - какие данные обрезать и сколько?
Мы в данный момент находимся на этапе качественного анализа данных. Смотрим, как вообще выглядят графики, что в них видно невооруженным глазом, а что требует каких-то тонких методов анализа; подчиняются ли данные каким-либо закономерностям.
На этом этапе допустимо принимать произвольные решения по отбрасыванию кусков данных без строгого обоснования. Решения принимаются чисто интуитивно, на основе прошлого опыта. Просто попробовать: если выбросить "некрасивые" данные - поможет ли это в деле обработки оставшихся "красивых"?
Если поможет - то потом уже думать об обосновании. Например, там могла быть экстремальная нагрузка из-за землетрясения на Банановых островах. Или переходный процесс при старте системы. Оптимизировать и повторить опыт в надежде, что там не будет "некрасивых" данных. Ну, а если отбрасывание данных не поможет - то вернуть все назад и думать дальше.
"Округление не проводится" - где-то проводится, иначе не было бы тенденции к формированию горизонтальных линий на графике. Возможно, это исходные (несглаженные) данные округляются. А медианное сглаживание не дает на выходе значений, которых не было в исходных данных. Вот и получаются ступени на графике. Можно проверить, как формируются исходные данные. Нет ли там излишних округлений? Или использовать для сглаживания скользящее среднее, а не медиану. Там на выходе будут промежуточные значения.
Да, медиана является робастной, а скользящее среднее - нет. Но как и за все в этом мире, за робастность надо платить. В частности: медианное сглаживание является нелинейной операцией, ее сложнее математически моделировать. Более высокая вычислительная сложность. Остаточная дисперсия после медианного сглаживания будет выше, чем после скользящего среднего. Ну и то, что мы наблюдаем в ваших графиках: если исходные данные принимали только значения из небольшого дискретного множества - то только такие останутся и после медианы; сглаживания до промежуточных значений не будет.
Я практикую подход, что для использования каких-то особых методов (вроде медианного сглаживания, или критерия Вилкоксона) нужны обоснования. Например: наличие явных выбросов в данных, которые сильно портят результаты на скользящем среднем. И только тогда использую робастные методы, когда в них есть необходимость.
Я работаю в другой области знаний, и поэтому многие вещи, очевидные для СУБДшника, для меня неочевидны. Отвечаю вам лишь в рамках своих скромных познаний общей теории обработки данных и статистики. Так что прошу простить, если где-то что-то очевидное для вас не усмотрел.
По вашим сглаженным данным: что есть горизонтальная ось? Это время? Если так, то очевидно наличие тренда в ваших данных. Этот тренд, особенно на рис. 1, существенно нелинейный. Моделировать его линейной функцией вряд ли поможет. А найти другую подходящую функцию - трудная задача, мне навскидку никаких простых моделей не пришло на ум. Лучше пойти другим путем.
Если опыты 1) и 2) проводились в одно и то же время суток - то можно вычесть второй график из первого. Если предположить, что суточные колебания одинаково действовали на результат в случаях 1) и 2) - то их разность не должна иметь ярко выраженного тренда. Если так, то ее можно будет прямо использовать для критерия Стьюдента с одной выборкой и проверять статистическую гипотезу о том, что среднее значение этой выборки равно нулю.
Судя по рисункам, до горизонтальной отметки 100 возможно наличие остаточного тренда в разности. Этот участок можно просто обрезать, если остальная часть данных будет в порядке.
Что мне еще бросилось в глаза на ваших рисунках - точки имеют тенденцию собираться в горизонтальные линии. Это обычно означает, что данные в ходе расчетов чрезмерно округляются, загрубляются. Рекомендую проверить и убрать это округление - иначе оно внесет дополнительную погрешность в результаты анализа.
Если вы берете как элементы выборки (для критерия Стьюдента) усредненные данные за 1 час - то для устранения влияния суточных колебаний вся выборка (из 10 значений) должна содержать только элементы, полученные от измерений в одно и то же время суток. Скажем, 18:00-19:00. Туда нельзя брать результаты, полученные между 2:00 и 3:00, потому что они будут существенно смещены из-за суточных колебаний. Поэтому для одной выборки из 10 элементов вам понадобятся результаты измерений за 10 дней (между 18:00 и 19:00 каждого дня). И даже в этом случае сохраняется опасность влияния недельных или месячных колебаний нагрузки.
Дело в том, что статистические методы сравнения (типа критериев Стьюдента или Вилкоксона) исходят из предположения о стационарности данных в пределах каждой выборки, и отсутствия в них автокорреляции. Суточные, недельные и прочие колебания это предположение нарушают, что приводит к существенным искажениям результатов статистических тестов.
У вас на сглаженных графиках наблюдаются суточные колебания? Может быть, я зря бью тревогу. Но я бы ожидал, что они там есть.
Суточные колебания и прочие медленные изменения случайной величины называют трендом. Наличие в данных тренда убивает многие статистические методы. Поэтому важно обеспечить отсутствие тренда.
Первый метод я предложил выше - если тренд периодический, то берем данные только в один и тот же момент периода.
Еще можно пытаться уменьшить время сбора данных так, чтобы влияние тренда за это время было несущественным. Это я имел в виду, предлагая уменьшить время усреднения или количество данных в выборке. Данный способ - самый экономный в плане времени сбора данных.
И третий способ - это пытаться смоделировать тренд в виде некоторой функции с неизвестными параметрами, которые определяются из данных. А потом вычесть смоделированный тренд из данных. Широко распространены методы моделирования линейного тренда - то есть линейной функции. Оценивается 2 параметра - угловой коэффициент и свободный член. В вашем случае можно моделировать тренд в виде какой-нибудь периодической функции, например, синуса.
Да, вы правильно поняли. Попробуйте предложенный метод.
Только осторожно. Если у вас результаты усредняются за 1 час, и для выборки берется 10 подряд идущих часов - то (периодические) суточные колебания нагрузки приведут к существенной нестационарности временного ряда и, как следствие - предположение о нормальном распределении данных в выборке из 10 значений будет нарушено.
Берите тогда в одну выборку или среднее за 1 час в одно и то же время суток (если, конечно, у вас есть достаточно данных измерений), или уменьшайте время усреднения с 1 часа до 30-10 минут (пока это сильно не нарушит нормальность распределения), или уменьшайте количество данных в выборке с 10 до 5-4.
В общем, надо что-то делать с этими суточными колебаниями. Варианта 3. Или брать в одну выборку только результаты, полученные в одно и то же время суток. Или пытаться уменьшить время получения выборки, чтобы суточные колебания не успели оказать влияние. Или применять методы удаления суточного тренда.
Почему-то у меня не работает функция "Paste", не могу цитировать ваше сообщение, поэтому кратко.
Если влияние внешних факторов "случайно, неуправляемо и непрогнозируемо" - прекрасно. Это именно то, с чем статистика и работает.
Предлагаю следующий план работ. Настраиваете параметры вашей системы, запускаете ее в реальных условиях. Даете некоторое время на релаксацию переходных процессов при старте (скажем, 10 мин). Потом собираете данные за некоторый период времени, скажем, 1 минуту. Без какой-либо предварительной обработки и отсеивания, просто вычисляете среднее за 1 минуту.
Сколько измерений за 1 минуту у вас проводится? Допустим, 60. А среднее - это сумма 60 значений, деленная на 60. Деление на константу распределения случайной величины не изменяет. А вот сумма - с большой точностью приводит любое произвольное исходное распределение к нормальному в соответствии с Центральной предельной теоремой.
Таким образом, усредненные за 1 минуту результаты будут почти наверняка распределены нормально. Если 1 минуты для этого недостаточно - возьмите 10 минут и более.
Накопите несколько (скажем, 10) таких усредненных результатов. Это будет первая выборка A. Потом повторите эксперимент при другом значении исследуемого параметра - получите выборку B. К ним уже применим критерий Стьюдента для сравнения.
По вопросу: "какая информация может быть получена из несглаженных значений" - это надо лезть глубоко в теорию. Всякая там автокорреляция, спектр. Кратко могу заметить, что усреднение и прочее сглаживание - это необратимые операции, ведущие к потере информации. Этого может как раз не доставать последующему статистическому анализу. Еще, например, сильная корреляция во времени, к которой обычно приводит сглаживание, может исказить результаты многих статистических методов (того же критерия Стьюдента), которые предполагают отсутствие автокорреляции в данных.
Сначала вы пишете, что предполагаете распределение показаний нормальным. Потом вы обрабатываете данные, пытаясь установить, является ли распределение нормальным, и далее действуете с учетом этого.
В статистике обычно так не делают. Там или предполагают, что данные распределены нормально, и далее опираются на это (что может, в случае неверности предположения о нормальности данных, повлиять на достоверность получаемых результатов). Или предполагают, что распределение данных не является нормальным и далее действуют с учетом этого. Еще могут считать распределение неизвестным, и пытаться статистически доказать, нормальное оно или нет.
Далее, вы выбираете одно число как "результат эксперимента", и хотите его проверить на (статистически значимое) равенство или неравенство с другим полученным так же числом. Статистика не может работать с отдельными числами. Ей нужна выборка из большего количества данных, чтобы оценить в этой выборке случайную погрешность.
А так, данные, полученные из опытов, где есть хоть какие-нибудь случайные погрешности, почти всегда (с вероятностью 1) будут не равны между собой. Даже если эксперимент был повторен в полностью идентичных условиях.
Теперь предложения.
Во-первых, я предлагаю отказаться от сглаживания данных. Статистические методы могут извлечь максимум информации именно из несглаженных данных.
Во-вторых, для начала попробовать простые методы, типа t-теста (критерий Стьюдента) на предмет равенства или неравенства среднего по двум выборкам данных. А именно: вы собираете несколько измерений, когда ваш параметр имел одно значение; и еще несколько, когда параметр имел другое значение. Это будут две ваши выборки. Применяете к ним тест Стьюдента, смотрите на результаты. Позволяет оценить, влияет ли ваш параметр вообще хоть как-нибудь на поведение вашей системы.
Если вы считаете, что распределение данных в выборках сильно отличается от нормального (что искажает результаты t-теста), то можете попробовать критерий Уилкоксона, который имеет несколько меньшую "чувствительность", но работает с любыми распределениями исходных данных, а не только нормальными.
Если выяснится, что ваш параметр статистически значимо влияет на результаты измерений - тогда можно будет пытаться найти коэффициент пропорциональности (с помощью регрессионного анализа) и другие тонкости.
Интересный, хороший проект. И в перспективе можно добавлять туда новые функции, ресурсов микроконтроллера более чем достаточно.
Меня только очень оттолкнула эта броская картинка "Гаечки" на заднем плане. Как оттолкнула бы любая другая броская картинка человека, котика или другого объекта, не имеющего отношения к функционалу прибора. Даже если бы там красивое фото какой-нибудь печатной платы было изображено - не нужно это. Такие картинки - как рекламные баннеры, привлекают к себе внимание и заставляют напрягать мозг для того, чтобы не пялиться на них, а использовать прибор по прямому назначению.
К сожалению, ввод новых стандартов C и C++ не решает проблем, стоящих перед программистами на практике.
На практике, к примеру, у нас на фирме пишется портируемый код на Си. Который предназначен для исполнения на 32-битных микроконтроллерах (несколько архитектур, не только ARM); на Линуксе (в режиме ядра и пользователя) и на Windows (32- и 64-бит).
Ладно, я давно отказался от идеи использовать "новые" стандарты Си, такие как C17 или C11. Остановился на C99 - вроде бы, прошло уже достаточно лет с момента его выпуска, чтобы этот стандарт поддерживался всеми компиляторами для наших целевых платформ. Так и было какое-то время. arm-gcc, Native GCC, MinGW-GCC компилировали код без проблем.
Но недавно возникло два крупных разочарования. 1) MSVC. Нам понадобилось использовать этот компилятор в одном из проектов. А он не поддерживает C99! Нет поддержки комплексных чисел (была важна для проекта). 2) Режим ядра в Линуксе - там обязательно использование C89 для версии ядра 4.x.
В итоге даже 24-летней давности C99 оказалось невозможным использовать.
Сейчас введут какой-нибудь новый C++24, C24 - но боюсь, что и через 20 лет на нем не будет возможно писать реально портируемый код, который поддерживается основной массой компиляторов.
Люди ценят эмпатию не за форму (что кто-то рядом высказывает слова сопереживания или ругается). А за то, что рядом живой человек находится в той же лодке; страдает так же, как ты, и тратит на это драгоценное и невосполнимое время своей жизни.
Сколько было недавно этих озарений на тему: "А давайте спросим у пользователя, понравилось ли ему! А давайте спросим его мнение о нашем продукте! А давайте скажем ему, что его мнение очень важно для нас!" Да, поначалу люди на это велись. Пока не обнаружили, что интерес их мнением - показной. Что на самом деле никто их мнением не интересуется. И оставлять отзывы и участвовать во всевозможных опросах - напрасная трата времени в лучшем случае. Фраза: "Ваше мнение очень важно для нас" и вовсе стала издевательской.
Так и здесь. Как только я пойму, что "сопереживает" и "грустит" со мной не живой человек, сидящий рядом (а в этом нетрудно убедиться, осмотревшись вокруг!), а скрипт, совершенно обстоятельствами не затронутый; время своей жизни не тратящий, а просто желающий ко мне подлизаться - то кроме отвращения к такому "помощнику", других чувств к нему испытывать не буду.
В самом деле, что мы испытываем к окружающим, которые кривят душой в своих изображаемых эмоциях? Которые нам фальшиво сопереживают или фальшиво радуются вместе с нами?
Добавлю. Yamaha DX7 был очень популярен в музыке середины 80х - начала 90х. Его использовало множество профессиональных музыкантов. Также профессионалами были созданы богатые библиотеки тембров ("пресетов", "патчей") для DX7.
А поиск красивых тембров для FM-синтезатора - трудная задача, требующая развития особых навыков. Большинство музыкантов этим не занимались - не было времени, и научиться было трудно. Использовали, как правило, небольшой набор "заводских" тембров, разработанных специалистами Yamaha. Ну и еще можно было докупить картриджи с библиотеками тембров от других авторов, которые специализировались на создании тембров.
А на сегодняшний день имеются богатые коллекции патчей для DX7, которые можно скачать бесплатно. Пополнение этих библиотек продолжается энтузиастами. Так что эмуляция именно этого ретро-синтезатора дает музыканту больше всего возможностей.
Потрясающе, великолепный проект! FM-синтезатор DX7 - прародитель и старший брат знаменитых звуковых карт Adlib, Sound Blaster, а также 16-битных приставок Sega Genesis (Megadrive) и большинства аркадных машин (игровых автоматов) конца 80-х - начала 90х. Но при этом возможности DX7 в плане синтеза намного превышают возможности чипов OPL2, OPL3 и других, стоявших на звуковых картах и приставках. В звуке DX7 все еще слышится "теплое, ламповое" FM, но этот звук гораздо богаче и разнообразнее.
А как насчет достоверности эмулятора Dexed - достаточно ли точно он эмулирует звук DX7?
Я видел обзоры на ютубах, авторы сравнивали - на некоторых примерах звук существенно отличается.
В вашем случае сумма и манхэттенская метрика - это одно и то же. Разница только в том, что последняя - сумма модулей, но так как у вас нет векторов с отрицательными координатами - то сумма компонентов векторов совпадает с суммой модулей этих компонентов.
Принципиальное преимущество в том, что такая метрика, возможно, лучше отражает физическую реальность в вашей ситуации. Всегда следует использовать наиболее близкие к реальности модели.
Я просто из своих познаний о работе интерфейсов ввода-вывода (диск или ОЗУ) припоминаю, что эти интерфейсы (и сами носители информации) не являются полнодуплексными. Одновременное чтение и запись невозможны. В каждый момент времени происходит или только чтение, или только запись. Поэтому максимальная производительность устройства ввода-вывода достигается только при передаче информации в одном направлении. Попытка одновременных чтения и записи (реализованная путем быстрого чередования малых операций чтения и записи) приведет, как минимум, к уменьшению скорости обмена в каждом направлении в 2 раза.
Отсюда и идея использовать манхэттенскую метрику. Одновременное чтение 1 ед/с и запись 1 ед/с создают "расстояние от центра" (суммарную нагрузку) в 2 ед/с.
В случае RAID-5 дисков, а также SSD-накопителей также нужно учесть, что запись в них происходит намного медленнее считывания.
А у вас есть возможность симулировать нагрузку на СУБД? Генерировать с помощью скрипта запросы "от клиентов"?
Спасибо. Есть еще вопросы по вашей метрике производительности.
1) Чем отличаются друг от друга N1 и N3? В описании я разницы не заметил. Возможно, вы допустили опечатку.
2) Что это за "блоки распределенной памяти", это не тот ли объем информации, который СУБД за единицу времени считывает с диска / записывает на диск? Но тогда результат ваших измерений более правильно было бы назвать "Нагрузкой на подсистему ввода-вывода", а не "Производительностью". Действительно, оптимизация БД, снижающая нагрузку на подсистему ввода-вывода (в вашем примере - введение индексов) не ухудшает, а улучшает работу БД с точки зрения пользователя.
А не будет ли логично измерять объем информации, принятый или переданный клиентам в ответ на их запросы за единицу времени? Или количество запросов, обслуженных за единицу времени? Или некоторую взвешенную сумму приведенных выше величин?
3) Почему вы вычисляете именно модуль вектора (N1,N2,N3) и как определен у вас этот "модуль"? Это именно модуль в Евклидовом пространстве = sqrt(N1^2+N2^2+N3^2) или что-то иное?
Если вы решили использовать Евклидову метрику - то она только тогда дает хорошие результаты, когда компоненты вектора взаимно перпендикулярны, т.е. ортогональны, т.е. не влияют друг на друга. Но я боюсь, что в вашей СУБД, скорее всего, присутствует взаимное влияние чтения и записи. Если вы измерите максимально достижимые скорости чтения и записи по отдельности, а потом одновременно - то вряд ли окажется, что чтение и запись можно вести одновременно на максимальной скорости. Или в вашей системе можно?
Если предположить, что максимальная скорость одновременных чтения/записи равна половине максимальной скорости чтения или записи по отдельности - тогда более подходящей будет не Евклидова, а Манхэттенская метрика для модуля векторов.
Спасибо за разъяснение. В приведенных в вашем комментарии графиках слишком мало данных - трудно увидеть на глаз какие-либо определенные закономерности. На первом графике несколько выпадающих точек, но какой закономерности они подчиняются, непонятно. На втором графике выпадающие точки как будто образуют линию. На третьем - опять непонятно.
А как у вас вообще определяется понятие "Производительность" и как проводится ее измерение?
Просто на правах абстрактного размышления. Вот вы получили из измерений какие-то данные. Например, измерили температуру всех пациентов в больнице. Если просто усреднить (средним или медианой) эти данные - то получите среднюю температуру по больнице - величину весьма бесполезную. Но если видно, что данные измерений имеют тенденцию кучковаться около нескольких "центров притяжения" - иными словами, образовывать кластеры - то есть смысл эти кластеры разделить.
Как правило, образованию кластеров способствуют изменения параметров наблюдаемого процесса. В случае больницы - тип заболевания. Если этот тип заранее известен (диагноз поставлен) - то можно измеренные температуры группировать в соответствии с диагнозом. Скорее всего, в каждой из групп после такого разделения больше не будет наблюдаться кластеризация.
Если же диагноз заранее неизвестен (например, ставится задача поставить диагноз по измеренной температуре) - то можно применить методы кластерного анализа для автоматического выявления кластеров и их разделения.
После анализа разделенных данных результаты всегда можно, если требуется, снова объединить. Например, если начальство интересует только средний процент выздоровления пациентов независимо от того, чем они болели. Но анализ разделенных данных обычно дает больше информации.
Особенно, если причины образования кластеров заранее неизвестны - то в ходе дальнейшего анализа данных и их исследования может появиться возможность выяснить эти причины и изучить их более подробно.
Здравствуйте. Я пришел сюда по ссылке из вашего предыдущего поста. Вопрос по графикам из раздела "Пример из жизни". На графиках исходных данных Эксперимента 1 видно как будто 2 кривых. Это что, данные одного и того же временного ряда имеют тенденцию группироваться так, как будто на графике две кривых? Для Эксперимента 2 происходит то же самое.
Если это данные одного временного ряда группируются в 2 явно выраженных кластера - то наилучшим подходом, на мой взгляд, было бы их сначала разделить на принадлежность к первому или второму кластеру, а потом обрабатывать по отдельности. Визуально, разделение возможно безошибочное: можно провести одну прямую, разделяющую формирующиеся на графиках кластеры.
Возможно, по теме "Кластерный анализ" найдутся подходящие методы.
Может ли быть такое, что на вашу БД приходит 2 разных вида запросов, и обработка одного вида длится стабильно дольше (или вызывает бОльшую нагрузку), чем второго? В таком случае имеет смысл при сборе исходных данных собирать не только данные по нагрузке, но и данные по поступающим видам запросов и впоследствии группировать данные измерений в соответствии с этим. Тогда не понадобится кластерный анализ. Ведь помимо сложностей с тем, чтобы с ним разобраться и наладить, всегда существует риск, что на некоторых видах исходных данных он выдаст неверные результаты.
В английской терминологии это называется "Two-sample Student's t-test". А в русской разве иначе?
Ок, задача ясна.
Первый вопрос: какая ожидается зависимость, линейная или нелинейная?
Если линейная - то достаточно провести 2 измерения, с двумя разными значениями исследуемого параметра. Разделить изменение результата (delta Y) на изменение исследуемого параметра (delta X) - получится коэффициент пропорциональности.
Если зависимость нелинейная - то нужно провести измерения для нескольких значений параметра и построить график зависимости. По горизонтали - значение параметра; по вертикали - производительность. И дальше смотреть и думать, что наблюдается на графике и какой функцией можно пытаться это моделировать.
Я так подозреваю, что либо исследуемый параметр нельзя увеличивать до бесконечности и тем самым добиваться бесконечного роста производительности, так? Либо, начиная с некоторого значения, дальнейшее увеличение параметра не приводит к росту производительности. В последнем случае зависимость должна быть нелинейной. Впрочем, на начальном своем участке ее, вероятно, можно приближенно считать линейной.
На начальном этапе можно отбрасывать как угодно, по душевному наитию. Потом, когда прояснится, насколько это помогает обработке данных; из-за чего часть данных приходится отбрасывать - тогда уже придумать и обосновать какой-нибудь критерий. При необходимости - провести измерения заново и выполнить анализ на чистовую, с соблюдением канонов статистической обработки данных, исключающих субъективность результатов.
В приведенном заголовке функции я округления не заметил. Там на входе и выходе значения в double precision, если я правильно понял. Но могут быть округлены входные данные для этой функции, либо же в ходе вычислений применяется какое-нибудь явное округление.
Предлагаю проверить, как формируются входные данные до медианного сглаживания. Как они рассчитываются? Может ли так быть, что входные данные в ходе вычислений грубо округляются? Или по каким-то другим причинам принимают только значения из небольшого дискретного множества?
Ну, результаты неплохие. Тренда почти не осталось.
Видно, что разность всегда больше нуля, даже при своих минимальных значениях. Думаю, что если применить любой из критериев сравнения (Стьюдента или Вилкоксона) - то будет получен явно положительный результат, подтверждающий влияние исследуемого параметра на данные. Но при таких явных результатах применять какие-то критерии излишне. Разве только для отчета.
Как показывает мой опыт: статистика - это последняя надежда, которая может что-то спасти в ситуации, когда данные настолько плохие, что результат их анализа неочевиден и весьма сомнителен.
Вот если бы разность колебалась около нуля - тогда было бы непонятно, влияет ли исследуемый параметр на результаты. Тогда и нужно было бы применять все эти критерии Стьюдента. И тогда распределение входных данных играло бы существенную роль. Думаю, если составить выборку из данных приведенного вами графика - то нормального распределения не получилось бы. Также явно присутствует, хоть и небольшой, но тренд. И колебания - признак наличия в данных автокорреляции во времени. С этим всем пришлось бы бороться. Возможно, применение критерия Вилкоксона (который не требует нормального распределения) позволило бы отложить эти проблемы на время. Но все равно этот критерий требует некоррелированности данных и отсутствия тренда, так что в спорных случаях к этому вопросу пришлось бы вернуться.
Мы в данный момент находимся на этапе качественного анализа данных. Смотрим, как вообще выглядят графики, что в них видно невооруженным глазом, а что требует каких-то тонких методов анализа; подчиняются ли данные каким-либо закономерностям.
На этом этапе допустимо принимать произвольные решения по отбрасыванию кусков данных без строгого обоснования. Решения принимаются чисто интуитивно, на основе прошлого опыта. Просто попробовать: если выбросить "некрасивые" данные - поможет ли это в деле обработки оставшихся "красивых"?
Если поможет - то потом уже думать об обосновании. Например, там могла быть экстремальная нагрузка из-за землетрясения на Банановых островах. Или переходный процесс при старте системы. Оптимизировать и повторить опыт в надежде, что там не будет "некрасивых" данных. Ну, а если отбрасывание данных не поможет - то вернуть все назад и думать дальше.
"Округление не проводится" - где-то проводится, иначе не было бы тенденции к формированию горизонтальных линий на графике. Возможно, это исходные (несглаженные) данные округляются. А медианное сглаживание не дает на выходе значений, которых не было в исходных данных. Вот и получаются ступени на графике. Можно проверить, как формируются исходные данные. Нет ли там излишних округлений? Или использовать для сглаживания скользящее среднее, а не медиану. Там на выходе будут промежуточные значения.
Да, медиана является робастной, а скользящее среднее - нет. Но как и за все в этом мире, за робастность надо платить. В частности: медианное сглаживание является нелинейной операцией, ее сложнее математически моделировать. Более высокая вычислительная сложность. Остаточная дисперсия после медианного сглаживания будет выше, чем после скользящего среднего. Ну и то, что мы наблюдаем в ваших графиках: если исходные данные принимали только значения из небольшого дискретного множества - то только такие останутся и после медианы; сглаживания до промежуточных значений не будет.
Я практикую подход, что для использования каких-то особых методов (вроде медианного сглаживания, или критерия Вилкоксона) нужны обоснования. Например: наличие явных выбросов в данных, которые сильно портят результаты на скользящем среднем. И только тогда использую робастные методы, когда в них есть необходимость.
Я работаю в другой области знаний, и поэтому многие вещи, очевидные для СУБДшника, для меня неочевидны. Отвечаю вам лишь в рамках своих скромных познаний общей теории обработки данных и статистики. Так что прошу простить, если где-то что-то очевидное для вас не усмотрел.
По вашим сглаженным данным: что есть горизонтальная ось? Это время? Если так, то очевидно наличие тренда в ваших данных. Этот тренд, особенно на рис. 1, существенно нелинейный. Моделировать его линейной функцией вряд ли поможет. А найти другую подходящую функцию - трудная задача, мне навскидку никаких простых моделей не пришло на ум. Лучше пойти другим путем.
Если опыты 1) и 2) проводились в одно и то же время суток - то можно вычесть второй график из первого. Если предположить, что суточные колебания одинаково действовали на результат в случаях 1) и 2) - то их разность не должна иметь ярко выраженного тренда. Если так, то ее можно будет прямо использовать для критерия Стьюдента с одной выборкой и проверять статистическую гипотезу о том, что среднее значение этой выборки равно нулю.
Судя по рисункам, до горизонтальной отметки 100 возможно наличие остаточного тренда в разности. Этот участок можно просто обрезать, если остальная часть данных будет в порядке.
Что мне еще бросилось в глаза на ваших рисунках - точки имеют тенденцию собираться в горизонтальные линии. Это обычно означает, что данные в ходе расчетов чрезмерно округляются, загрубляются. Рекомендую проверить и убрать это округление - иначе оно внесет дополнительную погрешность в результаты анализа.
Возможно, вы неправильно меня поняли.
Если вы берете как элементы выборки (для критерия Стьюдента) усредненные данные за 1 час - то для устранения влияния суточных колебаний вся выборка (из 10 значений) должна содержать только элементы, полученные от измерений в одно и то же время суток. Скажем, 18:00-19:00. Туда нельзя брать результаты, полученные между 2:00 и 3:00, потому что они будут существенно смещены из-за суточных колебаний. Поэтому для одной выборки из 10 элементов вам понадобятся результаты измерений за 10 дней (между 18:00 и 19:00 каждого дня). И даже в этом случае сохраняется опасность влияния недельных или месячных колебаний нагрузки.
Дело в том, что статистические методы сравнения (типа критериев Стьюдента или Вилкоксона) исходят из предположения о стационарности данных в пределах каждой выборки, и отсутствия в них автокорреляции. Суточные, недельные и прочие колебания это предположение нарушают, что приводит к существенным искажениям результатов статистических тестов.
У вас на сглаженных графиках наблюдаются суточные колебания? Может быть, я зря бью тревогу. Но я бы ожидал, что они там есть.
Суточные колебания и прочие медленные изменения случайной величины называют трендом. Наличие в данных тренда убивает многие статистические методы. Поэтому важно обеспечить отсутствие тренда.
Первый метод я предложил выше - если тренд периодический, то берем данные только в один и тот же момент периода.
Еще можно пытаться уменьшить время сбора данных так, чтобы влияние тренда за это время было несущественным. Это я имел в виду, предлагая уменьшить время усреднения или количество данных в выборке. Данный способ - самый экономный в плане времени сбора данных.
И третий способ - это пытаться смоделировать тренд в виде некоторой функции с неизвестными параметрами, которые определяются из данных. А потом вычесть смоделированный тренд из данных. Широко распространены методы моделирования линейного тренда - то есть линейной функции. Оценивается 2 параметра - угловой коэффициент и свободный член. В вашем случае можно моделировать тренд в виде какой-нибудь периодической функции, например, синуса.
Да, вы правильно поняли. Попробуйте предложенный метод.
Только осторожно. Если у вас результаты усредняются за 1 час, и для выборки берется 10 подряд идущих часов - то (периодические) суточные колебания нагрузки приведут к существенной нестационарности временного ряда и, как следствие - предположение о нормальном распределении данных в выборке из 10 значений будет нарушено.
Берите тогда в одну выборку или среднее за 1 час в одно и то же время суток (если, конечно, у вас есть достаточно данных измерений), или уменьшайте время усреднения с 1 часа до 30-10 минут (пока это сильно не нарушит нормальность распределения), или уменьшайте количество данных в выборке с 10 до 5-4.
В общем, надо что-то делать с этими суточными колебаниями. Варианта 3. Или брать в одну выборку только результаты, полученные в одно и то же время суток. Или пытаться уменьшить время получения выборки, чтобы суточные колебания не успели оказать влияние. Или применять методы удаления суточного тренда.
Почему-то у меня не работает функция "Paste", не могу цитировать ваше сообщение, поэтому кратко.
Если влияние внешних факторов "случайно, неуправляемо и непрогнозируемо" - прекрасно. Это именно то, с чем статистика и работает.
Предлагаю следующий план работ. Настраиваете параметры вашей системы, запускаете ее в реальных условиях. Даете некоторое время на релаксацию переходных процессов при старте (скажем, 10 мин). Потом собираете данные за некоторый период времени, скажем, 1 минуту. Без какой-либо предварительной обработки и отсеивания, просто вычисляете среднее за 1 минуту.
Сколько измерений за 1 минуту у вас проводится? Допустим, 60. А среднее - это сумма 60 значений, деленная на 60. Деление на константу распределения случайной величины не изменяет. А вот сумма - с большой точностью приводит любое произвольное исходное распределение к нормальному в соответствии с Центральной предельной теоремой.
Таким образом, усредненные за 1 минуту результаты будут почти наверняка распределены нормально. Если 1 минуты для этого недостаточно - возьмите 10 минут и более.
Накопите несколько (скажем, 10) таких усредненных результатов. Это будет первая выборка A. Потом повторите эксперимент при другом значении исследуемого параметра - получите выборку B. К ним уже применим критерий Стьюдента для сравнения.
По вопросу: "какая информация может быть получена из несглаженных значений" - это надо лезть глубоко в теорию. Всякая там автокорреляция, спектр. Кратко могу заметить, что усреднение и прочее сглаживание - это необратимые операции, ведущие к потере информации. Этого может как раз не доставать последующему статистическому анализу. Еще, например, сильная корреляция во времени, к которой обычно приводит сглаживание, может исказить результаты многих статистических методов (того же критерия Стьюдента), которые предполагают отсутствие автокорреляции в данных.
Сначала несколько замечаний по постановке задачи.
Сначала вы пишете, что предполагаете распределение показаний нормальным. Потом вы обрабатываете данные, пытаясь установить, является ли распределение нормальным, и далее действуете с учетом этого.
В статистике обычно так не делают. Там или предполагают, что данные распределены нормально, и далее опираются на это (что может, в случае неверности предположения о нормальности данных, повлиять на достоверность получаемых результатов). Или предполагают, что распределение данных не является нормальным и далее действуют с учетом этого. Еще могут считать распределение неизвестным, и пытаться статистически доказать, нормальное оно или нет.
Далее, вы выбираете одно число как "результат эксперимента", и хотите его проверить на (статистически значимое) равенство или неравенство с другим полученным так же числом. Статистика не может работать с отдельными числами. Ей нужна выборка из большего количества данных, чтобы оценить в этой выборке случайную погрешность.
А так, данные, полученные из опытов, где есть хоть какие-нибудь случайные погрешности, почти всегда (с вероятностью 1) будут не равны между собой. Даже если эксперимент был повторен в полностью идентичных условиях.
Теперь предложения.
Во-первых, я предлагаю отказаться от сглаживания данных. Статистические методы могут извлечь максимум информации именно из несглаженных данных.
Во-вторых, для начала попробовать простые методы, типа t-теста (критерий Стьюдента) на предмет равенства или неравенства среднего по двум выборкам данных. А именно: вы собираете несколько измерений, когда ваш параметр имел одно значение; и еще несколько, когда параметр имел другое значение. Это будут две ваши выборки. Применяете к ним тест Стьюдента, смотрите на результаты. Позволяет оценить, влияет ли ваш параметр вообще хоть как-нибудь на поведение вашей системы.
Если вы считаете, что распределение данных в выборках сильно отличается от нормального (что искажает результаты t-теста), то можете попробовать критерий Уилкоксона, который имеет несколько меньшую "чувствительность", но работает с любыми распределениями исходных данных, а не только нормальными.
Если выяснится, что ваш параметр статистически значимо влияет на результаты измерений - тогда можно будет пытаться найти коэффициент пропорциональности (с помощью регрессионного анализа) и другие тонкости.
Интересный, хороший проект. И в перспективе можно добавлять туда новые функции, ресурсов микроконтроллера более чем достаточно.
Меня только очень оттолкнула эта броская картинка "Гаечки" на заднем плане. Как оттолкнула бы любая другая броская картинка человека, котика или другого объекта, не имеющего отношения к функционалу прибора. Даже если бы там красивое фото какой-нибудь печатной платы было изображено - не нужно это. Такие картинки - как рекламные баннеры, привлекают к себе внимание и заставляют напрягать мозг для того, чтобы не пялиться на них, а использовать прибор по прямому назначению.
К сожалению, ввод новых стандартов C и C++ не решает проблем, стоящих перед программистами на практике.
На практике, к примеру, у нас на фирме пишется портируемый код на Си. Который предназначен для исполнения на 32-битных микроконтроллерах (несколько архитектур, не только ARM); на Линуксе (в режиме ядра и пользователя) и на Windows (32- и 64-бит).
Ладно, я давно отказался от идеи использовать "новые" стандарты Си, такие как C17 или C11. Остановился на C99 - вроде бы, прошло уже достаточно лет с момента его выпуска, чтобы этот стандарт поддерживался всеми компиляторами для наших целевых платформ. Так и было какое-то время. arm-gcc, Native GCC, MinGW-GCC компилировали код без проблем.
Но недавно возникло два крупных разочарования. 1) MSVC. Нам понадобилось использовать этот компилятор в одном из проектов. А он не поддерживает C99! Нет поддержки комплексных чисел (была важна для проекта). 2) Режим ядра в Линуксе - там обязательно использование C89 для версии ядра 4.x.
В итоге даже 24-летней давности C99 оказалось невозможным использовать.
Сейчас введут какой-нибудь новый C++24, C24 - но боюсь, что и через 20 лет на нем не будет возможно писать реально портируемый код, который поддерживается основной массой компиляторов.
Очередная идея обмануть людей красивой формой.
Люди ценят эмпатию не за форму (что кто-то рядом высказывает слова сопереживания или ругается). А за то, что рядом живой человек находится в той же лодке; страдает так же, как ты, и тратит на это драгоценное и невосполнимое время своей жизни.
Сколько было недавно этих озарений на тему: "А давайте спросим у пользователя, понравилось ли ему! А давайте спросим его мнение о нашем продукте! А давайте скажем ему, что его мнение очень важно для нас!" Да, поначалу люди на это велись. Пока не обнаружили, что интерес их мнением - показной. Что на самом деле никто их мнением не интересуется. И оставлять отзывы и участвовать во всевозможных опросах - напрасная трата времени в лучшем случае. Фраза: "Ваше мнение очень важно для нас" и вовсе стала издевательской.
Так и здесь. Как только я пойму, что "сопереживает" и "грустит" со мной не живой человек, сидящий рядом (а в этом нетрудно убедиться, осмотревшись вокруг!), а скрипт, совершенно обстоятельствами не затронутый; время своей жизни не тратящий, а просто желающий ко мне подлизаться - то кроме отвращения к такому "помощнику", других чувств к нему испытывать не буду.
В самом деле, что мы испытываем к окружающим, которые кривят душой в своих изображаемых эмоциях? Которые нам фальшиво сопереживают или фальшиво радуются вместе с нами?