![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Entry tags:
1280÷7
Начал тестировать одну софтинку на всяком старье – и сразу словил гемор, вестимо из IE, хоть и не слишком старого, 11 версии.
В CSS3 можно задавать размеры элементов, используя выражения типа width:(100% / 7) или width:(50% - 10px +1em) – то-есть сочетать разные единицы измерения в одном выражении. Исключительно удобая штука, хотя и дорогая в плане CPU и перерисовки.
Так вот, по мнению IE11, если поставить рядом 7 элементов с шириной calc(100% / 7), они в ряд почти всегда не помещаются, если эти 100% в пикселях на 7 нацело не делятся. При этом айтемы с шириной calc((100% - 0.01px) / 7) помещаются всегда.
То-есть второй факт однозначно свидетельствует, что внутренние расчёты всё таки subpixel-точности (как и требует стандарт). Вот только первый факт свидетельствует о том, что fp-арифметика там внутри скорее всего не IEEE-754, либо она хуже по точности, чем binary32.
Любопытно, что с обычной 64-битной fp-точностью все вычисления n/7*7 для целых n из нужного мне интервала [1250,1280] возвращают n точно. То-есть это роботы в IE team сидели и специально придумывали какую-нибудь недооптимизацию своей тормозной поделки, ну и по пути напакостили.
Типичное, впрочем, явление вообще для всего софта Microsoft, что я видел.
В CSS3 можно задавать размеры элементов, используя выражения типа width:(100% / 7) или width:(50% - 10px +1em) – то-есть сочетать разные единицы измерения в одном выражении. Исключительно удобая штука, хотя и дорогая в плане CPU и перерисовки.
Так вот, по мнению IE11, если поставить рядом 7 элементов с шириной calc(100% / 7), они в ряд почти всегда не помещаются, если эти 100% в пикселях на 7 нацело не делятся. При этом айтемы с шириной calc((100% - 0.01px) / 7) помещаются всегда.
То-есть второй факт однозначно свидетельствует, что внутренние расчёты всё таки subpixel-точности (как и требует стандарт). Вот только первый факт свидетельствует о том, что fp-арифметика там внутри скорее всего не IEEE-754, либо она хуже по точности, чем binary32.
Любопытно, что с обычной 64-битной fp-точностью все вычисления n/7*7 для целых n из нужного мне интервала [1250,1280] возвращают n точно. То-есть это роботы в IE team сидели и специально придумывали какую-нибудь недооптимизацию своей тормозной поделки, ну и по пути напакостили.
Типичное, впрочем, явление вообще для всего софта Microsoft, что я видел.
no subject
no subject
Потом, есть же поворот – и он не обязательно всегда будет на угол с рациональным тангенсом.