egorinsk

> Я разбираюсь с темой консонанса/диссонанса, т.е. степени «приятности» звучания аккорда.

Если я не ошибаюсь, она зависит не от соотношения амплитуд гармоник, а от соотношения частот входящих в него нот.

Вы знаете про соотношение частот нот (имеются в виду основная частота) в созвучных и несозвучных сочетаниях? Этим еще Пифагор занимался. Например, если ноты различаются на 12 полутонов, то это соотношение 2:1, если на 7 пт то 3:2, если на 5 пт то 5:4 (вроде так?). У таких «кратных нот» много совпадающих друг с другом гармоник. Они как бы сливаются при звучании.

Возьмем противоположный пример: ноты, различающиеся на 1пт. У сочетания таких нот, если изобразить спектр, гармоники не совпадают, выглядят сдвоенными палками, находятся близко друг к другу и звучат они не очень-то приятно.

В мажорном аккорде тоже есть какие-то соотношения между частотами звука отдельных нот.

Также, у меня есть ощущение, что мозг умеет объединять гармоники с основной частотой. Например, звуки музыкальных инструментов состоят из гармоник, но мы ведь слышим их как одну ноту, а не несколько. Потому, наверно, амплитуда отдельных гармоник (и характер их изменения во времени) определяет тембр звука, но не «приятность» звучания аккорда.

Надо сделать a индексом массива и использовать array_intersect_key/array_diff_key для поиска одинаковых записей. Тогда будет почти без циклов.

Проверка паспортных данных — единственный надежный способ.

Вы абсолютно правильно заметили. Не знаю, кто это придумал, но делать блоки на странице через подключение отдельных файлов абсолютно неэффективно с точки зрения производтельности и неуклюже с точки зрения архитектуры. Костыль, а не решение. Логично использовать для этого функции или статические методы классов (бонус: получаем автозагрузку и изоляцию локальных переменных). Пример шаблона:

class UserBlock {
public static function renderUserInfo($user) {
?>
… HTML код…
<?php
}
}

Пример использования:

<?php foreach ($users as $user): ?>
{div}<?php UserBlock::renderUserInfo($user); ?>{/div}
<?php endforeach ?>

Людям, которые скажут, что плохо использовать функции в шаблонах (почему, кстати?), предложите придумать более простое, изящное, быстрое, без использования громоздких бибилиотек и надежное решение, а потом убедитесь, что у них ничего не вышло.

Гармоники жестко привязаны к основной частоте, то есть когда она становится громче, они тоже становятся, так как они генерируются одним источником. В общем случае невозможно отличить допустим основную частоту + набор гармоник от суммы 2 кратных частот и их гармоник.

Это всего лишь математическая абстракция.

Я когда-то думал над подобным способом для поиска слов с опечатками. Одним хешем тут точно не обойтись, и вот почему. Допустим (упростим задачу), все слова имеют одинаковую длину, например, 4 символа, мы хотим, чтобы у слов, различающихся 1 буквой, был одинаковый хеш. Тогда слова abcd и abce имеют одинаковый хеш, слова abcd и zbcd имеют одинаковый хеш… в итоге, все слова будут иметь один и тот же хеш.

Потому, одним хешем тут не обойтись. Нужно как минимум, несколько.

Например, хеш для всех букв, кроме первой. Хеш для всех, кроме второй, и т.д. Тогда у различающихся 1 буквой слов будут 2 совпадающих хеша.

Или другой подход — разбиение слов на триграммы и поиск по ним. У похожих слов большинство триграмм будет одинаковыми.

По психологии литературы много, но мне кажется, чтение теоретической информации надо совмещать с практическими исследованиями, например наблюдением за поведением и анализом испытуемых субъектов в естественной среде, иначе это бесполезно.

Вы смотрели гугловский SPDY? Там вроде что-то сжимается как раз с заданным заранее словарем.

Наверно, разработчикам таких систем выгодно, чтобы машины угоняли и покупали новые. Других объяснений, при нынешнем то урвне развития технологии, я не вижу.

1) Берем словарь русского + словарь английского. 2) Убираем из текста словарные слова 3) Склеиваем то, что осталось.

Естественно, словарь придется дополнить опечатками, неологизмами, нецензуршиной и т.д.

На всяких фейсбуках и вконтактах данные ленты генерирует демон на компилируемом языке, который к тому же кучу информации кеширует в памяти. Осилите? Ну не знаете Си, можете попробовать на Node или Java написать, ну или на PHP в крайнем случае, если заложить возможность масштабирования, тоже будет ОК до поры до времении.

Алгоритм работы примерно такой: 1) выбираем id друзей юзера 2) выбираем последние события у каждого из них 3) отсеиваем защищенные приватностью 4) склеиваем списки, сортируем по дате и отдаем в браузер.

А на MySQL у вас с ростом нагрузки, числа друзей все это быстро положит сервер. Сделаем простейший расчет: средний юзер делает 10 событий в день, если юзеров хотя бы несколько тысяч, таблица событий быстро подпрыгнет в размере до миллионов записей. А всякие конструкции типа JOIN во-первых, грузят сервер, во-вторых, не шардятся.