Форум сайта python.su
BudulianinС моей стороны был осознанный выбор. Мой подход более очевиден и более легко модифицируется, при необходимости. Данные я могу обрабатывать как-нибудь ещё, генератор использовать тоже по-разному. Файловый дескриптор далее второй строки нигде не используется - это видно при беглом просмотре текста.
Просто я посмотрел на твой нерациональный подход и решил написать свой вариант.
Ты бессмысленно перебираешь массив 2 раза, когда задача решается в один проход, причём строки хранишь в списке(в памяти).
Офлайн
BudulianinЛучше strip, т.к. в файле могут быть лидирующие пробелы и strip элементарно короче пишется.
+ используешь strip, хотя достаточно rstrip
Budulianinenumerate говорит сам за себя и скрывает мешающую механику счетчиков.
enumerate я тоже осознанно не использовал
BudulianinЧитается лучше, но расходы памяти больше, если её беречь.я считаю что лучше писать, а неresult.append([i, j])result.append((i, j))
Отредактировано Shaman (Июнь 25, 2014 12:02:17)
Офлайн
ShamanМожет быть.
Лучше strip, т.к. в файле могут быть лидирующие пробелы
Shaman:D
strip элементарно короче пишется.
ShamanПросто там лишние действия происходят, которые можно не делать.
enumerate говорит сам за себя и скрывает мешающую механику счетчиков.
ShamanНамного?
Читается лучше, но расходы памяти больше, если её беречь.
Офлайн
BudulianinА сколько внутри интерпретатора действий происходит, но не писать же это на С? Использовал это всё в time-memory-limited проектах - ничего смертельного.
Просто там лишние действия происходят, которые можно не делать.
BudulianinНет, конечно.
Намного?
Офлайн
ShamanНе писать, но и не делать лишние действия(такие как обходы последовательностей лишний раз, хранения в памяти ненужных объектов и тп)
А сколько внутри интерпретатора действий происходит, но не писать же это на С?
ShamanНу вот и я о том же, поэтому лучше писать там список.
Нет, конечно.
Офлайн
ShamanТут дело не в том смертельно это или нет для машины, просто чем рациональнее алгоритм, тем лучше(в разумных пределах и в рамках Python)
Использовал это всё в time-memory-limited проектах - ничего смертельного.
Отредактировано Budulianin (Июнь 25, 2014 12:36:25)
Офлайн
BudulianinРациональность - штука неабсолютная и определяется целями.
просто чем рациональнее алгоритм, тем лучше(в разумных пределах и в рамках Python)
BudulianinА я за гуманистическое программирование, ибо чего стоит куча слоёв абстракций, если все их придётся умозрительно разворачивать для “оптимизации”?
Сегодня у меня такое мнение.
Отредактировано Shaman (Июнь 25, 2014 14:45:37)
Офлайн
ShamanСохранять все строки в список, потом опять перебирать их, когда есть итератор и можно эти действия сделать за одну итерацию, при такой задаче, это абсолютно нерационально.
Рациональность - штука неабсолютная и определяется целями.
Shaman
А я за гуманистическое программирование, ибо чего стоит куча слоёв абстракций, если все их придётся умозрительно разворачивать для “оптимизации”?
Офлайн
BudulianinПрочитай пункт dip3. tuples
Ну вот и я о том же, поэтому лучше писать там список.
Shaman
Так же предпочтительнее квантовать код по зонам ответственности.
Shamanwith open('graph.dat') as f: data = [l.strip() for l in f] def edges(data): for r, rd in enumerate(data, 1): for c, cd in enumerate(rd, 1): if int(cd): yield r, c
def read(): with open('graph.dat') as f: data = [l.strip() for l in f] return data def edges(data): for r, rd in enumerate(data, 1): for c, cd in enumerate(rd, 1): if int(cd): yield r, c
ShamanА в эту строку проник int, который знает, как были прочитаны данные. Узнал он это через устройство data, которое зависит от модуля чтения. То есть модули чтения и обработки сцеплены по формату, по формату data. Стоит измениться формату data в модуле чтения, и модуль обработки сломается.if int(cd):
Отредактировано py.user.next (Июнь 25, 2014 22:42:15)
Офлайн
py.user.next
Прочитай пункт dip3. tuples
Отредактировано Budulianin (Июнь 25, 2014 22:49:12)
Офлайн