Обдумываю концепцию новой кодировки

С другой стороны выровенные символы проще simd сканировать

Если только какое-то широкое сравнение делать, а что ты ещё на SIMD сделаешь со строками?

Или допустим на не проиндексированных текстовых данных делать бинарный поиск в многопотоке. Разбить по середине и т.д. и на потоки раскидывать куски.

С одной стороны это и в UTF-8 не проблема: разбиваешь побайтно, затем проверяешь свою середину. Если старшие биты 10xx xxxx, то это байт дополнения и нужно сместиться или влево, или вправо.

Но какой смысл искать только один codepoint? Чаще всего люди ищут многосимвольные (несколько codepoint) последовательности. Тем более, в Unicode одна графема может содержать до 7 codepoint.

Проектирую тут ЯП

а есть ли смысл если ИИ будет писать на чем угодно лучше и быстрее ?

Кстати, на неанглийский алфавит тратится больше токенов. Так что оптимизация под кириллицу вполне может иметь денежный выхлоп. Может прилететь оптимизация, откуда не ждали.

Не будет ИИ писать лучше и быстрее. А если будет мы в другом мире будем жить. Я тогда буду проектировать космический корабль, чтобы бороздить просторы вселенной, а не вот это вот всё.

Я здесь на порядок больше информации сейчас почерпнул к размышлению, чем от самого распальцованного ИИ за вчерашний вечер. Всё что он делал это лил из пустого в порожнее и по кругу. Может когда проиндексирует эту тему начнёт что-то полезное отвечать.

В любой из кодировок UNICODE нет возможности произвольного доступа к N-ному символу без сканирования с начала строки. Даже UTF-32, где code unit равен code point, для представления графемы (символа) может потребоваться несколько code point’ов.

нравицца не нравицца - спи, моя красавица

ничего кроме utf8 в мире нет.

Наполовину не нравится отсутствие перехода за O(1) по произвольному индексу.

А какой половиной тогда нравится?

Ну, это не фатальный недостаток. Выше даже не нашлось аргументов, а нафига козе баян. ИИ тоже ничего конкретного не придумал про произвольный доступ.

Так в этом случае тем более встаёт вопрос, а почему другие должны свои алфавиты в два байта пихать. Не дело это. Нужна новая кодировка.

Ты в курсе, что utf8 это не единственный формат utf?

Что значит «перемещаться по индексу»? Искать графемы? Код пойнты? А зачем? Рендереры юникода сейчас уже написаны - в частности, в браузерах и в графических тулкитах.

Я сам редактор делаю именно потому что в разработке асиков полна я жопа с инструментами. И код выложу. Но я тебе заранее говорю что кодировка это такая мелочь…

Undo-redo, свертывание кода, асинхронная работа парсера, подсказки - вот там задница. Ты походу не представляешь масштаба работ раз думаешь что кодировка что-то значит

Ненада

Надо Федя, надо…

…ровно это более 15 лет как реализовано в питоне

https://peps.python.org/pep-0393/

https://myshell.co.uk/blog/python-string-object-representation/

Мне вот интересно, а для чего понадобилось перемещаться по индексу за O(1)? И это индекс чего: unicode code point, glyph, grapheme? Графемы могут быть довольно длинные и составные даже в самом жирном варианте utf-32. Ну то есть как ни пляши, никакого O(1) и одновременно полноценного юникода не получится. И почему нельзя перемещаться по байтовому смещению за O(1)? Даже если не попали в начало кодепойнта, легко докрутить до следующего/предыдущего.

А что душевнобольные? Душевнобольной в одну харю взял, да TempleOS написал. А что сделали вы как душевноздоровый?

Существует ещё 7. Так ведь? Ведь так?..

А смысл бегать по кодпоинтам? Мы же со стройкой работаем, а не с байтами. Поэтому нужны именно границы глифов на экране пользователя, а не абстрактные байты. А я как понял в UTF-8 границы глифа не определены, поэтому нужно подключать стороннюю либу, чтобы находить их границы.

«деда, пей таблетки, а то получиш по жопе» (или как-то так) 🤭

Проектирую тут ЯП и дошло дело до UTF-8 и вот он мне, ну, совсем не нравится.

может копать глубже ? например концепция байта кажется весьма устаревшей. 8 бит в которые пытаются впихнуть всё а ещё и по разному переставлять. Битовое поле произвольной длины как-то лучше. Далее адресация random-access тоже похожа на костыль. Отчего память сразу не ассоциативная - так и O(1) можно обрящить ;-)

в свете моды LLM - так сразу и кодировать токенами ;-) зачем какие-то старинные коде-пойнты

Ну и, зачем нам бегать произвольно по индексам глифов? Какой алгоритм мы оптимизируем? Рендер текста по большому счёту потоковый, кое-где бэктрекинг для переносов строк.

Изредка бывает нужно обрезать кусок текста до некоторой длины, для всяких превью, но это можно сделать приближением, тычком в байтовое смещение, либо уже за O(n), вот единственное место где это хоть что-нибудь оптимизирует, но это так редко где нужно, тем более с точным количеством глифов оно никогда и не нужно, всё равно у пользователя шрифт будет с некоторым допуском.

Ни одна из задач работы со строками не предусматривает доступ к произвольным символам строки, поэтому равная длина закодированных элементов не имеет практической ценности.

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

Как минимум этого требует рендер. Потому что текст надо еще и красить.

А что сделали вы как душевноздоровый?

Меня пока не приследуют светящиеся ниггеры из ЦРУ. Рано ещё для ОС.

Undo-redo

Это вроде как решенная задача. Аж паттерн.

свертывание кода, асинхронная работа парсера, подсказки - вот там задница

Ну, возможно. Не надо просто редактор сразу под все языки делать.

Это вроде как решенная задача. Аж паттерн.

ахахахаха.

ну попробуй, человечек.

C и J из CJK уже хлебнули проблем с Юникодом, который некогда разошедшиеся иероглифы из разных языков свёл в одну точку. Теперь есть сложности с представлением текста. Чтобы нормально его отрендерить, нужно выбирать шрифт в соответствии языку.

Ты теперь хочешь аналогичных проблем навалить в другие языки? «α» и «а» станут одной точкой? И «Н» с «N» тоже станут одной точкой? У «Н» горизонтальная чёрточка относительно недавно только стала горизонтальной, раньше была по аналогии с «N». Что с написанием строчных? У «M» и «М» заглавные буквы ещё похожи, но их строчные варианты отличаются: «m» против «м».

Душевнобольной в одну харю взял, да TempleOS написал. А что сделали вы как душевноздоровый?

Бывают случаи, когда не сделать чего-то стоит считать большим благом и, соответственно, большим достижением, чем сделать. Не то чтобы это было прям так уж истинно для TempleOS — вряд ли мир без неё был бы ощутимо лучше, в данном случае скорее почти без разницы. Но тем не менее.

Что у тебя за комбайн, где Undo-Redo требует сверхчеловеческих усилий?

На все эти вопросы ещё предстоит ответить, я на столько не прорабатывал эту идею.

Не будет ИИ писать лучше и быстрее.

уже пишет

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

Ужасное решение, сделанное от не очень понятной жадности

смотрим на однобайтовую, видим в начале таблицы кучу кодов для управления сука мехтерминалом, чешим репу, а не взять ли один и не выделить его на операцию переключения кодировки, наступил на такой, значит следующие 2 байта номер кодировки в которой дальше идет текст, сука сказка для тех кто пишет и читает многоязыковые тексты

Если так, где уволенные из гугла разрабы?

пока сидят и молчат, выдавая код ИИ за свой )

Добавил конкретики https://chatgpt.com/share/6a97d97d-3fac-83ed-af50-6022e8f635e2 Для Ъ

Новый формат кодировки

Первый байт управляющий:

0-3 биты указывают на Windows-CP125x кодировку (9 вариантов)
4-6 биты указывают на алгоритм разбора строки:

000 - каждый char кодируется одним байтом 
      если у char первый бит 0, то его остальные 7 бит кодировать как ascii
      если у char первый бит 1, то его кодировать как Windows-CP125x в зависимости от выбора первого управляющего байта

001 - каждый char занимает ровно 2 байта
010 - каждый char занимает ровно 4 байта
011 - смешанный размер char
              если первый бит char 0, то это char размером в 1 байт и кодировать его как ascii
               если первый бит char 1, то это char размером в 2 байта (или больше) кодировать по дополнительным правилам
100 - смешанный размер char, но если первый бит 0, то этот char занимает 1 байт и кодировать его как cp-125x указанный в управляющем первом байте строки

8-ой бит установлен всегда в 1, если же он 0, то читаем строку как ascii последовательность начиная с первого байта

Suvic - a hybrid SBCS/Unicode variable-length character encoding

Заец, скажи мне а почему ты думаешь что отмена-возврат это легкая прогулка?

Мне просто кажется что ты дурень. Я под отмену-возврат подводил теорию некоторую, т.к. надо было еще и блоксхемы редактировать. Даже что-то сам себе доказывл , теоремы всякие. Корректная отмена не жрущая память это люто нетривиальная задача.

не жрущая память это люто нетривиальная задача

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

А как будешь китайский, японский, тайский, деванагари передавать? А если разные кодировки понадобятся в одной строке?

Режим 011 или 100 фактически utf8 Обдумываю концепцию новой кодировки (комментарий)

ucs4 и никаких проблем, память копейки стоит :)