Это комментарий (не целиком) к посту habrahabr.ru/post/118262, который больше недоступен.
Его получилось найти через Wayback Machine в чьих-то сохраненных комментариях.
А там ниже был еще более заплюсованный комментарий про фиолетовые ссылки.
Ну почему же, отличный пример того, как можно использовать данные. Ценность-то не в анализе таксопарка, а в примере того, как из данных можно извлечь новую информацию. Не обязательно анализировать поездки на такси, можно применить подход в другой отрасли. Из статьи понятно, что не обязательно обкалываться матаном для такого анализа, достаточно базового понимания теории вероятности.
Тут подробно о том, как сопоставляем товары из разных источников: habr.com/ru/post/456604
Тут подробно о том, как заполняем характеристики: habr.com/ru/post/499684
Если кратко, то распарсили пару сотен сайтов и 25 миллионов товаров на данный момент (+3 миллиона в месяц в среднем), а дальше автоматически сопоставляем товары и заполняем характеристики.
Да, все так. К сожалению, автоматом мы не сможем определить, что расстояние между креплениями — это критически важно, а бренд — нет. Но если свойств в категории немного, то расстояние все равно будет учитываться с большим относительным весом. У меня на этот счет есть такая идея: позволить человеку отмечать важные свойства для таких категорий. И для них мы не будем считать вес автоматически, а возьмем заведомо большое число.
Пока мы этого не делали, потому что рассматривали этот функционал как возможность получить полезный результат вообще без ручной работы, и оценить его востребованность клиентами. В дальнейшем будем экспериментировать, я думаю.
А пробовали открыть страницу https://accounts.google.com/DisplayUnlockCaptcha?
Я не пробовал именно для вивальди, но когда нужно было забирать почту с гугла из своего кода, это сработало. Но гуглил долго.
Перерабатывать никто не требует. Ну разве что случится что-то экстраординарное — например, новая фича должна заехать в срок в связи с изменениями законодательства. Некоторые сотрудники по своей инициативе вечером или в выходной берутся сделать что-то сверх рабочих задач. Стараемся следить, конечно, чтобы ребята не выгорали, отдыхать тоже важно.
Я посмотрел видео и интуитивно понял, что подразумевается под прямой линией на поверхности многогранника, но более-менее строгого определения дать не могу, к сожалению.
Но, мне кажется, это определение является ключевым для понимания, о чем вообще речь в статье. Может быть, кто-то может помочь с формулировкой?
Сделаю попытку:
1. Действие происходит на плоской развертке многогранника
2. Отрезки, которые являются границами развертки, разбиты на пары, и им присвоено направление таким образом, что при склеивании они совпадают (т.е. по сути это не отрезки, а векторы)
3. Если искомый луч (x) пересекает один из векторов пары (a), то он продолжается (y) из точки на втором векторе (b), расположенной на одинаковом расстоянии от его начала, при этом сумма углов между (x и a) и (y и b) равна пи.
Я вижу разницу, и да, я узнал, где настоящие, а где поддельные. И видел её раньше, просто пользуясь телефоном.
И это проблема, потому что мне эта форма неприятна. Глаз цепляется за неидеальность окружности, непрямую границу, и эффект получается аналогичный картинкам серии «ад перфекциониста».
Кожа рыб настолько же хороша в этом отношении, как и VantaBlack — самое черное вещество из всех, что были когда-либо созданы человеком. Но структура VantaBlack крайне сложна — там и углеродные нанотрубки, и специальная структура, и специфические свойства самого материала. Здесь же природа использовала то, что известно всем — меланин, и сделала это крайне эффективно.
Это неправда. Ну да, 99.5 и 99.96 на первый взгляд близки. А сравните 0.5 и 0.04 — разница уже на порядок.
10-20к RPS — это с данными в памяти, да.
А что касается функции, то, не вдаваясь в нюансы, такая будет соответствовать условиям с перестановками. С пропусками — нет, там другой алгоритм, не все сводится к хэшам.
public static int GetHash(string s){
return GetHash(s.Split(' '));
}
public static int GetHash(IEnumerable<string> tokens)
{
long hash = 0;
foreach (var token in tokens.Distinct())
{
hash ^= token.GetHashCode();
}
return hash;
}
Мы не генерируем перестановки, хэш-функция, которая не чувствительна к порядку, вполне с этим справляется.
Вариант с пропущенными токенами обрабатывается позже.
Что касается скорости, то на относительно современном ноутбуке (i5-7300HQ) сопоставляется 10 тысяч записей в секунду. С сохранением результатов в базу — 2-5 тысячи в секунду. Обработка 2.5 миллионов цен занимает около 5-10 минут.
Замысел состоит в том, что есть простые, быстрые и точные способы сопоставить товары. Например, полное совпадение названий. Потом совпадение названий с точностью до перестановок (с оговоркой, что существует единственный вариант). И если сработал один из этих способов, то результат у нас есть, и дальше обрабатывать товар не нужно. Естественно, это работает не всегда, на одних данных ничего не дает, на других дает 10% сопоставлений.
Не все названия из примера дадут одинаковый хэш. Но после алгоритма с хэшированием есть еще другие, которые могут сопоставить эти товары.
Нет, конкретно sphinx не пробовали.
Я не работал с sphinx, но elastic или full text search нам не подходят по следующим причинам:
Скорость. Я не знаю, как достичь 10 000 сопоставлений в секунду
Гибкость. Мы потратили несколько месяцев, придумывая алгоритмы, подбирая оптимальные параметры, тестируя каждое изменение. Я не знаю, как можно настроить, например, больший приоритет у токенов, которые содержат и буквы, и числа.
Со sphinx (или другим универсальным движком) можно получить результат быстрее. Писать что-то свое узкоспециализированное было долго и сложно, но, думаю, это было правильным выбором с учетом нашей цели обрабатывать десятки миллионов товаров в день.
Но если пойти по этому пути до конца, так и до машинных кодов дойти можно. А там и хаскель жадным окажется.
Питон скрыл сложность внутреннего устройства генератора за простым интерфейсом. Вы знаете, что под капотом там жадный код, но есть ли какие-то следствия из этого для пользователя интерфейса? А если нет, то в чем принципиальная разница генератора и ленивой функции?
Это комментарий (не целиком) к посту habrahabr.ru/post/118262, который больше недоступен.
Его получилось найти через Wayback Machine в чьих-то сохраненных комментариях.
А там ниже был еще более заплюсованный комментарий про фиолетовые ссылки.
Кстати, а кто-то знает, почему пост недоступен даже в архиве? web.archive.org/web/20120328165322/http://habrahabr.ru/post/118262/
Тут подробно о том, как заполняем характеристики: habr.com/ru/post/499684
Если кратко, то распарсили пару сотен сайтов и 25 миллионов товаров на данный момент (+3 миллиона в месяц в среднем), а дальше автоматически сопоставляем товары и заполняем характеристики.
Да, все так. К сожалению, автоматом мы не сможем определить, что расстояние между креплениями — это критически важно, а бренд — нет. Но если свойств в категории немного, то расстояние все равно будет учитываться с большим относительным весом. У меня на этот счет есть такая идея: позволить человеку отмечать важные свойства для таких категорий. И для них мы не будем считать вес автоматически, а возьмем заведомо большое число.
Пока мы этого не делали, потому что рассматривали этот функционал как возможность получить полезный результат вообще без ручной работы, и оценить его востребованность клиентами. В дальнейшем будем экспериментировать, я думаю.
Я не пробовал именно для вивальди, но когда нужно было забирать почту с гугла из своего кода, это сработало. Но гуглил долго.
Такому бизнесу и Stackoverflow — разработчик подойдет.
Но, мне кажется, это определение является ключевым для понимания, о чем вообще речь в статье. Может быть, кто-то может помочь с формулировкой?
Сделаю попытку:
1. Действие происходит на плоской развертке многогранника
2. Отрезки, которые являются границами развертки, разбиты на пары, и им присвоено направление таким образом, что при склеивании они совпадают (т.е. по сути это не отрезки, а векторы)
3. Если искомый луч (x) пересекает один из векторов пары (a), то он продолжается (y) из точки на втором векторе (b), расположенной на одинаковом расстоянии от его начала, при этом сумма углов между (x и a) и (y и b) равна пи.
И это проблема, потому что мне эта форма неприятна. Глаз цепляется за неидеальность окружности, непрямую границу, и эффект получается аналогичный картинкам серии «ад перфекциониста».
Это неправда. Ну да, 99.5 и 99.96 на первый взгляд близки. А сравните 0.5 и 0.04 — разница уже на порядок.
А что касается функции, то, не вдаваясь в нюансы, такая будет соответствовать условиям с перестановками. С пропусками — нет, там другой алгоритм, не все сводится к хэшам.
Вариант с пропущенными токенами обрабатывается позже.
Что касается скорости, то на относительно современном ноутбуке (i5-7300HQ) сопоставляется 10 тысяч записей в секунду. С сохранением результатов в базу — 2-5 тысячи в секунду. Обработка 2.5 миллионов цен занимает около 5-10 минут.
Не все названия из примера дадут одинаковый хэш. Но после алгоритма с хэшированием есть еще другие, которые могут сопоставить эти товары.
Я не работал с sphinx, но elastic или full text search нам не подходят по следующим причинам:
Со sphinx (или другим универсальным движком) можно получить результат быстрее. Писать что-то свое узкоспециализированное было долго и сложно, но, думаю, это было правильным выбором с учетом нашей цели обрабатывать десятки миллионов товаров в день.
Питон скрыл сложность внутреннего устройства генератора за простым интерфейсом. Вы знаете, что под капотом там жадный код, но есть ли какие-то следствия из этого для пользователя интерфейса? А если нет, то в чем принципиальная разница генератора и ленивой функции?
Я не знаю питон, вопрос без подвоха.