Comments 27
Честно говоря, лично мне непонятно, почему не было сразу использовано столь замечательное представление. Единственное возможное объяснение – на первых машинах, где результаты вычислений выводились на индикаторы (ламповые, между прочим)
а во времена оные с ламповыми индикаторами вообще частенько применялся серый код вместо простого двоичного, потому что сбалансирован по потребляемой электрической мощности для inc/dec счетчиков
Надо только помнить, что не на всех языках можно программировать это "в лоб". Например, стандарт Си "умничает", и для корректной работы с дополнительным кодом на всех компиляторах надо писать unsigned и работать со знаковыми числами как с беззнаковыми. Потому что для int стандарт такие вещи, как переполнение, определяет не так, как это должно быть по битам, а как "undefined". Если язык не ассемблер, то надо быть очень внимательным при написании кода.
Если уж изобретать, то изобретать такую СС для компов, которая смогла бы точно воспроизводить все хотя бы рациональные числа. А то вечно проблемы с округлением. То 1/3 в детятичной точно не записывается, то 0,3 в двоичной...
Есть и такие типы данных. Грубо говоря это структура из пары чисел числитель и знаменатель. Ещё если сделать их BigInt - неограниченными целыми, то точность будет ограничиваться памятью компьютера. Правда иррациональные они все равно приближают так себе...
Кстати, кто мне может объяснить, зачем для ранних IBM были специальные блоки для двоично-десятичной арифметики?
Деньги, это понятно. Но целое число долларов или центов прекрасно хранится как длинное целое число в бинарном виде.
смотрите, там ноги растут оттуда же что и серый код, что я писал выше: для первых электронных эвм, если ставился хоть какой-то фокус на бухучёт и коммерческие расчеты, то и заказчик, и разработчики железа, и поневоле разработчики софта, все они попадали в контекст привычных в то время механических вычислительных машин и арифмометров. А механические машины использовали только счётчики и работали только в десятичной системе, потому что зачем им еще что-то. Поэтому, видимо, эволюция шла двумя путями - машины для ученных и всяких там умников могли использовать нормальный компактный двоичный код и сумматоры, а для "серьёзных" людей в банках и страховках требовалось что-то посолиднее, "с понятными циферками". Язык Cobol опятьжеж, там это всё с BCD закрепилось.
Рано или поздно значение надо вывести в удобном для человека виде. Конкретно с помощью десятичных цифр. Алгоритм перевода с двоично-десятичного гораздо короче
Есть ещё момент, что деньги нужно не только хранить и складывать, но и иногда делить. А вот тут вылезают проблемы, что не каждая конечная десятичная дробь является конечной дробью в двоичной системе счисления. А у бухгалтерии может быть неприятное свойство, что нужно точно до копейки/цента, с правильным округлением, а не примерно.
это всё так, и удобство вывода конечно тоже, но чисто технически уже с шестидесятых годов это всё было не актуально, нормальные двоичные числа с фиксированной запятой давали ту же самую точность. Всётаки наверное более сильным фактором было legacy в мозгах заказчиков чем техническая необходимость. Тем более что очень скоро уже все машины были вынуждены поддерживать оба формата, экономией ресурсов там не пахнет.
Вот кстати, у автора там фотография пульта машины "Наири" - как раз начало шестидисятых, но уже умеет работать с числами и с фиксированной запятой, и с плавающей.
Да, именно она, конкретно "Наири-К", мне довелось на ней работать с 1984 по 1989 годы.
И у нее была еще одна замечательная фича - возможность в микрокоде создавать свои команды, которая и использовалась в системе.
В десятичной системе деление на 3 или 7 очень неприятно. Так что ...
Это решается тем, что любую сумму можно хранить в копейках/центах - минимальной денежной единице. Что и реализуется в стандарте SQL типом money.
А вот с округлением, все намного хуже, так как исходные данные и промежуточные результаты даже в бухгалтерии могут иметь дробные доли копеек. Например, курсы валют или цена. Отсюда, на практике, money типом почти никогда не пользуются, в пользу более гибкого decimal/numeric, в которых округлением можно управлять вручную, в зависимости от того, что промежуточный результат, а что сумма проводки.
Причина в том, что преобразование из десятичной системы исчисления в двоичную (или обратно) за один такт не сделаешь, поэтому, если числа вводятся и отображаются в десятичной системе исчисления, а арифметических операций с ними немного, то выгодней и хранить их в десятичной системе, и выполнять операции с ними тоже в десятичной системе.
Иногда идут на компромисс. Например, PostgreSQL хранит данные типа numeric/decimal в "почти" десятичном виде. Точнее в 10000-ной системе исчисления (четыре десятичные цифры в двоичном представлении в двух байтах). Результат произведения таких "цифр" всегда помещается в 32-х битовое целое, что весьма удобно. Можно оперировать с числами длиной в сотню тысяч десятичных цифр, без усложнения алгоритмов преобразования из десятичного представления во внутреннее и обратно.
Кстати, кто мне может объяснить, зачем для ранних IBM были специальные блоки для двоично-десятичной арифметики?
Для удобства вывода чисел на печать.
> все числа которой от 0 до 5 вполне себе представляются пальцами на одной руке и ничего лишнего нет.
В 12-ричной системе все числа представляются на одной руке: это 3 фаланги у 4 пальцев и большой палец как указатель. Соответственно, двумя руками легко досчитать до 144 (если вторая рука считает до 12) или 60 (если на второй руке загибать 5 пальцев).
Статья большая, очень много ненужных отвлечений.
Структурирована так себе, выделений важного мало.
Цель статьи в начале необозначена.
Тема очень интересная. Придётся прибегнуть к обработке статьи текстовым нейроботом, чтобы выделил основные моменты, а отвлечения убрал.
Добрый день. Статью пока не осилила, хотя тема мне интересна. Пока не забыла, хочется сделать одно небольшое уточнение и одно пожелание. Унарная (именно так она называется) СС широко применяется для записи чисел на ленте детерминированной машины Тьюринга с последовательным доступом, см. Кузнецов, Адельсон-Вельский "Дискретная математика для инженера".
Теперь по существу дела. Статью (имхо) можно было сделать намного интереснее, если бы статья начиналась с обзора систем счисления различных т.н. "примитивных народов". Например, у народа пираха вообще не сформировалось то ли понятие числа, то ли языковые обозначения для чисел. Во всяком случае, слова для обозначения единицы у них нет.
Позволю не согласится, в машине Тьюринга ячейка может иметь 2 состояния - помеченное и не помеченное, так что это все-таки по сути двоичная система, просто вместо нуля на ленте пустая позиция.
А вот это интересно, как вообще можно считать без единицы, надо будет посмотреть, спасибо за наводку.
Это в машине Поста два состояния. А в машине Тьюринга ячейка может содержать любой символ заданного при описании машины алфавита ленты.
как вообще можно считать без единицы
А пираха, до появления в их краях школ, никогда ничего не считали. У них просто потребности не было.
Почитайте "Не спи, кругом змеи". Но это было давно. Как только у пираха открыли школу - они считать научились.
К вопросу о числах