Нам нужно искать слова с опечатками и просто похожие варианты, и поиск не ограничивается только словами русского / английского языка. Например, на запрос "65U710KB" нужно предложить вариант "65U790KB", если ничего лучшего не было найдено.
Это поиск не для пользователей интернет-магазина, а для администраторов, и такой поиск упрощает их работу.
Простите, не так вас понял. Да, это можно. Конкретно в нашей ситуации сначала проще докупать память на одном сервере, чем делать масштабирование. До 256 ГБ можно докупить, дальше упираемся в ограничения используемого железа.
Если же делать из этого публичное решение, то конечно, масштабирование необходимо.
Все просто, горизонтальное масштабирование позволит хранить больше данных, но не позволит MS SQL Server быстрее искать по полнотекстовому индексу. Вызов функции Containstable на таком объеме данных занимает 98% времени обработки запроса, то есть, по сути те 2-5 секунд, о которых я писал вначале, и принципиально его не ускорить. Вместо этого мы сделали метод, который работает за 10 миллисекунд, эта часть ускорилась в 200-500 раз.
А что до ограничений памяти сервера, то аренда сервера с 64 гигабайтами стоит 50 евро в месяц. И ещё запас для роста в 2 раза остался.
Я не знаю, при помощи какого инструмента можно добиться такого результата "из коробки".
Поискал в Гугле, нашел упоминание 18000, 20000 как максимальных оборотов в минуту, и 6150 как оборотов в минуту, на которых достигается максимальная мощность, но это не конкретно plaid.
Спрашиваю потому что 60000 rpm - это очень много, это 1000 оборотов в секунду. По грубым прикидкам в уме при такой скорости вращения большого мотора напряжения в материале выше предела текучести стали. Конечно, есть и другие материалы, но все же непонятно, ради чего нужно преодолевать столько сложностей.
Как писали представители проекта Event Horizon Telescope, разрешения, достигнутого в проекте (25 микродуговых секунд), достаточно, чтобы читать газету в Нью-Йорке, находясь в уличном кафе в Париже.
Если понимать 25 микродуговых секунд как 25 микросекунд дуги, линейное разрешение на расстоянии 5800 км составит 42 миллиметра. При стандартной ширине полосы газеты, равной 300 миллиметров, это 7 пикселей в ширину. В общем, вот.
Попробую дать определение определенному поведению для C++20: это поведение, закрепленное в стандарте International Standard ISO/IEC 14882:2020(E) – Programming Language C++.
То, что поведение не меняется со временем, к определенному поведению отношения не имеет, если стандарт не предусматривает однозначного поведения для такой ситуации. Даже если какой-то код ведет себя одинаково с любым известным компилятором и любой известной средой выполнения, но стандарт не предусматривает однозначного поведения в такой ситуации - это все равно неопределенное поведение.
Я не спорю с тезисом про разные проекции, но пример с Африкой и Евразией не понял. На контурных картах, насколько я помню, Евразия была больше Африки. В реальности Евразия больше Африки.
Возможно, вы имели в виду пример с Россией (или СССР) и Африкой. В этом случае, если по памяти, то на карте они примерно одинаковой площади, хотя в реальности Африка значительно больше.
Я на прошлом месте работы за 3 года удалил кода больше, чем добавил. И это при том, что основной была все же работа над новыми фичами.
Нас таких было двое, и делали мы это под свою ответственность. Остальные избегали удалять старый код или делать хоть минимальный рефакторинг. На самом деле, я не берусь сказать на сто процентов, что мы были правы, а они нет. Но это был интересный опыт.
Пока думал над задачей, возник такой вопрос: если подойти максимально формально, то есть, если единственная разрешённая операция построения — чертить прямую через выбранные две точки, то можно ли вообще гарантированно построить прямую, не проходящую через пятно?
То есть, проблема в следующем: выбрали одну точку, выбрали другую точку, пробуем провести прямую - и не можем, потому что она пересекает пятно. И так постоянно. По идее, при таком наборе разрешенных операций нет вариантов "выберем точку поближе" или "выберем точку в другой стороне".
Когда-то пробовал играть, и вывод — по таким правилам играть неинтересно.
Вся игра сводится к поиску табличек, указателей и вывесок, и скоростному гуглингу. Угадывая таким образом все места с точностью плюс-минус двадцать метров, в итоге получаешь сравнимый с другими игроками результат. Но гуглить на скорость неинтересно.
Можно не гуглить, но тогда нет соревновательного момента, результаты всегда хуже, чем у 90% игроков.
Возможно, есть версия с запретом на перемещение? В нее я бы залип. Но я ничего такого не нашел.
Пользуюсь Вивальди на Андроид 10, в самом Андроиде выбрано управление жестами. При такой схеме что свайп слева направо, что свайп справа налево работают одинаково — аналогично кнопке "назад". А вы не думали использовать свайп справа налево для перехода вперёд по истории, если это технически возможно? Так работает в Сафари, и кажется более интуитивным и удобным.
По сути, мы именно это и сделали, только на уровне триграмм, а не слов.
Можно, на протяжении года так и работало. Потом нас перестала устраивать скорость работы такого подхода.
Нам нужно искать слова с опечатками и просто похожие варианты, и поиск не ограничивается только словами русского / английского языка. Например, на запрос "65U710KB" нужно предложить вариант "65U790KB", если ничего лучшего не было найдено.
Это поиск не для пользователей интернет-магазина, а для администраторов, и такой поиск упрощает их работу.
Мы пока загрузили 20 ГБ памяти, и ядра практически никак не загружены.
Простите, не так вас понял. Да, это можно. Конкретно в нашей ситуации сначала проще докупать память на одном сервере, чем делать масштабирование. До 256 ГБ можно докупить, дальше упираемся в ограничения используемого железа.
Если же делать из этого публичное решение, то конечно, масштабирование необходимо.
Все просто, горизонтальное масштабирование позволит хранить больше данных, но не позволит MS SQL Server быстрее искать по полнотекстовому индексу. Вызов функции Containstable на таком объеме данных занимает 98% времени обработки запроса, то есть, по сути те 2-5 секунд, о которых я писал вначале, и принципиально его не ускорить. Вместо этого мы сделали метод, который работает за 10 миллисекунд, эта часть ускорилась в 200-500 раз.
А что до ограничений памяти сервера, то аренда сервера с 64 гигабайтами стоит 50 евро в месяц. И ещё запас для роста в 2 раза остался.
Я не знаю, при помощи какого инструмента можно добиться такого результата "из коробки".
Перепроверил.
Прошу прощения у всех, кто мне поверил. Вы правы, я действительно посчитал микроминуты вместо микросекунд.
Та же газета в правильном разрешении.
Я не догадался и погуглил. Картинка остроумная.
Если вы тоже не догадались и читаете этот комментарий, рекомендую подумать, задача интересная.
А точно будет 60000 rpm?
Поискал в Гугле, нашел упоминание 18000, 20000 как максимальных оборотов в минуту, и 6150 как оборотов в минуту, на которых достигается максимальная мощность, но это не конкретно plaid.
Спрашиваю потому что 60000 rpm - это очень много, это 1000 оборотов в секунду. По грубым прикидкам в уме при такой скорости вращения большого мотора напряжения в материале выше предела текучести стали. Конечно, есть и другие материалы, но все же непонятно, ради чего нужно преодолевать столько сложностей.
Если понимать 25 микродуговых секунд как 25 микросекунд дуги, линейное разрешение на расстоянии 5800 км составит 42 миллиметра. При стандартной ширине полосы газеты, равной 300 миллиметров, это 7 пикселей в ширину. В общем, вот.
А вместо старшего грузчика? То-то и оно!
Ок, удавили углекислый газ, но что с ним делать дальше? Не хранить же в цистернах под давлением.
Какие вообще есть варианты?
Попробую дать определение определенному поведению для C++20: это поведение, закрепленное в стандарте International Standard ISO/IEC 14882:2020(E) – Programming Language C++.
То, что поведение не меняется со временем, к определенному поведению отношения не имеет, если стандарт не предусматривает однозначного поведения для такой ситуации. Даже если какой-то код ведет себя одинаково с любым известным компилятором и любой известной средой выполнения, но стандарт не предусматривает однозначного поведения в такой ситуации - это все равно неопределенное поведение.
Я не спорю с тезисом про разные проекции, но пример с Африкой и Евразией не понял. На контурных картах, насколько я помню, Евразия была больше Африки. В реальности Евразия больше Африки.
Возможно, вы имели в виду пример с Россией (или СССР) и Африкой. В этом случае, если по памяти, то на карте они примерно одинаковой площади, хотя в реальности Африка значительно больше.
Я на прошлом месте работы за 3 года удалил кода больше, чем добавил. И это при том, что основной была все же работа над новыми фичами.
Нас таких было двое, и делали мы это под свою ответственность. Остальные избегали удалять старый код или делать хоть минимальный рефакторинг. На самом деле, я не берусь сказать на сто процентов, что мы были правы, а они нет. Но это был интересный опыт.
Пока думал над задачей, возник такой вопрос: если подойти максимально формально, то есть, если единственная разрешённая операция построения — чертить прямую через выбранные две точки, то можно ли вообще гарантированно построить прямую, не проходящую через пятно?
То есть, проблема в следующем: выбрали одну точку, выбрали другую точку, пробуем провести прямую - и не можем, потому что она пересекает пятно. И так постоянно. По идее, при таком наборе разрешенных операций нет вариантов "выберем точку поближе" или "выберем точку в другой стороне".
Когда-то пробовал играть, и вывод — по таким правилам играть неинтересно.
Вся игра сводится к поиску табличек, указателей и вывесок, и скоростному гуглингу. Угадывая таким образом все места с точностью плюс-минус двадцать метров, в итоге получаешь сравнимый с другими игроками результат. Но гуглить на скорость неинтересно.
Можно не гуглить, но тогда нет соревновательного момента, результаты всегда хуже, чем у 90% игроков.
Возможно, есть версия с запретом на перемещение? В нее я бы залип. Но я ничего такого не нашел.
Дополню предыдущего комментатора, не только вкладки, но и кнопки экспресс-панели и выпадающий список подсказок в адресной строке.
Пользуюсь Вивальди на Андроид 10, в самом Андроиде выбрано управление жестами. При такой схеме что свайп слева направо, что свайп справа налево работают одинаково — аналогично кнопке "назад". А вы не думали использовать свайп справа налево для перехода вперёд по истории, если это технически возможно? Так работает в Сафари, и кажется более интуитивным и удобным.