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

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


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


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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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


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

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

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


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


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

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

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

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

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

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

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

    ***

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

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

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

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