Неудобно читать, потому что в разных запросах разные названия таблиц (t1/table1). Также в самом первом EXPLAIN-е два WHERE - это опечатка?
Что касается запроса:
Как заметили выше, левые джоины там не нужны.
Структура БД слегка подозрительная. table1 ссылается на table2, table2 на table3, table3 на table4 по первичному ключу. Кажется, что в такой ситуации в каждой последующей таблице должно быть не больше записей, чем в предыдущей, но из explain-ов видно, что в table1 проверяется 475k записей, а в table4 их 22M. Откуда лишние записи? Не стоит ли разделить какую-то из таблиц на несколько или просто почистить?
Необязательно писать в селекте именно ту таблицу, из которой нужно выбрать данные. Например, если, скажем, в какой-нибудь из таблиц в цепочке мало записей, можно попробовать джойнить остальные таблицы к ней.
Однако O(1) сложность из такого выражения законна, если имеется ввиду что X и Y это не "слагаемые из разрядов" а ДВЕ автономные ячейки переменных для АЛУ в которых все ведущие нули СЧИТАЮТСЯ но зато гарантируется что больше или меньше разрядов не будет
Это неверно. Во втором комментарии (у меня он показывается прямо над вашим) я дополнил, что О-большое символика неприменима к конечным множествам чисел. В частности, ко всем числам, которые помещаются в ячейку.
Подумайте еще над тем что в реальности вы не управляете тем в какой системе счисления считает АЛУ, да у вас есть биты которыми представлены данные но доступ у программиста только к представлению
Для анализа алгоритмической сложности система счисления в целом не имеет значения (за исключением, наверное, некоторых алгоритмов, связанных с теорией чисел).
Игрок при использовании переключателя видит перед собой результат действия.
Это тоже нарушается повсеместно и во многих случаях нормального решения этой проблемы нет.
Это где? Не припомню такого в первом Думе. И вообще во всех официальных классических Думах, кроме, возможно,TNT: Evilution.
Например если проход закрыт колоннами цвета ключа и открывается при наличии ключа на месте или же требует нажатия какой-то кнопки с ключом в каком-то другом месте карты.
Если проход закрыт объектом цвета ключа, это означает, что, чтобы открыть проход, нужен соответствующий ключ. Это не значит, что нужно нажимать на сам объект, кнопка может быть где-то рядом. Опять же, в первом думе нет ситуаций, что кнопка непонятно где "в другом месте карты".
в плане того куда игроку нужно идти в игре всё не так хорошо. Да, если игрок нашел дверь одного из трёх цветов, то это именно то место, куда нужно идти после нахождения соответствующего ключа - на этом логика заканчивается - где искать ключ вообще не понятно.
Когда непонятно, куда идти, и нужно исследовать уровень, это именно "хорошо". Плохо - это когда большая надпись на карте "вам сюда" и один коридор без ответвлений, который ведёт в то место.
Но заметьте, большинства этих проблем не было до внедрения этой поголовной компьютеризации. То есть она создает видимость освобождения человека от банальной рутины жизни, но взамен приносит еще больше искусственных проблем, на которые приходится тратить жизнь.
А никакой инновационный бизнес в принципе иначе работать и не может. Исследования требуют денег и не гарантируют положительный результат. Это не кафе открыть, которое через полгода отобъёт все затраты.
зачем вносить излишнюю сложность ..для того, что можно решить с помощью всего 20 строк простого кода?
Ответ, на мой взгляд, такой: решение, изложенное в статье, пишется за 15 минут и полностью удовлетворяет требованиям, которые есть здесь и сейчас. Когда понадобятся более сложные метрики, такое решение можно просто и относительно безболезненно выкинуть и начать думать в сторону БД.
Не стоит бояться одноразовых решений для конкретных задач. Потому что а) в определённых обстоятельствах всё равно придётся всё переделывать из-за изменившихся требований, и б) выкидывать решение, сделанное за 15 минут не так обидно, как если разработчики потратили месяцы на сложное решение, а бизнесу нужно срочно масштабироваться, а бизнесу нужно масштабироваться вниз.
Потом наверное сокурсник вспомнил что он мужчина, подождал вашего тимлида после работы, и вдумчиво объяснил что в следующий раз сломает ему руку ? Потому что если бы он молчал - было бы очевидно что дает зеленый свет на такие шутки.
Серьёзно? По-вашему, так нужно решать проблемы? Угрожать сломать руку или безропотно терпеть - выглядит, как ложная дихотомия. Не говоря уже о том, что первый вариант грозит проблемами с законом. Хорошо ещё, что не предолжили ей самой "вспомнить, что она женщина, и подсыпать цианистого калия в кофе тимлиду".
Поэтому нет и не будет никакого равенства. Когда кто-то кого-то называет "токсичным" - другой человек так же может воспринимать такое поведение "токсичным".
Следовательно, прежде, чем хоть как-то взаимодействовать с любым человеком, нужно выяснить, как он хочет, чтобы с ним взаимодействовали, и делать соответственно. Элементарно же)
А потом посмотрите на формальное доказательство Квиксорта. Я думаю вы этот алгоритм тоже понимаете. Доказательство там по настоящему взрослое.
Формальное доказательство алгоритма означает абсолютно конкретную штуку. Математическое доказательство вашего алгоритма как любой теоремы.
Вы, наверное, имеете в виду конкретно доказательство, подходящее для верификации. Обычное-то математическое доказательство должно быть довольно простым - с использованием индукции по длине массива (которую при верфикации, конечно, не применить).
Фальсифицируемость - это критерий оценки знания. Вот ваше личное знание субъективно или объективно? А знания человечества или, например, физического научного сообщества - они субъективны или объективны?
Гибкость снижает скорость разработки, это вечный компромисс. Если бы это было не так то все бы писали на чистом js, и не было бы ни реакта, ни vue, ведь нет ничего гибче чистого js.
Эта скорость появляется только из-за переиспользования кода: зачем писать с нуля что-то для чего есть библиотека. С императивными языками это работает. Но о каком переиспользовании речь в случае вёрстки? Дают вам дизайн сайта в jpg и говорят "сверстай" - что ускорит использование tailwind?
Пару лет назад я пытался прикрутить BEM к React, и мне не удалось это сделать, что меня сильно удивило.
Это как? Вроде стилизация в Реакте не отличается от обычного HTML: пишешь jsx-элемент с атрибутом className, подключаешь в этом компоненте css-файл (а то и sass), а там стили для этого класса. Или я что-то путаю?
Также я не понял вашу мысль насчёт работы с переменными.
Но для изменения всех цветов на сайте или всех отступов придется заранее прописывать все CSS-переменные и распространять их по всему коду.
На мой взгляд, все типичные цвета, отступы наборы шрифтов и т.п. в проекте и так должны быть определены в одном месте. Это примерно так же как использовать константы вместо волшебных чисел в императивных языках программирования. Опять же, это могут быть sass-переменные: при необходимости из них легко сделать css-перменные.
Некоторые считают, что BEM и Tailwind не противоречат друг другу. Да, их можно технически смешивать вместе, но это разные архитектуры. ... Такая смешанная архитектура должна быть хорошо продумана. Но я пока не видел НИ ОДНОЙ статьи по архитектуре Tailwind, чего уж говорить об архитектуре Tailwind + BEM.
Мне это кажется немного сомнительным. БЭМ с элементами несемантической вёрстки можно применять, но конкретно по канонам tailwind же один класс - это в среднем примерно одно css-свойство. Проще написать его в стили блока.
Раз уж вы процитировали мой комментарий в статье, хочу ещё кое что пояснить.
Ваши замечания:
UPD: Как хорошо подметили в комментариях, если у нас безразмерные целые числа, то понятно, что ты за один такт процессора их не сложить даже на современных процессорах.
Но если мы говорим про Int64, то это определенно O(1), а если это безразмерный Int то логарифм более похож на правду.
Если открыть учебник по матанализу за первый курс и посмотреть, что вообще такое О-большое, то нетрудно увидеть, что в его определении используется понятие предела (стремления). Например, применительно к оценке сложности алгритмов, когда говорится f(n) = O(g(n)), (где n - длина данных на входе), подразумевается поведение функции f при n стремящемся к бесконечности. Для любого конечного множества, например, для целых чисел, помещающихся в Int64, понятие О-большого не имеет смысла.
Причём, это оганичение существенно: непонятно, как распространить определение на конечное множество так, чтобы получилось что-то полезное. Например, дальше автор рассуждает про "ассимптотическую сложность" умножения и деления, но если и здесь речь про Int64, то сложность тоже в некотором смысле константная: я смогу подобрать такую константу, что умножение любых двух чисел из Int64 в неё заведомо уложится.
Если автор статьи имел в виду, что на современных процессорах скорость сложения и умножения встроенных чисел зависит от их длины определенным образом, нужно было так и сказать, а не пользоваться математическими терминами.
Теоретически мы можем отправить астронавта смертника внутрь черной дыры (дыра должна быть большой, чтобы его не разорвало). Он сможет наблюдать все своими глазами. Да, он не сможет рассказать об этом нам, но сам все увидит. Имеем ли мы право давать предпочтение нам над гибнущим астронавтом только потому, что ему осталось недолго? Не должны ли мы рассматривать все сознания равными в праве быть свидетелем мироздания?
Может быть, и должны, но к критерию фальсифицируемости не относится. Фальсифицируемость имеет смысл только для самого рассуждающего. Что бы ни увидел космонавт в чёрной дыре, для наблюдателей снаружи дыры заведомо ничего не изменится и нового знания не появится.
То есть, несмотря на теоретическую фальсифицируемость, нет никакой практической надежды проверить эту теорию экспериментально.
Вы, наверное, имели в виду "опровергнуть", а не "проверить", не так ли?)
Поэтому, так как она сложнее ОТО, мы ее вырезаем бритвой Оккама?
Что значит "вырезаем"? Если все проверяемые (опровергаемые) предсказания теории Эйнштейна-Картана действительно неотличимы от ОТО, значит они взаимозаменяемы: пользуясь одной мы пользуемся другой и наоборот.
Итак, что если теория фальсифицируема, но при таких условиях, что экспериментальная проверка невозможна?
Ну так и что, если?
В целом, мне кажется, в не вполне правильно понимаете смысл фальсифицируемости.
Упомянутые "более 100 тысяч", насколько я понял, это суммарно по всем магазинам, а не только Steam.
Учитывая популярность Стима и топ-10 попродажам, там легко может быть больше 100k продаж, а во всех остальных магазинах - незначительные остатки. По оценкам всяких сервисов (https://steamdb.info/app/2532550/charts/), 100k - это даже нижняя граница.
Про то, что больших проблем с покупками в Стиме нет, уже написали.
Почему правило «если мне 20 раз выпал орёл, то в 21-ый точно выпадет решка», в действительности, не работает
В смысле, «правило»? Заголовок звучит, как "Почему правило «2 + 2 = 5» в действительности не работает" :)
А не работает, просто потому что вероятность каждый раз 50%, не? Вся комбинаторика, с помощью которой вы пытаетесь это объяснять, не имеет особого отношения к математике процесса, а является следствием независимости событий и заданной вероятности.
Например, вот этот абзац:
Если же нас интересует вероятность конкретной комбинации -- то мы делаем то же самое, но возводим в степень не количество вариантов, а шанс конкретного. Шанс того, что кубик выдаст тройку -- 1/6, шанс получить орла -- 1/2. Таким образом, вероятность получить последовательность из трёх орлов равна 0.5^3 == 0.125
Если события броска не являются независимыми, это оъсяснение не подходит, а если являются, оно не требуется, так как и так понятно, что вероятность не меняется.
Это почти наверняка. Но не через десять лет, конечно; скорее, через сто.
За пределами крупных городов дикая территория, где творится полное беззаконие. Порядок устанавливается различными ЧВК и бандформированиями.
А это точно нет. Вне городов будет, в основном, лес. Непонятно, зачем какой-то банде находиться посреди тайги и что там делать. Звучит, как совершенно невыгодное занятие.
Почему-то тогда сельхоз страны самые бедные и нищие?
Если вы посмотрите статистику, то увидите, что крупнейшими экспортёрами еды являются развитые страны, а также Китай, Россия и Бразилия. Так что нет, страны с развитым сельским хозяйством - довольно богатые.
Неудобно читать, потому что в разных запросах разные названия таблиц (t1/table1). Также в самом первом EXPLAIN-е два WHERE - это опечатка?
Что касается запроса:
Как заметили выше, левые джоины там не нужны.
Структура БД слегка подозрительная. table1 ссылается на table2, table2 на table3, table3 на table4 по первичному ключу. Кажется, что в такой ситуации в каждой последующей таблице должно быть не больше записей, чем в предыдущей, но из explain-ов видно, что в table1 проверяется 475k записей, а в table4 их 22M. Откуда лишние записи? Не стоит ли разделить какую-то из таблиц на несколько или просто почистить?
Необязательно писать в селекте именно ту таблицу, из которой нужно выбрать данные. Например, если, скажем, в какой-нибудь из таблиц в цепочке мало записей, можно попробовать джойнить остальные таблицы к ней.
Это неверно. Во втором комментарии (у меня он показывается прямо над вашим) я дополнил, что О-большое символика неприменима к конечным множествам чисел. В частности, ко всем числам, которые помещаются в ячейку.
Для анализа алгоритмической сложности система счисления в целом не имеет значения (за исключением, наверное, некоторых алгоритмов, связанных с теорией чисел).
Это где? Не припомню такого в первом Думе. И вообще во всех официальных классических Думах, кроме, возможно,TNT: Evilution.
Если проход закрыт объектом цвета ключа, это означает, что, чтобы открыть проход, нужен соответствующий ключ. Это не значит, что нужно нажимать на сам объект, кнопка может быть где-то рядом. Опять же, в первом думе нет ситуаций, что кнопка непонятно где "в другом месте карты".
Когда непонятно, куда идти, и нужно исследовать уровень, это именно "хорошо". Плохо - это когда большая надпись на карте "вам сюда" и один коридор без ответвлений, который ведёт в то место.
Это какие проблемы, например?
А как это вообще проверить в C?
А никакой инновационный бизнес в принципе иначе работать и не может. Исследования требуют денег и не гарантируют положительный результат. Это не кафе открыть, которое через полгода отобъёт все затраты.
Ответ, на мой взгляд, такой: решение, изложенное в статье, пишется за 15 минут и полностью удовлетворяет требованиям, которые есть здесь и сейчас. Когда понадобятся более сложные метрики, такое решение можно просто и относительно безболезненно выкинуть и начать думать в сторону БД.
Не стоит бояться одноразовых решений для конкретных задач. Потому что а) в определённых обстоятельствах всё равно придётся всё переделывать из-за изменившихся требований, и б) выкидывать решение, сделанное за 15 минут не так обидно, как если разработчики потратили месяцы на сложное решение, а бизнесу нужно срочно масштабироваться, а бизнесу нужно масштабироваться вниз.
Серьёзно? По-вашему, так нужно решать проблемы? Угрожать сломать руку или безропотно терпеть - выглядит, как ложная дихотомия. Не говоря уже о том, что первый вариант грозит проблемами с законом. Хорошо ещё, что не предолжили ей самой "вспомнить, что она женщина, и подсыпать цианистого калия в кофе тимлиду".
Следовательно, прежде, чем хоть как-то взаимодействовать с любым человеком, нужно выяснить, как он хочет, чтобы с ним взаимодействовали, и делать соответственно. Элементарно же)
Вы, наверное, имеете в виду конкретно доказательство, подходящее для верификации. Обычное-то математическое доказательство должно быть довольно простым - с использованием индукции по длине массива (которую при верфикации, конечно, не применить).
Фальсифицируемость - это критерий оценки знания. Вот ваше личное знание субъективно или объективно? А знания человечества или, например, физического научного сообщества - они субъективны или объективны?
Эта скорость появляется только из-за переиспользования кода: зачем писать с нуля что-то для чего есть библиотека. С императивными языками это работает. Но о каком переиспользовании речь в случае вёрстки? Дают вам дизайн сайта
в jpgи говорят "сверстай" - что ускорит использование tailwind?Это как? Вроде стилизация в Реакте не отличается от обычного HTML: пишешь jsx-элемент с атрибутом className, подключаешь в этом компоненте css-файл (а то и sass), а там стили для этого класса. Или я что-то путаю?
Также я не понял вашу мысль насчёт работы с переменными.
На мой взгляд, все типичные цвета, отступы наборы шрифтов и т.п. в проекте и так должны быть определены в одном месте. Это примерно так же как использовать константы вместо волшебных чисел в императивных языках программирования. Опять же, это могут быть sass-переменные: при необходимости из них легко сделать css-перменные.
Мне это кажется немного сомнительным. БЭМ с элементами несемантической вёрстки можно применять, но конкретно по канонам tailwind же один класс - это в среднем примерно одно css-свойство. Проще написать его в стили блока.
@splincodewd
Раз уж вы процитировали мой комментарий в статье, хочу ещё кое что пояснить.
Ваши замечания:
Если открыть учебник по матанализу за первый курс и посмотреть, что вообще такое О-большое, то нетрудно увидеть, что в его определении используется понятие предела (стремления). Например, применительно к оценке сложности алгритмов, когда говорится f(n) = O(g(n)), (где n - длина данных на входе), подразумевается поведение функции f при n стремящемся к бесконечности. Для любого конечного множества, например, для целых чисел, помещающихся в Int64, понятие О-большого не имеет смысла.
Причём, это оганичение существенно: непонятно, как распространить определение на конечное множество так, чтобы получилось что-то полезное. Например, дальше автор рассуждает про "ассимптотическую сложность" умножения и деления, но если и здесь речь про Int64, то сложность тоже в некотором смысле константная: я смогу подобрать такую константу, что умножение любых двух чисел из Int64 в неё заведомо уложится.
Если автор статьи имел в виду, что на современных процессорах скорость сложения и умножения встроенных чисел зависит от их длины определенным образом, нужно было так и сказать, а не пользоваться математическими терминами.
Может быть, и должны, но к критерию фальсифицируемости не относится. Фальсифицируемость имеет смысл только для самого рассуждающего. Что бы ни увидел космонавт в чёрной дыре, для наблюдателей снаружи дыры заведомо ничего не изменится и нового знания не появится.
Вы, наверное, имели в виду "опровергнуть", а не "проверить", не так ли?)
Что значит "вырезаем"? Если все проверяемые (опровергаемые) предсказания теории Эйнштейна-Картана действительно неотличимы от ОТО, значит они взаимозаменяемы: пользуясь одной мы пользуемся другой и наоборот.
Ну так и что, если?
В целом, мне кажется, в не вполне правильно понимаете смысл фальсифицируемости.
Учитывая популярность Стима и топ-10 попродажам, там легко может быть больше 100k продаж, а во всех остальных магазинах - незначительные остатки. По оценкам всяких сервисов (https://steamdb.info/app/2532550/charts/), 100k - это даже нижняя граница.
Про то, что больших проблем с покупками в Стиме нет, уже написали.
В смысле, «правило»? Заголовок звучит, как "Почему правило «2 + 2 = 5» в действительности не работает" :)
А не работает, просто потому что вероятность каждый раз 50%, не? Вся комбинаторика, с помощью которой вы пытаетесь это объяснять, не имеет особого отношения к математике процесса, а является следствием независимости событий и заданной вероятности.
Например, вот этот абзац:
Если события броска не являются независимыми, это оъсяснение не подходит, а если являются, оно не требуется, так как и так понятно, что вероятность не меняется.
О настоящих причинах чего?
Это почти наверняка. Но не через десять лет, конечно; скорее, через сто.
А это точно нет. Вне городов будет, в основном, лес. Непонятно, зачем какой-то банде находиться посреди тайги и что там делать. Звучит, как совершенно невыгодное занятие.
Если вы посмотрите статистику, то увидите, что крупнейшими экспортёрами еды являются развитые страны, а также Китай, Россия и Бразилия. Так что нет, страны с развитым сельским хозяйством - довольно богатые.