D
почему бы перестать сравнивать где лучше и начать просто писать код
Пиздеть в чатиках проще будет
Size: a a a
2020 October 18
K
https://p.jugregator.org/6eee5899-1175-11eb-91a6-0242ac110003 вот такое нагородил
K
есть идеи как получше?
K
в плане алгоритма, а не то что на питоне
t
https://p.jugregator.org/6eee5899-1175-11eb-91a6-0242ac110003 вот такое нагородил
то есть, пересечения ты не мёржишь
t
хотя, может их не быть
t
если контракт такой
t
с таким контрактом мёрж можно распараллелить
t
в редюсере твоём каждый раз длина на 0 проверяется
t
ну и из-за того, что ты делаешь это через reduce, тебе приходится отрывать хвост, чтобы потом его приклеить. Иммутабельность, понимаю
t
забавно, что на двусвязном списке мутирующий алгоритм был бы проще
t
с вектором\массивом (непрерывным куском памяти) пришлось бы помечать "дырки"
c
Minoru
@sarakerrigan: вроде норм. Возможно, у тебя есть какие-то неозвученные требования или детали, тогда можно ещё поговорить
@sarakerrigan: вроде норм. Возможно, у тебя есть какие-то неозвученные требования или детали, тогда можно ещё поговорить
t
надеюсь, этот код так не оставят, потому что в контексте питона он говно
t
или питон научился в иммутабельность и оптимизации с иммутабельностью?
c
Minoru
по-моему, в контексте Питона он не оч только с той точки зрения, что написан в функциональном стиле. Императивно было бы понятнее. В остальном не вижу проблем, @ttldtor
по-моему, в контексте Питона он не оч только с той точки зрения, что написан в функциональном стиле. Императивно было бы понятнее. В остальном не вижу проблем, @ttldtor
t
а такая штука не создаёт новый ...список заново?
acc = acc[:-1]
acc = acc[:-1]
t
а такая? acc + [merged]
t
ну да, "функциональный" стиль
c
Minoru
первая наверняка нет, вторая наверняка да :)
первая наверняка нет, вторая наверняка да :)