Что представляет собой константа 0,0039215689?

Question

Что представляет собой константа 0,0039215689?

299

Я продолжаю видеть, что эта константа появляется в разных файлах графических заголовков

0.0039215689

Кажется, что-то связано с цветом?

Вот первый хит в Google:

void RDP_G_SETFOGCOLOR(void)
{
    Gfx.FogColor.R = _SHIFTR(w1, 24, 8) * 0.0039215689f;
    Gfx.FogColor.G = _SHIFTR(w1, 16, 8) * 0.0039215689f;
    Gfx.FogColor.B = _SHIFTR(w1, 8, 8) * 0.0039215689f;
    Gfx.FogColor.A = _SHIFTR(w1, 0, 8) * 0.0039215689f;
}

void RDP_G_SETBLENDCOLOR(void)
{
    Gfx.BlendColor.R = _SHIFTR(w1, 24, 8) * 0.0039215689f;
    Gfx.BlendColor.G = _SHIFTR(w1, 16, 8) * 0.0039215689f;
    Gfx.BlendColor.B = _SHIFTR(w1, 8, 8) * 0.0039215689f;
    Gfx.BlendColor.A = _SHIFTR(w1, 0, 8) * 0.0039215689f;

    if(OpenGL.Ext_FragmentProgram && (System.Options & BRDP_COMBINER)) {
        glProgramEnvParameter4fARB(GL_FRAGMENT_PROGRAM_ARB, 2, Gfx.BlendColor.R, Gfx.BlendColor.G, Gfx.BlendColor.B, Gfx.BlendColor.A);
    }
}

//...more like this

Что представляет этот номер? Почему никто, кажется, не объявляет его как const?

Я ничего не смог найти в Google, который объяснил это.

crush 24 март 2014, в 21:44

Источник

0

Примечание. Компоненты цвета (например, красный, зеленый, синий, альфа) часто представлены как целое число в [0; 255] во многих API
xav 24 март 2014, в 21:49
16

Есть ли какая-то причина, по которой исходный код написал бы это вместо (1.f/255) ?
M.M 25 март 2014, в 00:37
3

@MattMcNabb Возможно они надеются, что это не будет оценено в расширенной точности.
Navin 25 март 2014, в 01:25
51

Мммм ... если бы был какой-то способ избежать магических чисел ....
Paul Draper 25 март 2014, в 01:29
12

1/255 == 0.00(3921568627450980) - 1/255 == 0.00(3921568627450980) означает повторение.
jfs 25 март 2014, в 05:06
80

С вашим следующим магическим номером попробуйте спросить Wolfram Alpha
AakashM 25 март 2014, в 09:31
0

@AakashM Круто. Спасибо за это. Это действительно здорово.
crush 25 март 2014, в 13:08
1

@JFSebastian Обратите внимание, что в base-256 расширение будет явно {00}.{01}{01}{01}{01}... где {01} - это одна цифра «один» в base-256. Таким образом, в двоичном виде это будет 0.(00000001) где парены означают повторение.
Jeppe Stig Nielsen 27 март 2014, в 09:17
1

@JeppeStigNielsen: в base-256 это: 0.(1) ( 1 - более традиционное представление «один», чем {01} )
jfs 27 март 2014, в 09:51
11

безотносительно причины использование магического числа без документирования его назначения очень не круто
Isaac Rabinovitch 27 март 2014, в 19:13
0

@LionC Я не согласен с последним редактированием по этому вопросу. Хотя можно утверждать, что сам вопрос не имеет ничего общего с C , он имеет очень много общего с floating-point .
crush 10 апр. 2014, в 12:53
0

@crush Вы, вероятно, правы, кажется, у меня там есть мозги ;-) thx
LionC 10 апр. 2014, в 12:55
0

C dev есть рефлексы ... оптимизация на месте компилятора. Почему это первая версия? Есть проблема, а затем решить ее.
Sandburg 13 сен. 2018, в 12:35
0

@ IsaacRabinovitch, я боюсь, что я получил жалобы на комментирование вещей в коде ... есть вкус ко всему ... но я с тобой.
Luis Colorado 14 фев. 2019, в 15:29

Показать ещё 12 комментариев

Теги:

floating-point

c

constants

magic-numbers

2 ответа

73

Это умножение на 0.0039215689f преобразует интенсивность цвета с целым числом в диапазоне от 0 до 255 до реальной значащей интенсивности цвета в диапазоне от 0 до 1.

Как указывает Илмари Каронен, даже если это оптимизация, это довольно плохо выраженная. Было бы гораздо яснее размножаться на (1.0f/255).

David Heffernan 24 март 2014, в 22:49

5

Или, может быть, лучше, определяется как постоянная?
Johny 25 март 2014, в 21:54
9

@Johny Определено как константа. Дело не в волшебной ценности.
David Heffernan 25 март 2014, в 22:01

Ещё вопросы

Примечание. Компоненты цвета (например, красный, зеленый, синий, альфа) часто представлены как целое число в [0; 255] во многих API
Есть ли какая-то причина, по которой исходный код написал бы это вместо (1.f/255) ?
@MattMcNabb Возможно они надеются, что это не будет оценено в расширенной точности.
Мммм ... если бы был какой-то способ избежать магических чисел ....
1/255 == 0.00(3921568627450980) - 1/255 == 0.00(3921568627450980) означает повторение.
С вашим следующим магическим номером попробуйте спросить Wolfram Alpha
@AakashM Круто. Спасибо за это. Это действительно здорово.
@JFSebastian Обратите внимание, что в base-256 расширение будет явно {00}.{01}{01}{01}{01}... где {01} - это одна цифра «один» в base-256. Таким образом, в двоичном виде это будет 0.(00000001) где парены означают повторение.
@JeppeStigNielsen: в base-256 это: 0.(1) ( 1 - более традиционное представление «один», чем {01} )
безотносительно причины использование магического числа без документирования его назначения очень не круто
@LionC Я не согласен с последним редактированием по этому вопросу. Хотя можно утверждать, что сам вопрос не имеет ничего общего с C , он имеет очень много общего с floating-point .
@crush Вы, вероятно, правы, кажется, у меня там есть мозги ;-) thx
C dev есть рефлексы ... оптимизация на месте компилятора. Почему это первая версия? Есть проблема, а затем решить ее.
@ IsaacRabinovitch, я боюсь, что я получил жалобы на комментирование вещей в коде ... есть вкус ко всему ... но я с тобой.
Или, может быть, лучше, определяется как постоянная?
@Johny Определено как константа. Дело не в волшебной ценности.

Mysticial · Accepted Answer · 2014-03-24T22-08-00.000Z

387

Лучший ответ

0.0039215689 приблизительно равно 1/255.

Увидев, что это OpenGL, производительность, вероятно, важна. Поэтому, вероятно, можно с уверенностью предположить, что это было сделано по соображениям производительности.

Умножение на обратное происходит быстрее, чем повторное деление на 255.

Боковое примечание:

Если вам интересно, почему такая микро-оптимизация не оставлена компилятору, это потому, что это небезопасная оптимизация с плавающей запятой. Другими словами:

x / 255  !=  x * (1. / 255)

из-за ошибок округления с плавающей запятой.

Таким образом, хотя современные компиляторы могут быть достаточно умными для этой оптимизации, им не разрешается делать это, если вы явно не указали им через флаг компилятора.

Связано: Почему GCC не оптимизирует a * a * a * a * a * a (a * a * a) * (a * а * а)?

Mysticial 24 март 2014, в 22:08

1

Вот это да. Все, что я могу сказать, это отличный ответ. Я, вероятно, никогда бы не открыл это без вашего ведома. Конечно, теперь, зная, что это представляет, это кажется совершенно очевидным!
crush 24 март 2014, в 21:56
10

Я на самом деле не знал, что это было, когда я впервые увидел это. Но, видя, как он использовался, я подозревал, что это была оптимизация, умноженная на взаимность. Так что я проверил свой калькулятор и, конечно же, я догадался.
Mysticial 24 март 2014, в 22:08
0

Захватывающий. Я полагаю, на современном процессоре умножение может быть быстрее, чем таблица поиска. С другой стороны, я ожидаю, что преобразование из 8-битного цветового канала в плавающее положение потребует коррекции гаммы (или даже преобразования sRGB в линейное преобразование), и в этом случае справочная таблица, вероятно, является выигрышной.
Adrian McCarthy 24 март 2014, в 22:21
53

Я бы ожидал увидеть это записанным как a = b * (1.0f / 255) ; компиляторы все еще делают постоянное свертывание, не так ли?
Ilmari Karonen 24 март 2014, в 22:51
9

@IlmariKaronen Да, они все еще делают постоянное сворачивание. Это на самом деле требуется для некоторых вещей, таких как разрешения шаблонов и тому подобное. Но я бы просто вытащил это как константу или макрос. Но, эй, не весь код написан идеально. :)
Mysticial 24 март 2014, в 22:54
0

строгое соблюдение плавающей запятой ... разве не для этого используется ключевое слово strictfp (если оно вам нужно)?
Bohemian♦ 25 март 2014, в 02:14
2

@ Bohemian IIRC, стандарт допускает некоторую свободу в том, что промежуточные результаты выражения с плавающей точкой могут быть сделаны с более высокой точностью. strictfp отключает это. Но для выполнения небезопасных оптимизаций с плавающей запятой, которые требуют ассоциативности ( например, этой ), вам нужно указать компилятору сделать это. (В GCC это будет -ffast-math .)
Mysticial 25 март 2014, в 02:19
2

@Bohemian strictfp не является частью стандарта C. Он существует в Java, но не следует смешивать обсуждения Java и C относительно плавающей запятой, каждый из них достаточно сложен сам по себе (и совершенно различен).
Pascal Cuoq 25 март 2014, в 10:14
1

Мне кажется странным, что для таких вещей используется шкала 255, а не 256. Я что-то упустил?
hippietrail 25 март 2014, в 18:48
5

@hippietrail Изначально мне было интересно то же самое. Но если вы используете 256, он будет масштабироваться от 0.0 - 0.996 вместо желаемых 0.0 - 1.0 . ( 0.996 = 255/256 где 255 - наибольшее 8-разрядное целое число)
Mysticial 25 март 2014, в 18:53
4

Интересный вопрос может быть - почему бы не 0,0039215686 или 0,0039215687, которые являются более близкими приближениями с одинаковым уровнем точности?
Daniel Waechter 26 март 2014, в 00:32
7

И, конечно же, чтобы ответить на мой собственный вопрос, это потому, что два других числа не могут быть представлены как стандартные числа C. Следующий поплавок ниже 0,0039215689 - 0,0039215684.
Daniel Waechter 26 март 2014, в 00:53
0

Чтобы быть точным, самое близкое число IEEE с плавающей точкой одинарной точности к 1/255 составляет 0,0039215688593685626983642578125.
dan04 26 март 2014, в 02:46
5

Конечно, лучший программист, пишущий заголовочный файл, определил бы константу и использовал бы ее по имени.
Jack Aidley 26 март 2014, в 13:38
1

@JackAidley Это странная вещь. Я не смог найти ни одного примера в Интернете, где программист определил константу, но это магическое число, кажется, широко используется. Я действительно впервые столкнулся с этим при разборке исполняемого файла, который был написан на C ++. С тех пор я не смог найти ни одного экземпляра, где он определен как константа ... возможно, это часть какой-то стандартной графической библиотеки.
crush 26 март 2014, в 14:04
1

Возможно, стоит отметить, что для целых чисел существует аналогичная хитрость для умножения обратного числа, а не деления с использованием магических чисел . Например, n / 255 = (0x80808081 * n) >> 39.
Z boson 04 апр. 2014, в 19:12
0

@Mysticial Подождите ... почему быстрее умножить на обратную, чем делить на 255?
Rakshith Ravi 20 нояб. 2015, в 06:45
0

@RakshithRavi Потому что деление медленнее, чем умножение.
Mysticial 20 нояб. 2015, в 07:02
0

@ Мистик да, но почему?
Rakshith Ravi 21 нояб. 2015, в 14:54
0

@RakshithRavi stackoverflow.com/questions/15745819 / ...
Mysticial 21 нояб. 2015, в 17:36

Показать ещё 18 комментариев