Нет, это всё-таки странно, что там нет ограничений сверху на размер бита и байта ("ровно 2 состояния" и "минимально адресуемый [среди подходящих под прочие условия вроде того, что basic character set]").
"Network designers have generally used megabits per second (Mbit/s) to mean 1 048 576 bit/s, while telecommunications engineers have traditionally used the same term to mean 1 000 000 bit/s"
Но интересно, что они отсылают к рекламной стороне.
"term was also easy for salesmen and shops to use, and it caught on with the public. Take, for example, the ubiquitous and so-called 3,5 inch floppy disk"
Которая после их нововведения никуда не делась (имею в виду непоследовательность в macOS и Android)
И приводят в пример величину 133,3 MB/s, хотя она как раз иллюстрирует невозможность указать - по старой системе она записана или по новой.
Даже производители накопителей стали писать нормально
Их тут успели обвинить и в переходе на двоичные приставки, и в отказе от двоичных приставок, хотя они ничего не меняли.
А Винда... Ну вот такая эта Винда...
А винда продолжает использовать традиционные килобайты (у винды они всегда двоичные), как было до появления кибибайтов. Как в Android, только последовательнее.
Вот это в соседнем комменте тоже было славно вброшено:
На диске ёмкость нигде не указана, в названии число "42" и в магазинах его продавали как 42-меговый.
"For use also with" относится только к джамперам, у L40 другое число цилиндров. В рекламных каталогах его не найти, а в справочных каталогах он 41-меговый.
И в то время я точно не помню чтобы кто-то аппелировал к принятому стандарту разделяющему десятичные и двоичные ЕИ
...и на что отвечаете - тоже, уж извините. Я написал "это прослеживается до их появления в 50-х годах", то есть лет за 40 до стандарта IEC.
Переход на маркетинговые начался, если память не изменяет, где-то в районе 10гиговых дисков.
Изменяет. 1980-й год, ST-506, ёмкость 5.0 мегабайтов по мануалу и это десятичные мегабайты: 612 * 32 * 256 bytes = 5.01 MB = 4.78 MiB.
Он просто позволяет задать интерфейс для статического (compile-time) полиморфизма, не прибегая к концептам как к слишком новой штуке.
То есть мы в такой шаблон функции
template<typename T>
void foo(T bar) {
bar.f();
}
можем подавать* объекты любых классов, полагаясь на то, что у них есть метод f() (утиная типизация). А если нам это кажется небезопасным и хочется ограничить классы наследниками одного класса-интерфейса IBar, то это достигается с помощью CRTP.
* или как там правильно будет, "неявно специализировать"?
___
Не раскрыта тема девиртуализации. Компилятор достаточно умён, чтобы иногда избегать виртуальных вызовов. Используем CRTP = отказались от динамического полиморфизма = у компилятора есть возможность для девиртуализации, закатывание солнца вручную через CRTP может оказаться избыточным.
С таким байтом и в бите нельзя быть уверенным, ведь там, где байт определяют как наименьшую (?*) адресуемую единицу хранения данных, там бит определяют как
bit. unit of data storage in the execution environment large enough to hold an object that can have one of two values. It may not be possible to express the address of each individual bit of an object.
byte. addressable unit of data storage large enough to hold any member of the basic character set of the execution environment
* но там даже не сказано "наименьшую"?.. В обоих определениях размер ограничен снизу.
В Android с измерением свободного места было что-то ещё более странное
А именно, по крайней мере у Samsung, разницу между приставками на 2023 год прибавляют к размеру операционной системы.
Т.е. в телефоне имеется флеш-память на 512 ГиБ, без учёта служебной ёмкости (overprovisioning) доступно 512 ГБ, но в Android их хочется показать в двоичных гигабайтах (477 ГиБ), но красивее (477 двоичных контекстно-зависимых ГБ), но нет, ещё красивее (512 поддельных рекламных ГБ) - для этого разницу между 512 ГиБ и 512 ГБ прибавляют к размеру ОС, чтобы сошлось - и поэтому чем больше памяти у телефона, тем больше "весит" ОС.
когда они на hdd стали шлёпать ёмкость в десятичной системе
Они использовали десятичные гигабайты до и продолжили использовать после (и правы с точки зрения СИ, IEC или госта), но по мировому соглашению они дальше обязались добавлять приписки типа "*1TB = 1 trillion bytes" из-за винды.
То есть 80.06 GB = 74.56 GiB. Это норма. А надо найти найти хоть один обратный случай (и с учётом вероятного округления заявленной ёмкости вниз, а не до ближайшего).
Постарайтесь вспомнить. На этикетках 40-гиговых Maxtor'ов в гугле везде есть либо количество LBA, указывающее на десятичные гигабайты*, либо сразу приписка "1 GB=1,000,000,000 Bytes".
* например, продаётся как 40 ГБ и 80 293 248 LBA * 512 bytes = 41.1 GB = 38.3 GiB.
Вы распространяете заблуждения и написали статью в стиле "двухминутки ненависти" ради привлечения внимания.
Можно, конечно, поискать конспирологию в том, что это производители накопителей пролоббировали IEC
В гигабайтах тут считать выгоднее, вот маркетологи и насаждают это потребителям.
Жёсткие диски всегда использовали десятичные приставки, это прослеживается до их появления в 50-х годах.
Покупаешь жёсткий диск — на коробке написано 500 ГБ, а на самом деле там 465 ГиБ
Но на плашках RAM — «честные» гибибайты: сколько указано, столько и получаешь, только пишут всё равно 16 GB, а не 16 GiB
То есть правила СИ&IEC соблюдаются в HDD и нарушаются в RAM, но вы пытаетесь это вывернуть так, чтобы получить больше заявленного.
Ранние ОС действительно использовали систему подсчёта данных, основанную на степенях двойки
Ранняя macOS. Windows и дальше продолжает использовать двоичные килобайты, в Linux перешли на кибибайты. Если же смотреть из современной macOS, то вы увидите жёсткий диск на 500 ГБ как жёсткий диск на 500 ГБ и всё равно недовольны.
Или всё-таки на заре компьютеров бумеры-основатели зря решили пойти против существующих стандартов
Вы не предлагаете решения для тех времён и почему-то считаете систему СИ нерушимым абсолютом, хотя у Международного бюро мер и весов нет своей армии. Правила СИ&IEC до сих пор нарушаются и у Apple (в оперативной памяти), и у производителей различных микросхем. В Android с измерением свободного места было что-то ещё более странное. Они обычно смотрят на вопрос с рекламной стороны (как "1.44 МБ" раньше), а вы не замечаете.
так скорость выглядит в 8 раз больше
А размеры аудио-/видеофайлов в 8 раз больше? Битрейт (не байтрейт) - обычная практика.
ввела терминологию — киби-, меби-, гиби-, теби- и так далее — для того, чтобы отличать одно от другого и устранить растущую путаницу среди пользователей.
Но не дала механизма, который бы позволил отличить старые контекстно-зависимые килобайты от новых точно-десятичных килобайтов. Даже если все бы одновременно перешли на новые правила, старые тексты бы не исчезли. По ссылке выше такую ошибку допустили.
И вообще вроде бы есть специальные названия для ... «ровных»
сетевыми инженерами, которые считают 1 Гбит/с = 1 048 576 бит/с
В существование этих точек зрения после перечисленного не верится.
Да, этот прирост не нужен. Такие оптимизации пригодились бы, если бы у микроконтроллера были другие задачи, тогда ещё были бы нужны неблокирующие задержки, пришлось бы думать про (не)атомарность изменения PORTx.
использования регистров PINx (переключение пина без read-modify-write).
Я тут не подумал, что строка PORTB |= (1 << PB3); должна компилироваться в одну инструкцию SBI (Set Bit in I/O Register).
Так как почти весь прирост должен быть от зажигания 8 светодиодов вместо 1 и задержки во включённом состоянии, не стал писать про отказ от digitalWrite().
Но вообще тогда думал, что можно упороться вплоть до использования регистров PINx (переключение пина без read-modify-write). И чересстрочной развёртки, чтобы достичь незаметности мерцания на более низкой частоте:
Идеи
for (uint8_t rowIdx_ = 0; rowIdx_ < 8; rowIdx_++) {
uint8_t rowIdx = rowIdx_;
#if defined(USE_INTERLACED_SCAN)
rowIdx = rowIdx_/4 + 2*(rowIdx_%4); // 0,2,4,6,1,3,5,7
#endif
// 1. prepare columns
#define H(X) readAndUnpackPixel(frame, X, rowIdx) // helper macro
setMatrixColumns(H(0), H(1), H(2), H(3), H(4), H(5), H(6), H(7));
#undef H
// 2. activate row
ToggleRow(rowIdx);
// 3. delay in active state
delayMicroseconds(1000);
// 4. deactivate row
ToggleRow(rowIdx);
}
/* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ */
// Для инициализации; в т.ч. когда обновление прерывается,
// оставляя матрицу в неизвестном состоянии.
void SetRowsToHigh() {
PORTD |= ((1 << 2) | (1 << 1) | (1 << 4) | (1 << 5));
PORTB |= ((1 << 1) | (1 << 2) | (1 << 4));
PORTA |= ((1 << 1));
}
void ToggleRow(uint8_t rowIdx) {
switch(rowIdx) {
case 0: PIND = (1 << 2); break;
case 1: PINB = (1 << 1); break;
case 2: PINB = (1 << 2); break;
case 3: PIND = (1 << 1); break;
case 4: PINB = (1 << 4); break;
case 5: PINA = (1 << 1); break;
case 6: PIND = (1 << 4); break;
case 7: PIND = (1 << 5); break;
}
}
/* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ */
inline bool readAndUnpackPixel(frame, uint8_t colIdx, uint8_t rowIdx) {
return (bool)(pgm_read_byte(frame + colIdx) & (1 << rowIdx));
// ^^^^^^~~~~ изначально написал !! вместо этого, но не знаю,
// что лучше выразит намерение нормализовать bool
}
/* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ */
inline void setMatrixColumns(bool b0, bool b1, bool b2, bool b3,
bool b4, bool b5, bool b6, bool b7) {
PORTD &= ~((1 << 0) | (1 << 3) | (1 << 6));
PORTB &= ~((1 << 6) | (1 << 5) | (1 << 0) | (1 << 3));
PORTA &= ~((1 << 0));
// ^~~~~ можно вызывать реже,
// если в PINx передавать изменения относительно предыдущей строки
PIND = (b0 << 0) | (b1 << 3) | (b4 << 6);
PINB = (b2 << 6) | (b5 << 5) | (b6 << 0) | (b7 << 3);
PINA = (b3 << 0);
}
С последними стандартами плюсов, наверное, можно без особых ужасов проинициализировать массив consteval-функцией, которая бы делала необходимые оптимизации (повернуть массив в compile-time при необходимости и класть дельту начиная со второй строки матрицы, чтобы не считать её в рантайме).
Это что-то вроде простого баланса белого, но такого подхода недостаточно, чтобы определить RGB-пространство, в котором находимся, а из неизвестного пространства нельзя перейти в CIE XYZ, чтобы дальше перейти в OKLab.
Clear вроде приспосабливали для программной фильтрации инфракрасного света.
Этот датчик оказывается шатким фундаментом для OKLab, особенно если без калибровки по ColorChecker'у.
____
Заодно поправка к статье: адекватный перевод для gamut - это "цветовой охват", точно не "спектр".
*Постепенно пугаясь*
Это называют "трит".
Нет, это всё-таки странно, что там нет ограничений сверху на размер бита и байта ("ровно 2 состояния" и "минимально адресуемый [среди подходящих под прочие условия вроде того, что basic character set]").
Только второй пункт (и Гбит => Мбит).
"Network designers have generally used megabits per second (Mbit/s) to mean 1 048 576 bit/s, while telecommunications engineers have traditionally used the same term to mean 1 000 000 bit/s"
Спасибо. Всё равно странно, я о таком слышу в первый раз, а в google books только один результат с таким подходом есть.
https://books.google.ru/books?id=HhsoAQAAMAAJ&q="Kbit/s"+OR+"kbps"+"1024+bit/s"&dq="Kbit/s"+OR+"kbps"+"1024+bit/s"
Но интересно, что они отсылают к рекламной стороне.
"term was also easy for salesmen and shops to use, and it caught on with the public. Take, for example, the ubiquitous and so-called 3,5 inch floppy disk"
Которая после их нововведения никуда не делась (имею в виду непоследовательность в macOS и Android)
И приводят в пример величину 133,3 MB/s, хотя она как раз иллюстрирует невозможность указать - по старой системе она записана или по новой.
Ну и вакханалия.
Их тут успели обвинить и в переходе на двоичные приставки, и в отказе от двоичных приставок, хотя они ничего не меняли.
А винда продолжает использовать традиционные килобайты (у винды они всегда двоичные), как было до появления кибибайтов. Как в Android, только последовательнее.
Вот это в соседнем комменте тоже было славно вброшено:
Вы что-то недопоняли и продолжаете DDOS-атаку на меня.
Там вверху написано "LBA 145226112".
https://www.google.com/search?q=145226112+*+512+bytes+to+GB ~74 ГБ
оно же с двоичной приставкой будет
https://www.google.com/search?q=145226112+*+512+bytes+to+GiB ~69 ГиБ
То есть гигабайты на вашем диске десятичные, а я изначально заявил, что они на всех жёстких дисках десятичные.
Так вы смотрите, на что ссылаетесь.
На диске ёмкость нигде не указана, в названии число "42" и в магазинах его продавали как 42-меговый.
"For use also with" относится только к джамперам, у L40 другое число цилиндров. В рекламных каталогах его не найти, а в справочных каталогах он 41-меговый.
...и на что отвечаете - тоже, уж извините. Я написал "это прослеживается до их появления в 50-х годах", то есть лет за 40 до стандарта IEC.
Изменяет. 1980-й год, ST-506, ёмкость 5.0 мегабайтов по мануалу и это десятичные мегабайты: 612 * 32 * 256 bytes = 5.01 MB = 4.78 MiB.
Он просто позволяет задать интерфейс для статического (compile-time) полиморфизма, не прибегая к концептам как к слишком новой штуке.
То есть мы в такой шаблон функции
можем подавать* объекты любых классов, полагаясь на то, что у них есть метод f() (утиная типизация). А если нам это кажется небезопасным и хочется ограничить классы наследниками одного класса-интерфейса IBar, то это достигается с помощью CRTP.
* или как там правильно будет, "неявно специализировать"?
___
Не раскрыта тема девиртуализации. Компилятор достаточно умён, чтобы иногда избегать виртуальных вызовов. Используем CRTP = отказались от динамического полиморфизма = у компилятора есть возможность для девиртуализации, закатывание солнца вручную через CRTP может оказаться избыточным.
*Полушутя*
С таким байтом и в бите нельзя быть уверенным, ведь там, где байт определяют как наименьшую (?*) адресуемую единицу хранения данных, там бит определяют как
bit. unit of data storage in the execution environment large enough to hold an object that can have one of two values. It may not be possible to express the address of each individual bit of an object.
byte. addressable unit of data storage large enough to hold any member of the basic character set of the execution environment
* но там даже не сказано "наименьшую"?.. В обоих определениях размер ограничен снизу.
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3220.pdf#page=17
А именно, по крайней мере у Samsung, разницу между приставками на 2023 год прибавляют к размеру операционной системы.
Т.е. в телефоне имеется флеш-память на 512 ГиБ, без учёта служебной ёмкости (overprovisioning) доступно 512 ГБ, но в Android их хочется показать в двоичных гигабайтах (477 ГиБ), но красивее (477 двоичных контекстно-зависимых ГБ), но нет, ещё красивее (512 поддельных рекламных ГБ) - для этого разницу между 512 ГиБ и 512 ГБ прибавляют к размеру ОС, чтобы сошлось - и поэтому чем больше памяти у телефона, тем больше "весит" ОС.
Суд был, а этого не было:
Они использовали десятичные гигабайты до и продолжили использовать после (и правы с точки зрения СИ, IEC или госта), но по мировому соглашению они дальше обязались добавлять приписки типа "*1TB = 1 trillion bytes" из-за винды.
Там не прижились. Прижились в некотором софте - Linux в целом, ffmpeg...
Или из вежливости. Если читатель на самом деле не догадывается о точном значении приставки, его ждут ошибки в таких случаях:
"10.4 KB per track" - даташит на диск от пре-WD (Tandon)
"Head setting time: 15 Msec" - на диск из того диска
"768.0 Kbit/s" - пишет организация со 100-летней историей, National Association of Broadcasters.
"128 Kbps" - говорит американская ГКРЧ (FCC)
"9.6 Kbaud"
То есть 80.06 GB = 74.56 GiB. Это норма. А надо найти найти хоть один обратный случай (и с учётом вероятного округления заявленной ёмкости вниз, а не до ближайшего).
Постарайтесь вспомнить. На этикетках 40-гиговых Maxtor'ов в гугле везде есть либо количество LBA, указывающее на десятичные гигабайты*, либо сразу приписка "1 GB=1,000,000,000 Bytes".
* например, продаётся как 40 ГБ и 80 293 248 LBA * 512 bytes = 41.1 GB = 38.3 GiB.
Если ещё кто-нибудь вспомнит, то мы-таки получим настоящий эффект Манделы.
Вы распространяете заблуждения и написали статью в стиле "двухминутки ненависти" ради привлечения внимания.
Жёсткие диски всегда использовали десятичные приставки, это прослеживается до их появления в 50-х годах.
То есть правила СИ&IEC соблюдаются в HDD и нарушаются в RAM, но вы пытаетесь это вывернуть так, чтобы получить больше заявленного.
Ранняя macOS. Windows и дальше продолжает использовать двоичные килобайты, в Linux перешли на кибибайты. Если же смотреть из современной macOS, то вы увидите жёсткий диск на 500 ГБ как жёсткий диск на 500 ГБ и всё равно недовольны.
Вы не предлагаете решения для тех времён и почему-то считаете систему СИ нерушимым абсолютом, хотя у Международного бюро мер и весов нет своей армии. Правила СИ&IEC до сих пор нарушаются и у Apple (в оперативной памяти), и у производителей различных микросхем. В Android с измерением свободного места было что-то ещё более странное. Они обычно смотрят на вопрос с рекламной стороны (как "1.44 МБ" раньше), а вы не замечаете.
А размеры аудио-/видеофайлов в 8 раз больше? Битрейт (не байтрейт) - обычная практика.
Но не дала механизма, который бы позволил отличить старые контекстно-зависимые килобайты от новых точно-десятичных килобайтов. Даже если все бы одновременно перешли на новые правила, старые тексты бы не исчезли. По ссылке выше такую ошибку допустили.
В существование этих точек зрения после перечисленного не верится.
Зачем там больше гигабита?
Наверное, никак - в новые 8K-телевизоры 100 мбит/с ставят, прогоняя пользователей на Wi-Fi.
В даташите найти можно, хотя лучше знать, что искать.
https://ww1.microchip.com/downloads/en/DeviceDoc/doc8246.pdf#page=57
Да, этот прирост не нужен. Такие оптимизации пригодились бы, если бы у микроконтроллера были другие задачи, тогда ещё были бы нужны неблокирующие задержки, пришлось бы думать про (не)атомарность изменения PORTx.
Я тут не подумал, что строка
PORTB |= (1 << PB3);должна компилироваться в одну инструкцию SBI (Set Bit in I/O Register).Так как почти весь прирост должен быть от зажигания 8 светодиодов вместо 1 и задержки во включённом состоянии, не стал писать про отказ от digitalWrite().
Но вообще тогда думал, что можно упороться вплоть до использования регистров PINx (переключение пина без read-modify-write). И чересстрочной развёртки, чтобы достичь незаметности мерцания на более низкой частоте:
Идеи
С последними стандартами плюсов, наверное, можно без особых ужасов проинициализировать массив consteval-функцией, которая бы делала необходимые оптимизации (повернуть массив в compile-time при необходимости и класть дельту начиная со второй строки матрицы, чтобы не считать её в рантайме).
О, классно.
____
Заодно поправлю себя в прошлом комменте:
резистор
параллельнокаждому светодиоду(8+2)*8 =6480*Некропост*
Это что-то вроде простого баланса белого, но такого подхода недостаточно, чтобы определить RGB-пространство, в котором находимся, а из неизвестного пространства нельзя перейти в CIE XYZ, чтобы дальше перейти в OKLab.
Clear вроде приспосабливали для программной фильтрации инфракрасного света.
Этот датчик оказывается шатким фундаментом для OKLab, особенно если без калибровки по ColorChecker'у.
____
Заодно поправка к статье: адекватный перевод для gamut - это "цветовой охват", точно не "спектр".