У всех людей, кто хоть чуть-чуть интеллектом выше среднего уровня, есть синдром «самозванца». И это нормально и правильно
Наверное, вы говорите о второй части эффекта Даннинга-Крюгера — в том плане, что высококвалифицированный специалист сам не в состоянии объективно оценить свой уровень, и собственные знания и навыки кажутся ему очевидными, простыми, не имеющими высокой стоимости для всех остальных людей. Поэтому и возникает чувство вины, якобы продаешь «ничто» по завышенной стоимости.
Чёрт, почитал комментарии — так много людей через это проходили. Я думал, что нас единицы!
В свое время тоже пришлось разбираться с MIDI. Использовал вот эту статью: www.muzoborudovanie.ru/articles/midi/midi5.php. Стоит отметить, что формат довольно изощренный в силу своей древности: во-первых, big-endian, и, во-вторых, величины переменной длины с 7-битными байтами :) Кстати, что-то не нашел у Вас упоминания про важные мета-события, такие как end-of-track, set tempo и key signature. Они не имеют значения в рамках решаемой задачи?
Вообще спасибо за статью, особенно за указание моментов, которые редко встречаются либо вообще не применяются.
Меня заинтересовал Ваш способ уточнения частоты гармоники для ограниченного по времени фрагменту сигнала. Возможно, Вам будет интересно ознакомиться с методом, описанным в статье Спектральный анализ сигналов. Если кратко, то суть состоит в умножении исходного сигнала на экспоненту exp(i*w*t) и поиске такого значения w, когда спектр становится наиболее добротным. Это позволяет в несколько раз уменьшить шаг по оси частоты как раз в нужной окрестности.
Отдельное спасибо за наглядное представление групповой и фазовой скоростей!
Возможно, нужно для этого использовать идею Алгоритма Брезенхэма. Если «на пальцах», то результирующую кривую придется рисовать попиксельно, и для каждого пикселя определять из всех его соседей (соседей будет 7 штук, т.к. 8-й — это предыдущий пиксель) наиболее подходящий, у которого геометрический центр имеет наименьшее расхождение с аналитической кривой.
Если Вы говорите о проблеме локального оптимума, то вот здесь автор предложил решение. Правда, в той статье рассматривался метод потенциальных полей, но, я думаю, идею можно адаптировать и для волнового алгоритма.
Картинка с увеличенным контрастом разности похожа на результат работы фильтра noise в Photoshop. Интересно, Adobe там тоже что-то закодировали? :)
По делу: для увеличения плотности инкапсуляции можно использовать сокращенный алфавит вместо 8-битного ASCII. Например, base64-кодирование или нечто подобное. Разумеется, такой способ применим только для текста, а не двоичных данных.
универ не дал ничего что в будущем пригодилось на работе
Ну разве что пригодилось не непосредственно, а косвенно. Скорее всего должно быть «универ не имел отношения к трудоустройству». А на счет пригодилось/не пригодилось — об этом как раз в статье говорится. Универ делает то, чего не бывает на курсах — пичкает основами, формирует технический склад ума и выпускает самодостаточных джуниоров, которые при желании в дальнейшем могут сколько угодно и сколько нужно заниматься эффективным самообучением, никакие курсы уже будут не нужны.
Про сортировку кучей стоит добавить, что она не требует дополнительной памяти и применима только к структурам данных с прямым доступом. И вообще, выбор метода сортировки должен производиться индивидуально под конкретную задачу. При малых размерах эффективнее могут оказаться qsort или сортировка Шелла.
И еще про применение кучи. Помимо сортировки, можно выполнять эффективный поиск элементов по определенному условию. Например, кроме банального максимума (который является корнем в max-heap), легко найти 2-й или 3-й по величине элемент — это будут непосредственные потомки корня, ну и так далее. Также куча применяется в алгоритмах на графах.
Это действительно так. Несколько лет назад в институте была курсовая, где нужно было расшифровать текст, зашифрованный методом простой замены (перестановки букв в алфавите). В исходный данных было сказано, что язык — русский. Так вот, за счет ограниченной длины (порядка 300-400 символов) преподавателю удалось добиться «нестандартного» распределения плотности различных букв, и даже эвристика с наиболее частой буквой «о» в большинстве заданий не прокатывала. Были, например, тексты с наиболее повторяемой «и».
и расстояние между точками получается приличное
Я просто привел пример, как с помощью координат можно сохранить (иными словами, сжать с потерями) какую-то информацию об исходной строке. Для определения похожести, действительно, не годится.
метод наименьших квадратов
В данном случае я имел в виду обычное определение отклонения между двумя точками X(x1,x2...xn) и Y(y1,y2...yn):
R=(x1-y1)^2+(x2-y2)^2...(xn-yn)^2
Ограничив значения R некоторым порогом R0, можно получить множество точек внутри N-мерной сферы вокруг заданной точки. Такой способ не годится?
Мне сразу вспомнилась эта статья на Хабре: habrahabr.ru/post/236503 — на первый взгляд, никак не связанные показатели статистики, но очень сильно коррелируют.
Вы рассмотрели интересную задачу, но, похоже, оптимизация алгоритма отрицательно сказалась на результатах. На мой взгляд, функция отображения в N-мерное пространство слишком сильно размазывает полезную информацию. Как я понял, эта функция отобразит два бесконечно длинных текста практически в одну точку? Ведь частотность конкретной буквы полностью определяется языком (в русском наиболее частая буква «о»). Думаю, функцию обязательно нужно усложнить. Первое, что приходит на ум, это увеличить размерность пространства в 2 раза. Одной букве будет соответствовать два числа: число вхождений в текст (как и сейчас) и сумма расстояний этой буквы от начала текста. Пример: допустим, алфавит всего из тех букв abc, текст «aabbbaaaccc» отобразится в точку ( (5,19), (3,9), (3,27) ). Числа 5,3,3 — это количество вхождений букв a,b,c. Число 19 для буквы a получено, как сумма позиций буквы a в тексте, то есть 0+1+5+6+7=19.
И еще один момент, по поводу куба вокруг каждой точки. Возможно, я что-то не так понял. Не проще ли было обойтись методом наименьших квадратов вместо R-tree?
Вы будете смеяться, но у меня была паранойя: я не хотел, чтобы кто-то мог прочитать содержимое массива с помощью средств типа artmoney. Но Ваше предложение, безусловно, оптимальнее по скорости.
Помню, еще в школе столкнулся с подобной проблемой, когда пытался написать карточного «Дурака»: ломал голову, как же получить случайную карту именно из оставшейся колоды, а не из всей. Правда, уже тогда решение в лоб, то есть пинать рандом до тех пор, пока не выпадет неиспользованная карта, я считал неприемлемым. В итоге было решено использовать множество (писал на дельфи): после использования карта удалялась из множества, а аргумент функции random был равен числу элементов множества. Если бы писал на Си, использовал бы std::vector. Таким образом, мы получаем равновероятный исход (насколько это позволяет random) всего за один вызов, но приходится тратить время на reallocate массива. Думаю, что разработчики Lines нашли компромисс между ресурсами и случайностью, и не было цели сделать подлянку.
На счет последней ячейки небольшая поправка: Вы указали, что шарик попадет туда, только если все ячейки левее будут заняты. Точнее так: если random вернет число 79 (т.е. предпоследняя ячейка), и она окажется занятой, то как раз будет рассмотрена последняя. В принципе это может произойти хоть в начале партии.
Прочитав все вышесказанное, тоже пришел к такому умозаключению. Но вопрос в другом — какая вообще может быть польза от такого embedded-антивируса? Социальная сеть выпускает свой девайс — понятно. Свой канал на ТВ (а такое бывает?) — тоже можно понять. Но зачем антивирус-то, в голове не укладывается.
А я, пожалуй, соглашусь по поводу клонов. Сам в итоге пришел к такому же выводу, поскольку разработать техническое решение — это одно дело, а геймдизайн — совсем другое, но не менее сложное, особенно при отсутствии опыта.
Такая природа вокруг, наверное, очень сильно способствует разработке:) Я, например, люблю кодить на даче, чтобы можно было послушать птичек и воздухом подышать. По поводу статьи — сказать, что впечатляет, значит ничего не сказать! Такой колоссальный путь, да еще и в одиночку. А число установок не такое уж плохое — как я понял, порядка 10% активных в итоге? Мне кажется, даже у издателей бывает статистика похуже. Желаю удачи в продвижении этого и в дальнейших проектах!
Еще был более изощренный способ с перемешиванием иконок и названий ярлыков. Например, у ярлыка MS Word заменить название и иконку на Internet Explorer.
Наверное, вы говорите о второй части эффекта Даннинга-Крюгера — в том плане, что высококвалифицированный специалист сам не в состоянии объективно оценить свой уровень, и собственные знания и навыки кажутся ему очевидными, простыми, не имеющими высокой стоимости для всех остальных людей. Поэтому и возникает чувство вины, якобы продаешь «ничто» по завышенной стоимости.
Чёрт, почитал комментарии — так много людей через это проходили. Я думал, что нас единицы!
Вообще спасибо за статью, особенно за указание моментов, которые редко встречаются либо вообще не применяются.
Отдельное спасибо за наглядное представление групповой и фазовой скоростей!
По делу: для увеличения плотности инкапсуляции можно использовать сокращенный алфавит вместо 8-битного ASCII. Например, base64-кодирование или нечто подобное. Разумеется, такой способ применим только для текста, а не двоичных данных.
Ну разве что пригодилось не непосредственно, а косвенно. Скорее всего должно быть «универ не имел отношения к трудоустройству». А на счет пригодилось/не пригодилось — об этом как раз в статье говорится. Универ делает то, чего не бывает на курсах — пичкает основами, формирует технический склад ума и выпускает самодостаточных джуниоров, которые при желании в дальнейшем могут сколько угодно и сколько нужно заниматься эффективным самообучением, никакие курсы уже будут не нужны.
И еще про применение кучи. Помимо сортировки, можно выполнять эффективный поиск элементов по определенному условию. Например, кроме банального максимума (который является корнем в max-heap), легко найти 2-й или 3-й по величине элемент — это будут непосредственные потомки корня, ну и так далее. Также куча применяется в алгоритмах на графах.
Это действительно так. Несколько лет назад в институте была курсовая, где нужно было расшифровать текст, зашифрованный методом простой замены (перестановки букв в алфавите). В исходный данных было сказано, что язык — русский. Так вот, за счет ограниченной длины (порядка 300-400 символов) преподавателю удалось добиться «нестандартного» распределения плотности различных букв, и даже эвристика с наиболее частой буквой «о» в большинстве заданий не прокатывала. Были, например, тексты с наиболее повторяемой «и».
Я просто привел пример, как с помощью координат можно сохранить (иными словами, сжать с потерями) какую-то информацию об исходной строке. Для определения похожести, действительно, не годится.
В данном случае я имел в виду обычное определение отклонения между двумя точками X(x1,x2...xn) и Y(y1,y2...yn):
R=(x1-y1)^2+(x2-y2)^2...(xn-yn)^2
Ограничив значения R некоторым порогом R0, можно получить множество точек внутри N-мерной сферы вокруг заданной точки. Такой способ не годится?
Мне сразу вспомнилась эта статья на Хабре: habrahabr.ru/post/236503 — на первый взгляд, никак не связанные показатели статистики, но очень сильно коррелируют.
Вы рассмотрели интересную задачу, но, похоже, оптимизация алгоритма отрицательно сказалась на результатах. На мой взгляд, функция отображения в N-мерное пространство слишком сильно размазывает полезную информацию. Как я понял, эта функция отобразит два бесконечно длинных текста практически в одну точку? Ведь частотность конкретной буквы полностью определяется языком (в русском наиболее частая буква «о»). Думаю, функцию обязательно нужно усложнить. Первое, что приходит на ум, это увеличить размерность пространства в 2 раза. Одной букве будет соответствовать два числа: число вхождений в текст (как и сейчас) и сумма расстояний этой буквы от начала текста. Пример: допустим, алфавит всего из тех букв abc, текст «aabbbaaaccc» отобразится в точку ( (5,19), (3,9), (3,27) ). Числа 5,3,3 — это количество вхождений букв a,b,c. Число 19 для буквы a получено, как сумма позиций буквы a в тексте, то есть 0+1+5+6+7=19.
И еще один момент, по поводу куба вокруг каждой точки. Возможно, я что-то не так понял. Не проще ли было обойтись методом наименьших квадратов вместо R-tree?
На счет последней ячейки небольшая поправка: Вы указали, что шарик попадет туда, только если все ячейки левее будут заняты. Точнее так: если random вернет число 79 (т.е. предпоследняя ячейка), и она окажется занятой, то как раз будет рассмотрена последняя. В принципе это может произойти хоть в начале партии.