Re[38]: [performance] чего-то я не понимаю в этой жизни
От: Codealot Земля  
Дата: 02.07.22 21:54
Оценка:
Здравствуйте, rg45, Вы писали:

R>Ты снова ничего не понял. Ничего мы тебе доказать не пытаемся. Просто наше мнение таково, что такую возможность исключать нельзя до тех пор, пока не доказано обратное. А обратное не доказано. А наше мнение таково. Дошло, нет?


С такими выводами вам надо в духовную семинарию, а инженеры обычно оперируют логикой. Поэтому — см выше про бремя доказательства.
Ад пуст, все бесы здесь.
Re[34]: [performance] чего-то я не понимаю в этой жизни
От: Codealot Земля  
Дата: 02.07.22 22:00
Оценка:
Здравствуйте, rg45, Вы писали:

R>Вот! Вот это доказательство, и я понимаю! Больше огня, больше! Долей скипидара в анус-полыханус. А я пойду посплю. Утомил ты меня своей упоротостью.


Начал ты неплохо, и до чего докатился. Стыдно должно быть.
Ад пуст, все бесы здесь.
Re[39]: [performance] чего-то я не понимаю в этой жизни
От: rg45 СССР  
Дата: 03.07.22 05:37
Оценка: :)
Здравствуйте, Codealot, Вы писали:

C>С такими выводами вам надо в духовную семинарию, а инженеры обычно оперируют логикой. Поэтому — см выше про бремя доказательства.


У меня нет цели тебе что-либо доказывать. Соответствено, бремени тоже. Я уважаю твое право на свободное вероисповедание. Ты, конечно, можешь попробовать переубедить меня, если хочешь, но в этом случае придется тебе поработать над аргументацией.
--
Отредактировано 03.07.2022 9:34 rg45 . Предыдущая версия . Еще …
Отредактировано 03.07.2022 6:47 rg45 . Предыдущая версия .
Отредактировано 03.07.2022 5:41 rg45 . Предыдущая версия .
Re[35]: [performance] чего-то я не понимаю в этой жизни
От: rg45 СССР  
Дата: 03.07.22 05:39
Оценка: :)
Здравствуйте, Codealot, Вы писали:

C>Начал ты неплохо, и до чего докатился. Стыдно должно быть.


Чья бы мычала. Уж тебе я точно ничего не должен.
--
Отредактировано 03.07.2022 9:35 rg45 . Предыдущая версия . Еще …
Отредактировано 03.07.2022 9:31 rg45 . Предыдущая версия .
Re[41]: [performance] чего-то я не понимаю в этой жизни
От: rg45 СССР  
Дата: 03.07.22 05:46
Оценка:
Здравствуйте, Codealot, Вы писали:

C>Делаю вывод, что таки не сказки.


После того, как я это прямым текстом написал? Ты к врачам не пробовал обратиться? Я серьезно сейчас. Симптомы нехорошие у тебя.
--
Отредактировано 03.07.2022 5:47 rg45 . Предыдущая версия .
Re[24]: [performance] чего-то я не понимаю в этой жизни
От: rudzuk  
Дата: 03.07.22 10:03
Оценка:
Здравствуйте, rg45, Вы писали:

r> R>Я ничего не требую, просто удивляюсь, что ты сравниваешь разные вещи и по результатам такого сравнения делаешь какие-то выводы.


r> Ну это грубые оценки, я ж этого и не скрывал. Лично для меня очевидно, что сделать плюсовую реализацию более быстрой, чем сишарпную реально.


Я в этом даже не сомневаюсь. Интересно другое: а если и на шарпе использовать ParseInt?
avalon/3.0.0
Re[24]: [performance] чего-то я не понимаю в этой жизни
От: rudzuk  
Дата: 03.07.22 10:03
Оценка:
Здравствуйте, rg45, Вы писали:

r> R>Я ничего не требую, просто удивляюсь, что ты сравниваешь разные вещи и по результатам такого сравнения делаешь какие-то выводы.


r> А вот это
Автор: rudzuk
Дата: 02.07.22
что, если не требование?


Это пожелание.

r> Ну пожалуйста, добавляю контроль корректности входной последовательности:

...
r> Вопросы?

А знаки?
avalon/3.0.0
Re[18]: [performance] чего-то я не понимаю в этой жизни
От: rudzuk  
Дата: 03.07.22 10:03
Оценка:
Здравствуйте, 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 с ее последовательностями... Ну ты понял.
avalon/3.0.0
Re[15]: [performance] чего-то я не понимаю в этой жизни
От: σ  
Дата: 03.07.22 10:41
Оценка:
R>1. Итерация символов требует несколько проверок последовательностей (4), вместо единственной в UTF-16;
Задача "итерации символов", под которыми тут очевидно понимаются code points, встречается где-то кроме как в laba1.pas?
Re[16]: [performance] чего-то я не понимаю в этой жизни
От: rudzuk  
Дата: 03.07.22 10:42
Оценка:
Здравствуйте, σ, Вы писали:

σ> R>1. Итерация символов требует несколько проверок последовательностей (4), вместо единственной в UTF-16;


σ> Задача "итерации символов", под которыми тут очевидно понимаются code points, встречается где-то кроме как в laba1.pas?


Встречается.
avalon/3.0.0
Re[19]: [performance] чего-то я не понимаю в этой жизни
От: Videoman Россия https://hts.tv/
Дата: 03.07.22 11:04
Оценка:
Здравствуйте, 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 появился сильно позже, и это факт.

Вот почитай статью, думаю найдешь для себя много нового и интересного.
Отредактировано 03.07.2022 11:31 Videoman . Предыдущая версия .
Re[25]: [performance] чего-то я не понимаю в этой жизни
От: rg45 СССР  
Дата: 03.07.22 11:40
Оценка:
Здравствуйте, rudzuk, Вы писали:

r>> Вопросы?


R>А знаки?


А откуда взялось требование про знаки? Только потому, что Int.Parse так делает? Кто запрещает написать более специальную функцию, когда все числа заведомо неотрицательные?
--
Re[20]: [performance] чего-то я не понимаю в этой жизни
От: rudzuk  
Дата: 03.07.22 12:32
Оценка:
Здравствуйте, 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 и забил на всё остальное.


Жаль, что не понял. Ну да ладно.
avalon/3.0.0
Re[26]: [performance] чего-то я не понимаю в этой жизни
От: rudzuk  
Дата: 03.07.22 12:35
Оценка:
Здравствуйте, rg45, Вы писали:

r> r>> Вопросы?


r> R>А знаки?


r> А откуда взялось требование про знаки? Только потому, что Int.Parse так делает?


Ну да.

r> Кто запрещает написать более специальную функцию, когда все числа заведомо неотрицательные?


Никто не запрещает, но никто не обещал и заведомо положительные числа.
avalon/3.0.0
Re[27]: [performance] чего-то я не понимаю в этой жизни
От: rg45 СССР  
Дата: 03.07.22 12:40
Оценка:
Здравствуйте, rudzuk, Вы писали:

R>Никто не запрещает, но никто не обещал и заведомо положительные числа.


Согласно этим требованиям
Автор: Codealot
Дата: 30.06.22
, я могу на это рассчитывать.

Тебе нужно изменить твои входные данные, чтобы там были случайные целые от 0 до INT_MAX.


Только не заведомо положительные, а заведомо неотрицательные, если быть точным.
--
Re[28]: [performance] чего-то я не понимаю в этой жизни
От: rudzuk  
Дата: 03.07.22 12:50
Оценка:
Здравствуйте, rg45, Вы писали:

r> R>Никто не запрещает, но никто не обещал и заведомо положительные числа.


r> Согласно этим требованиям
Автор: Codealot
Дата: 30.06.22
, я могу на это рассчитывать.


r> Тебе нужно изменить твои входные данные, чтобы там были случайные целые от 0 до INT_MAX.


Насколько я помню, речь шла о том, что изначально у тебя массив инициализировался слишком короткими числами и поэтому там указана верхняя граница. В общем, как бы то ни было, для честного сравнения знак следовало бы учитывать.
avalon/3.0.0
Re[21]: [performance] чего-то я не понимаю в этой жизни
От: Videoman Россия https://hts.tv/
Дата: 03.07.22 13:16
Оценка: -1
Здравствуйте, rudzuk, Вы писали:

R>При том, что при нормализации композицией не будет никаких раздвоенных "Ё".

Какое отношение нормализация имеет к различиям UTF-8/16 ? Ё — я привел лишь как иллюстрацию, что многие Юникод символы состоят из нескольких кодпоинтов. Ты так и не ответил как ты решишь эту проблему в UTF-16 ?

R>Посмотри в rfc utf-8, почитай о security considerations.

Я смотрел. Все проверки на консистентность выполняются на этапе загрузки данных из внешних непроверенных источников. В этом смысле UTF-8/16 друг от друга ничем не отличаются.

R>Жаль, что не понял. Ну да ладно.

Ну слился так слился. Ни на один прямо поставленный вопрос не ответил.
Re[29]: [performance] чего-то я не понимаю в этой жизни
От: rg45 СССР  
Дата: 03.07.22 13:22
Оценка:
Здравствуйте, rudzuk, Вы писали:

R>Насколько я помню, речь шла о том, что изначально у тебя массив инициализировался слишком короткими числами и поэтому там указана верхняя граница.


Указана была не просто верхняя граница, а полый диапазон допустимых значений — от 0 до INT_MAX. Никакой двусмысленности я не наблюдаю в том высказывании.

R>В общем, как бы то ни было, для честного сравнения знак следовало бы учитывать.


Я повторюсь, *честного* сравниния никто не делал и не претендовал. Сравнение грубое, оценочное. Хочу также обратить внимание, что загрубление в обе стороны — не обрабатываются знаки, но в то же вриемя и не все возможности оптимизации исчерпаны. Просто это не та задача, на которую я готов потратить времени больше, чем уже потратил.
--
Отредактировано 03.07.2022 13:30 rg45 . Предыдущая версия . Еще …
Отредактировано 03.07.2022 13:27 rg45 . Предыдущая версия .
Re[30]: [performance] чего-то я не понимаю в этой жизни
От: rudzuk  
Дата: 03.07.22 13:37
Оценка: +1 :)
Здравствуйте, rg45, Вы писали:

r> Я повторюсь, *честного* сравниния никто не делал и не претендовал. Сравнение грубое, оценочное. Хочу также обратить внимание, что загрубление в обе стороны — не обрабатываются знаки, но в то же вриемя и не все возможности оптимизации исчерпаны. Просто это не та задача, на которую я готов потратить времени больше, чем уже потратил.


Да ты на ответы мне уже потратил времени больше, чем потратил бы на добавление поддержки знаков в парсинг
avalon/3.0.0
Re[31]: [performance] чего-то я не понимаю в этой жизни
От: rg45 СССР  
Дата: 03.07.22 13:38
Оценка:
Здравствуйте, rudzuk, Вы писали:

R>Да ты на ответы мне уже потратил времени больше, чем потратил бы на добавление поддержки знаков в парсинг


Так я и на ответы не планировал тратить столько времени. Шестой десяток живу, а не вестить на провокации так и не научился. Видимо, не судьба.
--
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.