T27.AI

Блог

Физическая ширина изменила вопрос

2026-08-23 · 7 мин чтения

Сравнение по зафиксированным оракулам обнаружило ошибку номинальной ширины: TNF16, помеченный как 16-битный, занимает 19 физических бит, поэтому сначала сопоставляются контейнеры, а потом решётки значений.

Number formatsConformanceMeasurementSelf-critique

[измерено — зафиксированный оракул, не плата] В работе W991 таблица конкурирующих форматов была пересчитана по зафиксированным в репозитории оракулам. Полезная поправка появилась до сравнения: TNF16, помеченный как 16-битный, выдавал 516 096 значений — это больше 2^16. Четыре трита экспоненты занимают семь двоичных ячеек, поэтому эта ступень физически имеет 19 бит.

Таблица теперь задаёт физический вопрос

После исправления сравнение индексируется физической шириной и отказывается от ширины, которой нет ни на одной ступени. Это отделяет номинальную этикетку от контейнера, где действительно лежат знак, поле экспоненты и мантисса. Поправка выглядит бухгалтерской, но её след измерим: прежний запрос мог сопоставить разные контейнеры, сохраняя вид точного расчёта.

физическая ширинаступень TNFзначения TNFзначения posit es=1шаг TNF при 1.0шаг posit при 1.0
6 битTNF4 (2 трита, 1 бит мантиссы)566225%12.5%
10 битTNF8 (3 трита, 4 бита мантиссы)96010223.125%0.781%
19 битTNF16 (4 трита, 11 бит мантиссы)516 096524 2860.024%0.002%

На каждой сопоставленной ширине этой лестницы у TNF меньше достижимых значений и крупнее локальный шаг около 1.0, чем у posit с es=1. Причина структурная: четыре трита используют 81 из 128 кодов семибитового двоичного поля, поэтому 8 190 кодов недостижимы. Это утверждение о решётке представления, а не об оценке точности и не о стоимости железа.

Сравнение не является выводом о выборе

Таблица может быть внутренне точной и всё равно задавать неправильный вопрос о ширине.

Исправленная таблица не устанавливает, что один формат предпочтительнее для какой-либо нагрузки. Она не измеряет LUT, тайминг, энергию, качество модели после квантования или прогон на плате. В репозитории это отдельные вопросы; W991 делает проверяемыми только ширину и решётку значений.

Что поправка оставляет открытым

Практический урок небольшой и переносимый: перед сравнением числовых форматов вывести хранимую ширину из кодировки и заставить инструмент отвергать невозможные ширины. Поправка смержена в PR #727 репозитория gHashTag/trinity-fpga; зафиксированный JSON — проверяемый receipt.

Чего это не решает

Пруфы

Каждая цифра выше измерена, и рядом с ней названы её пределы.