Over the next 10 minutes, Ono watched in stunned silence as the bot unfurled a solution in real time, showing its reasoning process along the way. The bot spent the first two minutes finding and mastering the related literature in the field. Then it wrote on the screen that it wanted to try solving a simpler “toy” version of the question first in order to learn. A few minutes later, it wrote that it was finally prepared to solve the more difficult problem. Five minutes after that, o4-mini presented a correct but sassy solution.
Я конечно хреновый математик, но лично я валидировать решение небанальной математической задачи не смогу если его передо мной будут разворачивать в режиме реального времени. В спокойной обстановке, без лишних людей вокруг, с пачкой бумаги и карандашом, - и то минут 30 может влёгкую уйти только чтобы въехать, в чём состоит решение и правильными ли объектами оперирует автор (+дьявол может быть в неявных допущениях), и от часа и больше на попытки составления контрпримеров и т.д.
Что они там за 10 минут умудрились осознать и провалидировать я понятия не имею, но очень сомневаюсь, что то, чем они занимались эти 10 минут, являлось анализом решения по существу.
Upd: виноват поторопился - бывают наборы векторов равной длины, дающие сумму 0 и не образующие правильный многоугольник. Причём наботы как с чётным, так и с нечётным кол-вом элементов.
С чётным кол-вом: вектора из центра прямоугольника в его углы С нечётным кол-вом: все положения часовых стрелок кроме 3,4,8,9,12. (равносторонний треугольник 2 6 10 + крест 1 5 7 11).
Суровые у вас девятиклассники... Имхо достаточно просто доказать лемму, что если сумма векторов равной длины, равна нулю, то концы этих векторов, исходящих из 1 точки, образуют правильный многоугольник. Далее противоречие с простотой p.
Выражение (rand() + rand() + rand()) / 3 всегда целочисленное (в C). Переменная RANDOM не указано какого типа, возможно что и float/double, в этом плане в ответе LLM нет ошибки. В случае RANDOM типа float/double произойдёт деление нацело (rand() + rand() + rand()) / 3 (не точное деление на 3 с плавающей точкой), результат будет преобразован во float/double и полученный float/double будет использован для инициализации RANDOM.
Я ошибся с изначальным комментом. С объяснением псевдослучайности/ нормального распределения всё ок. Небольшой недостаток ответа - не указано, что результат является целым числом, и не средним арифметическим, а результатом от деления нацело суммы 3 интов на 3. Например для "случайных" чисел 0, 0, 1 выражение вернёт 0 а не 1/3.
На rust я не вижу принципиального отличия от конструкции на go
Принципиальное отличие кода выше на Rust в том, что Rust гарантирует валидное значение переменной number в любом месте скоупа (при условии отсутствия unsafe блоков). Вызовом unwrap() разработчик явно подписывается, что при провале конвертации должна вызваться panic() и поток исполнения дальше не пойдёт.
Go же разрешит написать это ваше num, err := strconv.Atoi(str) и затем вместо условной обработки ошибки просто прибавить что-то к num без проверки err. Этот код свалится только во время выполнения.
PS: зачем две конвертации подряд, сначала i32 потом i64?? Этот код не эквивалентен коду на Go.
У команды Rust есть специальный документ под названием Edition guide, где они описывают что именно сломано между мажорными версиями :) Есть там и ваша фича, называется disjoint capture in closures:
Пофиксите логику авторизации :) слой с модальным окном, требующим авторизации на Github, убирается в пару кликов в ublock / browser devtools / ..., а под ним находится полностью доступный редактор доски.
Зачем вам эта авторизация вообще нужна??? я бы мб и пользовался вашей доской, например для быстрого зашаривания, но отсутствие анонимного доступа этому препятствует. У некоторых и github аккаунта нет.
Как вы отличаете tap dance от 2 быстро нажатых подряд обычных клавиш, когда юзер нажимает 2ю клавишу не успев отпустить 1ю? Именно если он подразумевает быстрый ввод 2 символов, а не активацию tap dance.
Это программное обеспечение, совместимое лишь с персональными компьютерами с операционными системами Windows и macOS.
На Linux есть неофициальный порт: Vinegar (порт Roblox Studio) и Sober (порт клиентского приложения Roblox Player). Ставил, всё работает, не без доп. действий конечно.
Как создать игру в Роблоксе на телефоне
Сурово. Даже если бы существовало такое ПО под смартфоны, я бы посмотрел на процесс разработки роблокс плагина на смартфоне...
Слева это роутер или мини пк или сонька? Зачем вам держать это устройство постоянно под рукой??? Не говоря уже о том, что лёгким движением руки его случайно можно отправить в полёт с левого края стола.
он достигает уже 100+МБ/с. Понятия не имею, в чём причина. Использование sudo значительно ускоряет скорость парсера.
Судя по отметке в 100 Mbps, больше похожей на типовое значение пропускной способности SSD, дело не в скорости парсинга (она должна быть на порядок выше этого значения даже на наивном парсере), а в том, что в тесте смешиваются скорость парсинга и скорость чтения с диска, и бутылочным горлышком является как раз i/o. При повторном запуске программа вероятно попадает в дисковый кэш. Sudo здесь ни при чём
Имхо параллелизм в данном коде на C# не поможет, тк пул задач здесь состоит из 100 млн мелких задач на несколько тактов CPU, программа больше потратит на синхронизацию тредов (при том что непохоже чтобы этот ConcurrentBag был lock free, не знаю как это вообще сделать для массива динамических строк неизвестной длины и непредсказуемой позиции в памяти, думаю он просто потокобезопасный и параллельной записи не происходит). Попробуйте выполнить свой код в 1 поток, очень подозреваю что быстродействие не изменится. Если уж сильно захотеть копать в сторону параллелизации, то имхо в первом приближении сработает грубый способ - написать код, который параллельно генерирует 8 одинаковых массивов размера 100000000/8 элементов (кусков результирующего массива).
На C# не умею писать, вот решение в лоб на C++ без потоков с вихрем Мерсенна в качестве ГПСЧ, выполняется 12 сек на моей машине: https://godbolt.org/z/bWEodGacv
ЯННП. Передавать объект "ошибка" через 100 уровней наверх, и обрабатывать его там, где теряется контекст ошибки, - антипаттерн. Если только высокоуровневая функция foo способна понять, что данные неверны, а bar и baz не способны, то какова альтернатива обработке этой ошибки в foo? Если её можно идентифицировать в bar, то почему foo а не bar занимается обработкой? Не обрабатывать делегированные ошибки - плохо. Как всё это дискредитирует оператор "?" я не понимаю. Исключения же вообще ортогональны обсуждению.
То есть из внешнего мира приходят недоверенные данные, а внутри приложения/бэкенда компоненты радостно общаются между собой всегда корректными данными через всегда неизменный API?
Я бы тоже хотел жить в стране единорогов, но увы не могу.
У вас мир такой простой, разработчик передал не валидную строку значит дурак. У меня в примере не "бебебе", а пустая строка, возникшая в результате ошибки возможно где-то посреди стека функций. Она может возникать в результате ввода определённых данных (валидных с ТЗ вызывающего и его кода).
Я конечно хреновый математик, но лично я валидировать решение небанальной математической задачи не смогу если его передо мной будут разворачивать в режиме реального времени. В спокойной обстановке, без лишних людей вокруг, с пачкой бумаги и карандашом, - и то минут 30 может влёгкую уйти только чтобы въехать, в чём состоит решение и правильными ли объектами оперирует автор (+дьявол может быть в неявных допущениях), и от часа и больше на попытки составления контрпримеров и т.д.
Что они там за 10 минут умудрились осознать и провалидировать я понятия не имею, но очень сомневаюсь, что то, чем они занимались эти 10 минут, являлось анализом решения по существу.
Upd: виноват поторопился - бывают наборы векторов равной длины, дающие сумму 0 и не образующие правильный многоугольник. Причём наботы как с чётным, так и с нечётным кол-вом элементов.
С чётным кол-вом: вектора из центра прямоугольника в его углы
С нечётным кол-вом: все положения часовых стрелок кроме 3,4,8,9,12. (равносторонний треугольник 2 6 10 + крест 1 5 7 11).
Суровые у вас девятиклассники... Имхо достаточно просто доказать лемму, что если сумма векторов равной длины, равна нулю, то концы этих векторов, исходящих из 1 точки, образуют правильный многоугольник. Далее противоречие с простотой p.
А аниме-то так и не зашарили. Или нынче образ Debian netinst идёт прямо с подборкой?
Выражение (rand() + rand() + rand()) / 3 всегда целочисленное (в C). Переменная RANDOM не указано какого типа, возможно что и float/double, в этом плане в ответе LLM нет ошибки. В случае RANDOM типа float/double произойдёт деление нацело (rand() + rand() + rand()) / 3 (не точное деление на 3 с плавающей точкой), результат будет преобразован во float/double и полученный float/double будет использован для инициализации RANDOM.
Я ошибся с изначальным комментом. С объяснением псевдослучайности/ нормального распределения всё ок. Небольшой недостаток ответа - не указано, что результат является целым числом, и не средним арифметическим, а результатом от деления нацело суммы 3 интов на 3. Например для "случайных" чисел 0, 0, 1 выражение вернёт 0 а не 1/3.
<del>
Принципиальное отличие кода выше на Rust в том, что Rust гарантирует валидное значение переменной number в любом месте скоупа (при условии отсутствия unsafe блоков). Вызовом unwrap() разработчик явно подписывается, что при провале конвертации должна вызваться panic() и поток исполнения дальше не пойдёт.
Go же разрешит написать это ваше
num, err := strconv.Atoi(str)и затем вместо условной обработки ошибки просто прибавить что-то к num без проверки err. Этот код свалится только во время выполнения.PS: зачем две конвертации подряд, сначала i32 потом i64?? Этот код не эквивалентен коду на Go.
У команды Rust есть специальный документ под названием Edition guide, где они описывают что именно сломано между мажорными версиями :) Есть там и ваша фича, называется disjoint capture in closures:
https://doc.rust-lang.org/edition-guide/rust-2021/disjoint-capture-in-closures.html
А clippy не выдал предупреждение, что где-то инкрементируется total_items, но затем никто его не читает?
Пофиксите логику авторизации :) слой с модальным окном, требующим авторизации на Github, убирается в пару кликов в ublock / browser devtools / ..., а под ним находится полностью доступный редактор доски.
Зачем вам эта авторизация вообще нужна??? я бы мб и пользовался вашей доской, например для быстрого зашаривания, но отсутствие анонимного доступа этому препятствует. У некоторых и github аккаунта нет.
Как вы отличаете tap dance от 2 быстро нажатых подряд обычных клавиш, когда юзер нажимает 2ю клавишу не успев отпустить 1ю? Именно если он подразумевает быстрый ввод 2 символов, а не активацию tap dance.
На Linux есть неофициальный порт: Vinegar (порт Roblox Studio) и Sober (порт клиентского приложения Roblox Player). Ставил, всё работает, не без доп. действий конечно.
Сурово. Даже если бы существовало такое ПО под смартфоны, я бы посмотрел на процесс разработки роблокс плагина на смартфоне...
Слева это роутер или мини пк или сонька? Зачем вам держать это устройство постоянно под рукой??? Не говоря уже о том, что лёгким движением руки его случайно можно отправить в полёт с левого края стола.
Судя по отметке в 100 Mbps, больше похожей на типовое значение пропускной способности SSD, дело не в скорости парсинга (она должна быть на порядок выше этого значения даже на наивном парсере), а в том, что в тесте смешиваются скорость парсинга и скорость чтения с диска, и бутылочным горлышком является как раз i/o. При повторном запуске программа вероятно попадает в дисковый кэш. Sudo здесь ни при чём
Рабочее место прямо суровое. Деревянный стул и столик 1x1м
Имхо параллелизм в данном коде на C# не поможет, тк пул задач здесь состоит из 100 млн мелких задач на несколько тактов CPU, программа больше потратит на синхронизацию тредов (при том что непохоже чтобы этот ConcurrentBag был lock free, не знаю как это вообще сделать для массива динамических строк неизвестной длины и непредсказуемой позиции в памяти, думаю он просто потокобезопасный и параллельной записи не происходит). Попробуйте выполнить свой код в 1 поток, очень подозреваю что быстродействие не изменится. Если уж сильно захотеть копать в сторону параллелизации, то имхо в первом приближении сработает грубый способ - написать код, который параллельно генерирует 8 одинаковых массивов размера 100000000/8 элементов (кусков результирующего массива).
На C# не умею писать, вот решение в лоб на C++ без потоков с вихрем Мерсенна в качестве ГПСЧ, выполняется 12 сек на моей машине:
https://godbolt.org/z/bWEodGacv
Ведущий разработчик компании ВСК:
ЯННП. Передавать объект "ошибка" через 100 уровней наверх, и обрабатывать его там, где теряется контекст ошибки, - антипаттерн. Если только высокоуровневая функция foo способна понять, что данные неверны, а bar и baz не способны, то какова альтернатива обработке этой ошибки в foo? Если её можно идентифицировать в bar, то почему foo а не bar занимается обработкой? Не обрабатывать делегированные ошибки - плохо. Как всё это дискредитирует оператор "?" я не понимаю. Исключения же вообще ортогональны обсуждению.
То есть из внешнего мира приходят недоверенные данные, а внутри приложения/бэкенда компоненты радостно общаются между собой всегда корректными данными через всегда неизменный API?
Я бы тоже хотел жить в стране единорогов, но увы не могу.
У вас мир такой простой, разработчик передал не валидную строку значит дурак. У меня в примере не "бебебе", а пустая строка, возникшая в результате ошибки возможно где-то посреди стека функций. Она может возникать в результате ввода определённых данных (валидных с ТЗ вызывающего и его кода).