Виноват) Когда нам читали вейвлеты в универе, рассказывали, что ФБР использует их для хранения и поиска отпечатков пальцев. То есть здесь и сжатие информации), и задачи классификации. Вообще вейвлеты хорошо подходят под задачи классификации сигналов: удобно сравнивать низкочастотные образы сигналов.
Не совсем понял, что вы хотели сказать, к сожалению.
<<Т.е. это всего навсего аналогия (как аналогия между спином и вращением)>>
Принцип неопределенности--это математическое свойство преобразования Фурье. Так получилось, что его доказали сначала в рамках квантовой механики (и в более общем виде--не только для преобразования Фурье). Но это доказательство никак не связано с физикой, просто математический аппарат квантовой механики--это гильбертовы пространства функций.
Вкратце написано о принципе неопределенности в ссылке из моего предыдущего поста (на википедию). Более подробно--например, вот в этой книге Давыдов, Квантовая механика, страница 53 (так что вам недолго разбираться:-)
Так же, кстати, работают строго типизированные helper methods в ASP.NET MVC (типа Html.TextBoxFor(model=>model.Name)). И еще можно заглянуть в ExpressionHelper.GetRouteValuesFromExpression из сборки ASP.NET MVC Futures. Название класса говорит само за себя)
Выше уже писали, что в JPEG2000 используется вейвлет-преобразование. В обычном JPEG--дискретное косинунсое преобразование (одна из вариаций Фурье-преобразования).
Про принцип неопределенности вы не правы. В общей форме (то есть не в популистской) этот принцип относится к любым двум самосопряженным линейным операторам гильбертова пространства. Оператор импульса пропорционален производной по соответствующей координате (x, например), и его собственные функции --это exp[ixk] (i--мнимая единица, k--волновой вектор). Переход к импульсному представлению поэтому совпадает с преобразованием Фурье. Поэтому принцип неопределенности все-таки непосредственно относится (чисто математически) к преобразованию Фурье. Притом даже при разложении по любому полному набору функций (не только экспонент), просто тогда вместо оператора импульса в выводе нужно использовать какой-то другой.
Даже более того. Поскольку вейвлет-преобразование обратимо, то система функций этого пробразования полная. А в общем случае преобразование Фурье--это разложение произвольного объекта гильбертова пространства на полную систему функций этого пространства через скалярное произведение на этом пространстве (в нашем случае скалярное произведение--это интегрирование; например, по функциям Бесселя можно раскладывать так же--через интеграл). Так что вейвлет-преобразование можно считать частным случаем общего преобразования Фурье.
Скорее для каждой страницы нужно будет делать маппер, который будет из модели бизнес-логики создавать модель представления, и вызывать этот маппер в каждом экшне контроллера.
Основные аргументы, на мой взгляд--это 1. стандартизированные библиотеки, которых в JS нет (а аналогов или нет или они менее надежные) и 2. возможность писать на разных языках--кому какой удобней. Ну и статическая типизация для желающих (вот мне она очень нравится:-).
Да, есть такая возможность у F#, но здесь она не поможет. Если интересно, то можете пройти по ссылке [4] из статьи и просмотреть пункты 3.2, 3.3. Там дело как раз в специальных ограничениях на перевод величин.
А вот и вспомнился реальный пример насчет юнит-тестов. Все в том же потоке по трубе известно аналитическое решение. Положим, я пишу тест (системный, табличный), который сравнивает моделирование с аналитическим решением. Оказывается, что порог принятия решения по ошибке надо установить в 1е-6 из-за особенностей алгоритма (то есть 1е-6--это максимально допустимая норма вектора ошибки). Но потом, когда после рефакторинга я перепутал в одном методе break с continue, через 100000 итераций моделирование стало асимметричным по сравнению с первоначальным на 1е-10. И этот тест бы ничего не обнаружил.
В общем, «мыши плакали, кололись, но продолжали жрать кактус, потому что кактус так и остается кактусом даже после юнит-тестов».
Disclaimer: к сожалению, после написания той статьи у меня не было возможности применить советы из комментов к прошлой статье, хотя они были полезными (кстати, спасибо!). Возможно, многие трудности из прошлой статьи частично бы решились.
Но почти все сложности из этой статьи остались бы. Дебаг параллелизма--сложнее и с юнит-тестами (хоть его и реже нужно будет применять); неочевидность ошибок остается (даже после юнит-тестов вы знаете, что в таком-то методе из 20 строк ошибка, вы далеко не сразу ее найдете); влияние сеттинга на результат вообще не зависит от юнит-тестов; при идентификации ошибок часто бывает так, что отклонение в работе--это не ошибка, и все тесты пройдут, и все равно придется мучаться с входными данными, заменой алгоритма и средствами из вот этогокоммента. Может быть, нелокальность ошибок будет легче анализировать.
Float--это внутренний typedef, doublereal--typedef CLAPACK; используются ссылки на массивы, а не std::vector вроде как для скорости и для интеграции с lapack. rightVector и rightSideMultipliers--те самые бессмысленные вектора.
<<Т.е. это всего навсего аналогия (как аналогия между спином и вращением)>>
Принцип неопределенности--это математическое свойство преобразования Фурье. Так получилось, что его доказали сначала в рамках квантовой механики (и в более общем виде--не только для преобразования Фурье). Но это доказательство никак не связано с физикой, просто математический аппарат квантовой механики--это гильбертовы пространства функций.
Вкратце написано о принципе неопределенности в ссылке из моего предыдущего поста (на википедию). Более подробно--например, вот в этой книге Давыдов, Квантовая механика, страница 53 (так что вам недолго разбираться:-)
И на русском
В общем, «мыши плакали, кололись, но продолжали жрать кактус, потому что кактус так и остается кактусом даже после юнит-тестов».
Но почти все сложности из этой статьи остались бы. Дебаг параллелизма--сложнее и с юнит-тестами (хоть его и реже нужно будет применять); неочевидность ошибок остается (даже после юнит-тестов вы знаете, что в таком-то методе из 20 строк ошибка, вы далеко не сразу ее найдете); влияние сеттинга на результат вообще не зависит от юнит-тестов; при идентификации ошибок часто бывает так, что отклонение в работе--это не ошибка, и все тесты пройдут, и все равно придется мучаться с входными данными, заменой алгоритма и средствами из вот этогокоммента. Может быть, нелокальность ошибок будет легче анализировать.
Float* knownMomentum, Float* rightSideMultipliers)
{
VectorUtilities::InitializeWith(rightVector, 0, unknownPopulationsSize);
int i;
for(i = 0; i < unknownPopulationsSize; i++)
{
rightVector[i] = knownDensity * rightSideMultipliers[i];
}
for(i = 0; i < dimensions; i++)
{
rightVector[unknownPopulationsSize + i] = knownDensity * currentNode->Velocity[i] — knownMomentum[i];
}
}
Float--это внутренний typedef, doublereal--typedef CLAPACK; используются ссылки на массивы, а не std::vector вроде как для скорости и для интеграции с lapack. rightVector и rightSideMultipliers--те самые бессмысленные вектора.