w495
0
Наиболее интересное определение дал Керубини [Understanding near-duplicate videos: a user-centric approach].

Нечеткие дубликаты видео — приблизительно одинаковые видео, которые могут отличаться параметрами кодирования, светоизмерительными параметрами (цветность, яркость), применением монтажа (титры, логотип), или наложением аудио. Идентичные видео с соответствующей дополнительной информацией, в любом из них (изменения длины клипа или сцен) рассматриваются как НДВ. Два различных видео с разным представлением и сценарии, считают НДВ, если они используют одинаковую семантику, и ни одного из них нет дополнительной информации.


Нечеткие дубликаты видео по Керубини
w495
0
По Башарату:
Нечеткие дубликаты видео — изображение того же эпизода (например, «беспилотный летательный аппарат в воздухе») при различных точках обзора, размерах видео, ландшафте, погодных условиях, моделях БПЛА и движениях камеры. Одна и та же смысловая концепция может быть выражена в различной форме, при разном освещении, и параметрах сцены.
[Content based video matching using spatiotemporal volumes]


Нечеткие дубликаты видео по Башарату
w495
0
А вот по Шену:
Нечеткие дубликаты видео — клипы, которые похожи или почти дублируют друг от друга, но выглядят по-разному. Они отличаются в силу разных условий съемки (точка обзора и настройки камеры, условия освещения, фон, передний план, и т. д.), преобразований (формат видео, частота кадров, разрешение, сдвиг, обрезка, гамма, контраст, яркость, насыщенность, размытие, выдержка, резкость и т. д.), операции монтажа (вставка, удаление, перемена мест кадров и модификация содержимого).
[UQLIPS: a real-time near-duplicate video clip detection system]


Нечеткие дубликаты видео по Шену
w495
0
На самом деле, интересно обратиться к формальному определению дубликатов видео.

Нечеткие дубликаты по Ву

Например, по Ву, Нечеткие дубликаты видео — идентичные или приблизительно идентичные видео, почти точные копии друг друга, но отличающийся форматами файлов, параметрами кодирования, светоизмерительными параметрами (цветность, яркость), применением монтажа (титры, логотип, рамка), длиной и набором модификаций (вставка или удаление кадров) (doi: 10.1145/1291233.1291280)

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

А какие алгоритмы Вам кажутся непонятными?
w495
+1
Может очень сильно зависеть, от того что это были за ребята. У алгоритмов разные сферы применения, в том числе и в «обратную» сторону. «Кинжал хорош для того, у кого он есть. И горе тому, у кого его не окажется в нужную минуту.»(Черный Абдулла из к/ф Белое солнце пустыни).
Мне кажется, что вопросы авторских нужно решать цивилизованно, и не учитывать позицию только одной стороны.
w495
0
А передать на курс младше ту же идею? В 2011 в NY так делали ребята из Алжира.
w495
0
А вы будете на имкапе в следующем году?
w495
+1
Не даром мы Российским флагом в Нью-Йорке махали, когда объявляли следующую принимающую страну (тогда ей стала Австралия). Пророчество сбылось!
w495
0
А расскажите подробнее о тех и о других, если можно. Sync никогда не использовал.
w495
0
На тему горячей замены кода попробуйте вот это:
github.com/zavr/nodectl
Мы пользуемся, пока нареканий не было.
w495
0
Главное быстро

Да, но как понимаю, в этом случае подойдет что угодно, втч «замечательные проекты на php». На тему быстро — требуется время на изучение фреймворка. Во некоторых подобных случаях удобнее и быстрее решить свою конкретную задачу руками.
Фремворки, кроме того, не всегда прозрачны (если, фреймворк написали не вы сами). Времени на понимание и отладку может уйди безумно много. А может и не уйти.

Про pyramid ничего сказать не смогу, — не пользовался.
А вот та же самая Django:
  • ограничение на схему бд;
  • крайне тяжело адаптировать к существующей базе;
  • сложно адаптировать к существующей инфраструктуре;
  • не удобно, и не всегда возможно оптимизировать;
  • есть проблемы с потокобезопасностью, не всегда ясно как их разруливать;
  • ...

писать что хочешь.

Опять зависит от того, что Вы конкретно хотите.
Не всегда задача авторов фреймворка совпадает и вашей текущей задачей.

Очень хорошо изучать подходы, а не их конкретные реализации. И потом использовать в своих проектах.
w495
0
Кстати, мне кажется, что ./tpl лучше убирать в ./priv
w495
0
Было бы интересно увидеть аналогичную статью, но DTL заменить на XSLT.
w495
0
Под конкретную задачу — конкретное решение.
Фреймворки плохо, ибо ограничивают в средствах.
Библиотеки (втч) аксепторы — хорошо, ибо есть много что готового, но это готовое, ты прозрачно можешь заменить на свое.
w495
0
А посадить его под nginx?
w495
0
O(n^2) по времени?
Ну как минимум операций больше.

Сложность весьма очевидна в C, и то не всегда (компиляторы умнеют быстро).
Тут мы имеем компилятор, который потенциально может разгуливать подобные ситуации,
и оптимизировать. Для конкретного случая надо проверять. Константа может перекрыть сложность.

Если позволяет логика приложения я бы сделал так:

map([], Acc, _) ->
    Acc;
map([Element | Elements], Acc, F) ->
    map(Elements, [F(Element)|Acc], F).

А развернул бы в другом месте со сходной семантикой.
Иногда это влечет трудно находимые ошибки.

То что lists:flatten — убийство, и использовать надо, только там где он действительно нужен, проверено многократно, на практике. Собственно из-за него я и сделал сравнение.
w495
+1
я как истинный нуб в Эрланге предположил и попробовал.


Так нельзя. Лучше сначала разобраться в вопросе, и потом уже строить предположения.
Есть много чего, о чем мне хочется тут рассказать,
но пока я не буду уверен в правильности и полезности,
делать это бессмысленно. Просто потрачу время, и свое и чужое.

Если это Ваши предположения, то не плохо бы это как-то пометить.
Выглядит как категоричное утверждение.
А неверное предположение, выданное за истину, вызывает негатив.
w495
+2
Тем, что не надо думать о деталях.
Хотя бы на первых порах.
Декларативность, что ли.
Ну во общем это не к Erlang, а к функциональным языкам.
w495
0
Пробовал. Картина не менялась. Но ждать было лениво.
Если получится что-то иное дай знать.
Но опять же, все может зависеть от версии.
Правда, на память особого внимания не обращал.

влияние сложности алгоритмов небольшое


Так это просто тест конкатенации.
И меня более интересовало представление строк.
О каких алгоритмах речь?
w495
+1
Этот быстрее, но первый по определению.
Если заюзать мемоизацию, то лучше писать, по определению, имхо.
w495
0
gist.github.com/2924882

lists:reverse — раньше брезговал, но

> erlang:is_builtin(lists, reverse, 2).
true


lists:flatten — убийство.
[List1, List2], в зависимоти от целей erlang:list_to_binary
w495
0
Отметим два неочевидных обстоятельства. Во-первых, нельзя запустить loop() перед spawn_link(). Казалось бы, так будет более надежно, т.к. функция-слушатель, запущенная до запуска потока-исполнителя, наверняка не пропустит ни одного сообщения от этого потока. Но опыт показывает, что в этом случае функция-слушатель вообще не получает сообщения от потока-исполнителя. По-видимому, это связано с тем, что статус отношения потоков не обновляется.


Откуда это все?
w495
0
Про ++ — уверен? Я не очень.
+ Какая альтернатива?
--> Можно, конечно, вложенные списки, но без опыта функ про осознать не просто.
w495
0
Хоть бы цену кто-то озвучил. Думаю, найдутся те, кто готов был бы это купить.
Ну или какую-то часть словаря.
w495
0
Там большая проблема это права на сами тексты, а не на их разметку.
В веб-выдаче они все равно с нарушенным порядком предложений, и сами произведения перемешаны. Автоматизировать разрешенные действия — сомневаюсь, что в этом есть что-то противозаконное. Блокировка по ip они делают все скорее для защиты от чрезмерных нагрузок.
w495
0
На тему лицензий, если уж совсем серьезно, то про них ничего вообще не сказано.
А потом, какой закон, и какую конкретно статью нарушит некто, решивший таки такое опубликовать в каких-то своих никому неведомых целях?

Думаю, тут скорее действует профессиональная этика что-ли.
w495
+3
В исследовательских целях — можно. Мне более и не надо было.
Результатом стало вот это:
www.slideshare.net/w-495/dsmts-diploma

В конце концов, я же никого не хакнул, а просто автоматизировал получение доступной информации.
w495
+3
Ну там в принципе на почту не отвечают.
Да ладно, писать краулер самому и парсить все это через html5lib было интересно.
w495
+2
Как я понимаю, товарищи не собираются ограничиваться одним корпусом.
Я в частности крайне жду параллельных многоязычных корпусов.
w495
+2
С НКРЯ можно попробовать расправиться через краулинг ответов с высокочастотными словами.
Правда после тысячного запроса, клиент банится по IP.
До какого-то момента я с ними возился. Но потом это все надоело.

+ У них есть серьезная проблема с интерфейсом. Иногда оно зависает и пытается выдать много одинаковых ответов на одну и ту же страничку. Много — в смысле, очень очень много. При попытке воспоизвести это в браузере привело к его падению. Хорошо, что такое поведение не регулярно.
w495
0
Так и не поправили (
Кстати, а вот это отрабатывает корректно:
Никитин "Распределенное программно-информационное обеспечение"
w495
+1
Писать. На диск.
Я не уверен, что современные sql-базы настолько примитивны. Никто не отменял отложенных записей, никто не отменял балков (говорил, же, что, все таки, неудобно).
+ Если и на диск (в чем я крупно сомневаюсь), то смотря какой диск.

Если интересно, могу свести с человеком который непосредственно этим занимался.
w495
0
Ага, только немного подкрутить надо.
w495
0
Фонетически сложнее произносить. Все время перед «ж» хочется «д» вставить.
w495
0
Спасибо, старались.

как эрланг начинает захлебываться (вероятно сообщениями)

Чтобы этого не было, можно попробовать, подкрутить (уменьшить?) число редукций на процесс. Но это грязно. Ну или разбирать конкретный случай, чтобы в очередях было минимальное число сообщений, и всеони пролетали очередь.
+ Сталкивался с проблемой числа файловых дескрипторов на процесс ос, но тут возможно это непричем.
В этом случае, он просто откажется выполнять библиотечные функции.

***

Горизонтально смаштабировать можно и без erlang, было бы на чем масштабировать. Как было сказано выше, мнезия только для мелких порций в малом количестве.

Пробывал redis и leveldb как альтернативу, но что-то с ними как-то не сложилось.
w495
+1
Есть и много других проблем.
1) При нескольких млн записях в секунду начинает резко падать скорость. Конечно можно разносить по машинам и балансировать нагрузка. Но количество машин ограничено.
2) Начинаются тормоза при двух млдр мелких записей в базе, даже когда скорость не сильно критична, такие тормоза раздражают.

Потому от mnesia мы отказались в пользу postgres. Гетерогенно и неудобно, но головной боли меньше.
w495
0
Почему, таки, Yaws? Он тяжел, и есть достаточное число http-аксепторов, библиотек и пр.
w495
0
Это ветка, конечно, похожа на холивар, но Вы приводите интересные и очень разумные аргументы, потому предлагаю продолжить.
Получат позже
Я с Вами согласен, что применять что-то пилотное в активном и критически важном проекте — не правильно. Но, как мне кажется, нужно смотреть дальше чем один проект. Живем не сегодняшним днем, и Ваши 5k строк через некоторое время могут превратиться в 50k, 500k строк (и это нормально) и их надо будет как-то поддерживать. Если есть немного свободного времени, посмотрите Cesarini F. Erlang programming, и сравните с тем что уже имеете.
язык программирования
Согласен, но как лингвист, я скажу что любые языки принципиально не эквивалентны. Сам язык, что — просто набор правил над некоторым множеством символов. Но за каждым естественным языком стоит его культура. За искусственным — парадигма, или архитектура абстрактной машины этого языка.
Знание внешней оболочки языка, без понимания основания делает человека «языковым чудищем». Вы просто спросили как пройти, а вам морду набили.
Парадигмы-то они эквивалентны, но некоторые вещи в лямда выражениях выглядят проще, удобнее, эффективнее, чем в рамках стековой машины (java, .net, python) или машины фон Неймана (C\C++, Fortran).
сделать удобную для проекта и задач платформу
По сути, тоже реализация некоторого языка, на основе существующего. А такое лучше делать на функционального подхода. + Делать платформу — это тоже время. А если она станет одноразовой, и даже частично не применимой, к чему-то другому — слишком дорого.
Локальные решения это хорошо, но только они не позволяют находить других локальных решений, которые, может быть, лучше. Траншею можно копать саперной лопаткой, а можно экскаватором. Если траншея одна в принципе, то лопатой, конечно быстрее. Она получится даже аккуратнее. А на экскаваторщика придется еще учиться. Но если траншей сотни, то лопата уже не применима.
w495
0
пока компилится С-шный код.

Вот тут мне кажется, ты не прав. Что такое у тебя долго компилировалось? И как долго?
Имхо, такие 5k как раз, скомпилятся вполне себе быстро.