Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Это не попытка "угодить всем", а вполне логичный шаг по стандартизации давно существующей и успешно применяемой практики Boost.Range EP>Range'и как концепция отлично дополняют итераторы, и существуют в других языках типа D.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>В этом нет ничего удивительного, учитывая поведение std::unique из ISO C++ прошлого века. EP>Такой вариант вполне логичный и оправданный — во-первых это более общо, во-вторых позволяет не делать лишнюю работу. Например таким же образом работает uniq(1) (тоже из прошлого века).
Извини, я сориентироваться хочу. Ты принципиально не читаешь ответы в теме, а пишешь свой для начала?
Здравствуйте, kaa.python, Вы писали:
KP>А почему реализация функционального концепта в языке программирования должна равняться на Юникс-утилиты
Ну она базируется на std::unique из C++1998. Но, даже если не знать про std::unique, а только про uniq — то существование такого интерфейса (отличного от distinct) должно натолкнуть на мысль таки заглянуть в документацию, и прочитать что именно делает используемая команда, а не строить догадки. В то что ты не знал ни про uniq, ни про std::unique — верится с трудом
KP>, а не, к примеру, на коммерческие функциональные языки?
Что ты называешь "коммерческими", какие преимущества аргументации эта "коммерческость" даёт по сравнению со стандартизированной uniq?
KP>(distinct [2 2 1 5 4 4 4 ]) KP>=> (2 1 5 4)
Это странный пример в обсуждаемом контексте, так как unique/uniq выдаст такой же результат
KP>Функциональные концепции в языке должны базироваться на подходах принятых в функциональных языках, по причинам, которые я вот тут объяснял
Ну вот если бы стоял выбор между интерфейсами uniq и distinct для Range'ей, то я бы выбрал uniq.
Во-первых, это более общо — например нужно удалить именно последовательные дубликаты, а не все.
Во-вторых, быстрее если данные уже в нужном порядке.
Тем не менее, и у интерфейса distinct тоже есть преемущества, так что в идеале нужны оба.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Ну она базируется на std::unique из C++1998.
Это прекрасно, как сочетается std::unique и заявленная ленивость?
EP> Но, даже если не знать про std::unique, а только про uniq — то существование такого интерфейса (отличного от distinct) должно натолкнуть на мысль таки заглянуть в документацию, и прочитать что именно делает используемая команда, а не строить догадки. В то что ты не знал ни про uniq, ни про std::unique — верится с трудом
Везде разные имена, где-то distinct, где-то uniq, как в моем примере с Clojure и Elixir
EP>Что ты называешь "коммерческими", какие преимущества аргументации эта "коммерческость" даёт по сравнению со стандартизированной uniq?
Довольно очевидное — это некий устаявшийся паттерн поведения, который могу ожидать люди имевшие опыт с инструментом. Но, знаю-знаю, это не C++-путь, у нас надо изобрести свой правильный велосипед с квадратными колесами.
KP>>(distinct [2 2 1 5 4 4 4 ]) KP>>=> (2 1 5 4)
EP>Это странный пример в обсуждаемом контексте, так как unique/uniq выдаст такой же результат
N>Ну, это и правда больше упражнение, благо для матриц сейчас библиотек достаточно и вряд ли кто-то решит писать сам. А необходимость поиска нескольких минимальных/максимальных элементов иногда встречается, реализации из коробки нет, вот и приходится самому думать. Что предлагают делать разработчики на Питоне? Сортировать! На втором месте уже np.argpartition, про который говорят, что он сработает за линейное время, что неверно в общем случае. И только где-то там самый быстрый алгоритм — heapq.nlargest. Хотя именно с кучей можно быстрее всего найти k-top элементов. Не хочется, чтобы С++ уходил в эту же сторону, краткость не решает.
Не читай советских газет перед обедом (с)
def kth(a, n):
m = a.shape[0]
perc = (np.arange(m-n,m)+1.0)/m*100
return np.percentile(a, perc)
N>Да, у меня есть проф деформация и я не очень люблю Питон из-за этого. Иногда кажется, что программирование на нём сродни программированию на Делфи: "А какой компонет может сделать ххх?" Только в Питоне слово "компонет" заменяется на "пакет". (Это конечно снобизм, я на нём сам такой же и с удовольствием пишу говноутилиты для парсинга и перекладывания разных штук, не выходя за рамки стантартных пакетов.) N>Но глобально, я не понимаю, что стоит за вывеской питоновских import xxx, ни тут, за вывеской ranges. И если что-то будет тормозить, то придётся не разбираться, а тупо переписывать. Мне стрёмно, когда я не могу посмотреть в отладчике какой-то код или вставить в него логи.
Здравствуйте, kaa.python, Вы писали:
EP>>Ну она базируется на std::unique из C++1998. KP>Это прекрасно, как сочетается std::unique и заявленная ленивость?
А что смущает? Например имя/интерфейс views::transform базируется на std::transform — одно ленивое, другое энергичное
KP>Везде разные имена, где-то distinct, где-то uniq, как в моем примере с Clojure и Elixir
Суть не в именах, а в том что в природе встречается и тот и другой интерфейс.
EP>>Что ты называешь "коммерческими", какие преимущества аргументации эта "коммерческость" даёт по сравнению со стандартизированной uniq? KP>Довольно очевидное — это некий устаявшийся паттерн поведения, который могу ожидать люди имевшие опыт с инструментом. Но, знаю-знаю, это не C++-путь, у нас надо изобрести свой правильный велосипед с квадратными колесами.
Аллё гараж, какой ещё C++-путь, интерфейсу uniq(1) много десятков лет, он к тому же стандартизирован в POSIX.
