Если изменение состояния часов происходит раз в минуту (т. е. минутная ходит по 1/60 круга, а часовая — по 1/720), то получаем дополнительное ограничение , которое оставляет одно или два решения.
Или предполагается, что одна стрелка движется рывками, а другая непрерывно?
Совершенно согласен с тем, что в будущем и в психологии, и в медицине искусственный интеллект будет занимать всё большее место.
Что касается конкретной теории, то, увы, она слишком похожа на «простое объяснение всего на свете», а не на научную гипотезу — хотя бы отсутствием статистически достоверных экспериментальных данных. Ведь корреляцию цветовых предпочтений с какими-либо особенностями характера проверить совсем несложно. Где же статьи с революционными открытиями? Поделитесь ссылками?
Но, повторюсь, с точки зрения выпускного проекта это совершенно неважно. А важно то, что редактор корпоративного блога не уделил достаточно внимания хорошему оформлению материала. Я мало что знаю об OTUS'е и подобная небрежность оставляет довольно неприятное впечатление. Уверен, что Ваше исследование не заслуживает такого отношения.
Довольно сомнительная с точки зрения научности тема — это ещё можно пережить. В конце концов, если никакими экспериментами предложенная теория не обосновывается (я, во всяком случае, найти быстро не смог), то применение машинного обучения вполне сойдёт за какое-никакое, но обоснование.
Но, чёрт возьми, код скриншотами, практически никаких технических подробностей, картинки с не вполне внятными подписями... Так себе реклама, как по мне.
Статья прямо как телемагазин: сначала обозначает проблему, затем драматизирует её до предела («Движок в сто раз больше полезной нагрузки!»), а затем предлагает блестящее решение — без подробностей, замеров производительности и прочих обоснований. Честно говоря, к концу я перестал понимать, что автор называет сайт, а что — движок и какую проблему вообще решает. Но и это ещё не всё: зачем vendor со всеми пакетами лежит в репозитории?
Вы совершенно правы, и именно поэтому статья располагается в разделе "ненормальное программирование". Практических целей у дальнейших оптимизаций нет, просто было интересно.
При реальном бане с запасом хватает скорости наивной реализации, а бан делается пачкой через ipset, потому что добавление правил по одному в iptables, конечно же, сильно тормозит (в том числе и обработку длинной цепочки правил). Кстати, в README репозитория есть инструкции на этот счёт.
Если взять просто разделение строк по memchr, то производительность выходит порядка 0,26Гб/0,173 с = ~1,5 Гб/с.
В оригинальной статье про simdjson указано, что на Skylake@3,4GHz парсинг происходил со скоростью 2,2Гб/с. На виртуалке тоже Skylake, но на частоте 2,3GHz, что при пересчёте даёт те же 1,5 Гб/с.
Таким образом, если задействовать AVX, который использует memchr , и делить на строки одновременно с парсингом, то, думаю, схожей производительности можно и добиться. Как-нибудь надо будет попробовать...
А 12 Гб/с simdjson достигает, судя по той же таблице на с. 17, на select, то есть выборке из уже разобранного дерева. Кстати, в этом он не чемпион, его обгоняет sajson.
Кстати, логи можно собирать с нескольких серверов. nginx умеет логировать в rsyslog, а тот умеет пересылать логи по сети.
В имеющейся схеме парсер логов запускается раз в минуту, и чем меньше времени (и, соответственно, ресурсов) он будет отъедать при разборе накопившегося — тем лучше.
Да, это точно. Я полагаю, что даже простое изменение формата лога (просто в виде IP/datetime) сильно бы помогло производительности. Но интересно было решать задачу именно с заданным форматом.
Лично меня очень путала разница = / := (и ещё можно пользоваться var, а можно и нет). А читать мешает то, что тип указывается после переменной/параметра, но без двоеточия. Для меня привычно смотрятся варианты bool a (как в C/Java/PHP) и a: bool (как в Паскале/Python/TypeScript). А вот Go в обоих случаях идёт особым путём.
Насколько я понимаю, если писать с Just так, как обычно пишут на JS, то все чудеса быстродействия сойдут на нет. И, похоже, проект писался специально под бенчмарк (в отличие от большинства прочих представленных там фреймворков).
P.S. Пару недель назад добрался, наконец, до Rust Book и влюбился. Интересно, удастся ли ему набрать достаточно популярности?
Если настроить «натуральные» (2:1) октавы на фортепиано, то биения будут из-за того, что реальные струны несколько отличаются от идеальных, и гармоники у них не вполне совпадают с натуральным звукорядом. Поэтому октавы на фортепиано растягивают при настройке.
Это я к тому, что математические абстракции неизбежно спотыкаются об реальную акустику (в меньшей степени) и психоакустику (в большей степени). И игнорирование реальности приводит к очередным идеальным системам, не имеющим отношение к реальной жизни.
Если изменение состояния часов происходит раз в минуту (т. е. минутная ходит по 1/60 круга, а часовая — по 1/720), то получаем дополнительное ограничение
, которое оставляет одно или два решения.
Или предполагается, что одна стрелка движется рывками, а другая непрерывно?
Да, по сути это то же самое. При этом для меня, честно говоря, комплексную экспоненту гораздо проще визуализировать в контексте часовых задач.
Какое любопытное графическое решение! Но и тут требуется дополнительный шаг, чтобы убрать «задвоение» 12 часов
Как неожиданно приятно, спасибо за комментарий!
Совершенно согласен с тем, что в будущем и в психологии, и в медицине искусственный интеллект будет занимать всё большее место.
Что касается конкретной теории, то, увы, она слишком похожа на «простое объяснение всего на свете», а не на научную гипотезу — хотя бы отсутствием статистически достоверных экспериментальных данных. Ведь корреляцию цветовых предпочтений с какими-либо особенностями характера проверить совсем несложно. Где же статьи с революционными открытиями? Поделитесь ссылками?
Но, повторюсь, с точки зрения выпускного проекта это совершенно неважно. А важно то, что редактор корпоративного блога не уделил достаточно внимания хорошему оформлению материала. Я мало что знаю об OTUS'е и подобная небрежность оставляет довольно неприятное впечатление. Уверен, что Ваше исследование не заслуживает такого отношения.
Довольно сомнительная с точки зрения научности тема — это ещё можно пережить. В конце концов, если никакими экспериментами предложенная теория не обосновывается (я, во всяком случае, найти быстро не смог), то применение машинного обучения вполне сойдёт за какое-никакое, но обоснование.
Но, чёрт возьми, код скриншотами, практически никаких технических подробностей, картинки с не вполне внятными подписями... Так себе реклама, как по мне.
Статья прямо как телемагазин: сначала обозначает проблему, затем драматизирует её до предела («Движок в сто раз больше полезной нагрузки!»), а затем предлагает блестящее решение — без подробностей, замеров производительности и прочих обоснований. Честно говоря, к концу я перестал понимать, что автор называет сайт, а что — движок и какую проблему вообще решает. Но и это ещё не всё: зачем
vendorсо всеми пакетами лежит в репозитории?Вы совершенно правы, и именно поэтому статья располагается в разделе "ненормальное программирование". Практических целей у дальнейших оптимизаций нет, просто было интересно.
При реальном бане с запасом хватает скорости наивной реализации, а бан делается пачкой через
ipset, потому что добавление правил по одному вiptables, конечно же, сильно тормозит (в том числе и обработку длинной цепочки правил). Кстати, в README репозитория есть инструкции на этот счёт.Если взять просто разделение строк по
memchr, то производительность выходит порядка 0,26Гб/0,173 с = ~1,5 Гб/с.В оригинальной статье про simdjson указано, что на Skylake@3,4GHz парсинг происходил со скоростью 2,2Гб/с. На виртуалке тоже Skylake, но на частоте 2,3GHz, что при пересчёте даёт те же 1,5 Гб/с.
Таким образом, если задействовать AVX, который использует
memchr, и делить на строки одновременно с парсингом, то, думаю, схожей производительности можно и добиться. Как-нибудь надо будет попробовать...А 12 Гб/с simdjson достигает, судя по той же таблице на с. 17, на
select, то есть выборке из уже разобранного дерева. Кстати, в этом он не чемпион, его обгоняет sajson.Кстати, логи можно собирать с нескольких серверов.
nginxумеет логировать вrsyslog, а тот умеет пересылать логи по сети.В имеющейся схеме парсер логов запускается раз в минуту, и чем меньше времени (и, соответственно, ресурсов) он будет отъедать при разборе накопившегося — тем лучше.
Да, это точно. Я полагаю, что даже простое изменение формата лога (просто в виде IP/datetime) сильно бы помогло производительности. Но интересно было решать задачу именно с заданным форматом.
Лично меня очень путала разница
=/:=(и ещё можно пользоватьсяvar, а можно и нет). А читать мешает то, что тип указывается после переменной/параметра, но без двоеточия. Для меня привычно смотрятся вариантыbool a(как в C/Java/PHP) иa: bool(как в Паскале/Python/TypeScript). А вот Go в обоих случаях идёт особым путём.Это, кажется, дело вкуса. По моим ощущениям в сравнении с C/Java/PHP оба достаточно инопланетные.
Кстати, меня удивило, что количество строк практическо одинаковое (700 и 711), при том, что Go продвигается именно под соусом "простоты".
А в чём ещё проще?
Кстати, а чем Go удобнее для Вас?
Присоединяюсь к идее открыть максимум данных
И на промежуточный вариант тоже было бы интересно посмотреть.
Спасибо! Было бы интересно прочитать более подробное описание, если это возможно
Если я правильно нашёл в тексте, то это «съёмный магнитный диск», то есть подходят дискеты любого размера.
А если серьёзно, то я правильно понял, что запатентован примерно тот же метод, что был описан в посте несколько лет назад?
Насколько я понимаю, если писать с Just так, как обычно пишут на JS, то все чудеса быстродействия сойдут на нет. И, похоже, проект писался специально под бенчмарк (в отличие от большинства прочих представленных там фреймворков).
P.S. Пару недель назад добрался, наконец, до Rust Book и влюбился. Интересно, удастся ли ему набрать достаточно популярности?
Если настроить «натуральные» (2:1) октавы на фортепиано, то биения будут из-за того, что реальные струны несколько отличаются от идеальных, и гармоники у них не вполне совпадают с натуральным звукорядом. Поэтому октавы на фортепиано растягивают при настройке.
Это я к тому, что математические абстракции неизбежно спотыкаются об реальную акустику (в меньшей степени) и психоакустику (в большей степени). И игнорирование реальности приводит к очередным идеальным системам, не имеющим отношение к реальной жизни.