Python-сообщество

Iskatel
но всеже: причем тут нафиг строки???

Никто не спорит что файлов с текстом практически нет. Но нужен конструктив. Надо что-то менять с подходами или нет в тех таки случаях когда в файле текст? Все и так могут открыть файл open(“aaa.txt”,“rb”). И будет счастье.

doza_and
когда в файле текст

ok, даже в томже rtmp, который я упоминал, есть текст… и стараниями rdump например поток может стать файлом.

А дальше что? ДА, в файле есть текст (ГЫЫ) но без понимания основ даже текст оттуда не достать…

Зы. и опять все про текст… Слишком узко используете язык…

Отредактировано Iskatel (Окт. 14, 2016 21:29:40)

doza_and
Для utf-8 - ввод вывод тривиален. Поиск по индексу именно буквы операция сложности O(N) где N длина строки.

Там квадратный поиск получается. Ты должен взять символ, раскодировать его, только после этого ты знаешь, куда сместиться, чтобы взять следующий символ и раскодировать его. И так для каждого символа. Если искомый символ в конце, ты сначала должен раскодировать всё, что стоит слева от него, шагая от символа к символу.
А с юникодом - ты просто взял число, сравнил с ним число, взял число, сравнил с ним число. А последний символ ты можешь сразу взять и проверить за O(1), так как размер чисел фиксирован. Да, оно там хранится в памяти, но если подумать, много это получается? Сколько ты видел строк в памяти? Хотя бы мегабайт видел когда-нибудь? Очень сомнительно.
Так что юникодовые строки по времени быстрее обрабатываются, так как не надо неявно кодировать и раскодировать при операциях.

py.user.next
должен раскодировать всё, что стоит слева от него, шагая от символа к символу.

Ну и где тут квадратный? это алгоритм линейной сложности. Работа с потоком символов.

py.user.next
Сколько ты видел строк в памяти? Хотя бы мегабайт видел когда-нибудь?

У меня каждый второй скрипт такой. И не 1 -2 мегабайта а сотни мегабайт. Не факт что у всех так. Мы с ZZZ это уже обсуждали. Мне текстовых редакторов не хватает потому что они долго грузят большие текстовые файлы. :)

Задачек куча. Анализ логов систем. У нас практически всегда описание интерфейсов программ это текстовые файлы специальных форматов. Количество интерфейсных переменных миллион легко! Характерный размер 2-3 мегабайта, но доходит и до 200 мегабайт. И далеко не всегда можно сделать однопроходный алгоритм анализа. Куча работы с анализом текстов программ. Они обычно скопом не грузятся но объемы тоже бывают десятки мегабайт. Файлы входных данных для расчетных физических программ это тоже текстовые файлы на десятки мегабайт иногда до гигабайт. И их тоже надо обрабатывать. Еще интересная задача правка отчетов в docx. Самый быстрый способ это распаковать docx и регулярками его поправить, а потом обратно запаковать результат. Микрософт не скупится и это обычно единицы или десятки мегабайт xml

ну вот последний отчет который шкурили


5 мегабайт текста.

unicode или utf-8 для меня - это положение границы на которой я должен переходить от более простых и быстрых алгоритмов обработки в памяти к потоковым алгоритмам.

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

Ну и напоследок иллюстрация для python3


для 10 мб файла время в секундах
readlines 0.28752883687402336
open(“aaa.txt”,“r”) + read() 0.060072484389587656
open(“aaa.txt”,“rb”) + read() 0.007378245696503398
для полноты картины добавлю lxml.parce 0.4258351969049158

т.е. потоковый алгоритм - просто катастрофа. utf-8 - unicode долго но терпимо, но в 10 раз хуже чем могло быть.

Отредактировано doza_and (Окт. 15, 2016 10:22:54)

doza_and
У меня каждый второй скрипт такой.

Ты имеешь в виду обработку данных, я же говорю про работу со строками. Не про данные, а про строки текстовые. Какая разница между этими понятиями? В строках есть понятие символа, а в данных такого понятия нет. И юникод позволяет работать вот с этими символами.

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

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

doza_and
Ну и где тут квадратный? это алгоритм линейной сложности. Работа с потоком символов.

Квадрат здесь в этом раскодировании необходимом.

Вот тебе строка без юникода
Напиши функцию, которая возвращает третий символ, если первые два символа равны. Юникод использовать нельзя. Покажи линейность, о которой ты говоришь тут налево и направо.

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

Ладно, вот тебе задача: поступает поток символов текста, нужно его разделить по абзацам и вернуть поток абзацев. (Абзац - десять предложений.)

Вот тебе ещё задача
Вот для этой строки напиши функцию, которая разбивает её на куски длины n.
Вызываешь, например, f(s, 5) и она возвращает тебе последовательность по пять иероглифов, а если вызываешь f(s, 6), то она возвращает тебе последовательность по шесть иероглифов. Юникод использовать нельзя.
А функцию назовёшь fold(). Когда она будет готова, тебя ждёт сюрприз.

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

Отредактировано py.user.next (Окт. 15, 2016 10:17:16)

py.user.next
В строках есть понятие символа

Да полностью с вами согласен. В этом смысле я со строками ни разу в жизни не работал. Мне надо обычно найти в строке (строке в смысле питона, которая прочитана из файла) заданный образец и что-то с ним сделать. Меня ни капельки не волнует сколько в нем букв или байт, я фрагмент просто копирую в программу из другого файла или набираю ручками, поскольку это в 99% случаев обычный ascii.

py.user.next
Я давал ссылку, которую ты не читал, там есть пример.

Так дело не в учебных примерах. Я просил пример из ВАШЕГО ПРАКТИЧЕСКОГО опыта а не высосаный из пальца. Вы пока его не привели, поэтому к вашей писанине я пока отношусь как писанине теоретика программирования.

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

А по поводу измерения времени, умеете лучше, так не трепите языком, напишите как надо укажите на ошибки. Посмотрим что дадут ваши знания :)

Отредактировано doza_and (Окт. 15, 2016 10:46:39)

doza_and
Так дело не в учебных примерах. Я просил пример из ВАШЕГО ПРАКТИЧЕСКОГО опыта а не высосаный из пальца.

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

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

Отредактировано py.user.next (Окт. 15, 2016 10:56:06)

py.user.next
Я не могу тебе дать из практического, потому что там учебные нужно щёлкать, как орешки, а ты их не тянешь.

:) Улыбнуло.

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

doza_and
:) Улыбнуло.

Вот ты писал
Нафиг ты результат readlines() к списку приводишь?
Надо было написать
Так было бы веселее :) Ясность кода и всё такое.
Я даже не угараю, просто вижу, что ты редко пишешь что-либо, поэтому не помнишь, что там происходит. А почему не можешь проверить, что он возвращает? А потому что среда не настроена. Это всё видно. ;)

А алгоритмически ты тоже не напишешь. Кодерством-то гораздо легче заниматься, чем алгоритмикой.

Отредактировано py.user.next (Окт. 16, 2016 04:00:33)

py.user.next
Нафиг ты результат readlines() к списку приводишь?

Да блин, век живи век учись. Спасибо! Не думал что в питоне 3 вернут список а не итератор. На этом потеряли 0.1 сек. И это ровным счетом никак не повлияло на выводы.

py.user.next
что ты редко пишешь

Не то что редко. Я так вообще никогда не пишу. Для маленьких файлов до гигабайта вообще нет смысла морочиться а скорость обработки выше. А большие файлы читать конструкциями
Могут позволить себе только академики от программирования :) . Время обработки будет непозволительно большим. Поэтому разбиение на блоки и опять чтение и обработка большими кусками. При этом python2 рулит. Он оказывается примерно вдвое быстрее троечки.

По поводу разбиения. Да надо правильно выравнивать блоки. Но выравнивать понятное дело не по границам букв, а по лексемам или даже еще более сложным конструкциям характерным для данного типа файлов. Это обычно “\n” или пробелы. Поэтому алгоритм выравнивания по границам букв для разбиения на блоки вообще не нужен даже если вашей работе встречаются нехарактерные лексемы типа “сиски”.

Если вам нужен зачем-то алгоритм выравнивания по буквам для utf-8 не стесняйтесь, пишите. Насколько я понимаю это пара строчек кода.

Но это все лирика. Главный вопрос в другом. Похоже что внутренняя форма представления строк в питоне неудачная. Их можно хранить в виде utf-8. На конструкциях программ это никак не скажется. Но просядет производительность извлечения подстрок, может просядут регулярные выражения, но не факт, и изменится бог знает сколько интерфейсов с ОС. При этом существенно поднимется скорость обмена с диском и снизятся затраты памяти. Это вопрос на подумать тем кто понимает.