Можно было бы ввести кодирование base43 (символы пробела и % проблематично использовать в URL), но простой расчет показывает, что base10 все-равно выгоднее, т.к. (10/3) / log(10) < (11/2) / log(43). Хотя, разница не велика, а если есть возможность записать весь URL капсом, то можно сэкономить на переключении между режимами кодирования (и к тому же на длину сообщения в этом случае выделяется на 1 бит меньше, чем для цифрового кодирования).
Интересно, если б провести сканирование сайтов на Вордпресс с определением версий, то какая там картина сложилась бы.
Главная фича WordPress - обратная совместимость. Там нет мажорных версий, как в Joomla. Там просто каждый раз увеличивают версию на 0.1. Обратная совместимость ломается только если это связано с безопасностью. Поэтому там не так страшно обновляться, и как правило это делается даже без развертывания stage-окружения.
У меня когда-то был небольшой сайт на WordPress, который просуществовал с 2007 по 2019, и парочка плагинов разработанных для WordPress 2.3 без каких-либо исправлений прожили до 4.9 (наверняка и с последующими версиями проблем бы не было, но к тому моменту сайт уже давно отслужил своё).
Плюс, в WordPress всегда можно быстренько поговнокодить в functions.php, чтобы на лету добавить/убрать необходимое без создания полноценного плагина. Поэтому и порог вхождения там гораздо ниже (но и, как следствие, качество кода большинства плагинов - тоже).
На самом деле, в самолетах действительно есть стоп-кран, и он действительно обычно красного цвета (можете погуглить фото). GPT4 выдает вполне верный ответ:
Стоп-кран (также известный как "fire handle" или "engine fire handle") в самолете — это устройство, используемое для прекращения подачи топлива, гидравлической жидкости и пневматического давления в двигатель в случае пожара или другой аварийной ситуации. В большинстве коммерческих и военных самолетов стоп-краны обычно имеют красный цвет, чтобы их было легко идентифицировать в критических ситуациях. Красный цвет является универсальным сигналом опасности и требует немедленного внимания, что делает его идеальным выбором для таких важных устройств управления.
Насколько я помню, в Unicode 1.0 для codepoint не было такого ограничения, но уже в какой-то из последующих версий это было добавлено, т.к. кодировка UTF-16 не способна представлять большие значения через механизм суррогатных пар.
Там по ассемблерному коду видно, что компилятор оптимизирует до просто print *, 0.0 и никуда не лезет. И даже в более сложных случаях, если нет побочных эффектов, merge заменяется на сравнение и условный переход, т.е. полностью аналогично тернарному условному оператору.
Если функция a объявлена как pure, т.е. не имеет побочных эффектов, то уже в режиме -O1 компилятор gfortran не будет вызывать ее без необходимости: https://godbolt.org/z/cKcdMrdxP А иначе, да, стандарт требует вычисления всех аргументов функции. Но в большинстве случаев gfortran (в отличие от ifort и ifx, как ни парадоксально) очень хорошо оптимизирует merge.
А почему вы сравниваете с ttf от fonts.google.com, а не woff2 оттуда же, которые заботливо разбиты на unicode-range (см. например https://fonts.googleapis.com/css2?family=Roboto)? Не потому ли, что в этом случае разницы практически не будет (для Roboto: 15.4Кб латиница, 9.4Кб кириллица, и т.д.)?
А почему XeTeX, а не LuaTeX? Вроде бы последний сейчас гораздо чаще используется, обладает бОльшим количеством возможностей и поддерживает почти всё, что умеет XeTeX?
Но ведь сутки — это тоже внесистемная единица времени. Поэтому давайте вместо этого всё измерять в секундах, а за ноль примем какой-нибудь случайный момент времени, например полночь 1 января 1970 года.
Там суть в том, что по мере увеличения k форма кривой стремится к гауссиане (с максимумом в точке x0=σ2=k), а вклад хвоста e-x уменьшается из-за множителя 1/k!, так что все условия выполняются, всё сходится, но нужны достаточно большие значения k.
Можно было бы ввести кодирование base43 (символы пробела и % проблематично использовать в URL), но простой расчет показывает, что base10 все-равно выгоднее, т.к. (10/3) / log(10) < (11/2) / log(43). Хотя, разница не велика, а если есть возможность записать весь URL капсом, то можно сэкономить на переключении между режимами кодирования (и к тому же на длину сообщения в этом случае выделяется на 1 бит меньше, чем для цифрового кодирования).
Главная фича WordPress - обратная совместимость. Там нет мажорных версий, как в Joomla. Там просто каждый раз увеличивают версию на 0.1. Обратная совместимость ломается только если это связано с безопасностью. Поэтому там не так страшно обновляться, и как правило это делается даже без развертывания stage-окружения.
У меня когда-то был небольшой сайт на WordPress, который просуществовал с 2007 по 2019, и парочка плагинов разработанных для WordPress 2.3 без каких-либо исправлений прожили до 4.9 (наверняка и с последующими версиями проблем бы не было, но к тому моменту сайт уже давно отслужил своё).
Плюс, в WordPress всегда можно быстренько поговнокодить в functions.php, чтобы на лету добавить/убрать необходимое без создания полноценного плагина. Поэтому и порог вхождения там гораздо ниже (но и, как следствие, качество кода большинства плагинов - тоже).
Юмористы
А у меня получилось N=log(0.95)/log(0.9999)≈513.
Кажется, в BASIC 2 строки внизу экрана были зарезервированы, поэтому доступная высота сокращалась до 176.
На самом деле, в самолетах действительно есть стоп-кран, и он действительно обычно красного цвета (можете погуглить фото). GPT4 выдает вполне верный ответ:
Насколько я помню, в Unicode 1.0 для codepoint не было такого ограничения, но уже в какой-то из последующих версий это было добавлено, т.к. кодировка UTF-16 не способна представлять большие значения через механизм суррогатных пар.
Могу сослаться на определение в текущем стандарте:
https://www.unicode.org/versions/Unicode15.1.0/ch03.pdf
"Unicode codespace: A range of integers from 0 to 10FFFF."
После того как в стандарте максимальный codepoint ограничили значением 10FFFF, уже не может. 4 байта хватит всем.
Там по ассемблерному коду видно, что компилятор оптимизирует до просто
print *, 0.0и никуда не лезет. И даже в более сложных случаях, если нет побочных эффектов,mergeзаменяется на сравнение и условный переход, т.е. полностью аналогично тернарному условному оператору.Ну так вы же специально указали
-fcheck=bounds. Без него (просто-O3) у меня gfortran 13.2 выводит0.00000000E+00без каких-либо ошибок.
Да и не понимаю я, о чем мы спорим. Я просто привел пример, каким был аналог тернарного условного оператора в предыдущих версиях Fortran.
А, тогда тем более будет оптимизировано.
Если функция
aобъявлена какpure, т.е. не имеет побочных эффектов, то уже в режиме-O1компилятор gfortran не будет вызывать ее без необходимости:https://godbolt.org/z/cKcdMrdxP
А иначе, да, стандарт требует вычисления всех аргументов функции.
Но в большинстве случаев gfortran (в отличие от ifort и ifx, как ни парадоксально) очень хорошо оптимизирует
merge.Было
merge(a, 0.0, a>0.0), а теперь в качестве альтернативы добавили привычный по другим языкам синтаксис(a>0.0 ? a : 0.0).А почему вы сравниваете с ttf от fonts.google.com, а не woff2 оттуда же, которые заботливо разбиты на unicode-range (см. например https://fonts.googleapis.com/css2?family=Roboto)? Не потому ли, что в этом случае разницы практически не будет (для Roboto: 15.4Кб латиница, 9.4Кб кириллица, и т.д.)?
А почему XeTeX, а не LuaTeX? Вроде бы последний сейчас гораздо чаще используется, обладает бОльшим количеством возможностей и поддерживает почти всё, что умеет XeTeX?
Но ведь сутки — это тоже внесистемная единица времени. Поэтому давайте вместо этого всё измерять в секундах, а за ноль примем какой-нибудь случайный момент времени, например полночь 1 января 1970 года.
Такое чувство, что вместо гибкого DI опять пришли к Service Locator с глобальным состоянием.
Чем переводили?
Это как? :-)
Там суть в том, что по мере увеличения k форма кривой стремится к гауссиане (с максимумом в точке x0=σ2=k), а вклад хвоста e-x уменьшается из-за множителя 1/k!, так что все условия выполняются, всё сходится, но нужны достаточно большие значения k.