• Flipper Zero — прогресс за сентябрь
    0
    Не знаю, насколько реализуемо, но может быть подпружиненную металлическую пластину-защелку типа такой? В текстолите тогда достаточно будет отверстия под неё.

  • Ещё один велосипед: храним юникодные строки на 30-60% компактнее, чем UTF-8
    +1

    Абсолютно верно, и об этом сказано в самой статье.


    Если в вашей задаче важно, чтобы при повреждении строк сохранялась целостность последующего за ними текста — используйте UTF-8. Это ведь нормально — подбирать решение под задачу.


    В моей задаче (да и во многих других практических задачах), риск повреждений невысок, а если они возникли — то это уже ошибка в любом случае, независимо от того, сколько именно символов затронуто.

  • Ещё один велосипед: храним юникодные строки на 30-60% компактнее, чем UTF-8
    +1
    Значит, понимание того, что «гораздо проще» у нас с вами несколько разное.

    Для меня, повторюсь, вариант тащить полноценную либу, осваивать её апи, готовить для неё какие-то данные (в надежде, что они будут репрезентативными для любого будущего датасета), и потом потенциально страдать от недостаточной производительности — не ощущался проще, чем написать две функции на 100 строчек кода. И что самое важное, это точно не ощущалось интереснее :)

    В то же время я совершенно не спорю, что кому-то другому может показаться иначе (и это нормально). Хорошо же, что у нас всех есть свобода выбирать, какими решениями пользоваться, и какие велосипеды писать :)
  • Ещё один велосипед: храним юникодные строки на 30-60% компактнее, чем UTF-8
    +1
    Ошибся, семь: греческий (U+0370..U+03FF), армянский (коды U+0530..U+058F), иврит (U+0590..U+05FF), арабский (два блока, U+0600..U+06FF и U+0750..U+077F), сирийский (U+0700..U+074F), тана (мальдивский язык, U+0780..U+07BF) и н'ко, использующийся в языках манде в Западной Африке (U+07C0..U+07FF).
  • Ещё один велосипед: храним юникодные строки на 30-60% компактнее, чем UTF-8
    +1
    О, спасибо. Если вы не против, я бы добавил этот график в статью, чтобы было наглядно видно, на каких длинах строк мой подход предпочтительнее.
  • Ещё один велосипед: храним юникодные строки на 30-60% компактнее, чем UTF-8
    +1
    Для обработки (как в вашем случае)
    Не могу сказать, что в моём случае это так. Как раз-таки содержимое строк мне трогать не нужно (не требуются никакие изменения строк, поиск подстрок и тому подобное), они абсолютно статичны.

    Кажется, это всё-таки чистая задача хранения строк, но при условии их малой длины (что мешает использовать алгоритмы сжатия).
  • Ещё один велосипед: храним юникодные строки на 30-60% компактнее, чем UTF-8
    +1
    То нужно знать конкретный язык текста
    Да, неплохо бы это делать с учётом языка, не спорю (и никто не мешает дополнительно и эту информацию хранить и использовать при сортировке, как это делается в MySQL, к примеру).

    Но ещё я отмечу, что Юникод всё-таки определяет и некий базовый порядок сортировки символов (DUCET) и даже без уточнения под конкретный язык он даст более адекватную в большинстве случаев сортировку, нежели предлагаемую вами сортировку по кодовым точкам.

    Главный мой поинт остаётся в силе — если мы хотим естественный порядок, нам нужно декодировать строки (да, хорошо бы при этом знать язык).

    Если же в массиве строк есть и чешские, и польские, и немецкие, и шведские, (а то ещё и турецкие,) то «естественный порядок» не определён, и единственный порядок, имеющий смысл при сортировке такого массива — это порядок по codepoints, что UTF-8 и обеспечивает.
    Окей, я понял, что ваша цель не в естественном порядке. Но тогда я вообще не очень понимаю, что вы называете смыслом данного порядка, какая практическая задача этим решается?

    Вот цитата непосредственно из документа Unicode Collation Algorithm:
    The basic principle to remember is: The position of characters in the Unicode code charts does not specify their sort order.

    Так что мне кажется, сортировка по кодовым точкам не особо лучше любой другой детерменированной сортировки (как, например, по байтам в закодированном виде).
  • Ещё один велосипед: храним юникодные строки на 30-60% компактнее, чем UTF-8
    0
    Те варианты, что я видел, были заточены в первую очередь под английский язык (возможно, что-то упустил — смотрел довольно поверхностно). Впрочем, я даже о существовании SCSU не сразу узнал :)
  • Ещё один велосипед: храним юникодные строки на 30-60% компактнее, чем UTF-8
    +3

    Как минимум, Юникод хорош тем, что это один общий стандарт, который сейчас уже более-менее всё поддерживает. Если вам нужно обозначить какой-то символ — в юникоде точно найдётся его код.


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


    Ей-богу, риторика в духе «8 бит хватит всем» мне кажется очень странной.

  • Ещё один велосипед: храним юникодные строки на 30-60% компактнее, чем UTF-8
    +3

    Думается, если есть такие опасения, то задачу сохранения целостности на протоколы передачи данных и стоит возложить. В любом случае, мне сложно представить ситуацию, когда с покусанной таким образом строкой клиент сможет сделать что-то осмысленное — независимо от того, по границе символа её обкусали или нет.


    (Да и не для того это делалось же, чтобы эти строчки куда-то в сеть передавать)

  • Ещё один велосипед: храним юникодные строки на 30-60% компактнее, чем UTF-8
    +1
    Не соглашусь: поиск затруднён тем, что вхождение подстроки байт не гарантирует вхождение подстроки символов. Со сравнением строк это не связано.

    Когда вы отмечали третий недостаток, вы цитировали моё сообщение:
    И когда нужно что-то искать в массиве пожатых строк, это достаточно недорого делается вызовом функции декодирования для каждой.

    Наверное, я неточно сформулировал ту фразу, но речь там шла не про подстроки, а именно про бинпоиск нужной строки (что требует таких же сравнений, как при сортировке).

    Если так, тогда конкатенация строк требует перекодировки.
    Да, это так. Все мутирующие операции тут требуют декодирования.

    Строки в UTF-8 можно сортировать без декодирования, в этом и фишка.
    Скажем так, это спорный момент.

    Сортировать без декодирования так-то можно что угодно (и тем же бинпоиском искать потом). Сортировка прямо в UTF-8 гарантирует только то, что строки будут посортированы по порядковым кодам символов, а это неидеально: например, хорошо бы, чтобы сравнение шло без учёта регистра (чтобы буквы, отличающиеся только регистром, стояли рядом, а в Юникоде это почти никогда не так). Западноевропейские символы из Latin-1 Supplement и вовсе оторваны от родственных им аналогов без диакритики (как и русская «ё» от «е»). Так что если цель сортировать естественным образом, то декодировать нужно в любом случае, а потом применять Unicode collation algorithm.
  • Ещё один велосипед: храним юникодные строки на 30-60% компактнее, чем UTF-8
    +1
    Дополнил финальный раздел. Надеюсь, теперь точно недопониманий не возникнет :)
  • Ещё один велосипед: храним юникодные строки на 30-60% компактнее, чем UTF-8
    +2
    Есть вещи типа github.com/google/snappy
    For instance, compared to the fastest mode of zlib, Snappy is an order of magnitude faster for most inputs, but the resulting compressed files are anywhere from 20% to 100% bigger.
    Ну то есть тоже trade-off какой-то присутствует. Тоже было бы любопытно сравнить (я не утверждаю, что любое сжатие медленнее кодирования на нескольких ифах, но кажется, что второе заоптимизировать можно гораздо лучше, чем первое).

    Просто базируясь на вашем названнии (UTF-C), я преполагаю что вы хотели бы предложить это в качестве стандарта в каком-то виде.
    Ни в коем случае! Название это просто отсылка к UTF-8, на котором я построил свой подход (ну и мне показалась забавной созвучность USB-C, если честно :)

    Напротив: я написал код (и статью) так, чтобы его можно было не только импортировать в свой проект по надобности, а скопировать и поменять под свои нужды. Я об этом говорю в разделе «Возможные доработки»: я считаю, что когда речь идёт о внутренних частях своего проекта, то иногда полезно не только стремиться к стандартизации (помним картинку про competing standards от xkcd), но и к кастомизации под конкретную задачу.
  • Ещё один велосипед: храним юникодные строки на 30-60% компактнее, чем UTF-8
    +1
    Прочитать статью, обращая внимание на каждый упомянутый недостаток? По правде сказать, мне казалось, предостережений я в тексте оставил порядочно :)
  • Ещё один велосипед: храним юникодные строки на 30-60% компактнее, чем UTF-8
    +1
    Вне BMP всё-таки только очень редко используемые иероглифы. Я, например, наугад открыл несколько статей в китайской Википедии, и не нашёл в них ни одного символа с кодом больше 0xFFFF.

    Так же как, например, у кириллицы есть несколько дополнительных блоков кроме 0x0400 —0x04FF, но на практике мы с ними практически не сталкиваемся.
  • Ещё один велосипед: храним юникодные строки на 30-60% компактнее, чем UTF-8
    +1
    Зато в самом начале есть дисклеймер, где выделена ключевая мысль :)

    Дисклеймер. Сразу сделаю несколько важных оговорок: описанное решение не предлагается как универсальная замена UTF-8, оно подходит только в узком списке случаев (о них ниже)
  • Ещё один велосипед: храним юникодные строки на 30-60% компактнее, чем UTF-8
    +1
    Я с вашего демо взял пример, у вас там сравнение 674 байт против 379 байт в вашей кодировке
    Там всё-таки достаточно длинные примеры, просто для наглядности. На строках длиной менее ~100 символов gzip начинает давать текст даже длиннее, чем UTF-8 (и не забываем ещё про тот факт, что процесс сжатия всё-таки более затратный, чем кодирование — которое делается в один проход, с небольшим числом операций на каждый символ).

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

    ASCII transparency это основное преимущество, если его нету то пусть будет просто компрессия, она сможет на типичных данных в разы преимущество давать.
    Да, в каких-то областях применений это разумеется так. Но, например, когда речь про то, чтобы держать массив строк в памяти своего приложения ASCII transparency не требуется (хорошая компрессия требуется, но, повторюсь, надо смотреть на типичную длину строк).
  • Ещё один велосипед: храним юникодные строки на 30-60% компактнее, чем UTF-8
    0
    Извините, но кажется отмеченный вами четвёртый недостаток полностью совпадает с третьим :)

    Отмечу, что поскольку одна и та же строка кодируется одним и тем же способом, точное сравнение вполне допустимо делать побайтово, без декодирования. А для сравнения при сортировки сложность декодирования сравнима со сложностью декодирования UTF-8 (принципы у них одинаковые).

    Честно говоря, у меня складывается ощущение, что вы хотите просто сказать, что я сделал плохую и бесполезную (по вашему мнению) вещь. Для меня это несколько неприятно, но я готов принять и такое мнение.
  • Ещё один велосипед: храним юникодные строки на 30-60% компактнее, чем UTF-8
    +1
    Да, уложит, но Хаффман не может «из воздуха» получить информацию о том, какой символ кодировать коротким кодом, а какой — подлиннее. Либо мы на каждую строчку дополнительно держим частоты символов (т.е. добавляем оверхед), либо строим какой-то отдельный глобальный словарь (но если мы хотим чтобы любая строка всегда кодировалась одним и тем же образом, он должен быть заранее зафиксирован). Такой «зашитый» в алгоритм частотный словарь — да, тоже приемлемая альтернатива, но мне показалась излишне сложной (и не факт, что стоящей того на практике).
  • Ещё один велосипед: храним юникодные строки на 30-60% компактнее, чем UTF-8
    +1
    Но обмен Вы отдали даже шанс на понимание Вашей кодировки чем-то, что с ней не знакомо и работает только с привычными стандартами.

    Как я уже писал, речь про использование этой кодировки в своём коде. Всё взаимодействие с ней обёрнуто в функции Encode/Decode, которые на выходе/входе дают массив байт. Если нужно что-то с содержимым сделать — декодируем (обычно это нужно только в момент ввода или вывода), а если передать чему-то стороннему (или сбросить на диск, например) — передаём просто как байты.

    При этом если Вам надо держать в памяти миллион коротких строк по 10 символов — почему бы не заменить это на 10 тысяч строк по 1000 символов, по принципу зип архива — если уж на то пошло?
    Но «держать миллион строк по 10 символов» это же вводная, как её можно поменять на другую? :) Вот представьте, у нас смешанный словарь, содержащий слова разных языков мира. Или, например, список заголовков статей всех Википедий. Как вы их склеите так, чтобы иметь доступ за O(1) к каждому заголовку по его индексу?
  • Ещё один велосипед: храним юникодные строки на 30-60% компактнее, чем UTF-8
    0
    Я не совсем понимаю, какой вывод из этого нужно сделать.

    Обо всех этих недостатках я упомянул в теле статьи, о преимуществах тоже. Их существенность зависит от контекста: очевидно, что в одних классах задач встают одни требования, в других — другие. Поэтому в одном случае эффективнее одно решение, а в другом — другое.

    Отдельно замечу, что во многих ситуациях UTF-8 точно так же требует кодирования/декодирования, как и мой подход. Но в отличие от, например, алгоритмов сжатия (у которых тоже своя область применимости) тут довольно простая логика, это не так затратно.
  • Ещё один велосипед: храним юникодные строки на 30-60% компактнее, чем UTF-8
    +1
    Но ведь по сути это и будет тем, что описано в статье. Грубо говоря, первый байт определяет кодировку и дальше тратится по одному байту на символ. Исключения, соответственно, кодируются 2-3 байтами (вместо 7 байт на html entities).
  • Ещё один велосипед: храним юникодные строки на 30-60% компактнее, чем UTF-8
    +2
    Если их немного, то как вариант можно хранить пометку «исключение» с хранением исходного текста в дополнительной таблице, при этом в основной хранить приведенный текст.
    Мне кажется, мы с вами всё-таки немного про разные категории задач говорим. Вы больше про конкретный продукт, который кладёт тексты в какую-то базу, а я писал движок, который сам по себе «база данных» в некотором смысле, и у него нет знаний об используемом языке. И когда нужно что-то искать в массиве пожатых строк, это достаточно недорого делается вызовом функции декодирования для каждой.
  • Ещё один велосипед: храним юникодные строки на 30-60% компактнее, чем UTF-8
    +1
    Описанный вами подход выглядит очень похоже на описанный в статье, только вместо целого байта 0xFF в качестве маркера я трачу 1-3 бита. Да, чуть проще — чуть менее эффективно.

    Так что поздравляю вас с изобретением велосипеда )
    Спасибо, я старался!
  • Ещё один велосипед: храним юникодные строки на 30-60% компактнее, чем UTF-8
    0
    Ну тогда попробуйте провести сравнение ваших результатов с результатами полученными алгоритмами сжатия, для более-менее длинных текстов. Можно даже и для коротких, если мы предположим что у нас есть универсальные словари комперссии для специфичных языков.

    Но зачем? Основная область применения UTF-C — именно короткие тексты, когда алгоритмы сжатия не работают.
  • Ещё один велосипед: храним юникодные строки на 30-60% компактнее, чем UTF-8
    +12
    В моей статье есть целый раздел, озаглавленный словами «Зачем же выдумывать что-то новое?». Мне несколько обидно, что вы не уделили ему внимания.

    Смысл разработки в экономии места в случаях, когда алгоритмы сжатия общего назначения неэффективны. Например, если вам нужно держать миллион коротких (10-20 символов) строк в памяти. В таких случаях алгоритмы вроде deflate дадут больше оверхеда, чем пользы.
  • Ещё один велосипед: храним юникодные строки на 30-60% компактнее, чем UTF-8
    +3

    Видимо, под «обычным текстом» подразумевается текст преимущественно на каком-то одном языке, чтобы под него можно было выбрать удобную однобайтовую кодировку?)


    Мне вот хотелось уметь хорошо хранить строчки, язык которых заранее неизвестен.


    Кстати, Википедия говорит, что вот SQL Server 2008 R2 как раз SCSU внутри себя использует, чтобы компактно строчки хранить.

  • Ещё один велосипед: храним юникодные строки на 30-60% компактнее, чем UTF-8
    +2

    Да, это верно как для SCSU, так и для моей UTF-C.


    Но в моей задаче (и кажется, во многих практических задачах тоже) такая проблема не может возникнуть, так что у меня не стояло цели её решать. Цель была только в компактности.

  • Рендеринг каустики воды в реальном времени
    +6
    Занятно, в тексте дважды используется прилагательное «важный» в местах, где по смыслу явно должно быть «значительный»:

    обратите внимание, что эффект каустики менее важен на акуле
    (тут подошло бы и «менее выражен»)
    Такое ограничение приводит к неверным результатам каустики, если преломление оказывается слишком важным.

    Сначала подумал, что это ошибка переводчика, но оказалось, что в оригинале important в обоих случаях. Похоже, ошибся сам автор: кажется, он француз, а во французском слово important действительно имеет второе значение, significant.
  • Как мы внедрили скрытие аккаунтов в Telegram или #ДуровДобавьДвойноеДно
    +1

    Почему нет? Не знаю, как конкретно это API устроено, но не звучит как какая-то непосильная задача. Может ребята из Postuf снова заморочатся и пришлют пулл-реквест для андроид-версии тоже :)

  • Как мы внедрили скрытие аккаунтов в Telegram или #ДуровДобавьДвойноеДно
    +2

    Что мешает просто не использовать API андроида для хранения скрытых аккаунтов, чтобы они не отображались в системных настройках?

  • Мои размышления про экранную клавиатуру для Flipper Zero под экранчик 128х64 пикселя
    0

    Там корпус уже почти финализирован, посмотрите фото. Четыре кнопки-стрелки, одна по центру, и одна «назад».

  • Мои размышления про экранную клавиатуру для Flipper Zero под экранчик 128х64 пикселя
    +5

    Эксперименты с трёхмерными клавиатурами и дизерингом это, конечно, занятно, но всё-таки очень непрактично. Больше напоминает 3D-демки, нежели постоянно используемый способ ввода.


    Вот применение генетических алгоритмов для оптимизации расположения клавиш это уже интересно. Правда, я увидел упоминания файлов layouts.html и layouts-more.html, но не увидел ссылок :) Я бы предложил всё-таки разделить раскладки и оптимизировать их для каждого языка отдельно. Ну и прогонять стоит, конечно, не на паре рандомных статей из вики, а на частотных словарях.


    Но все равно кажется, что пользователю будет удобнее ориентироваться на привычной QWERTY, чем на какой-то новой (пусть и оптимальной) раскладке.


    А вообще я за предиктивный ввод + то, что выше предложили (с разбивкой на круговые секторы) или что-то наподобие ввода на старых кнопочных мобильники. Зачем оптимизировать расположение кнопок заранее, если можно их подбирать прямо по мере ввода? :)

  • Flipper Zero — как выйти на Кикстартер сидя на карантине на даче
    0

    Конечно, это ещё зависит и от разновидности штрихкода.


    Я тут глянул несколько карточек, которые были под рукой, и оказалось, что, например, Магнит и Икеа используют QR-коды версии 1 (21x21 пиксель), Лента и Helix — Code 128 (его ширина может быть разной, у Ленты оказался 12-значный номер, на который хватит 101 пикселя, у Helix — 16-значный, 123 пикселя). В общем, в большинстве случаев дисплейчика вполне должно хватать.

  • Flipper Zero — как выйти на Кикстартер сидя на карантине на даче
    0

    95 монохромных пикселей по идее должно хватать:


    A complete UPC-A is 95 modules wide: 84 modules for the digits (L and R sections) combined with 11 modules for the S (start), M (middle), and E (end) guard patterns.

    (Отсюда)

  • Платформу Free TON запустили без Павла Дурова
    0

    Ещё можно писать на диск только состояние (какой-то небольшой процент от трафика), а основную часть канала тратить на перекидывание сообщений между нодами.

  • Платформу Free TON запустили без Павла Дурова
    0

    В оригинальной документации Николая Дурова (это первоисточник, но продираться через него тяжелее) и в доках, которые уже TON Labs написали.

  • Забудьте про RGB и HEX
    +2

    Так разговор-то про разницу между RGB и HSL, а три числа есть и там, и там.

  • Дуров не имеет никакого отношения к TON
    +5
    Есть непоколебимая вера людей в то, что молчание — знак согласия. Мол, если Павел Дуров не отрицает новости про TON, то TON существует.

    Я не совсем понимаю, что дало поводы автору объявлять мою статью (ссылкой на которую является слово «вера») подтверждением какой-то там «непоколебимой веры».


    В вышеупомянутой статье с обзором тестового клиента (как и в предыдущих статьях на тему TON) — специально для зануд и конспирологов — присутствуют следующие оговорки:


    Тогда стал доступен объемный технический документ, который, предположительно, был написан Николаем Дуровым и описывал структуру будущей сети.

    ...


    Повторюсь, официальных подтверждений страницы и всех этих документов со стороны Телеграма не было, но объем этих материалов делает их достаточно правдоподобными.
  • Тестовый клиент TON (Telegram Open Network) и новый язык Fift для смарт-контрактов
    0

    Видимо, тестовую ноду выключили