Там по ассемблерному коду видно, что компилятор оптимизирует до просто 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.
Можно и пример математического объяснения привести. Во многих случаях (и в ваших примерах тоже) рассматриваемые величины являются положительными, и поэтому их распределения часто ближе к пуассоновским p(x;k)=1/k!xke-x, чем к гауссовым p(x;x0,σ)=(2πσ)-1/2e-(x-x0)2/2σ2. А распределение суммы n пуассоновских распределений также является пуассоновским распределением c k'=n(k+1)-1, поэтому хвост e-x (вместо ожидаемого e-x2) никуда не исчезает, просто на фоне роста основного писка он становится всё менее и менее заметным.
Я тут немножко поною в уголочке, не обращайте внимания.
Когда-то деревья были высокими на Хабре были уникальные интересные статьи (а по пятницам даже сиськи на голом CSS).
Потом пришла эпоха кучи переводных статей (а иногда даже переводных новостей).
Сейчас просто копируют свой контент с других сайтов (можно даже с задержкой в 3 недели и без указания ссылки на первоисточник).
== вы находитесь здесь ==
(и у меня даже мыслей нет, что может быть следующим в списке)
Насколько я сужу по знакомым, никто не тратит время на подачу таких уведомлений. Вместо этого просто ограничивают время своего визита (не более 30 дней). Не знаю, насколько это законно, но пока что никаких претензий ни к кому не было.
Так в этом-то и проблема. У меня один знакомый лет 15 назад принимал участие в разработке сайта со стихотворениями, там как раз нужно было каждое стихотворение разместить по центру, но при этом выравнивание должно быть по левому краю. Если не ошибаюсь, там в итоге каждую строку обернули в span и на JS рассчитывали максимальную длину строки и задавали размер родителю.
А можно, чтобы ширина блока с текстом была не минимально возможная, а максимально возможная в пределах родительского блока, но с тем же эффектом центрирования?
После того как в стандарте максимальный 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.
Можно и пример математического объяснения привести. Во многих случаях (и в ваших примерах тоже) рассматриваемые величины являются положительными, и поэтому их распределения часто ближе к пуассоновским p(x;k)=1/k!xke-x, чем к гауссовым p(x;x0,σ)=(2πσ)-1/2e-(x-x0)2/2σ2. А распределение суммы n пуассоновских распределений также является пуассоновским распределением c k'=n(k+1)-1, поэтому хвост e-x (вместо ожидаемого e-x2) никуда не исчезает, просто на фоне роста основного писка он становится всё менее и менее заметным.
Я тут немножко поною в уголочке, не обращайте внимания.
Когда-то
деревья были высокимина Хабре были уникальные интересные статьи (а по пятницам даже сиськи на голом CSS).Потом пришла эпоха кучи переводных статей (а иногда даже переводных новостей).
Сейчас просто копируют свой контент с других сайтов (можно даже с задержкой в 3 недели и без указания ссылки на первоисточник).
== вы находитесь здесь ==
(и у меня даже мыслей нет, что может быть следующим в списке)
Насколько я сужу по знакомым, никто не тратит время на подачу таких уведомлений. Вместо этого просто ограничивают время своего визита (не более 30 дней). Не знаю, насколько это законно, но пока что никаких претензий ни к кому не было.
Спасибо, возьму на заметку.
Так в этом-то и проблема. У меня один знакомый лет 15 назад принимал участие в разработке сайта со стихотворениями, там как раз нужно было каждое стихотворение разместить по центру, но при этом выравнивание должно быть по левому краю. Если не ошибаюсь, там в итоге каждую строку обернули в span и на JS рассчитывали максимальную длину строки и задавали размер родителю.
А можно, чтобы ширина блока с текстом была не минимально возможная, а максимально возможная в пределах родительского блока, но с тем же эффектом центрирования?
А что с вариантом итерации через
reset/key/next?