Comments 99
Все эти форматы объединяются термином «minifloat».
А разве не "плавающая точка"
Кто вообще пользуется этой "запятой"? В каком компиляторе запятая поддерживается?
В русской терминологии и математике - запятая. В английской - точка.
Запятая не только в русской, а точка не только в английской. И вообще "плавать" может не только запятая или точка.
А в области, связанной с программированием то, что поддерживается компиляторами. Странно говорить про запятую, а писать в коде точку, не находите?
И вообще, русская терминология устарела, и пора её менять.
Запятая пришла к нам со времён рукописного текста - её проще ставить и заметить. Сейчас она как десятичный разделитель устарела, и надо стараться избавляться от неё всеми доступными способами, в том числе и при написании образовательных статей, чтобы новое поколение не тянуло эту legacy.
Вспомнилось, как я в школе на контрольной по математике выпендрился и везде вместо запятой поставил точку, как истинный "тру-программист", а еще ноль перечёркнутый.
За что мне училка поставила жирную двойку, хотя решено было идеально.
Как же у меня подгорало от вселенской несправедливости... )))
Очевидно, это некомпетентная "училка". Но в школах, увы, редко бывают хорошие учителя математики, очень уж сильны социальные факторы, препятствующие этому.
Слегка оффтоп: я во время учебной практики в аспирантуре получил хороший урок. Мы проверяли работы по вступительному письменному экзамену по математике на мехмат или ВМК, и мне попалась работа, написанная ужасно неразборчиво и неряшливо. Попыхтев некоторое время, я поставил ноль баллов за задачу, в решении которой ни слова не разобрал, пометив "невозможно прочесть". И получил её обратно от более опытного второго проверяющего: "мы обязаны разобраться! Если там есть решение, сколь угодно неразборчивое, но верное (!), его нужно зачесть." Очень долго просидел над этой работой, но таки разобрался, что верное решение там было.
надо стараться избавляться от неё всеми доступными способами
Желаю удачи избавиться от запятой в ЕСКД. Как получится — можно будет продолжить дискуссию о её устарелости.
Желаю удачи избавиться от запятой в ЕСКД. Как получится — можно будет продолжить дискуссию о её устарелости.
Тем не менее, избавляться надо. Например, в научном мире обменный формат - это чаще всего простой текстовый файл, где данные пишутся либо в выровненные столбики, либо, для сокращения объема, через запятую. Но в обоих случаях десятичный разделитель - это всегда исключительно точка:
3.14,1917.11,42.0,...
Так как традиционно все древние языки программирования такую запись считают стандартной и правильно ее понимают (про современные я просто не знаю). Вероятно, поэтому в русскоязычных рейтинговых журналах в статьях обычно именно точка используется (во всяком случае, в нашей области).
Но недавно мы отправили статью в один журнал "второго эшелона", очень уважительно относящийся к Правилам русского языка. Пришлось везде по тексту статьи менять точки на запятые... после чего списки из нескольких числовых значений превращаются в непонятно что. Там надо запятые на что-то еще поменять... но на что, если запятая - это общепринятый разделитель в списке?
Особенно интересно, когда в статье есть заимствованные картинки (сканы из цитируемых статей). Ведь там десятичный разделитель практически всегда исключительно точка. Ее-то не поменяешь (и дело даже не в технической возне с растром - это просто авторским правом запрещено).
В общем, это боль....
Короче, если кто-то таки пробьет это изменение Правилах русского языка (что автоматически спустится дальше в ЕСКД/ЕСПД и т.д.), ему при жизни поставят сразу несколько памятников. От IT-шников, от научных сотрудников, от учащихся школ и так далее ;-)
Какой символ является десятичным разделителем определяется локалью. Локали регулируются ISO и национальными организациями по стандартам.
В некоторых странах десятичный разделитель это точка, в других -- запятая. Это было ещё задолго до повсеместного распространения компьютеров, используемых в задачах, где эта разница существенна. Так что и начинать вам надо оттуда.
Там надо запятые на что-то еще поменять... но на что, если запятая - это общепринятый разделитель в списке?
Он не общепринятый, а только в тех локалях, где задан таковым.
И там, где десятичным разделителем является запятая, для форматирования CSV может быть использована точка с запятой. Что, кстати, почти везде стандартизовано
Какой символ является десятичным разделителем определяется локалью. Локали регулируются ISO и национальными организациями по стандартам.
Все так, но огромная куча научного софта игнорирует локали. При перемалывании чисел они нафиг никому не нужны, так как лишь породят жуткую кучу проблем совместимости. Я могу привести примеры, но там придется писать страницу преамбулы, чтобы подойти к сути. Поэтому приведу вместо этого аналогию. Разве не очевидно, что в идеальном мире максимально дружественного ПО компьютер должен общаться с юзером на родном языке? Вот кто-то, кому это было очевидно, когда-то давно локализовал (русифицировал) написание имен функций в Excell. Если Вы лично с последствиями не сталкивались (счастливый человек, завидую искренне!) - почитайте, сколько "благодарных" пользователей с тех пор расхлебывают этот ад. Как говорится, благими намерениями...
Сейчас практически все научное ПО (во всяком случае в нашей области) разговаривает на своеобразном эсперанто - то есть на ASCII8 (даже как бы не 7) со стандартным использованием служебных символов. При этом многие программы применяются десятилетиями, и до сих пор являются международным стандартом, хотя их авторы уже давным-давно умерли (пример: Этерна). И они не устаревают, так как физические законы не изменяются. Но и не модифицируются...
Еще больше существует файлов данных, сделанных в традиционных форматах. Причем старые наблюдения у нас так же важны, как и новые. Например, Вы скачиваете свежий блок наблюдений за 2022г, а затем склеиваете его с 50-ю предыдущими годовыми файлами, и запускаете обработку.
В общем, любая попытка внедрить вместо этого эсперанто многоязычие станет попросту катастрофой для целой отрасли знаний и не вызовет ничего, кроме абсолютно ненужных проблем. Как в истории про ту бабу, которая поросенка купила...
P.S. Я понимаю, сейчас есть модный тренд поддержки всего нетрадиционного. Но, не сочтите меня ретроградом, в тех сферах, где непрерывные наблюдения идут много лет, давайте все-таки с "нетрадиционными" форматами файлов (включая локали и разделители) будем поосторожнее? Очень-очень прошу...
Все так, но огромная куча научного софта игнорирует локали.
Это лишь означает, что этот софт написан некорректно.
При перемалывании чисел они нафиг никому не нужны, так как лишь породят жуткую кучу проблем совместимости.
Совместимости некорректно написанного софта с корректно написанным.
Разве не очевидно, что в идеальном мире максимально дружественного ПО компьютер должен общаться с юзером на родном языке?
Очевидно. Как очевидно и то, что язык взаимодействия является частью локали.
Представьте себе, например, французскую локаль. В которой вторник это «Mardi», десятичный разделитель -- запятая, а разделитель групп разрядов -- пробел. В этой локали вот такое будет корректной десятичной дробью.
1 234 567,89
Почему вы считаете, что, например, locale-aware парсер даты и чисел должен понимать Mardi, но игнорировать разделители?
Вот кто-то, кому это было очевидно, когда-то давно локализовал (русифицировал) написание имен функций в Excell
Причём тут это вообще? Синтаксис языков программирования не является частью локалей.
Сейчас практически все научное ПО (во всяком случае в нашей области) разговаривает на своеобразном эсперанто - то есть на ASCII8
...
В общем, любая попытка внедрить вместо этого эсперанто многоязычие
ASCII8 и ASCII7 это не локали, это кодировки. А то, что вы, скорее всего, имеете в виду, называется C или POSIX, и это локали. Абсолютно ничего не мешает корректно написанным программам общаться между собой в этих локалях, если уж вы так печетёсь об их интероперабельности и обратной совместимости с легаси софтом и данными.
давайте все-таки с "нетрадиционными" форматами файлов (включая локали и разделители) будем поосторожнее?
Традиционным подходом в разработке ПО является как раз-таки следование стандартам. Если с ними правильно работать, то как раз именно тех проблем, на которые вы жалуетесь, будет гораздо меньше.
Приведу пример, раз уж вы аргументируете Excel'ем. Он является, как ни удивительно, одним из немногих популярных продуктов, который учитывает системную локаль. В том числе -- при парсинге CSV-файлов разделителем полей в Excel считается именно тот символ, который выставлен в настройках системной локали, как на скришоте, который я привёл выше. А не тот, который кто-либо считает традиционным.
А вот более очевидный пример. Допустим, работая с Excel во французской локали, в ячейку типа Number я вношу десятичную дробь «1 234 567,89», которая будет корректно распарсена и сохранена в самом документе как float. При открытии этого документа в Excel в другой локали, например, американской, этот флоат будет отображён с точкой как 1234567.89, в соответствии с национальными американскими стандартами.
Это и есть функция локали -- обеспечивать представление данных, как вы выразились, «на родном для юзера языке», если речь идёт об интерфейсе человек-машина. На интерфейсе машина-машина пусть общаются в машинных локалях, о которых я упоминал выше.
Что плохого в такой схеме?
Все так, но огромная куча научного софта игнорирует локали.
Это лишь означает, что этот софт написан некорректно.
Конкретно тот софт, который я привел в качестве примера (Этерна), был написан еще до того, как понятие "локаль" приблизилось к современному пониманию. А многоязычность программ стала стандартом. Это помимо вопроса об удобстве следования ему в конкретной среде разработки (которая в науке выбирается совсем из других соображений, чем в программировании). И тем не менее, эта программа - мировой стандарт на сегодняшний день. Поэтому позиция "Мы наш, мы новый мир построим" (вместо старого неправильного) выглядит в этом случае, хм, несколько спорной.
Хотя... Если Вы настаиваете, что действительно нужные программы (а Этерна в их число совершенно точно входит) следует переписать по стандартам, и что ради этого не грех приложит достаточные усилия - то флаг в руки. Правда, конкретно в этом случае нам для этого придется как-то вытащить ее автора обратно в наш мир... Но если (чем черт не шутит?) Вы и правда сумеете это сделать, то вне зависимости от того, уговорится ли он переделать свое ПО, или нет, множество народу будет Вам благодарно. Включая и те десятки людей, которые пытались переписать Этерну в более современном виде уже после ухода автора... но вот не сумели.
И второй нюанс.
Научный софт не пишется коллективами программистов, у которых есть куча ресурсов, в том числе и на организацию "правильного" интерфейса. Чаще всего такие программы - это результат труда одно-двух гениев, главные знания и умения которых - это вовсе не программирование. Они сначала делают что-то такое, что никто в мире не смог, а потом в качестве "побочного эффекта" реализуют это в виде программы. Один такой выдающийся человек получил достаточно серьезные результаты в теории земных приливов, и реализовал эти свои достижения в виде программы Атлантида, которая эти приливы рассчитывает. А для организации интерфейса к своим алгоритмам он взял какую-то библиотеку, которая как раз-таки умеет в локали. Я даже не знаю, какую именно... но что-то он там недокрутил немного (или может в библиотеке была ошибка), и теперь все пользователи Атлантиды при
вводе параметров счета
испытывают чудовищные мучения, так как при чтении введенных параметров настройки локали обрабатываются одним методом, а при вставке умолчаний - каким-то другим, и эти методы конфликтуют. В результате чего во всех полях ввода приходится вручную править точки на запятые или наоборот. И на большинстве компов никакие настройки ОС не помогают это исправить. То есть лично у автора на компе по какому-то стечению обстоятельств все работало... а больше почти ни у кого не работает.
А тестировать свою программу на других версиях ОС у таких людей обычно просто возможности нет. Так как такая отладка требует еще плюс 50% к времени написания работающего кода. Плюс надо где-то эти компы физически взять, и т.д. и т.п. А у них совсем другие задачи в приоритете.
Ну а когда стало понятно, что глюк этот массовый и весьма неприятный, то у автора что-либо править уже физической возможности не было :-(
Да, современные продвинутые программисты, которые сами никогда не совершают ошибок, с высоты прожитых лет наверно имеют моральное право посмеиваться над дремучим неучем из научной среды, который не понимает разницу между "корректно" и "некорректно" написанным софтом. Только вот если бы этот неуч посвятил свое время изучению программирования, то никакого вклада в развитие теории приливов он бы, скорее всего, не внес. Попросту не успел бы. И самой этой программы не было бы.
Это я все к чему говорю: если бы автор Атлантиды не заморачивался с попыткой учета "стандартов", а тупо использовал в качестве десятичного разделителя точку всегда и везде, то ВСЕМ было бы гораздо удобнее. Включая и тех же французов. Которые, кстати, его Атлантиду используют.
Конкретно тот софт, который я привел в качестве примера (Этерна), был написан еще до того, как понятие "локаль" приблизилось к современному пониманию.
Позвольте усомниться.
Локали в более-менее современном виде появились в POSIX, а это начало 1980-х. Но я понимаю, о чём вы. Ни Фортран, ни Бейсик не умеют нативно в локали и до сих пор.
Поэтому позиция "Мы наш, мы новый мир построим" (вместо старого неправильного) выглядит в этом случае, хм, несколько спорной.
Новый мир уже давно построен и работает. Это как раз вы пытаетесь отстоять и оправдать исключительность очень узко-нишевого легаси, написанного на косячных инструментах без намёка на удобство сопровождения продукта.
Но если (чем черт не шутит?) Вы и правда сумеете это сделать,
...
множество народу будет Вам благодарно
За ваши деньги -- любой каприз.
Научный софт не
Вот это вы сейчас лихо рассказываете, какие программы пишут люди из научной среды как-раз таки человеку из научной среды, который в этой среде пишет программы. Не надо частные особенности возводить в правило и, тем более, в культ.
если бы автор Атлантиды не заморачивался с попыткой учета "стандартов", а тупо использовал в качестве десятичного разделителя точку всегда и везде,
Аргументировать несоблюдение стандартов криворукостью автора это мощно, да.
И я понимаю, что таких может быть даже большинство. Но это не делает данный подход верным, а всего лишь распространённым.
Локали в более-менее современном виде появились в POSIX, а это начало 1980-х.
Именно Этерна писалась и работала в DOS. Подавляющее число обычных людей тогда о локалях не задумывалось, насколько я помню. Если бы автор какой-то консольной программы типа Этерны сделал настраиваемый десятичный разделитель, на него бы посмотрели, как на идиота.
Кроме того, сам факт зарождения современного стандарта в стародавние времена нам виден только сейчас. А в те стародавние времена разных стандартов в информатике было множество (например, экран 25х80), и какой из них выживет (а какой умрет/эволюционирует), обычному человеку было совершенно не ясно.
Аргументировать несоблюдение стандартов криворукостью автора (...) не делает данный подход верным, а всего лишь распространённым.
Я наверно плохо сформулировал свою мысль, и из-за этого остался непонятым. Я имел в виду, что профессионализм в любой области не дается бесплатно. А высокий профессионализм (когда ты один из лучших в мире, а то и вовсе лучший) - стоит очень большого времени. Тот человек, о котором я написал, в своей области был лучшим. При этом он еще и сформулировал свои алгоритмы в виде общедоступной программы, которой пользуются специалисты из разных стран мира, так как она лучше других аналогов. Тестирование на данных европейских станций сети сверхпроводящих гравиметров показало, что Атлантида на треть точнее, чем самые продвинутые альтернативы.
Так вот, говоря чисто теоретически, он мог бы использовать более простой интерфейс (без претензии на учет локалей), и сделал бы более удобную в использовании программу с тем же самым функционалом. Я тут защищаю именно этот подход. Даже несмотря на всю его ущербность, которую мне тут уже достаточно доходчиво объяснили.
Но позвольте тогда и мне объяснить, почему я защищаю столь странную в современном мире позицию. Дело в том, что если бы этот конкретный Е.А. больше времени посвятил программированию (вместо развития теории приливов), то он, несомненно, научился бы писать программы без глюков. Только вот в этом случае у него не осталось бы времени получить прорывные результаты в теории приливов. И его программа с локалями и без глюков была бы никому не нужна.
В сети есть хороший мем
качественно-дешево-быстро
В нашем случае ситуация полностью аналогичная. Все, что Вы пишете - правильно. Проблема лишь в том, что в рассмотренных мной конкретных условиях (научный институт, причем вовсе не обязательно здесь в РФ-ии) этого "не бывает".
А excel уже научился в русской локали автоматически детектировать и правильно считывать csv-шки с десятичной точкой? А то очень неудобно, что при использовании csv как формата обмена между системами с разными локалями нет универсального варианта - или в одной системе нужно вручную выставлять правильный разделитель, или в другой.
Это не только проблемы "совместимости некорректно написанного софта с корректно написанным", но и проблемы совместимости форматов. В том числе передачи данных.
Синтаксис языков программирования не является частью локалей.
Что интересно, я вроде бы не слышал, чтобы какой-нибудь язык программирования использовал локализованные разделители при вводе чисел, или, например, списков. По-моему, большинство в последнее время сходится на общем формате с точкой в роли десятичного разделителя и подчёркиванием в роли разделителя групп разрядов.
А excel уже научился в русской локали автоматически детектировать и правильно считывать csv-шки с десятичной точкой?
А должен? В русской локали, ЕМНИП, десятичный разделитель это запятая.
или в одной системе нужно вручную выставлять правильный разделитель, или в другой.
А лучше вообще не использовать человеко-читаемые форматы данных на интерфейсе машина-машина.
Что интересно, я вроде бы не слышал, чтобы какой-нибудь язык программирования использовал локализованные разделители при вводе чисел, или, например, списков.
Совершенно верно. Именно по той причине, которую я указал выше -- синтаксис языка не является ни частью локали, ни даже национальным стандартом.
Но вот данные, которые считывают программы, написанные на этом языке, национально-специфичному форматированию вполне могут быть подвержены. Нет здесь противоречий.
Формально, наверное, не должен... если мы предполагаем, что обмен csv-файлами между пользователями с разными локалями событие редкое. В моём случае, увы, это не так.
Насчёт "не использовать человекочитаемые форматы на интерфейсе машина-машина" - не могу полностью согласиться. Как минимум это зачастую может существенно упростить отладку. Не говоря уже о том, что многие интерфейсы не чисто человек-машина, а смешанные, пригодные для использования как машинами, так и людьми.
И да, для меня лично единообразие между представлением чисел в программном коде и во всех остальных случаях (а также функционирование ПО, которое не полностью корректно отрабатывает десятичные разделители) достаточно приоритетно, чтобы всегда в своих компьютерах использовать английскую локаль.
А лучше вообще не использовать человеко-читаемые форматы данных на интерфейсе машина-машина.
Ну да, ну да! И одновременно закрыть все Линуксы/Юниксы, где это считается лучшей практикой. Пусть все платят умным парням от MS. Они вам все локали исправят и сделают WYSIWYG.
А покажите, пожалуйста, где именно в Линуксе это считается лучшей практикой.
Нет там такого.
пишите программы, которые бы поддерживали текстовые потоки, поскольку это универсальный интерфейс.
Write programs to handle text streams, because that is a universal interface.
храните данные в простых текстовых файлах;
Store data in flat text files.
Попытался представить себе условный нетфликс, который стримит фильмы в текстовом потоке...
Эти принципы, как и любые другие, имеют свою область применимости. И не следует возводить их в абсолют.
А покажите, пожалуйста, где именно в Линуксе это считается лучшей практикой.
Нет там такого.
Эти принципы, как и любые другие, имеют свою область применимости.
Мягкий дрейф мнения. А написать «был неправ» сил не хватило.
Вам от этого легче станет?
Ну окей, я был неправ по поводу того, что "нет там такого".
Остальное всё в силе.
Остальное всё в силе.
Мы вроде только об этом и спорили. Остальное это что?
Если об «области применимости» – конечно это так. X например, это абсолютно бинарный протокол потому что это лучшее решение в случае. И оно перевешивает преимущества человеко-читаемых данных. Но только в этом конкретном случае.
А философия Линукс в случае заключается в том, что всегда следует стремиться сделать данные человеко-читаемыми. И отступать от этого только если обстоятельства не позволяют (например производительность).
А философия Линукс в случае заключается в том, что всегда следует стремиться сделать данные человеко-читаемыми. И отступать от этого только если обстоятельства не позволяют (например производительность).
Вот эти линукс-философы на ранней стадии развития Интернета понапридумывали человеко-читаемых протоколов, все эти HTTP/SMTP/POP3/IMAP/IRC/Telnet/SIP/XMPP и, прости г-ди, FTP, кое-где даже нарушая разделение сетевой модели на уровни. Плюс извращения вроде того, что кошерный SMTP обязательно должен влезать в 7-битный ASCII, так что извольте сексоваться с MIME туда-сюда.
А сейчас не могу не заметить явную тенденцию, что всё, что приходит им на смену -- сплошная бинарщина. Не отдельные изолированные случаи нехватки производительности, а просто везде. http/3,grpc,mtproto,ssh и всё в этом же духе.
Не спроста это жжж.
ASCII8 и ASCII7 это не локали, это кодировки. А то, что вы, скорее всего, имеете в виду, называется C или POSIX, и это локали. Абсолютно ничего не мешает корректно написанным программам общаться между собой в этих локалях, если уж вы так печетёсь об их интероперабельности и обратной совместимости с легаси софтом и данными.
Я понимаю разницу между кодировками и локалями. Но научный софт - это вовсе не черный ящик, где надо нажать кнопку "сделай мне хорошо". В эти файлы почти всегда приходится сперва "лазить руками". И ситуация, когда в файле десятичным разделителем будет точка, а в интерфейсе программы - запятая, будет катастрофически неудобна для того, кто с этим работает. Так как у него основная часть головы занята совсем другим, а не форматами/кодировками. А если в одном файле будет запятая, а в другом точно таком же точка (имеющая тот же смысл), то это
вообще катастрофа
Если, конечно, не разделить науку на страны по принципу "точка, точка, запятая" и не запретить ученым из разных зон общаться между собой (прощай, глобальная сеть метеонаблюдений, а также сейсмическая, гравиметрическая и т.д.).
так как все эти файлы сплошь и рядом режутся на куски и склеиваются в разных пропорциях в ходе работы. Или Вы предлагаете в каждый файл добавить пометку, в какой локали он создан? Идея, наверное, неплохая, если, конечно, одновременно с принятием такого решения сразу же провести рефакторинг абсолютно всех существующих файлов данных (сколько их там в мире всего?) и абсолютно всего софта. Да, забыл: надо же ведь еще как-то заставить абсолютно весь мир с этим рефакторингом согласиться...
В общем, в каком-то сферическом вакууме какие-то идеально написанные программы может и смогут со всем этим работать... но я в соседних ветках привел кучу примеров, что в реальной жизни это в принципе невозможно.
Поэтому конкретно в науке нужна простая и тупая унифицированная система, к которой один раз привыкаешь - и все, навсегда.
И в науке такая система уже есть де-факто. Она включает огромное количество файлов данных и огромное число программ, которые в этом стандарте работают. Прекрасно выполняя свои задачи. ПРичем, эти программы используют точку в качестве десятичного разделителя даже в тех странах, где обычно разделителем является запятая. То есть, имеется один универсальный язык, на котором де-факто разговаривают абсолютно все. И всех понимают.
Вы предлагаете всю эту систему сломать, заменить чем-то более совершенным, но ради чего? Ради какого-то абстрактного идеала? Но пользователи таких программ - это не бабушки на кухне, которые привыкли запятой в ценнике, и точка в неправильном месте сразу заканчивается инфарктом. Любые улучшения должны идти на пользу тем, кто этим софтом пользуется. А не ради стандарта (который к тому же еще и меняется иногда).
Мир таков, каков он есть, и это надо принять и смириться. А все улучшения пусть внедряются исключительно добровольно. В противном случае можно закончить насильственным внедрением системы СИ, например, в США - ради общего блага, естественно. А если вдруг кто-нибудь будет против, то это неправильный человек и ему не место в цивилизованном мире. Можно его в резервацию, а лучше сразу атомной бомбой.... Опыт показывает, что такие попытки насильно сделать людей счастливыми ничем хорошим никогда не заканчиваются. Увы.
И в науке такая система уже есть де-факто.
Не спешите расписываться за всю науку. Я довольно много работал с сырыми данными миссий SRTM да и вообще с DEM моделями, как для пет-проектов, так и для муниципальных. И не было там никаких точек и десятичных разделителей вообще. Чистая бинарщина, двухкоординатный меш из 16-bit signed big-endian. Что есть архитектурно правильно.
Вы предлагаете всю эту систему сломать
Нет. Я предлагаю хотя бы называть вещи своими именами. Кривое легаси -- кривым легаси.
В противном случае можно закончить насильственным внедрением системы СИ, например, в США - ради общего блага, естественно.
А вы в курсе, что в этих самых США однажды всю космическую индустрию вместе с NASA взяли да и принудительно перевели как раз таки на систему СИ?
Потому что до того кто-то там посчитал параметры Mars Climate Orbiter в одной неметрической системе, а кто-то другой -- в другой, но тоже неметрической и в результате корабль был потерян с концами. Это к вопросу о том, нужно ли стандарты соблюдать или делать «как привычно».
Не спешите расписываться за всю науку.
Возражение принимается. Разумеется, я знаком лишь с несколькими ее разделами. Но во всех этих разделах (довольно разных) ЕСЛИ обменный формат текстовый, ТО разделитель всегда точка. Отсюда я экстраполировал, что это почти всегда так. Ваш пример, между прочим, этот мой тезис не опровергает. Кстати, не для спора, но просто интересно: если кто-то видел текстовый обменный формат с десятичным разделителем-запятой, поделитесь, пожалуйста?
Кривое легаси -- кривым легаси.
Легаси - согласен, кривое - нет.
Так как эта система прекрасно работает и полностью самосогласованна, пока ее не пытаются насильственно адаптировать к тем стандартам, для которых все это не предназначено. Если обмен данными идет успешно, расчеты выполняются правильно, а все участники цепочки довольны, т.е. целевая функция достигается, то я нахожу странным называть такую систему "кривой".
А вы в курсе, что в этих самых США однажды всю космическую индустрию вместе с NASA взяли да и принудительно перевели как раз таки на систему СИ?
Нет, детали не знал. Но здесь речь идет об инженерном проекте, а на заправке, я надеюсь, никто этих людей не заставляет покупать бензин в кубометрах?
В фундаментальной науке очень многие программы пишутся в расчете на одного юзера и на использование "один раз" (т.е. в рамках единственного проекта). И в момент написания (пока результаты не получены и не проанализированы) далеко не всегда можно предугадать, что программа станет нужна многим людям и постоянно. Поэтому изначально закладывать туда что-то сверх минимально необходимого никто не будет (да и не сможет физически). Но даже когда востребованность наметилась (а это может случиться через год после завершения проекта, когда статью прочтут и заинтересуются), серьезно вкладываться в доработку интерфейса мало кто станет, так как автор программы обычно уже увлечен другими идеями и задачами. Ему новый проект двигать надо. Хорошо, если он к консольному приложению прикрутит GUI... а чаще просто - берите as is. Это же не коммерция, автор за доработку программы (почти) никаких бонусов не получит.
Это к вопросу о том, нужно ли стандарты соблюдать или делать «как привычно».
Ну кто же спорит, что лучше быть богатым и здоровым одновременно. "Как привычно" - это же не от вредности. Конечно хорошо, когда ученый умеет и то, и другое на высшем уровне. Только вот "не бывает"...
А вы в курсе, что в этих самых США однажды всю космическую индустрию вместе с NASA взяли да и принудительно перевели как раз таки на систему СИ?
Имперская система для кого-то такой же стандарт, как написание чисел. Проблема возникла на стыке стандартов. Аж чем-то локали напоминает. Человек и предлагает свести хотя бы научные данные к единому стандарту написания. Прям как NASA.
Ещё раз, вы путаете возможность и должествование. Возможно использовать запятую? Возможно, даже для этого есть стандарты, локали и традиции.
ДОлжно ли использовать запятую, и обрекать людей на проблемы, дополнительные ошибки, и, как следствие, более высокую стоимость разработки? Конечно, нет!
Я всегда на виндовых компах, где работаю, правлю настройки локали чтобы запятой не было, потому что иначе имею проблемы с частью научного и рассчётного софта. Поэтому в моих лабах настройки локали - точка.
Это не я путаю.
ДОлжно ли использовать запятую
Должно правильно работать с локалями. Т.е. перекладывать заботу о том, точка там нужна или запятая на подсистему ОС или рантайм, а не на юзера и тем более не на хардкод. Экономия на standard compliance всегда вылазит боком, в том числе и по деньгам, просто немного позже в жизненном цикле продукта.
А если вы правильным подходом считаете править системные настройки в угоду криво написанному софту, то рано или поздно у вас возникнет ситуация, когда две разные софтины потребуют взаимоисключающих правок. И вам придётся в размышлениях о высокой стоимости разработки лепить какое-то middleware.
Компиляторы должны работать с локалями?
Если компиляторы занимаются чтением и обработкой данных, которые подвержены национально-специфичному форматированию -- то да, иначе -- нет.
Назовите мне признаки "данных, которые подвержены национально-специфичному форматированию".
Код это такие данные?
Признак: данные, которые подвержены национально-специфичному форматированию.
Например, локализованные названия дней недели, месяцев, метки am/pm, да даже банальный DD-MM-YYYY или MM-DD-YYYY.
Код это такие данные?
Нет, не такие. А к чему вопрос?
Признак: данные, которые подвержены национально-специфичному форматированию.
Так признакт-то какие? Как, глядя на данные, мне нужно понять, что их надо представлять в машино (компиляторо) нечитаемом виде? Мне кажется, что это только те данные, с которыми больше не будут работать, а будут только читать люди. То есть уже не нужные данные.
Нет, не такие. А к чему вопрос?
статья про код. Значит в этой статье нет данных, подверженых коррозии "национально-специфичному форматированию". Значит тут запятая неуместна.
Как, глядя на данные, мне нужно понять, что их надо представлять в машино (компиляторо) нечитаемом виде?
Очень просто. Вы же знаете, кто эти данные будет читать, исходя из ТЗ и архитектуры проекта? Ну вот в таком виде и представляйте.
Тем более, я конкретные примеры привёл.
статья про код.
Статья -- да. А конкретно эта ветка -- про особенности текстового представления десятичных дробей и смежные проблемы. Ваш экскурс в компиляторы вообще не уместен.
По-моему, надо избавляться от жесткой привязки семантики к представлению в коде. Все нормальные библиотеки работы с данными должны иметь возможность выбирать читать как запятые, так и точки по выбору (кроме того, что хранить численные данные в текстовом представлении — вообще плохая практика в науке, от которой стоит отказываться). При написании статьи в LaTeX можно пользоваться пакетом siunitx, в котором замена точки на запятую делается одним параметром output-decimal-marker или вообще заданием локали для пакета.
По-моему, легаси — это как раз игнорирование языкового и типографического разнообразия. Как раньше все только с ASCII работали и предполагали, что других символов кроме латиницы в мире нет, а сейчас отсутствие поддержки юникода — дурной тон.
По-моему, легаси — это как раз игнорирование языкового и типографического разнообразия. Как раньше все только с ASCII работали и предполагали, что других символов кроме латиницы в мире нет, а сейчас отсутствие поддержки юникода — дурной тон.
Вы в каком-то идеальном мире живете.
В науке ситуация совершенно другая.
Реальная ситуация такова: есть один человек, и у него условные 10 часов, за которые можно либо повысить точность расчета в 10 раз (и получить нечто выше мирового уровня), либо вместо этого оформить мультиязычный интерфейс к своей программе (но сами результаты расчетов будут никому не нужны).
Что Вы выберете на месте такого сотрудника?
Вы в каком-то идеальном мире живете.
Мы его пишем.
Что Вы выберете на месте такого сотрудника?
Выберу место работы, где руководство не вынуждает стоять перед подобными дилеммами.
Мы его пишем.
Искренне желаю Вам удачи в этом деле.
Но, столь же искренне сомневаюсь, что такой мир возможен. Если за столько лет даже столь массовый продукт, как Exell, не научился снимать с юзера все проблемы с совместимостью локалей и версий, то что уж об остальных говорить... Ведь даже если кто-то сумеет решить все такие проблемы в своем заповеднике, есть же еще огромный остальной мир, с которым придется как-то взаимодействовать, и который на эти стандарты либо забьет, либо примет свои, либо будет кишеть нестандартизированным легаси...Тут как с календарем: имеющий легаси-календарь ужасен, уродлив и неудобен чуть меньше, чем всем. Гораздо более идеальных календарей - пруд пруди. И тем не менее шансы, что один из них будет принят ВСЕМ миром, пока что строго равны нулю...
Выберу место работы, где руководство не вынуждает стоять перед подобными дилеммами.
Совет хороший, но годится далеко не для всех. В соседней ветке я подробно рассказал о своем коллеге. У него такого выбора в принципе не было, так как дилемма исходит вовсе не от начальства, а от гораздо более фундаментальных вещей. И, глядя на интерфейс других программ расчета приливов, у меня складывается впечатление, что в фундаментальной (а не прикладной) науке это достаточно типичная ситуация.
При использовании сторонних протестированных инструментов вместо собственных костылей писать более совместимые вещи еще и выходит быстрее. Та же поддержка юникода распространилась больше за счет языков и библиотек, нативно поддерживающих юникод, а не копания в том, как юникод устроен. И уж точно тот факт, что сотрудник вручную через CSV данные пишет и читает без автоматического экранирования, не был бы ему плюсом.
Я сам всю жизнь в науке работаю, понимаю, сколько в ней уродливого софта, и что не всегда есть возможность избежать его использования. Но это повод хотя бы не стремиться к лучшему.
А в области, связанной с программированием то, что поддерживается компиляторами.
Да и от использования русского языка тоже надо отказаться. Ведь компиляторы его не поддерживают.
Запятая пришла к нам со времён рукописного текста - её проще ставить и заметить.
А англичане-то не знали. Пользовались точкой и мучились, бедные. Если что вот тут освещена история вопроса
А уж как устарела имперская система мер!
С ней будем бороться?
Но ведь она действительно устарела и бороться с ней активнее очень было бы неплохо!
Да!
Представляю себе новый корпус SOIC8(EU) с расстоянием между ножками 1,5мм вместо 1,27))
А почему бы и не 1,27? Главное, чтобы это было именно 1,27 мм, а не 1/20''
Очень много современных SMD элементы имеют размеры закругленные по метрической системе.
А кстати, 1.27мм это именно метрический размер. Если бы написали 50mils, это было бы по имперски.
Сейчас как бы милы точно соответствуют миллиметрам, это раньше был разброс в точных значениях.
Соотношение дюйма и сантиметра (из Вики):
1819 год — 1000000/393694 см ≈ 2,5400438 см;
1895 год — 2,5399978 см;
1922 год — 2,5399956 см;
1932 год — 2,5399950 см;
1947 год — 2,5399931 см.
с 1958 года приравнивается точно к 2,54 см.
Я писал именно о приведении к кратности к миллиметру и его десятичным частям.
Хотя ясно что уже столько выпущено деталей что никто переделывать привязку к дюйму уже не будет.
А вы не задумывались, почему все более современные SMD компоненты уже названы и стандартизированы в миллиметрах?
Да. И местами удачно. Фарм индустрия в США потихоньку переезжает на метрику, и это спасает кучу человекочасов, причём весьма квалифицированных, то есть делает производство дешевле, выгоду болшьше а продукт доступнее.
NF4 это какая-то хитрая разновидность формата с фиксированной запятой? Судя по числам, там разные расстояния между соседними числами в положительной и отрицательной областях. Это кстати оправдано?
Нет, NF4 это не про фиксированную запятую. Это теоретически оптимальное lossy minimum entropy encoding: вероятность энкодинга числа в каждый из 16 значений должна быть одинаковой, для этого берется нормальное распределение и считаются нужные квантили. Но было бы странно, если бы они были несимметричны, нужно смотреть оригинальную статью (qlora), чтобы разобраться
На PIC помню еще был float24
А физики смотрят на этот "пир духа" и тихонько посмеиваются, делая ставки на то, когда до ML-щиков дойдёт понятие "численной устойчивости метода".
Данные форматы, начиная с half и ниже, предназначены для хранения данных а не для вычислений. Операций вычисления даже с half я с ходу не могу сказать кто вообще поддерживает, может быть какие то железки специально для ML, GPU хоть и поддерживают half но только для уменьшения bandwidth, вычисления делаются в single.
GPU хоть и поддерживают half но только для уменьшения bandwidth, вычисления делаются в single.
Это не правда. Некоторые карты Nvidia и любые карты AMD после Поляриса, поддерживают нативные вычисления в FP16. Ровно как и GPU Apple.
https://www.techpowerup.com/gpu-specs/geforce-rtx-2080-ti.c3305
RTX2080ti
FP16 (half)26.90 TFLOPS (2:1)
FP32 (float)13.45 TFLOPS
FP64 (double)420.2 GFLOPS (1:32)
Radeon RX7800
https://www.techpowerup.com/gpu-specs/radeon-rx-7800-xt.c3839
FP16 (half)74.65 TFLOPS (2:1)
FP32 (float)37.32 TFLOPS
FP64 (double)1,166 GFLOPS (1:32)
32-битный регистр содержит две 16-битных половинки. Можно работать как с одной половинкой, так и сразу с двумя, командами типа V_PK_MUL_F16 и другими.
Для числовых форматов с малой разрядностью весь набор операций можно реализовать таблично. Если получившаяся табличка влезет в кэш, то получится весьма быстро и без поддержки CPU.
Это же для neural net используется. Здесь вычислительная устойчивость достигается другими методами, да и вообще нейросеть, для каких-то задач может быть вообще не применима. Для задач, решаемых с использованием нейросетей, требуется другая устойчивость - "робастность".
Так устойчивость и не достигается же. С одними и теми же весами, сидом и промптом Stable Diffusion вам разные картинки нарисует на разных видеокартах. Похожие, но разные. Вот эту похожесть и называют робастностью, насколько я понимаю.
Если на карточках нет багов с арифметикой - то одну и ту же.
Робастность означает, что если вы попросили лошадь, то ни при каком сиде вам космический корабль не нарисуют.
Я вам отвечу как разработчик, писавший тесты для реализаций редукции на GPU: даже эта базовая операция нейрона в half (а уж тем более в bfloat) при типичных параметрах нейросетей вообще численно нестабильна, слишком велики ошибки округления на каждой операции. И это не баг, это фича арифметики с плавающей запятой - там операции неассоциативны, раз, и точность их реализации по стандарту допускает ошибки (обычно в последнем знаке), два, а ошибки у разных вендоров и моделей в разную сторону. Так что воспроизводимость у нейросетей весьма условная.
С другой стороны, может, это и хорошо. Получаем "живость", а не как "бездушный автомат".
Это как раз плохо. Компьютеры у нас не квантовые. Поэтому при одинаковых битиках на входе расчётные алгоритмы должны выдавать одинаковые битики на выходе независимо от алгоритма.
Даже с нейросетями плохо - нельзя использовать некоторые стратегии распараллеливания задач (когда часть вычислений дублируется).
Я думал, что их применяют там, где устойчивость заведомо есть.
Любой алгоритм на числах с плавающей точкой можно переписать на целых числах. И когда речь идет о 4-битных числах, то сам бог велел. И проще и нагляднее и быстрее.
Не знаю почему городят эти пляски с плавающей точкой... Если кто знает, пусть объяснит.
как ответили выше , 4-битные числа экономят место для хранения
в целыс числах всегда занимает больше места
Я имел ввиду 4-битные целые числа. Они занимают точно такое место и принимают точно те же 16 значения.
За счёт неравномерной сетки получается лучше перемножать числа < 1. Т.е. (1/16)^2 на целых не вычислишь, а на таких флоатах - вычислишь, хоть и с погрешностями.
Вы не прочитали мой первый пост по теме. Если алгоритмы написаны с целыми числами, то нужды вычислять (1/16)^2 не возникнет. Там будут только целые числа. А кстати, покажите-ка как с 4-битными числами запишете 1/16 вычислите результат (хоть с большей разрядностью) и запишете результат? Получится 0*0 = 0.
ок, давайте пример из статьи переведем в целые числа
0.0000, 0.0052, 0.6667, 1.0000, 0.3333, 0.5000, 0.1667, 0.2500, 0.0000, -0.0052, -0.6667, -1.0000, -0.3333, -0.5000, -0.1667, -0.2500
...
Честно говоря, я не знаю как эти числа в статье были получены. Покажите двоичный код. Два нуля вижу. Но где 2хNaN и 2хInf?
А вообще-то если примем, что должно перекрывать диапазон -1..+1, то в инт, просто надо разделить число на 8: получим диапазон от -8/8 .. +7/8 = -1 .. 0.875; Единица младшего разряда будет 1/8 = 0.125;
С целыми у вас не получится динамический диапазон сделать как у вещественного, если вы про реализацию дробных чисел целыми, как в DSP целочисленных делают. А если в уме начнете множители учитывать, так получите свою реализацию вещественного формата на 4 бита, а не целочисленную математику, то-же самое будет у вас, но чуть по другому.
Наоборот. У 4-битового числа с плавающей точкой все-равно есть два нуля, две бесконечности и два NaN. То есть использовать можно 11 значений. У 4-битового целого есть все 16 значения и динамический диапазон у него больше.
Про "NaN" - судя из теста статьи, в этом формате этого нет. Беглый поиск не дал точное описание формата, поэтому делаю предположение, что NaN там и не будет, а будет контроль переполнения, тогда в результате переполнения будет максимум, как делают в ЦОС и DSP процессорах. И в плавающей точке эти проверки будут делаться автоматически, а для целой точки вам придется или это как-то контролировать и получите примерно то-же самое, если начнете обставлять операции проверками.
Целые числа, например, используют, когда сетку засовывают, например, в FPGA - там заранее при анализе смотрят на диапазоны и где можно - переводят в целую точку.
Точно не скажу, но основная хитрость в том, что значения распределены не равномерно, ближе к нулю значений становится больше (можно заметить на графике синуса). То есть точность повышается при стремлении к нулю. А с точки зрения байтов, да, никакой разницы.
@iBuilder: С целыми у вас не получится динамический диапазон сделать как у вещественного
@zartdinov: Точно не скажу, но основная хитрость в том, что значения распределены не равномерно, ближе к нулю значений становится больше
Все верно... но бывают и контрпримеры. Например, у нас часто измерительный датчик прикручен ко входу 16-битного АЦП. То есть значения на выходе по сути получаются целые. Хотя по физическому смыслу они real. Только этот real надо еще сперва вычислить, прибавив к базовому смещению произведение выходного сигнала на цену деления одного разряда АЦП. Например, нулевому значению АЦП может соответствовать число "100", а максимальному - "1000". И дальше уже не важно, преобразуются ли данные после АЦП в real сразу же, или это делается когда-то потом. Количество возможных значений все равно ограничено разрядностью АЦП.
Для хранения таких данных равномерная сетка подойдет значительно лучше, чем динамическая. Важно лишь, чтобы она заполняла целевой диапазон и только его. Поэтому мы еще в 1989 году сделали в своей программе формат real*16. Правда, не для расчетов, а для хранения данных в БД.
На практике для работы с такими сигналами сперва задается максимальный диапазон изменения физической величины (обычно это делает юзер при оформлении паспорта ряда). Затем этот диапазон делится на 2^16 уровней (в том числе пара служебных - для пропусков и т.п.), и в базу заносится не само real-число, а номер ближайшего уровня. При распаковке из базы выполняется обратное преобразование, так что клиент всегда видит значение в физических единицах. Например, для хранения измерений атмосферного давления, которые изменяются от 900 до 1100 мбар, неравномерная сетка значений (более плотная вблизи нуля) заведомо хуже, чем равномерная, но покрывающая только диапазон 900-1100.
А спустя много лет почти такой же формат реализовала в своей системе фирма Zetlab.
Но, конечно, это не универсальный «minifloat», а узкоспециализированный, так как кроме массива данных надо где-то отдельно хранить еще и границы диапазона.
P.S. Что интересно, сейчас в наших базах геофизических рядов данных этот 16-битный формат - основной, так как лишь очень немногие системы измерений действительно дают такую точность, при которой 16-битная дискретизация уже недостаточна.
Вообще обычно это называется fixed point (формат с фиксированной точкой). Или вы что-то другое сделали?
обычно это называется fixed point (формат с фиксированной точкой). Или вы что-то другое сделали?
Да, это похоже на fixed point, но не совсем. Так как у нас диапазон строится не от нуля, а в произвольном месте шкалы. Например, сопротивление глубокого горизонта может меняться от 500 до 550 ом*м. Классический 2-байтовый fixed point, если я ничего не путаю, позволит сохранять такие значения с одним-двумя точными десятичными знаками: если полный диапазон -32768..+32767, то 510.12345 превратится в 510.1, ну или в 510.12 при наличии некоторых ухищрений. А в нашем случае соседние уровни будут идти с шагом 0.001: 510.123, 510.124 и т.д. Немного, но все-таки поточнее.
Мне видимо просто повезло, что когда я эту систему придумывал, то про fixed point не знал ничего. Хотя она в то время (1988год) уже эксплуатировалась вовсю...
Например, для хранения измерений атмосферного давления, которые изменяются от 900 до 1100 мбар, неравномерная сетка значений (более плотная вблизи нуля) заведомо хуже, чем равномерная, но покрывающая только диапазон 900-1100.
Ну нет. Ноль при измерении атмосферного давления принимаем за 1000 мбар, а отклонение упаковываем во float8 например, как-раз и знак пригодится. Тогда самая большая часть будет вблизи значений с максимальной точностью, а редкие вылеты за норму будут более грубо представлены. Как на картинке синусоиды в статье. Плюс масштабирующий коэффициент чтобы +- 100 мбар укладывались в диапазон float8.
Обычно как-то так Y= x0 + k*x
В каком-то случае этого будет недостаточно и потребуется масштабирование нелинейное, полиномом или таблично. Но это теоретически, вряд ли это в рамках инженерной задачи потребуется экономия на битах. Проще хранить избыточные данные, float64 и включить сжатие данных, хоть на уровне файловой системы.
где-то отдельно хранить еще и границы диапазона
Еще где-то хранится порог аварийного срабатывания например и желаемой значение для систем автоматического регулирования. Но это вроде совсем другое всё. Именно к структуре числа не относится, это интерпретация значения и уточнение контекста в конкретном применении данных.
Ну нет. Ноль при измерении атмосферного давления принимаем за 1000 мбар, а отклонение упаковываем во float8 например, как-раз и знак пригодится
Да, мысль интересная (а в идеальном сферическом мире так и вовсе должна быть за аксиому). Но у нас все проще и прозаичнее: на выходе датчика стоит 16-битный АЦП. Который дает 2^16 уровней. Вот они-то фактически и хранятся в БД.
А весь смысл в том, что клиент получает из базы обычные real-значения в физических единицах. Которые сразу можно в арифметику. Она тогда была строго 32-битная. Это же все на 8086 делалось, а 286 для нас революцией стал. Там надо было, чтоб просто и быстро. Какие уж там избыточные данные...
А сжатие данных - оно в любом варианте работает почти одинаково.
P.S. Но что касается современной эпохи, то идея с заменой 16-битной равномерной сетки на 8-битную неравномерную (real*8) - рабочая. Наверно и правда сделаем такой вариант хранения данных, как опцию. Технически при нашей архитектуре это вообще без проблем (правда, обратная совместимость нарушится). Так что спасибо за наводку ;-) Ради таких идей и нужны прогулки по комментариям ;-)
Но все же вряд ли такой формат будет широко востребован, так как у нас очень редко сигнал имеет фиксированный уровень, вблизи которого группируется основная масса значений, и "хвосты", где точность высокая не нужна. Большинство сигналов постоянно "гуляет" вверх-вниз, почти равномерно заполняя треть или даже половину диапазона. Например, у сопротивления основная компонента сигнала - это сезонный ход. А у синусоиды, как известно, функция распределения имеет два горба по краям и провал в середине. Ну и дрейфы, конечно, из-за которых Ф.Р. размазывается... А наклоны - так и просто дрейфуют постоянно туда-сюда. То есть, возле границ диапазона наша равномерная сетка и правда загущена (так как там всегда нужен какой -то запас, а значений немного), но вот понятие "центр" у нас очень-очень растянуто.
UPD. Черт возьми! Хотел за ценный совет
плюсануть карму
а оказалось, что она уже давно заплюсована...Может, это кто-нибудь из неравнодушных за меня сделает?
Может, там используется такая функция активации с длинными хвостами, что нужен большой диапазон чисел. Хотя, имхо проводить вычисления над 4-битным Float - это уже перебор, для 4 бит лучше таблица поиска типа NF4, но специально оптимизированная под данную нейросеть.
Точнее, две таблицы: для распаковки 4bit->8bit и для упаковки 8bit->4bit, а вычисления проводить в целом 8bit или 16bit формате.
Может, там используется такая функция активации с длинными хвостами, что нужен большой диапазон чисел.
В статье не хватает сравнения действительно с обычными целочисленными 4-битными числами. На сколько увеличится ошибка. Float все же не идеальный формат и дает более грубое представление значения по краям диапазона. Может разница будет в 10-20% всего.
Int-ы хороши для чего-то, измеряемого в штуках, а у нас нечто непрерывное, тяготеющее к диапазону [0(или-1)..1]. Есть такая вещь, как фиксированная точка, но это уже не так наглядно, а динамический диапазон много меньше. Кстати, где вы поставите точку? Либо вы её позицию стандартизируете - зафиксируете для всей индустрии, (еще хуже с диапазоном), либо проще превращается в боль с отслеживанием и согласованием её в контексте.
А на счет быстрее (производительнее?) - не так велик там выигрыш, даже для здоровых матричных молотилок. (А самые здоровые матричные молотилки еще и обучать должны, а это градиенты, а градиенты к динамическому диапазону чувствительны страшно.)
Я в своё время тоже недоумевал, почему про квантизацию на каждой конфе говорят, и так мало делают.
Ну мало делают это смотря где. Если embedded разработка и нужно что бы работало на какой-нибудь платке да еще и в реальном времени, то делают часто.
Опенсурсные энтузиасты LLM-ок тоже активно юзают и фактически развивают сейчас это направление. Ибо модели огромные и всем охота поиграться на домашних видеокартах, а не лезть в облака за A100 какой-нибудь. И тут весь цвет общества применяется. 16 бит для весов это уже стандарт, 8 бит и 4 бита легко. Плюс всякие GPTQ и AWQ методы.
Другое дело что это у энтузиастов и всяких ребят решивших срубить денег как хостинги для опенсусрных моделей. Применяют ли все это большие ребята типа OpenAI или Anthropic в продакшене, черт его знает.
Так эволюционно сложилось.
Переделка на целочисленные алгоритмы требует работы, и не гарантирует заметный выигрыш, а других перспективных направлений работы в ML хватает.
Но научные статьи на эту тему уже есть, вот например авторы предлагают не использовать полумеры типа квантизации, а именно целые числа - https://arxiv.org/abs/2207.08822
4 бита еще не самая большая наркомания в машинном обучении. Как вам 3 и даже 2 бита? Правда тут конечно уже не плавающая точка. И квантизация не везде проходит до 2 битов, но тем нем менее. Причем активно используется, когда дело касается опенсурсных LLM. Поддерживается библиотекой transformers.
16-, 8- и 4-битные форматы чисел с плавающей запятой