Имеются в виду оптимизации от противного. Signed overflow надо как-то обязательно проверять (так как есть консенсус, как обрабатывать это неопределенное поведение), даже если это выделенная инструкция ассемблера с флагами overflow.
Половина современной крифтографии была бы невозможна, если бы математики не «assumed Riemann hypothisis», т.е. есть принимали её как правду БЕЗ ДОКАЗАТЕЛЬСТВА. Если не дай бог она оказывается ложной это будет катастрофой. en.wikipedia.org/wiki/Miller%E2%80%93Rabin_primality_test
Тест Миллера без Rabin-а зависит от правдивости гипотезы.
Так же как теорема о модулярности (частный случай этой теоремы это Теорема Ферма, а сама теоремы это частный случай abc гипотезы) это ключевая гипотеза всех точных наук.
Наоборот. Там либо баг в компиляторе будет (без возможности обойти) либо огромная утечка памяти причем неустранимая, так как извините но gc у нас не умеет так.
А вообще-то вы понимаете, что бесконечная петля или неправильное чтение или еще что (почитайте последние баги в turbo jpeg репозитории) это как бы и не баг с точки зрения компилятора, но DoS вы такой получите, мало не покажется.
Но вообще да можно написать jpeg быстрее, но по-первых, а вы учли CMYK? А ICC код? А код YCbCr to R'G'B' у вас идеальный? А математически совместима библиотека с jpeg reference 6? А с 9? А как насчет garbage in not grabage out? От последнего даже turbo jpeg отказались! А как насчет lossless jpeg, которых 6 видов? Мда. А как насчет center chroma location для FIR для 4:2:0?
И еще построчная загрузка на лету с сети обязательно нужна!
Для библиотек обычно нужно и 32 бит и 64 бит. Как и на ПК.
Canary обновляется каждый день у меня. Всё норм.
Chrome Canary как работал, так и работает. Он обновляется каждый день.
Т.е. поставить Split apk вы не можете. Canary никто не блокирует.
Не работает. Пару дней назад блокнули v2 snowflake опять.
Chrome Canary только сегодня обновил.
https://jsfiddle.net/dj643whu/1/
Недоступен.
И вот это. Хорошо хоть его можно в Visual Studio 2022 скопилировать. http://audiophilesoft.ru/load/coders_utils/qaac/7-1-0-50
Декодер есть... Только библиотека нужна проприетарная... https://code.videolan.org/mansr/mqa/-/blob/master/mqa.rst
Никто и не говорил, что он без потерь. Второй unfold точно с потерями.
Т.е. 200 МБ 192 k 24 бита за 5 минут это нормально? Это flac.
Вот именно. Да и что значит, точка отключила? Провайдеры все равно имеют стык.
Ну это завист от умников, которые позволили 8 бит экран при просто 10 бит hdmi. Но экран всего-то 8.
Ну что вы паритесь? Давно же уже png для > 8 бит сделали.
https://github.com/jursonovicst/gradient
Декодировать данный файл может только mpv. 11.5 bit можно сохранить в 12 бит как бы...
Имеются в виду оптимизации от противного. Signed overflow надо как-то обязательно проверять (так как есть консенсус, как обрабатывать это неопределенное поведение), даже если это выделенная инструкция ассемблера с флагами overflow.
>Undefined signed integer overflow allows the compiler to assume that overflows don't happen, which may introduce optimization opportunities.
Одна из важнейших фич в Си, как по мне. В ffmpeg постоянно int меняют на unsigned (unsigned это синоним unsigned int).
Например, github.com/FFmpeg/FFmpeg/commit/bf33a384995ac21aa41422c6246ebdc5d9632452
ИЛИ вот этот ужас github.com/FFmpeg/FFmpeg/commit/203b0e3561dea1ec459be226d805abe73e7535e5
Я не смог завести Edge. Мы в Chromium до сих пор допиливаем.
Mpv теперь поддерживает dolby vision.
Тест Миллера без Rabin-а зависит от правдивости гипотезы.
Так же как теорема о модулярности (частный случай этой теоремы это Теорема Ферма, а сама теоремы это частный случай abc гипотезы) это ключевая гипотеза всех точных наук.
Вообще можно сказать, что гипотеза Римана самый важная гипотеза в мире, и уж слишком много где она принимается как теорема. mathoverflow.net/questions/17209/consequences-of-the-riemann-hypothesis
И её следствия до сих пор доказывают. www.quantamagazine.org/mathematicians-prove-30-year-old-andre-oort-conjecture-20220203
Наоборот. Там либо баг в компиляторе будет (без возможности обойти) либо огромная утечка памяти причем неустранимая, так как извините но gc у нас не умеет так.
А вообще-то вы понимаете, что бесконечная петля или неправильное чтение или еще что (почитайте последние баги в turbo jpeg репозитории) это как бы и не баг с точки зрения компилятора, но DoS вы такой получите, мало не покажется.
Но вообще да можно написать jpeg быстрее, но по-первых, а вы учли CMYK? А ICC код? А код YCbCr to R'G'B' у вас идеальный? А математически совместима библиотека с jpeg reference 6? А с 9? А как насчет garbage in not grabage out? От последнего даже turbo jpeg отказались! А как насчет lossless jpeg, которых 6 видов? Мда. А как насчет center chroma location для FIR для 4:2:0?
И еще построчная загрузка на лету с сети обязательно нужна!