Здравствуйте, rg45, Вы писали:
R>Ты снова ничего не понял. Ничего мы тебе доказать не пытаемся. Просто наше мнение таково, что такую возможность исключать нельзя до тех пор, пока не доказано обратное. А обратное не доказано. А наше мнение таково. Дошло, нет?
С такими выводами вам надо в духовную семинарию, а инженеры обычно оперируют логикой. Поэтому — см выше про бремя доказательства.
Ад пуст, все бесы здесь.
Re[34]: [performance] чего-то я не понимаю в этой жизни
Здравствуйте, rg45, Вы писали:
R>Вот! Вот это доказательство, и я понимаю! Больше огня, больше! Долей скипидара в анус-полыханус. А я пойду посплю. Утомил ты меня своей упоротостью.
Начал ты неплохо, и до чего докатился. Стыдно должно быть.
Ад пуст, все бесы здесь.
Re[39]: [performance] чего-то я не понимаю в этой жизни
Здравствуйте, Codealot, Вы писали:
C>С такими выводами вам надо в духовную семинарию, а инженеры обычно оперируют логикой. Поэтому — см выше про бремя доказательства.
У меня нет цели тебе что-либо доказывать. Соответствено, бремени тоже. Я уважаю твое право на свободное вероисповедание. Ты, конечно, можешь попробовать переубедить меня, если хочешь, но в этом случае придется тебе поработать над аргументацией.
--
Не можешь достичь желаемого — пожелай достигнутого.
Здравствуйте, rg45, Вы писали:
r> R>Я ничего не требую, просто удивляюсь, что ты сравниваешь разные вещи и по результатам такого сравнения делаешь какие-то выводы.
r> Ну это грубые оценки, я ж этого и не скрывал. Лично для меня очевидно, что сделать плюсовую реализацию более быстрой, чем сишарпную реально.
Я в этом даже не сомневаюсь. Интересно другое: а если и на шарпе использовать ParseInt?
Здравствуйте, rg45, Вы писали:
r> R>Я ничего не требую, просто удивляюсь, что ты сравниваешь разные вещи и по результатам такого сравнения делаешь какие-то выводы.
r> А вот это
Здравствуйте, Videoman, Вы писали:
V> R>Итеририровать кодпоинты. В utf-8 четыре проверки, в utf-16 — одна. Вопрос нормализации выносим за скобки т.к. он существует вне зависимости от кодировки.
V> R>Я вроде согласился, что как кодировка для сериализации utf-8 удобна, но мы говорим о хранении и обработке строк. При хранении той же кириллицы от utf-8 профита никакого, при хранении китайских иероглифов utf-8 еще и более требовательна к памяти. Единственный выигрыш это латиница.
V> Вот две одинаковые буквы 'Ё', только одна занимает один кодпоинт, а другая два, какие иероглифы??? Вторая Ё занимает и в UTF-8, и в UTF-16 по 4-ре байта. Символ — не равно кодпоинт.
V> Ё — 0х0401 V> Ё — 0х0415 0х0308
Я для кого только что написал о нормализации?
V> Короче моё утверждение: Невозможно ни в какой кодировке работать с Юникод оперируя индексами кодпоинтов как символами. Уже даже в рамках европейских языков существую комбинируемые диакритические знак, префиксы, индексы, зачеркивание и т.д. Так зачем плодить кодировки, если UTF-8 на практике компактнее, да еще и удобнее для передачи и хранения ?!
В utf-16 вполне. После нормализации (еще раз). Не нужно несколько проверок на длину последовательности, не нужно проверок корректности последовательностей.
V> R>Я о том, что кодпоинты вне BMP это эмоджи и прочее.
V> Т.е. эможджи нафиг, так ?! Ну так нафига тогда говорить за весь Юникод. Пиши что ты имеешь в виду свою, выдуманную кодировку, где половина информации из любого современного мессенджера будет похерено, не говоря уже о сайтах и текстовых редакторах.
Нет, не пофиг. Просто это не самые используемые части unicode. Это к тому, что получить кодпоинт из сурроганой пары utf-16 это, мало того, что очень просто, так это еще и не придется делать очень часто. А вот в utf-8 с ее последовательностями... Ну ты понял.
R>1. Итерация символов требует несколько проверок последовательностей (4), вместо единственной в UTF-16;
Задача "итерации символов", под которыми тут очевидно понимаются code points, встречается где-то кроме как в laba1.pas?
Re[16]: [performance] чего-то я не понимаю в этой жизни
Здравствуйте, σ, Вы писали:
σ> R>1. Итерация символов требует несколько проверок последовательностей (4), вместо единственной в UTF-16;
σ> Задача "итерации символов", под которыми тут очевидно понимаются code points, встречается где-то кроме как в laba1.pas?
Здравствуйте, rudzuk, Вы писали:
R>Я для кого только что написал о нормализации?
При чем тут нормализация. Мы не собираемся реализовывать нечеткое сравнение строк. Все-равно куча символов будет состоять из нескольких кодпоинтов. Если бы весь UTF-16 можно было бы запихнуть в одно слово (UCS-2), то суррогатные пары были бы не нужны, точка.
R>В utf-16 вполне. После нормализации (еще раз). Не нужно несколько проверок на длину последовательности, не нужно проверок корректности последовательностей.
О каких проверка речь? Признайся что ты никогда не работал с Юникодом, иначе бы не писал такую чушь ! Или приведи пример кода из которого станет ясно что ты имеешь в виду.
Если мы говорим о гипотетической функции codepoint_next(), то я утверждаю, что её варианты: UTF-8/16/32 — ни один не будет иметь ни одного условного перехода, только приращение указателя на следующий кодпоинт.
R>Нет, не пофиг. Просто это не самые используемые части unicode. Это к тому, что получить кодпоинт из сурроганой пары utf-16 это, мало того, что очень просто, так это еще и не придется делать очень часто. А вот в utf-8 с ее последовательностями... Ну ты понял.
Я понял одно, что ты теоретик, который рассуждает о том, с чем на самом деле никогда не сталкивался и никогда не работал. Либо работал с UCS-2 и забил на всё остальное.
На практике, на реальных данных UTF-8:
— компактнее
— имеет один вариант порядка байт
— обратно совместим с ANSI интерфейсом
— используется повсеместно и вытесняет все остальные кодировки
Создатели Linux не дураки и использовали именно UTF-8 и, в итоге, не получили такого же гемора, какой устроили разработчикам Microsoft. Единственная причина почему UTF-16 использовался в Windows, С#, Java — это то, что на момент их создания стандарта UTF-8 еще не существовало. Да, именно, UTF-8 появился сильно позже, и это факт.
Вот почитай статью, думаю найдешь для себя много нового и интересного.
Здравствуйте, rudzuk, Вы писали:
r>> Вопросы?
R>А знаки?
А откуда взялось требование про знаки? Только потому, что Int.Parse так делает? Кто запрещает написать более специальную функцию, когда все числа заведомо неотрицательные?
--
Не можешь достичь желаемого — пожелай достигнутого.
Re[20]: [performance] чего-то я не понимаю в этой жизни
Здравствуйте, Videoman, Вы писали:
V> R>Я для кого только что написал о нормализации?
V> При чем тут нормализация. Мы не собираемся реализовывать нечеткое сравнение строк. Все-равно куча символов будет состоять из нескольких кодпоинтов. Если бы весь UTF-16 можно было бы запихнуть в одно слово (UCS-2), то суррогатные пары были бы не нужны, точка.
При том, что при нормализации композицией не будет никаких раздвоенных "Ё".
V> R>В utf-16 вполне. После нормализации (еще раз). Не нужно несколько проверок на длину последовательности, не нужно проверок корректности последовательностей.
V> О каких проверка речь?
Посмотри в rfc utf-8, почитай о security considerations.
V> R>Нет, не пофиг. Просто это не самые используемые части unicode. Это к тому, что получить кодпоинт из сурроганой пары utf-16 это, мало того, что очень просто, так это еще и не придется делать очень часто. А вот в utf-8 с ее последовательностями... Ну ты понял.
V> Я понял одно, что ты теоретик, который рассуждает о том, с чем он на самом деле никогда не сталкивался и никогда не работал. Либо работал с UCS-2 и забил на всё остальное.
, я могу на это рассчитывать.
r> Тебе нужно изменить твои входные данные, чтобы там были случайные целые от 0 до INT_MAX.
Насколько я помню, речь шла о том, что изначально у тебя массив инициализировался слишком короткими числами и поэтому там указана верхняя граница. В общем, как бы то ни было, для честного сравнения знак следовало бы учитывать.
Здравствуйте, rudzuk, Вы писали:
R>При том, что при нормализации композицией не будет никаких раздвоенных "Ё".
Какое отношение нормализация имеет к различиям UTF-8/16 ? Ё — я привел лишь как иллюстрацию, что многие Юникод символы состоят из нескольких кодпоинтов. Ты так и не ответил как ты решишь эту проблему в UTF-16 ?
R>Посмотри в rfc utf-8, почитай о security considerations.
Я смотрел. Все проверки на консистентность выполняются на этапе загрузки данных из внешних непроверенных источников. В этом смысле UTF-8/16 друг от друга ничем не отличаются.
R>Жаль, что не понял. Ну да ладно.
Ну слился так слился. Ни на один прямо поставленный вопрос не ответил.
Re[29]: [performance] чего-то я не понимаю в этой жизни
Здравствуйте, rudzuk, Вы писали:
R>Насколько я помню, речь шла о том, что изначально у тебя массив инициализировался слишком короткими числами и поэтому там указана верхняя граница.
Указана была не просто верхняя граница, а полый диапазон допустимых значений — от 0 до INT_MAX. Никакой двусмысленности я не наблюдаю в том высказывании.
R>В общем, как бы то ни было, для честного сравнения знак следовало бы учитывать.
Я повторюсь, *честного* сравниния никто не делал и не претендовал. Сравнение грубое, оценочное. Хочу также обратить внимание, что загрубление в обе стороны — не обрабатываются знаки, но в то же вриемя и не все возможности оптимизации исчерпаны. Просто это не та задача, на которую я готов потратить времени больше, чем уже потратил.
--
Не можешь достичь желаемого — пожелай достигнутого.
Здравствуйте, rg45, Вы писали:
r> Я повторюсь, *честного* сравниния никто не делал и не претендовал. Сравнение грубое, оценочное. Хочу также обратить внимание, что загрубление в обе стороны — не обрабатываются знаки, но в то же вриемя и не все возможности оптимизации исчерпаны. Просто это не та задача, на которую я готов потратить времени больше, чем уже потратил.
Да ты на ответы мне уже потратил времени больше, чем потратил бы на добавление поддержки знаков в парсинг
