ну, например, wraparound для целых чисел: если число долго умножать на 2, то оно öбнулится
или ещё фокусы типа 0.1 + 0.2 != 0.3
всё это из-за того, что компьютер почему-то считает в двоичной системе
C++, например. Был даже какой-то мелкий скандальчик, что какую-то фичу не приняли в стандарт, поскольку она принципиально была не совместима с троичными машинами.
не приняли в стандарт, поскольку она принципиально была не совместима с троичными машинами
это правильно, что пытаются поддерживать потенциальную совместимость с 3-чной логикой
потому что какими будут оптические процессоры - 2-чными или 3-чными - вроде бы пока не ясно
кстати, а как в троичной логике будут расширяться Сишные битовые операторы?
понятно, что OR - это максимум, AND - это минимум
а что с XOR?
что будет означать Сишное выражение a^b на процессоре с 3-чной логикой?
сумму по модулю 3?
тогда оно не будет совместимо с привычными понятиями битовых флагов, когда наXORивая дважды одно и то же, возвращаешься к исходному значению, а это неявно используется почти во всём коде, написанном ранее )))
например, линукс не будет работать правильно на троичном процессоре )))
миграция будет тяжкой…
есть такой «принцип наименьшего о*уевания»
слазь в википедию, если не слышал о таком: principle of least astonishment (POLA)
так вот, двоичная система, влезая в наши ЯП, нарушает его на каждом шагу )))
если посмотреть со стороны, то программисту двоичная система нафиг не нужна, программист «прогибается» под удобство процессора
это было разумно в эпоху компов с 4Кб ОЗУ, но сейчас смысла в этом нет
если с точки зрения человека «обычное число» - это десятичное без ограничений на длину, то компьютер должен именно с такими и работать, и никаких двоично-убогих числовых типов в ЯП быть не должно
если с точки зрения человека «обычное число» - это десятичное без ограничений на длину, то компьютер должен именно с такими и работать, и никаких двоично-убогих числовых типов в ЯП быть не должно
Есть такие библиотеки для языков. В некоторых языках даже в стандартной библиотеке.
Просто это медленнее чем процессорные типы. А так есть и «обычное целое» число и «обычное рациональное число» без ограничений точности…
это должно быть в ядре языка, а не в опциональной библиотеке!
мне нравится как сделано в БД оракл
там по умолчанию число - десятичное 38-цифренное (то есть, там 0.1 + 0.2 всегда = 0.3)
обычные флоаты там тоже есть, но нужно писать специальный литерал:
1 = десятичное 38-циферное число 1.0
1d = 8-байтный double = 1.0
1f = 4-байтный float = 1.0
это сделано как раз затем, чтобы не было о*уевания от текучих абстракций, т.к. БД ориентирована в первую очередь на банковские расчёты, деньги за эту БД клиенты платят немалые, и поэтому подошли к дизайну ответственно
конечно, эти числа медленнее, чем FPU-типы, потому что арифметика реализована через вызов сишной функции, а не через одну инструкцию процессора.
но вовсе не арифметика является местом затыка быстродействия в БД.
думаю, то же самое справедливо для большинства ЯП - арифметика занимает жалкие доли процента от процессорного времени, потреблённого работающей программой
конечно, арабские цифры изобретены хрен знает когда ))
а BCD - это просто способ записи числа 0..99 в байте
было ли «во всех майнфреймах IBM» равенство 0.1+0.2=0.3 ?
что-то я сомневаюсь
кстати, инструкции x86 по переводу числа 0..99 в BCD-байт и обратно - бесполезны на практике (функции перевода чисел из десятичных в двоичные и обратно, написанные без этих инструкций. будут и быстрее, и короче)
если посмотреть со стороны, то программисту двоичная система нафиг не нужна, программист «прогибается» под удобство процессора это было разумно в эпоху компов с 4Кб ОЗУ, но сейчас смысла в этом нет
Компы с тех пор принципиально не изменились и всё также на уровне электрических сигналов работают в двоичной системе
было ли «во всех майнфреймах IBM» равенство 0.1+0.2=0.3 ?
Да. BCD для них было нативным.
кстати, инструкции x86 по переводу числа 0..99 в BCD-байт и обратно - бесполезны на практике (функции перевода чисел из десятичных в двоичные и обратно, написанные без этих инструкций. будут и быстрее, и короче)
вижу, опыта в написании ассемблерного кода у тебя нет
ты перепутал порядок операндов (для интеловского асма нужно писать первым регистр-приёмник, а для АТ&T асма нужно использовать другой синтаксис для ячеек памяти и имён регистров)
ответ по существу: в мире, где нет других операций над числами кроме сложения, эти BCD инструкции будут полезны. ))
но если ты пишешь либу арифметики длинных целых чисел (напр, для использования в RSA), то хранение чисел в BCD-формате себя не оправдывает, т.к. сильно проигрываешь на скорости вычислений умножения (быстрее будет сначала перевести BCD в двоичную запись, выполнить умножение и перевести двоичный результат обратно в BCD)
вот если бы x86 поддерживал всю BCD-арифметику аппаратно, то возможно, был бы шанс (но я всё равно сомневаюсь, ведь работа в системе счисления 256 будет быстрее, чем в системе счисления 100 из-за чуть меньшей длины чисел)
не зря в 64-битном режиме процессора интел выкинул к чёртовой бабушке весь этот недо-BCD )))
будто аналогичные «фокусы» не возможны в троичной системе
конечно, возможны
я к тому, что не нужно привязываться ни к какой системе счисления, числа должны быть «с человеческим лицом» )))
общее правило: не нужно через интерфейс светить детали реализации
выпьем за инкапсуляцию!
Не будет никакой троичной логики никогда. Преимуществ ноль, а геморроя много.
как будто у тебя будет выбор: быть ей или не быть )))
троичную систему выбирают не из эстетических соображений
физики обнаружат явление, которое удобно для организации нетривиальной логики
инженеры на её базе сделают универсальный вычислитель
а программисту просто скажут: «пиши софт под вот эту хреновину», и куды деваться-то? )))
именно так было в 50-х годах прошлого века с «сетунью»:
физический процесс - намагничивание магнитных сердечников, намагниченность может быть «туда», «сюда» или «никуда».
инженеры создали память на троичных ферритодиодных ячейках.
адресное пространство у тёплого лампового процессора было 243 ячейки )))
в ближайшем будущем может выясниться, что в оптическом компе сигналы будут «поляризация такая», «поляризация ортогональная» и «свет выключен».
и история повторится.
и все будущие туториалы по программированию будут начинаться с описания 3-ичной системы счисления.
константы типа «3 в 9-ой степени» будут знать наизусть )))
не нужно привязываться ни к какой системе счисления
Так не бывает. Даже под «обычным человеческим видом чисел» всё равно большинством людей понимается конкретная привычная им десятичная система счисления.
А что получится при отвязке от систем счисления? Даже унарная система счисления - это тоже система счисления.
Физически никакой бинарности в электрических схемах нет, просто с инженерной точки зрения было проще диапазон напряжений разбить так, чтобы образовалось 2 уровня. Например, от 0 до 0.3 это 0, от 0.7 до 1 это 1, а всё что между это непонятно что. Точно также можно было в этот промежуток добавить и третье и четвертое значение, но почему-то делать не стали. И я более чем уверен, что это ««туда», «сюда» или «никуда»» на самом деле не настоящая троичность, а тоже плавает некая величина в известно диапазоне значений.