Выражение (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?
Я бы тоже хотел жить в стране единорогов, но увы не могу.
У вас мир такой простой, разработчик передал не валидную строку значит дурак. У меня в примере не "бебебе", а пустая строка, возникшая в результате ошибки возможно где-то посреди стека функций. Она может возникать в результате ввода определённых данных (валидных с ТЗ вызывающего и его кода).
При чём здесь тесты, я говорю про код самой ф-и. По спеке от него или будет требоваться валидация входной строки или нет. Если не будет, то не надо сравнивать код на Perl без валидации с кодом на Rust, делающим валидацию. Иначе я на Rust напишу без валидации let total = price.unsafe_parse() * quantity.unsafe_parse() (если уж хочется принимать строку, а не сразу принять int и быть свободным от перлопроблем) и скажу что Rust не сильно и длиннее. Если требуется валидация, то как я уже сказал на стороне перла в споре будет участвовать далеко не однострочник.
Да, только результатом такого превращения обычно становится код, обложенный велосипедами для валидации. И вы возвращаетесь к исходной задаче с Perl vs Rust, только со стороны перла у вас теперь не однострочник, а уже код гм побольше.
Адепты динамической типизации обычно куда-то пропадают, когда речь заходит о:
Больших проектах на миллионы строк со сложной логикой. Отличный пример с $price * $quantity кстати. Сегодня всё работает нормально, завтра вы уволились и никто больше не знает что одна из кор библиотек делает небезопасное умножение строк как чисел, а послезавтра разработчик кода 2 уровнями логики выше (и 10 уровнями выше по стеку вызовов) допустит, нет, не поминаемую вами ошибку типизации с передачей строки вместо инта. Просто ошибку. Но в результате этой ошибки в вашу функцию в качестве $quantity придёт пустая строка, которую Perl спокойно интерпретирует как 0 и вернёт 0. И пустая строка будет приходить не гарантированно, а в определённой фазе луны и в ситуации, не покрытой тестами. Удачи с отладкой.
Разработке библиотек, т.е. о ситуации где вы не знаете в каких условиях будет применяться ваш код и у вас не будет права делать предположения о важности или неважности некорректной работы вашей программы на некорректных входных данных.
А аниме-то так и не зашарили. Или нынче образ 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?
Я бы тоже хотел жить в стране единорогов, но увы не могу.
У вас мир такой простой, разработчик передал не валидную строку значит дурак. У меня в примере не "бебебе", а пустая строка, возникшая в результате ошибки возможно где-то посреди стека функций. Она может возникать в результате ввода определённых данных (валидных с ТЗ вызывающего и его кода).
При чём здесь тесты, я говорю про код самой ф-и. По спеке от него или будет требоваться валидация входной строки или нет. Если не будет, то не надо сравнивать код на Perl без валидации с кодом на Rust, делающим валидацию. Иначе я на Rust напишу без валидации let total = price.unsafe_parse() * quantity.unsafe_parse() (если уж хочется принимать строку, а не сразу принять int и быть свободным от перлопроблем) и скажу что Rust не сильно и длиннее. Если требуется валидация, то как я уже сказал на стороне перла в споре будет участвовать далеко не однострочник.
Да, только результатом такого превращения обычно становится код, обложенный велосипедами для валидации. И вы возвращаетесь к исходной задаче с Perl vs Rust, только со стороны перла у вас теперь не однострочник, а уже код гм побольше.
Адепты динамической типизации обычно куда-то пропадают, когда речь заходит о:
Больших проектах на миллионы строк со сложной логикой. Отличный пример с $price * $quantity кстати. Сегодня всё работает нормально, завтра вы уволились и никто больше не знает что одна из кор библиотек делает небезопасное умножение строк как чисел, а послезавтра разработчик кода 2 уровнями логики выше (и 10 уровнями выше по стеку вызовов) допустит, нет, не поминаемую вами ошибку типизации с передачей строки вместо инта. Просто ошибку. Но в результате этой ошибки в вашу функцию в качестве $quantity придёт пустая строка, которую Perl спокойно интерпретирует как 0 и вернёт 0. И пустая строка будет приходить не гарантированно, а в определённой фазе луны и в ситуации, не покрытой тестами. Удачи с отладкой.
Разработке библиотек, т.е. о ситуации где вы не знаете в каких условиях будет применяться ваш код и у вас не будет права делать предположения о важности или неважности некорректной работы вашей программы на некорректных входных данных.