64-рёхричная система счисления

Уважаемые коллеги! Работа над одним из проектов столкнула меня с оперированием большими числами. Стало понятно, что ни десятичная, ни шестнадцатеричная, ни, тем более двоичная системы счисления, как бы, не совсем удовлетворяют решению поставленной задачи.
Рассмотрев возможные способы упрощения работы над числами, пришел к выводу о целесообразности использования 64-рёхричной системы счисления (далее - 64СС).
Проблема возникла при определении возможных букв и символов для использования их в 64СС. Хотелось бы обсудить эту проблему с обществом.

Однозначно, что в 64СС будут задействованы остальные буквы английского алфавита. Обсуждению подлежит использование буквы «О». В добрые старые времена, чтобы отличить от неё «ноль», цифру «Ø» перечеркивали слешем. Но в мировом сообществе это не прижилось, и О от 0 отличают лишь по ширине овала, хотя это не всегда соблюдается. Полагаю, в случае добавления на клавиатуру новых кнопок программисты имеют право выдвинуть требование писать «ноль» перечеркнутым слешем или с жирной точкой внутри – «Θ».

Далее, идет проблема использования специальных символов. Многие из них задействованы в математике, физике, химии, биологии, медицине и т д. Но, тем не менее, это не должно помешать их применению в 64СС:

- специальные знаки: @, #, %, ⌘, &;

- знаки валюты
€ Евро
$ Доллар
¢ Цент
£ Фунт
¥ Йена и юань
₽ Рубль
¤ Общий знак валюты
*) знак флорина удален по причине его схожести с буквой f.

- отдельные буквы греческого и русского алфавитов:
• Σ, Ψ, Ω;
• Б, Ж, И, П, Ф, Ц, Ш, Э, Ю, Я;

Необходимость ее внедрения обсуждать не будем, так как она диктуется кругом решаемых задач. У математиков эта проблема существует давно – они ее преодолевают по-разному, но есть предчувствие, что скоро эта проблема будет стоять перед всеми.

Любителей троллинга и "юмористов-сатириков" прошу не волноваться и проходить мимо

0

Alexis333, ТС явно упоминал магнитные ленты и прочие цифровые носители)

0

Сообщение от Usaga Текст пишется символами. Но символы кодируются байтами

для кодирования символов обычного текста вполне достаточно 6 бит, так что нет

Добавлено через 58 секунд

Сообщение от Usaga ТС явно упоминал магнитные ленты и прочие цифровые носители

это чтобы никто не догадался

0

Любезный, вы невнимательно прочли мой вопрос. Там ни разу не упоминается ОЗУ/ПЗУ...
И желание иметь 64СС напрямую связано с 64 разрядным процессором и регистрами. Чтобы при операциях с большими числами снизить затраты процессорного времени, снизить требуемые объемы хранящихся на дисках файлов и, тем более, снизить количество обращений к диску ( чтение/запись ), т к известно, что это самые затратные временные операции, если, конечно не принимать во внимание архивацию/разархивацию, которые занимают бог знает сколько циклов/тактов или герц/мегагерц частоты. Я не сомневаюсь, что это все вы знаете лучше меня, но больше всего мне импонирует ваша проницательность. Я очень плохо написал мелкими буквами, как говорят, "нечитабельно" последнюю строку, поэтому повторю ее более крупными буквами: "Любителей троллинга и "юмористов-сатириков" прошу не волноваться и проходить мимо". Поэтому, ради Бога, не волнуйтесь... Ну и далее по тексту.

0

Сообщение от Alexis333 для кодирования символов обычного текста вполне достаточно 6 бит, так что нет

Но ТС планирует кодировать биты текстом.

Сообщение от SergeClause Чтобы при операциях с большими числами снизить затраты процессорного времени, снизить требуемые объемы хранящихся на дисках файлов и, тем более, снизить количество обращений к диску ( чтение/запись )

Ключевой момент тут в том, что вы собрались уменьшать объёмы данных за счёт увеличения объёма данных. Ещё раз подумайте, КАК вы собрались в памяти представлять данные в своей системе счисления.

Добавлено через 1 минуту

Сообщение от SergeClause Я очень плохо написал мелкими буквами, как говорят, "нечитабельно" последнюю строку, поэтому повторю ее более крупными буквами: "Любителей троллинга и "юмористов-сатириков" прошу не волноваться и проходить мимо". Поэтому, ради Бога, не волнуйтесь...

Началось) Если не можешь понять вопроса или нечего ответить, то обвини собеседника в троллинге? Я вполне конкретные и прямые вопросы задаю по вашей задумке. Не провоцирую. Я вижу, что вы слабо ориентируетесь в том, что хотите сделать. Вот и пытаюсь натолкнуть на верный путь.

2

"... Вопрос "уплотнения" данных решается вагоном и маленькой тележкой алгоритмов сжатия..." - сколько времени будет занимать уплотнение/распаковка данных? Вопрос интересный. Можно поэкспериментировать. Только нужно учитывать, что ( я сейчас точно сказать не могу) вот типа таких "больших" файлов может быть порядка тысячи штук, но, может, и сто тысяч... А маленьких файлов - может миллион... "Маленькие" группируются в файлы по многу-многу-многу штук.И они все будут, делить большие числа, получать и анализировать остатки от деления... Какая уж тут к черту архивация разархивация... Хотя, может, я и ошибаюсь. Нужно поэкспериментировать. Если не забуду, и не заблокируют, расскажу...Там еще одна проблема просматривается... Даже две... Если потом не всплывет еще что-нибудь. Вначале хотел вообще напрямую к памяти SSD обращаться. Не использовать файловую систему, а к секторам напрямую. Там же ничего не крутится, ни вертится. Сколько времени экономится при прямом обращении. Вот, представляете, спутник вокруг земли витает. Один оборот так и называют - "виток". Сколько с него телеметрии поступает. Вот, действительно, воз и маленькая тележка. А у нас информация идет в 16-ричном, ну, пусть, в 32-разрядном формате (хотя 32СС нет) - процессоры молотят вхолостую. Точнее, ресурсы полностью не загружаются. Разрядность системы счисления должна совпадать с разрядностью процессора. В противном случае начинается "подгонка" данных под процессор, а это либо недогрузка вычислительной мощности ( если разрядность меньше), либо разбивка на более мелкие фрагменты ( как это было в 8086), когда разрядность данных ( адресов ) была больше разрядности регистров.

Еще раз жму руку!
До завтра!

0

Сообщение от SergeClause А у нас информация идет в 16-ричном, ну, пусть, в 32-разрядном формате (хотя 32СС нет) - процессоры молотят вхолостую.

С какого перепугу?

0

Сообщение от SergeClause сколько времени будет занимать уплотнение/распаковка данных?

Не дольше, чем ваш подход, который более избыточен даже)

Вы предлагаете кодировать числа текстом, который кодируется теми же самими байтами, которые вас не устраивают. Вы в этом не видите противоречий?

1

Не кодируются. Отображаются. Мы не имеем права менять телеметрию. Наши самолеты и космические корабли и так слишком часто падают. Речь идет о текстовых файлах, в которых хранятся числа. В одном из своих сообщений я пристыковал два файла. Скачайте, посмотрите. В них числа хранятся в 10СС. Конвертируйте в 16СС, и посмотрим, как изменится их объем.
Можете подождать, когда я "добью" 64СС, посмотрим, что получится. Надеюсь, к концу недели сделаю, если меня опять в словоболизм не втянут.

Вообще изначально я хотел посоветоваться, какие недостающие символы использовать для создания 64СС.
Британцы/американцы увидят русские буквы - закричат путин нихт шиссен... Украинцы увидят русскую Э, закричат - а мы свою "Є" хотим. Еще вот такая буква есть "Ǝ", только она не понятно чья, да и похожа на нашу Э.

А что касается необходимости этой системы, то опять же - в первом сообщении было предупреждение
"Необходимость ее внедрения обсуждать не будем, так как она диктуется кругом решаемых задач."
Файлик специально тебе посылаю, прочти. Да и вообще, кто хочет, пусть прочтёт.

Вложения

СортировкаДНК.doc (101.0 Кб, 5 просмотров)

0

Сообщение от Usaga ТС явно упоминал магнитные ленты и прочие цифровые носители)

Крайний раз НМЛ (накопитель на магнитной ленте) я видел в Москве в 2003-2007 годах, в каком, точно не помню. Конечно он отличался от тех, которые любили показывать по ТВ в конце прошлого века. Те были монстры, пальчик сунешь - оторвёт. А этот был миниатюрный и писал на кассеты от видеомагнитофона. 300 или 500 мб - точно не помню. Но все равно - неудобно и дорого. Кассеты с лентами требовали особых условий хранения. Еще SSD упомянул - надысь получил из Китая, китайцы 16 ТБ обещают ёмкость. Еще не проверял. Надеюсь, для 13 ТБ, которые упоминаются в статье, которую я вам выслал, хватит.
А какие я еще упоминал? Хотя могу рассказать о перфолентах и перфокартах. Перфокарты - хорошая штука, из них получались классные пепельницы. Бычком можно было прожечь только специально. Потом всё это ушло...

0

Сообщение от SergeClause Не кодируются. Отображаются.

А отображение на размер данных как влияет?)

0

Размер данных влияет на отображение.
Представьте это число в двоичном виде: 2^{2 431 955 721 959 582 657}
И вы поймете
В прилагающемся файле - таблица систем счисления. Задача - найти подходящие симболы и заполнить пустые ячейки.

Вложения

ТаблицаСистемСчисления.doc (115.5 Кб, 2 просмотров)

0

Как отображение влияет на размер данных? Оно может быть удобным и предоставлять человеку правильное понятие о том, с чем он имеет дело, но может быть и неудобным - человек просто не сможет его прочесть и понять.

0

SergeClause,

Мне как-то неудобно спрашивать - а чем вам Base64 не угодила? см. https://en.wikipedia.org/wiki/Base64

0

sqltd1, казалось бы, каким боком сюда base64

0

Сообщение от Алексей1153 казалось бы, каким боком сюда base64

собственно - это 64-ричная система счисления с "цифрами" ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmn opqrstuvwxyz0123456789+/

напомню на всякий случай -

у 16-ричной системы счисления (base16, она же - hex) "цифры" - 0123456789ABCDEF

а у 10-ричной системы счисления цифры - 0123456789

0

sqltd1, base64 - это способ представления последовательности произвольных 8-битовых байтов в виде байтов с двумя обнулёнными старшими битами.
Объём данных становится избыточным (увеличивается на 33% )
Но при этом результат можно использовать в текстовых протоколах и форматах - вот это и есть предназначение base64

то есть, к сабжу отношение никакое

0

Алексей1153,
я заменил в вашем тексте base64 на 16-ричную систему счисления.

Сообщение от Алексей1153 base64 16-ричная система счисления - это способ представления последовательности произвольных 8-битовых байтов в виде байтов с двумя четырьмя обнулёнными старшими битами. Объём данных становится избыточным (увеличивается на 25% 100% ) Но при этом результат можно использовать в текстовых протоколах и форматах - вот это и есть предназначение base64 16-ричной системы счисления

Вы согласны с этой фразой?

0

sqltd1, нет, не согласен. Вот, что такое 16-ричная система счисления

Добавлено через 29 секунд
от смены системы счисления объём данных не меняется

0

Сообщение от sqltd1 Мне как-то неудобно спрашивать - а чем вам Base64 не угодила? см. https://en.wikipedia.org/wiki/Base64

Если я не ошибаюсь, в ней заглавные и маленькие буквы воспринимаются как разные, но вообще интересно. Я ни разу с ней не сталкивался, нужно присмотреться.

0

Сообщение от SergeClause Размер данных влияет на отображение.

Но отображение на размер данных не влияет.

0