"Множество мелких" для передачи по сети сериализуется в JSON или Protobuf, и получается "один большой текст", который сжимается ZIP.
Я понял, что вас интересовало время кодирования/декодирования, я сказал, что на фоне времени передачи данных разница выглядит незначительно. Если вы быстрее кодируете, но получаете больше данных для передачи, то будет быстрее передавать 1 пакет в ZIP, чем 2 пакета в вашей кодировке без ZIP.
"Cо своими метаданными" означает, что у вас кроме самого текста передается какая-то структура. Но фоне которой экономия нескольких байт выглядит еще меньше. А еще есть заголовок TCP-пакета 20 байт. А если вы передаете по HTTP, то еще и заголовки HTTP. Поэтому просто передача в одном запросе 2 токенов вместо 1 даст большую экономию по размеру и времени обработки, чем специальная кодировка текста.
Для передачи одного токена по сети ваша кодировка может и является подходящим решением, но это недостаточная причина, чтобы использовать ее вместо UTF-8, как вы предлагаете в статье.
Я не говорил, что у редакторов могут возникнуть сложности со вставкой в середину. Я сказал, что "последний режим кодирования строки" для этого бесполезен. Также я сказал, что это займет больше процессорного времени по сравнению со вставкой в середину строки c UTF-8.
Зачем мне сжимать отдельно каждый токен в ZIP, если для всего текста он сжимает лучше? Что это должно доказать? Я говорю про стандартное сжатие, которое делают сервер и браузер при передаче данных.
Проверил с этим regexp и JSON по ссылке выше, выигрыш от ZIP по сравнению с просто JSON.stringify(tokens) начинается уже от 8 токенов. Как сюда встроить $mol_charset_ucf_encode для каждого токена и использовать результат для передачи по сети я не разобрался. Хотите проверить, приводите конкретный код тестирования, который вы себе представляете.
Только не забудьте ещё и время замерить.
Если вы будете передавать 33 килобайта в UCF без ZIP по сравнению с 10 килобайт в UTF8 с ZIP, то передача дополнительных сетевых пакетов займет значительно больше времени, чем вы сэкономите на отсутствии ZIP.
Охотно верю, что если вы передаете по сети по одному слову в запросе, то ваша кодировка будет меньше на несколько байт. Только обычно так никто не делает, и на масштабах длины одного слова это тем более незначительно.
Я не понимаю с чем конкретно вы спорите. Что это возможно сделать? Я не говорил, что это невозможно. Процитированный вами текст был про отсылку на "спеку" с фразой про последний режим кодирования строки, которая была использована как возражение на мое описание логики работы редактора при вставке. Я сказал, что это работать не будет, потому что нужен предыдущий режим в середине строки.
Если вашу кодировку нельзя использовать как есть для работы со строками, и их нужно конвертировать во что-то еще, значит она нужна только для передачи данных. А для этого лучше использовать ZIP.
Какую конкретно статистику? У вас есть на экране абзац текста с русскими и латинскими символами, вы ставите курсор в середину строки. Вам надо пройти по этому тексту обратно и найти код переключения страницы. Если ставите курсор в другое место, надо еще раз сделать то же самое. Последний код переключения в строке тут не нужен.
Ваш комментарий был в контексте прогноза в статье и прогноза в комментарии. Существующий ИИ не является релевантным этому контексту. Ваш комментарий выглядит примерно как если бы кто-то 200 лет назад сказал "Поезда могут ездить только по рельсам, значит конюхи переживут появление движущихся механизмов".
Общий интеллект, или же сильный, — способность выполнять любую задачу, которую может выполнить человек, по крайней мере на равном уровне — входит в число долгосрочных целей данной области.
Artificial general intelligence Artificial general intelligence (AGI) is a hypothetical type of artificial intelligence that would match or surpass human capabilities across virtually all cognitive tasks.
Weak artificial intelligence Weak artificial intelligence (weak AI) is artificial intelligence that implements a limited part of the mind, or, as narrow AI, artificial narrow intelligence (ANI), is focused on one narrow task.
но текущий ИИ
При чем тут текущий ИИ, если я отвечал на комментарий про "появление ИИ", а статья называется "Через 3 года"? LLM в общепринятой терминологии это слабый ИИ. Сильный ИИ, который может выполнять любую задачу аналогично человеку, еще не появился.
"Спекой" вы называете вот это коротенькое описание? Почитал, ответа на этот вопрос там нет. Есть одна строчка с фантазией на тему что можно попробовать. Которая не будет работать.
text = 'Тут есть строка 1ab и AB@>:0 1ab'
// UCF:
// \xA4 " C B \x95 5 A B L \x95 A B @ > : 0 \x95 \x81 \x9C a b \x20 \xA4 8 \x95 \x9C A B @ > : 0 \x20 1 a b
// Т у т _ е с т ь _ с т р о к а _ 1 a b _ и _ A B @ > : 0 _ 1 a b
str = 'строка 1ab'
// UCF:
// \xA4 A B @ > : 0 \x95 \x81 \x9C a b
// с т р о к а _ 1 a b
str = 'строка'
// UCF:
// \xA4 A B @ > : 0
// с т р о к а
str = '1ab'
// UCF:
// 1 a b
// 1 a b
Занятно, что у вас пробелы и цифры кодируются по-разному в зависимости от предыдущего текста. Так становится еще более непонятно.
Ну давайте, почитайте вашу спеку и напишите тут код функции поиска, которая будет выдавать только позицию 9 для первого случая, только 9 для второго случая, и 16 и 29 для третьего. Раз вам все понятно, это вам не составит труда.
Никто не будет двигать мегабайты туда-сюда Они работают не так, как вы наивно полагаете.
Я не говорил ни про какие движения мегабайтов туда-сюда. Читайте комментарий внимательно.
со вставкой текста Аналогично читаем спеку.
Там написано то же самое, что я написал в комментарии. И нет, "её последний режим кодирования" не будет работать, потому что в текстовом редакторе можно делать вставку в середину строки. Дальше подумайте, что вы будете делать с исходной "ненаивной" строкой и как будете использовать позицию курсора.
Их уже переписали на матчинг по кодовым точкам
И? От этого они магически будут не считать символами текста ваши переключатели страниц?
Текст и картинки имеют разную критичность. Стыдно этого не знать.
Стыдно подменять понятия. Критичность к разговору про размер данных не имеет никакого отношения. Вы заявили про компактность, но эффект в реальных приложениях незаметен. Не говоря уже о том, что обычный ZIP дает лучшую компактность.
Сильно усложнится поиск и редактирование строк. Допустим мы ищем в тексте строку с русскими и латинскими символами. Она начинается с байта переключения на страницу русских символов. А в тексте такой последовательности байтов нет, он в основном на русском, и код переключения на страницу русских символов находится в самом начале. Поэтому стандартные механизмы поиска не будут работать. Тут вообще не очень понятно, как сделать поиск.
Регулярные выражения тоже работать не будут. Я не уверен, что в таком подходе они вообще возможны, в любом месте текста может встретиться код переключения страницы, который не соответствует паттерну. В крайнем случае надо будет переписать все движки регулярных выражений.
В текстовом редакторе при изменении позиции курсора надо будет каждый раз проверять каждый байт текста от позиции курсора в обратном порядке и проверять где там предыдущий код переключения страницы, чтобы определить, добавлять его при вводе символа или нет. Аналогично со вставкой текста, потому что он начинается с кода переключения символа.
Вы сэкономили несколько байт на передаче текста один раз, которые на фоне размера картинок выглядят незначительно, зато увеличили время процессора для его обработки постоянно.
А одна вот эта картинка занимает 66617 байт. Даже по сравнению с ней разница загружаемых данных получается около 1 процента. А если все картинки посчитать, то еще меньше.
Я вам на это уже ответил. С какой целью вы повторяете одно и то же? Все три корня x^3 = 0 тождественно равны, но считается, что это 3 разных корня. Вот и у меня считается, что это разные корни.
"после кругосветки по экватору" у вас будет одна кругосветка по экватору. Иногда это имеет значение. Если эта "кругосветка" создает какую-нибудь электродвижущую силу.
Общий случай a^b, где a, b — комплексные числа, определяется через представление в показательной форме согласно определяющей формуле:
Если хотите, можете считать, что в рамках моей теории это тоже называется "корень уравнения", поэтому в рамках моей теории их бесконечно много. Разговор был про отсутствие самосогласованности моей теории, то есть про несогласованность ее положений, а не про ее соответствие другой теории. Вы примеров такой несогласованности не привели.
Я не вижу в ваших формулах ту неизвестную величину, которую нужно найти.
Это вообще-то значение x. Это выражения вида 2^3 = 8 при рассмотрении уравнения x^3 = 8.
Корня должно быть три.
(1/2 + i^9 *sqrt(3)/2) это тоже корень. Вы можете сколько угодно считать, что это не является решением, только при применении например в физике вращений может быть сколько угодно, и вам надо будет это учитывать.
"Множество мелких" для передачи по сети сериализуется в JSON или Protobuf, и получается "один большой текст", который сжимается ZIP.
Я понял, что вас интересовало время кодирования/декодирования, я сказал, что на фоне времени передачи данных разница выглядит незначительно. Если вы быстрее кодируете, но получаете больше данных для передачи, то будет быстрее передавать 1 пакет в ZIP, чем 2 пакета в вашей кодировке без ZIP.
"Cо своими метаданными" означает, что у вас кроме самого текста передается какая-то структура. Но фоне которой экономия нескольких байт выглядит еще меньше. А еще есть заголовок TCP-пакета 20 байт. А если вы передаете по HTTP, то еще и заголовки HTTP. Поэтому просто передача в одном запросе 2 токенов вместо 1 даст большую экономию по размеру и времени обработки, чем специальная кодировка текста.
Для передачи одного токена по сети ваша кодировка может и является подходящим решением, но это недостаточная причина, чтобы использовать ее вместо UTF-8, как вы предлагаете в статье.
Я не говорил, что у редакторов могут возникнуть сложности со вставкой в середину. Я сказал, что "последний режим кодирования строки" для этого бесполезен. Также я сказал, что это займет больше процессорного времени по сравнению со вставкой в середину строки c UTF-8.
Сколько минусов без аргументов. Видимо люди уверены, что LLM это и есть настоящий ИИ, и ничего лучше быть не может.
Зачем мне сжимать отдельно каждый токен в ZIP, если для всего текста он сжимает лучше? Что это должно доказать? Я говорю про стандартное сжатие, которое делают сервер и браузер при передаче данных.
Проверил с этим regexp и JSON по ссылке выше, выигрыш от ZIP по сравнению с просто
JSON.stringify(tokens)начинается уже от 8 токенов. Как сюда встроить$mol_charset_ucf_encodeдля каждого токена и использовать результат для передачи по сети я не разобрался. Хотите проверить, приводите конкретный код тестирования, который вы себе представляете.Если вы будете передавать 33 килобайта в UCF без ZIP по сравнению с 10 килобайт в UTF8 с ZIP, то передача дополнительных сетевых пакетов займет значительно больше времени, чем вы сэкономите на отсутствии ZIP.
Охотно верю, что если вы передаете по сети по одному слову в запросе, то ваша кодировка будет меньше на несколько байт. Только обычно так никто не делает, и на масштабах длины одного слова это тем более незначительно.
Я не понимаю с чем конкретно вы спорите. Что это возможно сделать? Я не говорил, что это невозможно. Процитированный вами текст был про отсылку на "спеку" с фразой про последний режим кодирования строки, которая была использована как возражение на мое описание логики работы редактора при вставке. Я сказал, что это работать не будет, потому что нужен предыдущий режим в середине строки.
Если вашу кодировку нельзя использовать как есть для работы со строками, и их нужно конвертировать во что-то еще, значит она нужна только для передачи данных. А для этого лучше использовать ZIP.
Какую конкретно статистику? У вас есть на экране абзац текста с русскими и латинскими символами, вы ставите курсор в середину строки. Вам надо пройти по этому тексту обратно и найти код переключения страницы. Если ставите курсор в другое место, надо еще раз сделать то же самое. Последний код переключения в строке тут не нужен.
Поверьте, вы и так об этом услышите.
Ваш комментарий был в контексте прогноза в статье и прогноза в комментарии. Существующий ИИ не является релевантным этому контексту. Ваш комментарий выглядит примерно как если бы кто-то 200 лет назад сказал "Поезда могут ездить только по рельсам, значит конюхи переживут появление движущихся механизмов".
Поэтому придумали разделение на сильный и слабый ИИ. LLM это слабый ИИ, а в прогнозах говорят про сильный.
Искусственный интеллект
Общий интеллект, или же сильный, — способность выполнять любую задачу, которую может выполнить человек, по крайней мере на равном уровне — входит в число долгосрочных целей данной области.
Artificial general intelligence
Artificial general intelligence (AGI) is a hypothetical type of artificial intelligence that would match or surpass human capabilities across virtually all cognitive tasks.
Weak artificial intelligence
Weak artificial intelligence (weak AI) is artificial intelligence that implements a limited part of the mind, or, as narrow AI, artificial narrow intelligence (ANI), is focused on one narrow task.
При чем тут текущий ИИ, если я отвечал на комментарий про "появление ИИ", а статья называется "Через 3 года"?
LLM в общепринятой терминологии это слабый ИИ. Сильный ИИ, который может выполнять любую задачу аналогично человеку, еще не появился.
"Спекой" вы называете вот это коротенькое описание?
Почитал, ответа на этот вопрос там нет. Есть одна строчка с фантазией на тему что можно попробовать. Которая не будет работать.
Занятно, что у вас пробелы и цифры кодируются по-разному в зависимости от предыдущего текста. Так становится еще более непонятно.
Ну давайте, почитайте вашу спеку и напишите тут код функции поиска, которая будет выдавать только позицию 9 для первого случая, только 9 для второго случая, и 16 и 29 для третьего. Раз вам все понятно, это вам не составит труда.
Я не говорил ни про какие движения мегабайтов туда-сюда. Читайте комментарий внимательно.
Там написано то же самое, что я написал в комментарии.
И нет, "её последний режим кодирования" не будет работать, потому что в текстовом редакторе можно делать вставку в середину строки. Дальше подумайте, что вы будете делать с исходной "ненаивной" строкой и как будете использовать позицию курсора.
И? От этого они магически будут не считать символами текста ваши переключатели страниц?
Стыдно подменять понятия. Критичность к разговору про размер данных не имеет никакого отношения. Вы заявили про компактность, но эффект в реальных приложениях незаметен. Не говоря уже о том, что обычный ZIP дает лучшую компактность.
Калькулятор не умеет выполнять все функции естественного интеллекта, а искусственный интеллект умеет. Потому он так и называется.
Люди, которые говорят о замене их на искусственный интеллект, знают определение термина "искусственный интеллект" и цель его изобретения.
Сильно усложнится поиск и редактирование строк. Допустим мы ищем в тексте строку с русскими и латинскими символами. Она начинается с байта переключения на страницу русских символов. А в тексте такой последовательности байтов нет, он в основном на русском, и код переключения на страницу русских символов находится в самом начале. Поэтому стандартные механизмы поиска не будут работать. Тут вообще не очень понятно, как сделать поиск.
Регулярные выражения тоже работать не будут. Я не уверен, что в таком подходе они вообще возможны, в любом месте текста может встретиться код переключения страницы, который не соответствует паттерну. В крайнем случае надо будет переписать все движки регулярных выражений.
В текстовом редакторе при изменении позиции курсора надо будет каждый раз проверять каждый байт текста от позиции курсора в обратном порядке и проверять где там предыдущий код переключения страницы, чтобы определить, добавлять его при вводе символа или нет. Аналогично со вставкой текста, потому что он начинается с кода переключения символа.
Вы сэкономили несколько байт на передаче текста один раз, которые на фоне размера картинок выглядят незначительно, зато увеличили время процессора для его обработки постоянно.
https://habr.com/kek/v2/articles/?period=daily&sort=date&fl=en%2Cru&hl=ru&page=1&perPage=10
Size 41 Кб
Transferred 10.70 Кб
Я взял этот текст, перевел в UCF и сжал ZIP.
Даже в вашей кодировке сжатие все равно дает значительное уменьшение размера. То есть свою цель вы не достигли.
На 3 уровне сжатия получилась разница 1149 байт, на 9 уровне 902 байта. Для сжатого размера разница 10 процентов.
https://habrastorage.org/r/w1560/getpro/habr/upload_files/db0/84f/9bd/db084f9bd52c89eb8163135cfb686fce.png
А одна вот эта картинка занимает 66617 байт. Даже по сравнению с ней разница загружаемых данных получается около 1 процента. А если все картинки посчитать, то еще меньше.
Да вы что) Вся наука построена вокруг этого вопроса.
Вы играете словами, в этом случае вопрос превращается "а почему вам в аксиоматике удобнее использовать минус". Я объяснил это уже много раз.
Вот дело как раз в том, что вы не можете объяснить, почему она в этом случае совпадает. А я могу.
Я вам на это уже ответил. С какой целью вы повторяете одно и то же?
Все три корня x^3 = 0 тождественно равны, но считается, что это 3 разных корня. Вот и у меня считается, что это разные корни.
"после кругосветки по экватору" у вас будет одна кругосветка по экватору. Иногда это имеет значение. Если эта "кругосветка" создает какую-нибудь электродвижущую силу.
Комплексная степень
Общий случай a^b, где a, b — комплексные числа, определяется через представление в показательной форме согласно определяющей формуле:
Если хотите, можете считать, что в рамках моей теории это тоже называется "корень уравнения", поэтому в рамках моей теории их бесконечно много. Разговор был про отсутствие самосогласованности моей теории, то есть про несогласованность ее положений, а не про ее соответствие другой теории. Вы примеров такой несогласованности не привели.
Это вообще-то значение x. Это выражения вида 2^3 = 8 при рассмотрении уравнения x^3 = 8.
(1/2 + i^9 *sqrt(3)/2) это тоже корень. Вы можете сколько угодно считать, что это не является решением, только при применении например в физике вращений может быть сколько угодно, и вам надо будет это учитывать.