• Силовики предлагают запретить ПО, скрывающее пользователя в Сети
    0
    Во всех вопросах истина (оптимум/профит) обычно посредине…
  • Как попасть в «золотой миллиард» или отрезвляющая статистика
    0
    Это смотря где. В Африке или, скажем, Индии, еще как модно.
  • Как попасть в «золотой миллиард» или отрезвляющая статистика
    –1
    Существуют три вида лжи: ложь, наглая ложь и статистика


    Интересен подход, когда берется твой непосредственный заработок и сравнивается со средним зароботком 7 миллиардов человек из которых (признаюсь, числа с потолка, но похожи на правду):
    4 млрд. дети,
    1 млрд. старики,
    1 млрд. не имеют работы или другого дохода по той или инной причине (тунеядец, безработный и в стране не платят пособие, ну или весь доход «в черную» идет мимо статистики).

    Итого, если ты не относишься к указанным 6 млрд., то поздравляю! Ты относишься к тому самому «позолоченному» миллиарду, у которого хоть какой-то доход есть, пусть хоть пособие по безработице :)

    И вообще, надо бы вводить не net income, а скорее household income per person, т.е. доход семьи деленный на кол-во иждевенцев. Тогда это хоть какой-то смысл имеет.
  • Хотите, чтобы ваша компания развивалась? Избавьтесь от менеджеров!
    0
    Так, но теперь теряется смысл самой статьи — упразднить всех менеджеров :) Поощрять можно по разному, но речь не об мотивации, а о том, что внутренней мотивации многим не хватит для самостоятельного исполнения своих обязанностей, и тут-то на сцену выходит менеджер с кнутом и пряником нормативами и премиями.
  • Хотите, чтобы ваша компания развивалась? Избавьтесь от менеджеров!
    +1
    Ну так вроде Valve как раз подтверждает мое утверждение: главный Гэйб яавляется владельцем и вобще самым-самым главным, народа у них не много, и в основном творческие люди. Думаю, у менее творческих подразделений иерархия присутствует: врядли есть много идейных адептов работы в поддержке.
  • Хотите, чтобы ваша компания развивалась? Избавьтесь от менеджеров!
    +8
    Идея хорошая и, в целом, правильная, но ограниченной применимости: нужен «главный», который обладает достаточной властью и решимость, чтобы принять столь экстравагантное решение (если он не владелец компании, то его живьем съедят), компания должна быть не очень большой и кроме того, компания должна состоять в основном из самомотивированных людей (например, представителей творческих профессий). В общем, утопия… Да и тунеядцы, оказавшиеся лишними на этом празднике жизни, будут против, а у них тоже есть некоторая власть.
  • BMW делает ставку на беспилотные автомобили
    0
    Согласен, не очень логично. Может предполагается, что повышение эффективности на 90% приведет к тому, что нужно будет меньше машин, но выглядит неправдоподобно.
  • BMW делает ставку на беспилотные автомобили
    +5
    Так уже :) «Не можешь предотвратить – возглавь».
    А потом сведут все к какому-то УГ, что автомобиль надо будет покупать каждый год или «лицензию на автопилот» продлять.
  • Файлообменник Mega запущен в работу
    0
    В LocalStorage он действительно есть. Там хранится длинная простыня чисел под названием «privk». Но каким образом будет работать это на другой машине непонятно. Разве что через синхронизацию самого Chrome, но сомневаюсь что он синхронизует LocalStorage.
  • Семинар-встреча «e-Estonia – путь в Европу!»#2
    0
    А какие проблемы вы видите?
    У Microsoft уже отработаны методы вывоза программистов из России. Не думаю, что законы Эстонии настолько суровы, что им туда привезти сотрудника откуда-то сильно сложнее, чем в США. Ну и кроме того наличие предложения подобных вакансий обитателям РФ уже говорит о том, что это более чем возможно.
  • Семинар-встреча «e-Estonia – путь в Европу!»#2
    0
    В скайп (который теперь MS) можно. Предлагают иногда позиции в Таллине/Стокгольме.
  • Экспорт истории сообщений из Skype 4.*
    0
    Лезть ручками в SQLite это уже какой-то крайний метод. Есть же API для доступа. Пока аккаунт пока еще ваш и скайп работает, можно на python со Skype4Py только так написать экспортилку истории и всего остального.
  • Немного о сборке мусора и поколениях
    +1
    Тема, конечно, интересная, но хотелось бы некоторого введения. А то сходу специфической терминологией оперировать начинаете и заведомо предполагаете, что все в курсе когда в каком поколении объект находится и почему.
  • В Оренбургской области заблокирована Ubuntu
    0
    И это еще закон не вступил в силу… С ноября этим заниматься сможет шушера рангом пониже — вот тогда вообще бардак будет.
  • Магистратура и аспирантура в Японии: 2012
    +1
    А подскажите, пожалуйста, как в таких случаях решается вопрос с семьей? Можно, например, с собой вторую половинку и/или ребенка взять? И если можно, то чем они там смогут заниматься (т.е. сможет ли по данной визе вторая половина работать)?
  • Игра на SDL — вдвойне легко
    0
    Ага, а потом очередная версия пошаговой стратежки, которая когда-то летала на 486, еле ворочается на core 2 :)

    Ну а если серьезно, есть еще мобильные платформы, где процессор разбазаривать не стоит. Кроме того, отрисовать страницу текста тем методом, как на примере, при SDL_Delay(50), будет жрать порядка 30% ядра. А в игре еще ничего даже не начиналось…
  • Игра на SDL — вдвойне легко
    0
    Хорошо бы было упомянуть, что использование растровых шрифтов и TTF — это совсем разные вещи с точки зрения производительности и возможностей.
    Freetype дает возможность использовать кучу шрифтов, в т.ч. не моноширных, менять размеры кегля, толщины линий, использовать кернинг и многое другое. Но это конечно не бесплатно — рендеринг текста ну о-о-очень медленный, т.е. много fps не выжать в игре, если рендерить текст каждую итерацию. Растровые шрифты гораздо быстрее, но сильно не поуправляешь отображением текста: какие буквы подготовили, такие и будут. Кроме того надо приложить некоторые усилия для использования шрифтов переменной ширины (а фиксированная ширина шрифта плохенько выглядит).
    В принципе, рабочий вариант — это использовать TTF, но кэшировать отрендеренные символы или строки целиком для дальнейшего использования.
  • Google Developer Day 2011: посещенные секции
    +1
    Точно. В андроидовской секции рассказывали то, что можно самому прочитать буквально на первой странице соответствующего раздела developers.android.com, причем давно уже.

    Выбирали, судя по анкете-заявке, участников поопытнее, а потом вот такие доклады для новичков выкатывают. Зачем?
  • Алгоритм быстрого нахождения похожих изображений
    0
    Согласно некоторым статьям, успешные реализации поиска похожих картинок работает на основе так называемого «мешка слов». Т.е. из изображений выделяются особые точки, кластеризуются и формируется словарь особых точек. После этого все картинки раскладываются по данному словарю. Дальше поиск ничем не отличается от обычного текстового поиска с ранжированием по метрикам схожести документов.

    Дабы не быть голословным, вот.
  • Property в C++
    0
    Вот только у property на лбу, к сожалению, не написано ReadWrite она или ReadOnly. Это как раз уже минус.
  • Хранение своего архива фотографий
    +1
    Google Picasa вас спасет — это практически лучший софт общего назначения для управления фотографиями, что я видел на Linux (подозреваю что и на Win).

    Если никакой профессиональной деятельности с фотками не предполагается, то есть только два действия, которые можно делать с альбомами: 1) показать друзьям подвыборку из 5% фотографий 2) посмотреть раз в год самому 20% из фотографий. 80% фотографий не будут посмотрены никем и никогда, но это и не важно, мы не против хомячества :) Перед показом друзьям хочется минимально приукрасить фотки, при этом не попортив оригинал (ибо хомячество).

    Раскидываете все по папочкам вида «2008/2008.02/2008.02.23 какое нибудь описание», чтобы даже выдранное из контекста название папки содержало полную инфу (в picasa так удобнее полное имя папки «2008.02.23 какое нибудь описание», а если ручками по папкам шариться, то надо иметь иерархию). Натравливаете picasa на эти все фотки и формируете прямо в ней подборки-альбомы, которые подправляете прямо в picasa (большинству людей хватает двух-трех кнопок вроде «сделать зашибись» и «сделать зашибись, если первый вариант не понравился», которые благоразумно вынесены в удобное место). Редактирование запоминается, но не затрагивает оригинал, если не нажимать «сохранить». Легким нажатием кнопки сделанные подборки-альбомы публикуются на вашем аккаунте у гугла, после чего можно всем рассылать ссылочки и ждать восторженных отзывов. В большинстве случаев и сами вы смотрите именно опубликованные фотки, т.к. нет желания рыться в тех трех тысячах снимков, что вы привезли из поездки.

    Таким образом фотографии
    1) отсортированы
    2) в целости и сохранности
    3) есть отретушированный набор для показа
    4) этот набор опубликован в вебе
  • Хранение своего архива фотографий
    0
    Новые версии picasa весьма неплохо работают в wine. Правда бывает не подхватывает альбомы после переустановки.
  • Суффиксный массив — удобная замена суффиксного дерева
    0
    Спасибо, я старался.

    Значит ждем статью про суффиксный автомат ;) Очень интересно почитать.
  • Суффиксный массив — удобная замена суффиксного дерева
    0
    Основное практическое применение — это как раз индексация текстов для быстрого поиска в них. Т.е. например проиндексировать по-простому (без морфологии) справку для полнотекстового поиска, или же проиндексировать геном. Думаю не совру, если скажу что практически все поисковики пользуются суффиксными массивами тоже. Слишком уж много сложностей с деревьями.
  • Доработка контейнера vector для работы с большими объемами данных
    0
    Да, немного неправильно выразился. Сами элементы не копируются, копируется таблица мэппинга индексов при переаллокации. Т.е. всплески могут быть все-равно и они будут O(n). Но константа, конечно, сильно меньше, чем в векторе.
  • Доработка контейнера vector для работы с большими объемами данных
    –4
    Ну deque тут не поможет. Обычно у STL-ного deque тоже переаллокация с копированием элементов происходит. Например в gcc используется реализация с вектором и циклической индексацией. Т.е. когда место в векторе закончится, то будет все то же самое.
  • Поиск подстроки и смежные вопросы
    0
    Думаю ваш алгоритм может быть полезен когда вычисление хэша от набора объектов заметно дешевле их сравнения. Т.е. не для строк, а для, каких-нибудь больших и сложных объектов.
  • Поиск подстроки и смежные вопросы
    0
    Окей, попробую объяснить.

    Почему за линейное время в простом случае, когда для k=i-r+1 дуального i Z[k] меньше чем оставшийся Z-блок понятно — просто смотрим результат для Z[k] и вписывем в i-ю ячейку. Очевидно О(1).

    Допустим Z[k] больше или равно расстоянию до конца Z-блока. Тогда мы будем проверять h+1 символов правее конца нашего самого правого Z-блока. При этом окажется, что Z[i]=Z[k]+h, что при отсчете от i-ой позиции закончится дальше, чем текущий r-тый Z-блок на h позиций. А значит r-тый мы разжалуем и возьмем за любимый Z-блок этот самый новый Z[i]. Но он будет заканчиваться на h позиций дальше, а значит для этих h позиций мы схалтурим на следующих шагах с проверкой не сравнивая больше их для других суффиксов, так как по логике подобия Z-блоков такая обработка уже совершалась. Таким образом второй тип шага для каждого символа будет проделан 1 раз. Что и дает общую сложность O(n). Да, нет гарантии что каждый шаг выполнится за O(1), но общий все-таки O(n).
  • Поиск подстроки и смежные вопросы
    0
    1) a) Ну собственно так и считаю. Второй вариант совсем извращенный, хотя похоже тоже O(mn), если, конечно, он работает.
    б) Да, точно. Не углядел. Кстати, а это уже аргумент за «break» — он заметнее.

    2) Ну если так, то в принципе они и описаны. Динамическое программирование на рекуррентном соотношении дала бы именно такие алгоритмы. Собственно а в чем разница? Вы решаете n задачек нахождения некой функции в каждой точке. И для этого используете предыдущие результаты вычислений. В описаниях приведены правила перехода в i+1 позицию при наличии решений до 1..i позиций. Разве что само соотношение не записано, ибо условия, когда его применять, весьма муторно выписывать.
    Для Z-функции получилось бы в точности то самое. Для префикс-функции возможно получился бы какой-то побочный вариант вроде «сильной префикс функции» — когда результаты «откатов» назад протаскиваются вперед чтобы не повторять откаты. Но это был бы по сути такой же КМП.

    3) Если интересно, то вот здесь есть еще синонимы этой структуры. На мой взгляд «бор» — веселее. Бор — это же лес деревьев. Кроме того, более широко распространено.
  • Поиск подстроки и смежные вопросы
    0
    1) Ну хорошо, вот ваш пример который без «отката». Вот вы вошли во внутренний цикл, пощупали i+1-й символ, i+2-й, i+3-й, и тут бац! Облом. Не то. И дальше вы выходите и внутреннего и продолжаете с i+1-й позиции. И чем не откат назад? Вы же уже смотрели i+1, i+2 и т.д. символы. По логике то же самое, а код к тому месту, которое значилось как пример как делать не надо, я не писал :)
    Кстати, если бы сделали break во внутреннем цикле, то вышли бы гораздо раньше, а так даже если вторая буква из пятисот не совпала, вы все-равно все пятсот шерстите.

    2) Можно, но если что-то можно записать нерекурсивно, то зачем это делать рекурсией? И факториал рекурсивно считается, но зачем? Чтобы потом надеяться, что компилятор соптимизирует?

    3) Это одно и то же. Бор — это лес деревьев во всех смыслах. Как ни странно, это вполне употребимый термин.
  • Поиск подстроки и смежные вопросы
    0
    Спасибо! Поправил.
  • Поиск подстроки и смежные вопросы
    0
    Оба алгоритма просматривают строки последовательно. Т.е. оба найдут первое вхождение в общем случае раньше, чем обработают всю строку. Правда КМП обнаруживает конец вхождения, а Z-функция начало. В случае длинного шаблона поиска в этом будет разница на длину X (КМП обработает на |X| символов больше), если вы это имели ввиду.
  • Поиск подстроки и смежные вопросы
    +3
    Пожалуйста!

    Вообще, производительность методов эквивалентна. Z-функция в самом плохом случае выполняет 2|X|+2|A| сферических операций, а КМП — 3|X|+3|A|. Но наступление этих самых плохих ситуаций происходит при синтетических заготовках текста, например КМП обычно не три раза каждый символ смотрит, а полтора раза в среднем. В реальной жизни еще надо думать о каких именно операциях идет речь.
    А вообще эти алгоритмы интересны не столько тем, что они особо быстрые, сколько тем, что Z-функция и преффикс-функция используются в других алгоритмах работы со строками. А самым быстрым считают Бойера-Мура и его модификации, как утверждает википедия.