Как раз эта самая. Вопрос же был, "то плохого в акции, которой мне или вам лень воспользоваться."
Индикатор такой. Если есть акция — это значит что все остальное с большой вероятностью дороже. Если есть возможность(увы, сейчас практически невозможно) — лучше в магазин с акцией не ходить, чтобы его прибыль не увеличивать и такое поведение не поощрять.
Мне вот не очевидно, что прибыль получается с того товара, на который делается скидка. Скорее поверю, что скидку делают на одно (чтобы народ привлечь), а на все остальное, что попутно покупают, цену повышают, чтобы общая сумма покупки больше была.
Деньги, потраченные/не заработанные магазином за счет акции не из воздуха берутся. Они собираются с остальных, кому лень. Т.е. они с большой вероятностью потратят чуточку больше денег, чем могли бы.
Многие ли будут коллекционировать крышки? Я, например, не готов ;)
Такой-нельзя. Если скидкой нельзя или слишком сложно воспользоваться — это значит, что ее никогда почти никогда не дают и она ни на что не влиете.
Гораздо хуже, когда скидкой может и хочет воспользоваться достаточное количество народа… но это не ты. Ибо это означает, что их скидка — в значительной мере за твой счет. Как кэшбек, кстати. Из чьих денег он в конечном счете платится?
Кажется, уже были статьи, что это не просто в одной компании. А что торговые сети уже настолько приучили людей к этим акциям и они стали настолько выгодны покупателям (потому что не сам покупатель следит за всем этим, а приложение), что без акций (т.е. без упоминания магазина в этом приложении) покупатели уже не идут.
И торговые сети на сложившуюся ситуацию жалуются. Приходится и акции делать и этим приложениям-агрегаторам-рекламщикам платить. Смешно, да.
Предлагаете в Тесле требовать нажатия определенной кнопки каждые N минут?
Ну хотя бы.
А какое у гужевого решение? «Куда она из колеи денется?» (с)
Ну хорошо, не только гужевого.
Когда верхом едут — тут тоже 'автопилот' явно присутствует. И вероятность, когда транспортное средство само что-то сделала и кого-нибудь зашибло (окружающих или 'водителя') — тоже имеется.
Так что все вопросы, что, к железному автопилоту есть — уже давно решались.
Потому что когда косишь, часть листьев все-таки остается?
А эта штука, если верить картинками и видео, выжигает молодые всходы сорняков на корню. Если делать так достаточно часто и достаточно долго, то, наверное, сорняки все-таки рано или поздно сдохнут. Или будут сильно мельче нужной культуры и не дадут семян.
Зачем со всеми остальными то? Это как утверждать, что при сортировке надо очередной элемент сравнивать со всеми остальными, хотя это далеко не так. Нет, понятно, что для чисел и прочих подобных им само отношение порядка помогает. Но группировки требование " каждый-с каждым" тоже сомнительно.
В моем примере: если в текущем корне дерева некий баг от которого настал конец света — то в левую сторону от него будут все похожие баги (т.е. которые тоже к концу света приводят), с дальнейшим дроблениям по причинам. А в правую сторону — те, что не приводят. И сравнивать первые со вторыми как бы уже не надо.
Тут нужно понимать, что какую-то группировку мы так или иначе получим. Хотя бы в виде 'номер категории — последняя цифра номера бага'. Берем и пользуемся.
Если нам 'какая-то' не нужна, и к ней есть некие требования по 'разумности', то эти самые требования сразу лимитируют, что с чем сравнивать стоит или не стоит.
Грубо говоря, у нас есть операция попарного 'сравнения': "Относится ли issue A к той же группе, что issue B".
Дальше смотрим, как строится бинарное дерево сортировки. Там n^2 попарных сравнений, если я правильно помню, не требуется. Если приблизительно похожим способом генерировать категории (то что похоже — в левую кучку, не похоже — в правую. Время от времени issue-корень-категории меняем, чтобы перебалансировать глубину классификации) — то будет приблизительно с той же сложностью.
Как то не очень воодушевляет, что diff для настолько мелких изменений (фактически, 'вместо объекта класса A используй объект класса B') так плохо в экран помещается.
И что так все-таки с ревью? Где и как можно написать "не надо этот сервис дергать, все умрет"?.
Именно эта библиотечная, насколько я понимаю, была придумана во первых, давно и, во вторых, больше для удобства и однозначности расстановки по шкафам. А удобство поиска в каталоге 'найти что-то по теме' — это немного меньше учитывали.
В современных условиях можно категории для нужд хранения просто лексикографически по ISBN использовать, а поиск — полнотекстовым индексированием делать.
100к багов 95к — это трейсы, а 5к — заполненные человеком багрепорты.
Которые успешно попадают в 5% 'прочие'. Которой категории потом, если уж нас так ручные багрепорты заинтересовали (после сортировки по категориям) и присваивается приоритет 'важная'. Если же ручные багрепорты интересуют больше еще до начала сортировки — то и соответствующая категория создается сразу.
Кроме того, если заранее есть требование 'все что 5% — должно заметить и поместить в собственную категорию', то и размер sample исходя из этого требования подсчитывается.
Прошу объяснить. Почему нельзя 27Gb/s c тем спутником что на западе, и еще 27Gb/s — с тем, что на востоке. Антенны же везде направленные и западная линия восточную вроде бы видеть не должна.
Предположим, что у нас 100к багов, среди них есть 100, заслуживающих 5 важных категорий.
Как бы не может быть. 100 из 100k — это категория 'прочие' из-за явной редкости.
Хотя, по большому счету, мы во всем этом обсуждении забываем вопрос 'а какой цели эта категоризация служить должна?' и что слово "категория" у нас означает.
Кому какой баг назначим? Значит категорий не более количество человек в проекте.
В каком модуле бага? Значит категорий не больше количество модулей
итд итп.
Как видно, в некоторых вариантах категории вообще создаются не глядя на сами баги.
И опять же на мой взгляд вы вряд ли наберёте 200 тысяч или тем более 2 миллиона багов если у вас нет каких-то серьёзных проблем с архитектурой/технологией.
Пример придумать легко. Берем какую-нибудь буровую платформу. Целиком, не только софт, что там в чипах живет. Я подозреваю, что 2 миллиона багов и требований (опять же, не только софтовых) ко всей этой конструкции — это будет даже мало.
Можно повторить то же самое для любой большой и дорогой железки, которую десятками лет строят.
Как раз эта самая. Вопрос же был, "то плохого в акции, которой мне или вам лень воспользоваться."
Индикатор такой. Если есть акция — это значит что все остальное с большой вероятностью дороже. Если есть возможность(увы, сейчас практически невозможно) — лучше в магазин с акцией не ходить, чтобы его прибыль не увеличивать и такое поведение не поощрять.
Мне вот не очевидно, что прибыль получается с того товара, на который делается скидка. Скорее поверю, что скидку делают на одно (чтобы народ привлечь), а на все остальное, что попутно покупают, цену повышают, чтобы общая сумма покупки больше была.
Деньги, потраченные/не заработанные магазином за счет акции не из воздуха берутся. Они собираются с остальных, кому лень. Т.е. они с большой вероятностью потратят чуточку больше денег, чем могли бы.
Такой-нельзя. Если скидкой нельзя или слишком сложно воспользоваться — это значит, что ее никогда почти никогда не дают и она ни на что не влиете.
Гораздо хуже, когда скидкой может и хочет воспользоваться достаточное количество народа… но это не ты. Ибо это означает, что их скидка — в значительной мере за твой счет. Как кэшбек, кстати. Из чьих денег он в конечном счете платится?
Кажется, уже были статьи, что это не просто в одной компании. А что торговые сети уже настолько приучили людей к этим акциям и они стали настолько выгодны покупателям (потому что не сам покупатель следит за всем этим, а приложение), что без акций (т.е. без упоминания магазина в этом приложении) покупатели уже не идут.
И торговые сети на сложившуюся ситуацию жалуются. Приходится и акции делать и этим приложениям-агрегаторам-рекламщикам платить. Смешно, да.
Ну хотя бы.
Ну хорошо, не только гужевого.
Когда верхом едут — тут тоже 'автопилот' явно присутствует. И вероятность, когда транспортное средство само что-то сделала и кого-нибудь зашибло (окружающих или 'водителя') — тоже имеется.
Так что все вопросы, что, к железному автопилоту есть — уже давно решались.
Проблема же давно решена у 'водителей' железнодорожного транспорта, нет?
И у водителей гужевого. Там 'машина' тоже в значительной мере сама едет.
Потому что когда косишь, часть листьев все-таки остается?
А эта штука, если верить картинками и видео, выжигает молодые всходы сорняков на корню. Если делать так достаточно часто и достаточно долго, то, наверное, сорняки все-таки рано или поздно сдохнут. Или будут сильно мельче нужной культуры и не дадут семян.
Зачем со всеми остальными то? Это как утверждать, что при сортировке надо очередной элемент сравнивать со всеми остальными, хотя это далеко не так. Нет, понятно, что для чисел и прочих подобных им само отношение порядка помогает. Но группировки требование " каждый-с каждым" тоже сомнительно.
В моем примере: если в текущем корне дерева некий баг от которого настал конец света — то в левую сторону от него будут все похожие баги (т.е. которые тоже к концу света приводят), с дальнейшим дроблениям по причинам. А в правую сторону — те, что не приводят. И сравнивать первые со вторыми как бы уже не надо.
Тут нужно понимать, что какую-то группировку мы так или иначе получим. Хотя бы в виде 'номер категории — последняя цифра номера бага'. Берем и пользуемся.
Если нам 'какая-то' не нужна, и к ней есть некие требования по 'разумности', то эти самые требования сразу лимитируют, что с чем сравнивать стоит или не стоит.
n^2 не нужно.
Грубо говоря, у нас есть операция попарного 'сравнения': "Относится ли issue A к той же группе, что issue B".
Дальше смотрим, как строится бинарное дерево сортировки. Там n^2 попарных сравнений, если я правильно помню, не требуется. Если приблизительно похожим способом генерировать категории (то что похоже — в левую кучку, не похоже — в правую. Время от времени issue-корень-категории меняем, чтобы перебалансировать глубину классификации) — то будет приблизительно с той же сложностью.
Как то не очень воодушевляет, что diff для настолько мелких изменений (фактически, 'вместо объекта класса A используй объект класса B') так плохо в экран помещается.
И что так все-таки с ревью? Где и как можно написать "не надо этот сервис дергать, все умрет"?.
Так как все-так выглядит решение вопроса "что тут у нас изменилось с прошлой версии процесса?" покажите картинку
Ну и, за компанию — как выглядит собственно ревью к этим изменениям "вот тут нужно было делать не так, а вот так..", коль скоро утверждается, что
А кто бы сказал. Tут (Wikipedia): 'Class 700 — Arts and recreation'
EDIT: Пройдя по ссылкам на оригинальную статью (gutenberg.org)
Чтобы храниться в той части библиотеки, что в здании факультета изящных искусств находится.
Так это именно вопрос цели классификации.
Именно эта библиотечная, насколько я понимаю, была придумана во первых, давно и, во вторых, больше для удобства и однозначности расстановки по шкафам. А удобство поиска в каталоге 'найти что-то по теме' — это немного меньше учитывали.
В современных условиях можно категории для нужд хранения просто лексикографически по ISBN использовать, а поиск — полнотекстовым индексированием делать.
Которые успешно попадают в 5% 'прочие'. Которой категории потом, если уж нас так ручные багрепорты заинтересовали (после сортировки по категориям) и присваивается приоритет 'важная'. Если же ручные багрепорты интересуют больше еще до начала сортировки — то и соответствующая категория создается сразу.
Кроме того, если заранее есть требование 'все что 5% — должно заметить и поместить в собственную категорию', то и размер sample исходя из этого требования подсчитывается.
Прошу объяснить. Почему нельзя 27Gb/s c тем спутником что на западе, и еще 27Gb/s — с тем, что на востоке. Антенны же везде направленные и западная линия восточную вроде бы видеть не должна.
Как бы не может быть. 100 из 100k — это категория 'прочие' из-за явной редкости.
Хотя, по большому счету, мы во всем этом обсуждении забываем вопрос 'а какой цели эта категоризация служить должна?' и что слово "категория" у нас означает.
Кому какой баг назначим? Значит категорий не более количество человек в проекте.
В каком модуле бага? Значит категорий не больше количество модулей
итд итп.
Как видно, в некоторых вариантах категории вообще создаются не глядя на сами баги.
Однако классификацию книг как-то сумели сделать, не сравнивая каждую книгу с каждой (те самые θ(n*n))
Пример придумать легко. Берем какую-нибудь буровую платформу. Целиком, не только софт, что там в чипах живет. Я подозреваю, что 2 миллиона багов и требований (опять же, не только софтовых) ко всей этой конструкции — это будет даже мало.
Можно повторить то же самое для любой большой и дорогой железки, которую десятками лет строят.