В былые времена это было бы аналогом использования какого-либо сложного алгоритма. Например, я врядли смогу действительно понять логику триангуляции Делоне или Шведского алгоритма (да и времени в проекте у меня на это может не быть), даже не смотря на то что я их руками портировал с C++ на Delphi, но я ими буду пользоваться и знать, что они проверены временем, другими проектами, признаны индустрией и имеют известные ограничения и краевые случаи (и покрыты тестами у меня в проекте тоже).
Для стандартных RGB значений это весь диапазон и есть - верхняя граница в него входит - [0.0 - 1,0], а если бы не входила, то мы бы его просто перенормировали, чтобы входила, т.к. по факту она есть, а за ней ничего нет :-)
Верно, вы говорите о диапазонах (для простоты, опять же, нагляднее оперировать 2битным цветом) - у вас получается 4 отрезка, [0 - 0,25 | 0,25 - 0,5 | 0,5 - 0,75 | 0.75 - 1,0]. Но здесь важный момент: 0, 1, 2, 3 - это номера этих диапазонов, а не их значения. Почти-черный попадет в диапазон номер 0, а почти-белый цвет будет находиться в диапазоне номер 3. Это квантизация. В ней действительно кажется, что номер диапазона тождественен его левой границе, а правая .. "где-то перед следующей левой". При квантизации мы теряем информацию (из какого-то плавного источника) и решаем из какого из четырёх диапазонов пришло значение. И тут возможны варианты, брать центра, края или как-то ешё.
Вопрос с дальнейшим выводом - как это транслируется в цвета. Для работы у нас есть 4 значения и мы из них можем выжать только 4 цвета. У нас должен быть самый темный (назовём его черный), очевидно это диапазон номер 0 и самый светлый (назовём его белый), очевидно это диапазон номер 3. Каким будет цвет диапазона номер 1 ... темно-серым, а 2 - светло-серым. Всё.. приехали.
То есть что важно - при работе с картинками/цветами, именно правило восстановления диктует нам каким должен был быть квантователь выше. Он должен нам "черный", "белый" и "два посередине". Что интересно, "два посередине" уже даёт пространство для маневра - это гамма (обычно 1,6 если я верно помню). Но вот от краёв никуда не уйти. Т.е. крайние коды (0 и N-1) закрепляются за крайними цветами, а промежуточные равномерно располагаются между ними. Поэтому для N бит получается деление именно на 2^N-1, а не на 2^N.
P.S. Отдельный реверанс в сторону устройства отображения - монитор (в 95%), на котором белый это тоже условность и зависит от крутилки яркости, но это уже за пределами спора о деквантизации ))
0.5 - это точная середина в условно-непрерывном пространстве float (и то, при допущении, что мы берем [0..1], а не [0..1), что уже не совсем корректно.
В целочисленном диапазоне от 0 до 3 середины в этом понимании нету (она лежит точно на границе между 1 и 2). Это "фишка" двоичной (и кратной) системы счисления. В троичной системе точная середина была бы (два трита, диапазон значений от 0 до 8, ровная середина - 4).
Давайте переведем белый (один компонент для простоты) из 8бит в 16бит с транзитом во float для наглядности. `255 / 256 = 0,99609375 --> 0,99609375 * 65536 -> 65280`. Нет, какая-то ерунда получается, если делить на число значений. И во float уже не белый, и в 16бит потемнел.
А если по уму, делить на максимальное значение? `255 / 255 = 1.0 -> 1.0 * 65535 --> 65535`. Вот теперь нормально. Везде максимально белый.
А ещё, приход нового человека в команду это прекрасная возможность для "коридорного тестирования" внутренних процессов. Да, "у нас так принято", но если все регулярно собирают одни и те же грабли, проблема вероятно не только в них. Все вот эти неявные знания, личные договорённости итп надо переодически проверять и переносить в процессы, так, чтобы накосячить было сложнее (или невозможно).
Как пример, у нас было принято первым делом выдавать новичку инструкции по настройке окружения - простынка на 6-7 страниц шагов, (в то же время это и мини-экскурсия по стеку) и просить их дополнять непонятные шаги или обновлять изменившиеся (после консультации с коллегами).
Уточнения от автора: - написаны на Delphi. RAD как таковой (в смысле Rapid Application Development) почти не используется. - KaM Remake это ремейк движка игры. Для работы он требует ресурсные файлы оригинальной игры. Сама игра по прежнему "закрытая" и продается на Стим и ГОГ. - Knights Province это не тест, а отдельная игра основанная на форке движка ремейка. Сейчас она в открытой Альфе.
Качественно, для инженерии, часть которой IT, - это регресс, а точнее, я бы сказал, шаг в сторону. До LLM всё инженерное дело строилось на том чтобы формализовать правила игры, убрать или ограничить неопределенности. Сделать так, чтобы алгоритм мог работать и мог быть понят и объяснён (и воспроизведен в точности). LLM это что-то принципиально другое, не инженерное.
Да, но нет. Каждая предыдущая инкапсуляция сохраняла детерминизм (с оговорками на глобальное состояние). LLM же принципиально работает на вероятностях и "температуре" (и своих скрытых версиях). Вы не получите два одинаковых ответа на одинаковый промпт неделю назад и сегодня.
Желаю вам всяческого успеха в этом непростом деле! Если у вас могут быть какие-то вопросы к нашему опыту (хотя судя по статьям вы про всё уже знаете гораздо больше нас, но всё же), то с удовольствием готов поделиться.
А мы так Knights and Merchants Remake активно запилили с 2008 по 2013 примерно. В основном из-за образовательных целей и любви к игре. И до сих пор поддерживаем. А когда уже почти всё было ремейкнуто, то с него уже совсем свой проект форкнулся в 2013 - Knights Province.
Интересно что там в оригинале было. Какая редакция. Судя по всему путаница с играми еще больше чем казалось - Network Q RAC Rally и Network Q RAC Rally Championship International Rally Championship это три совсем разных редакции (а "слава КПСС совсем не человек"). Я играл именно в Network Q RAC Rally Championship :-)
Поищите конкретно по названию "Network Q RAC Rally", она есть на площадках со старыми играми. Я правда так и не смог найти версию с непорезаной CD-музыкой, но это уже мелочи. Оригиналтный EXE на современной винде уже на заводится, но в DosBox работает. Вчера как раз погонял по 58-километровой трассе под крики штурмана "Hard Right!").
Я тоже большой фанат Network Q RAC Rally. Сочная графика, видеовставки, звук, голос штурмана "Hairpin right!". Уже лет 25 с собой по разным компам таскаю. Одной из самых крутых вещей на то время, было также наличие трассы длиной в 50-с-гаком км. Её прохождение занимало порядочно времени (на фоне того же NFS, где трасса делалась минут за 5-7).
В былые времена это было бы аналогом использования какого-либо сложного алгоритма. Например, я врядли смогу действительно понять логику триангуляции Делоне или Шведского алгоритма (да и времени в проекте у меня на это может не быть), даже не смотря на то что я их руками портировал с C++ на Delphi, но я ими буду пользоваться и знать, что они проверены временем, другими проектами, признаны индустрией и имеют известные ограничения и краевые случаи (и покрыты тестами у меня в проекте тоже).
Попробуйте Reasoning Effort поставить на Low (вместо дефолтного Extra High). Модель действительно ужасно много думает без особого толку (или валится).
Для стандартных RGB значений это весь диапазон и есть - верхняя граница в него входит - [0.0 - 1,0], а если бы не входила, то мы бы его просто перенормировали, чтобы входила, т.к. по факту она есть, а за ней ничего нет :-)
Верно, вы говорите о диапазонах (для простоты, опять же, нагляднее оперировать 2битным цветом) - у вас получается 4 отрезка, [0 - 0,25 | 0,25 - 0,5 | 0,5 - 0,75 | 0.75 - 1,0]. Но здесь важный момент: 0, 1, 2, 3 - это номера этих диапазонов, а не их значения. Почти-черный попадет в диапазон номер 0, а почти-белый цвет будет находиться в диапазоне номер 3. Это квантизация. В ней действительно кажется, что номер диапазона тождественен его левой границе, а правая .. "где-то перед следующей левой". При квантизации мы теряем информацию (из какого-то плавного источника) и решаем из какого из четырёх диапазонов пришло значение. И тут возможны варианты, брать центра, края или как-то ешё.
Вопрос с дальнейшим выводом - как это транслируется в цвета. Для работы у нас есть 4 значения и мы из них можем выжать только 4 цвета. У нас должен быть самый темный (назовём его черный), очевидно это диапазон номер 0 и самый светлый (назовём его белый), очевидно это диапазон номер 3. Каким будет цвет диапазона номер 1 ... темно-серым, а 2 - светло-серым. Всё.. приехали.
То есть что важно - при работе с картинками/цветами, именно правило восстановления диктует нам каким должен был быть квантователь выше. Он должен нам "черный", "белый" и "два посередине". Что интересно, "два посередине" уже даёт пространство для маневра - это гамма (обычно 1,6 если я верно помню). Но вот от краёв никуда не уйти. Т.е. крайние коды (0 и N-1) закрепляются за крайними цветами, а промежуточные равномерно располагаются между ними. Поэтому для N бит получается деление именно на 2^N-1, а не на 2^N.
P.S. Отдельный реверанс в сторону устройства отображения - монитор (в 95%), на котором белый это тоже условность и зависит от крутилки яркости, но это уже за пределами спора о деквантизации ))
0.5 - это точная середина в условно-непрерывном пространстве float (и то, при допущении, что мы берем [0..1], а не [0..1), что уже не совсем корректно.
В целочисленном диапазоне от 0 до 3 середины в этом понимании нету (она лежит точно на границе между 1 и 2). Это "фишка" двоичной (и кратной) системы счисления. В троичной системе точная середина была бы (два трита, диапазон значений от 0 до 8, ровная середина - 4).
Логика вас подводит, 128 это не средний серый.
Точно так же как если бы у нас был 2битный цвет (значения от 0 до 3), 2 - это не середина диапазона. [ 0 | 1 | 2 | 3 ].
И точно так же, было бы ошибочно утверждать, что 2 из этого диапазона должна стать 128, а не 170.
Кажется не раскрытой тема с MTP, дающим неплохое такое ускорение.
Давайте переведем белый (один компонент для простоты) из 8бит в 16бит с транзитом во float для наглядности.
`255 / 256 = 0,99609375 --> 0,99609375 * 65536 -> 65280`. Нет, какая-то ерунда получается, если делить на число значений. И во float уже не белый, и в 16бит потемнел.
А если по уму, делить на максимальное значение?
`255 / 255 = 1.0 -> 1.0 * 65535 --> 65535`. Вот теперь нормально. Везде максимально белый.
Очень необычно видеть в качестве единиц измерения центисекунды (сотые) вместо классический тысячных (мсек). Почему такой выбор?
А для Windows ещё лучше Agent Ransack, он конечно не такой быстрый, но зато умеет искать по содержимому файлов.
А ещё, приход нового человека в команду это прекрасная возможность для "коридорного тестирования" внутренних процессов. Да, "у нас так принято", но если все регулярно собирают одни и те же грабли, проблема вероятно не только в них. Все вот эти неявные знания, личные договорённости итп надо переодически проверять и переносить в процессы, так, чтобы накосячить было сложнее (или невозможно).
Как пример, у нас было принято первым делом выдавать новичку инструкции по настройке окружения - простынка на 6-7 страниц шагов, (в то же время это и мини-экскурсия по стеку) и просить их дополнять непонятные шаги или обновлять изменившиеся (после консультации с коллегами).
Уточнения от автора:
- написаны на Delphi. RAD как таковой (в смысле Rapid Application Development) почти не используется.
- KaM Remake это ремейк движка игры. Для работы он требует ресурсные файлы оригинальной игры. Сама игра по прежнему "закрытая" и продается на Стим и ГОГ.
- Knights Province это не тест, а отдельная игра основанная на форке движка ремейка. Сейчас она в открытой Альфе.
Качественно, для инженерии, часть которой IT, - это регресс, а точнее, я бы сказал, шаг в сторону. До LLM всё инженерное дело строилось на том чтобы формализовать правила игры, убрать или ограничить неопределенности. Сделать так, чтобы алгоритм мог работать и мог быть понят и объяснён (и воспроизведен в точности). LLM это что-то принципиально другое, не инженерное.
Да, но нет. Каждая предыдущая инкапсуляция сохраняла детерминизм (с оговорками на глобальное состояние). LLM же принципиально работает на вероятностях и "температуре" (и своих скрытых версиях). Вы не получите два одинаковых ответа на одинаковый промпт неделю назад и сегодня.
Желаю вам всяческого успеха в этом непростом деле! Если у вас могут быть какие-то вопросы к нашему опыту (хотя судя по статьям вы про всё уже знаете гораздо больше нас, но всё же), то с удовольствием готов поделиться.
А мы так Knights and Merchants Remake активно запилили с 2008 по 2013 примерно. В основном из-за образовательных целей и любви к игре. И до сих пор поддерживаем. А когда уже почти всё было ремейкнуто, то с него уже совсем свой проект форкнулся в 2013 - Knights Province.
Интересно что там в оригинале было. Какая редакция. Судя по всему путаница с играми еще больше чем казалось - Network Q RAC Rally и Network Q RAC Rally Championship International Rally Championship это три совсем разных редакции (а "слава КПСС совсем не человек"). Я играл именно в Network Q RAC Rally Championship :-)
Поищите конкретно по названию "Network Q RAC Rally", она есть на площадках со старыми играми. Я правда так и не смог найти версию с непорезаной CD-музыкой, но это уже мелочи. Оригиналтный EXE на современной винде уже на заводится, но в DosBox работает. Вчера как раз погонял по 58-километровой трассе под крики штурмана "Hard Right!").
Я тоже большой фанат Network Q RAC Rally. Сочная графика, видеовставки, звук, голос штурмана "Hairpin right!". Уже лет 25 с собой по разным компам таскаю. Одной из самых крутых вещей на то время, было также наличие трассы длиной в 50-с-гаком км. Её прохождение занимало порядочно времени (на фоне того же NFS, где трасса делалась минут за 5-7).
Спасибо за исчерпывающе-информативный ответ! Надеюсь UI/UX доработают.