Здравствуйте, alex_public, Вы писали:
_>Интересно чего будет стоить что бы модифицировать тот пример на linq под это условие?
Императивный код на C# никто ведь не запрещает писать при необходимости.
_>Код же на boost'е выше можно подправить под это условие парой букв.
Каких букв?
_>в xor должны попадать только числа или находящиеся на позиции не большей чем длинна предыдущей строки или стоящие после числа меньше их.
Учёт предыдущих элементов обычно делается через зип со сдвигом.
// В xor должны попадать только числа или находящиеся на позиции не большей,
// чем длина предыдущей строки, или стоящие после числа меньше их.var lines = File.ReadAllLines("Numbers.txt").Select(line => line.Split(','));
var previousLengths = lines.Select(numbers => numbers.Length).StartWith(0);
var results = lines
.Select(line => line.Select(Int32.Parse))
.Zip(previousLengths, (numbers, previousLength) =>
numbers.StartWith(Int32.MinValue)
.Zip(numbers, (previous, current) => new { previous, current })
.Select((value, index) => new { value.previous, value.current, index })
.Where(value => value.index <= previousLength || value.previous < value.current)
.Select(value => value.current)
.Aggregate(0, (total, number) => total ^ number));
results.OrderByDescending(result => result)
.ForEach(Console.WriteLine);
Да, иногда в коде могут использоваться расширения для Linq из Rx (точнее, System.Interactive.dll). Здесь это ForEach() и StartWith(). Но по запросу могу выложить полный трёхстрочный код этих функций.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, _d_m_, Вы писали:
___>>Ну-ну... хватит фантазий.
_>Слова Redis, MongoDB и т.п. знакомы? Там ещё несколько десятков таких. И они сейчас уверенно выходят на сцену. Причём как раз в тех областях где раньше безраздельно царили всякие разновидности slq баз.
Это просто модные тенденции, которые имеют под собой в основе то, что большинство потребителей данной продукции не смогли осилить SQL.
Здравствуйте, Qbit86, Вы писали:
Q>Да, иногда в коде могут использоваться расширения для Linq из Rx (точнее, System.Interactive.dll). Здесь это ForEach() и StartWith(). Но по запросу могу выложить полный трёхстрочный код этих функций.
А я вот поддерживаю мнение, что ForEach() — это все-таки не Linq. В силу его неленивости.
Здравствуйте, _d_m_, Вы писали:
_>>Слова Redis, MongoDB и т.п. знакомы? Там ещё несколько десятков таких. И они сейчас уверенно выходят на сцену. Причём как раз в тех областях где раньше безраздельно царили всякие разновидности slq баз. ___>Это просто модные тенденции, которые имеют под собой в основе то, что большинство потребителей данной продукции не смогли осилить SQL.
Ты не понимаешь. У этого фаната Плюсов такой способ самоутверждаться — писать побольше базвордов.
Здравствуйте, MxMsk, Вы писали:
Q>>Да, иногда в коде могут использоваться расширения для Linq из Rx (точнее, System.Interactive.dll). Здесь это ForEach() и StartWith(). Но по запросу могу выложить полный трёхстрочный код этих функций. MM>А я вот поддерживаю мнение, что ForEach() — это все-таки не Linq. В силу его неленивости.
Linq можно рассматривать как порт стандартных библиотек последовательностей из других функциональных языков. В некоторых наряду с map (Select) есть и iter (ForEach), например, в OCaml/F#.
Здравствуйте, MxMsk, Вы писали:
MM> ___>Это просто модные тенденции, которые имеют под собой в основе то, что большинство потребителей данной продукции не смогли осилить SQL. MM> Ты не понимаешь. У этого фаната Плюсов такой способ самоутверждаться — писать побольше базвордов.
А что, такой любитель передовых морковок все еще не наделся ни на одну из них? Странно это очень, смотри упустишь шанс и будешь потом слюни пускать... Хотя, я видимо упустил из виду, что передовые морковки хороши только от МС
Здравствуйте, Qbit86, Вы писали:
Q>Linq можно рассматривать как порт стандартных библиотек последовательностей из других функциональных языков. В некоторых наряду с map (Select) есть и iter (ForEach), например, в OCaml/F#.
Они выполняются сразу же по месту вызова?
Здравствуйте, MxMsk, Вы писали:
Q>>..В некоторых [библиотеках] наряду с map (Select) есть и iter (ForEach), например, в OCaml/F#. MM>Они выполняются сразу же по месту вызова?
А чего ещё ждать от функции с сигнатурой «List.iter : ('T -> unit) -> 'T list -> unit»?
Здравствуйте, Qbit86, Вы писали:
MM>>Они выполняются сразу же по месту вызова? Q>А чего ещё ждать от функции с сигнатурой «List.iter : ('T -> unit) -> 'T list -> unit»?
Ок. Я F# особо не изучал. Чисто теоретически ForEach можно реализовать как Select, возвращающий исходный список по-элементно, через yield, после применения функции.
Здравствуйте, MxMsk, Вы писали:
MM>>>Они выполняются сразу же по месту вызова? Q>>А чего ещё ждать от функции с сигнатурой «List.iter : ('T -> unit) -> 'T list -> unit»? MM>Ок. Я F# особо не изучал. Чисто теоретически ForEach можно реализовать как Select, возвращающий исходный список по-элементно, через yield, после применения функции.
Но результирующий ленивый список придётся форсить, чтобы применения процедуры выполнились. Скажем, .ToList(). А зачем оно такое надо?
Здравствуйте, Qbit86, Вы писали:
MM>>Ок. Я F# особо не изучал. Чисто теоретически ForEach можно реализовать как Select, возвращающий исходный список по-элементно, через yield, после применения функции. Q>Но результирующий ленивый список придётся форсить, чтобы применения процедуры выполнились. Скажем, .ToList(). А зачем оно такое надо?
Форсить тогда, когда надо. ForEach был бы аналогом Observable.Do, чтобы не писать типа:
Здравствуйте, Аноним, Вы писали:
А>А что Вы думаете по этому поводу?
Еще интернационализация, проще перевести один большой формат целиком, чем гадать, какой кусок от какой фразы мы переводим, если там в серединке вставлен вывод переменной. И будет ли осмыслена вообще потом полученная фраза.
Здравствуйте, MxMsk, Вы писали:
Q>>Linq можно рассматривать как порт стандартных библиотек последовательностей из других функциональных языков. В некоторых наряду с map (Select) есть и iter (ForEach), например, в OCaml/F#. MM>Они выполняются сразу же по месту вызова?
И OCaml и F# и даже их предок вообще-то ко всему и вполне полноценные императивные языки
Правда тот же List.iter в OCaml изменить список по месту не даст, так как список иммутабельный,
но вот функцию с сигнатурой 'a -> unit бессмысленной в чистом ФЯ вызывает без проблем.
Здравствуйте, alex_public, Вы писали:
_>Только он отрицательные числа не учитывает. )
Ну ты же понимаешь, что анализ минуса заметно на перформансе не скажется?
_>Да, C++ потоки — это безусловные тормоза. И раньше про это слышал и вот на этих примерах сам убедился.
Ну они не то чтобы прям тормоза, просто слишком примитивные. В джаве, кстати, такая же проблема — неиспользование BufferedStream одна из основных ошибок начинающих.
_>Проверил у себя. Этот код выполняется быстрее варианта stl с потоками, приблизительно одинаковое время с stl загружающей данные через fread (кстати очень характерный момент) и в 2,4 раза медленнее варианта с Boost'ом или же кодом в лоб.
после чего человек, называвший это отрывом от реальности, резко пропал.
Вот эта фраза:
в xor должны попадать только числа или находящиеся на позиции не большей чем длинна предыдущей строки или стоящие после числа меньше их.
по правилам русской грамматики не парсится.
НС>>Хм, вообще то чистый функциональный код по определению декларативен.
_>Ха, а вот на эту тему в соседнем разделе был недавно спор. Который начался с тезиса о том что Лисп — это императивный язык. Могу кинуть ссылку, если интересно. Но вообще хочу заметить что даже среди очень немногих языков имеющих само понятие "чистоты функции" у нас наблюдается язык D (наследник C++ — ну никак не декларативный язык).
Pure function и pure functional это не одно и тоже.
In computer science, functional programming is a programming paradigm that treats computation as the evaluation of mathematical functions and avoids state and mutable data.
_>Я уже писал, этo естественно не обращение к sql серверу в привычном понимание. Просто sql — это некий dsl. Он может быть реализован не только внешне, но и внутри любого языка.
А list comprehension в Лиспе — это тоже sql? Что то я не пойму, в какой момент у тебя continuation monad превращается в sql?
_> И соответственно linq — это своебразная реализация под C#.
Реализация чего? Просто какого то DSL? В C# много подобных "DSL". Все из них являются sql? Или только какие то конкретные синтаксические конструкции? Какие и почему?
_>Разве что надо понимать что 1. подобный синтаксический сахар сам по себе подходит не ко всем задачам
Какой синтаксический сахар ты имеешь в виду? По сравнению с С++ в тесте ровно одна новая конструкция — extension methods. К каким задачам он не подходит?
_> 2. частенько это будет стоить определённых потерь в производительности.
extension methods никогда не приводят к потерям производительности, это просто статические методы, только синтаксис вызова похитрее. Или ты про лямбды?
_>А вот некоторые фанатики не очень это понимают и уже даже думают что в будущем нечто подобное и в C++ заменит STL.
Я не фанатик, но с появлением лямбд обязательно что то похожее появится. Хотя без замыканий, конечно, будет тяжко.
НС>>В очень узких областях. Там, где хранятся структурированные данные больших объемов, альтернатив SQL-серверам нет и в обозримом будущем не предвидится.
_>Это уже вообще отдельная тема для разговора.
Не я ее завел.
_> Но хочу напомнить что как раз на очень больших объёмах nosql базы и начали интенсивно применяться.
Неструктурированных данных. Я даже выделил жирным ключевое слово, но ты таки умудрился его проигнорировать.
_> Достаточно вспомнить как хранят данные всякие там гуглы, фейсбуки, твитеры.
Вот вот. Осталось задаться вопросом, почему ни одна ERP не использует эти новомодные map-reduce сотоварищи.
_>Так я и не говорю что тормозит сам linq, в смысле процесс связывания.
А что тормозит? extension methods? Лямбды? foreach?
_> Естественно проблемы где-нибудь в лишнем создание/копирование строк и т.п.
Нет там лишнего копирования.
_> Но тормозит именно из-за linq!
LINQ это абстракция. Из-за него не может ничего тормозить. Но мне очень интересно, на основании чего ты сделал такие выводы.
_> Потому что этот синтаксический сахар навязывает нам определённую архитектуру приводящую к лишним накладным расходам.
Что именно он навязывает? Конкретно.
_> Просто во многих случаях всем наплеваеть на такие нюансы с памятью и быстродействием, так что можно спокойно наслаждаться симпатичным кодом (естественно когда задача ложится на slq стиль — это ещё не всегда).
Что такое sql-стиль?
_>Кстати, замечу что если программировать на stl в её функциональном стиле, то опять же натыкаемся на похожие проблемы.
Мы натыкаемся на гораздо большее количество проблем, с чего, собственно, этот тред и начался.
_> А вот при использование всяческих boost хитростей или же написание императивного кода действующего в лоб уже никаких потерь нет.
Если это всегда выливается в тот ужас ужас, что ты продемонстрировал, то такое надо применять только в сверхкрайних случаях.
_> И кстати при этом boost код ещё и короче всех рассмотренных вариантов вообще.
Здравствуйте, MxMsk, Вы писали:
MM>А я вот поддерживаю мнение, что ForEach() — это все-таки не Linq. В силу его неленивости.
Неленивость это фигня, даже в standard query pattern дофига неленивых методов, тот же Count или там Any. Прежде всего он императивен и с побочными эффектами.
Здравствуйте, Qbit86, Вы писали:
Q>Императивный код на C# никто ведь не запрещает писать при необходимости.
Вооот, наконец то! И я про это. Что частенько императивный код намного эффективнее. А linq заточен совсем под другую модель, так что в определённых случаях неудобен (а позиционировался то тут как универсальные контейнеры). Что я и сказал, а ты сразу про отрыв от реальности... )))
_>>Код же на boost'е выше можно подправить под это условие парой букв. Q>Каких букв?
Там две лямбды (первая вызывается после каждого числа, а вторая после каждой строки). Из второй if убираем, а в первую добавляем. И всё. По объёму код даже не изменится.
Q>Учёт предыдущих элементов обычно делается через зип со сдвигом. Q>
Q>// В xor должны попадать только числа или находящиеся на позиции не большей,
Q>// чем длина предыдущей строки, или стоящие после числа меньше их.
Q>var lines = File.ReadAllLines("Numbers.txt").Select(line => line.Split(','));
Q>var previousLengths = lines.Select(numbers => numbers.Length).StartWith(0);
Q>var results = lines
Q> .Select(line => line.Select(Int32.Parse))
Q> .Zip(previousLengths, (numbers, previousLength) =>
Q> numbers.StartWith(Int32.MinValue)
Q> .Zip(numbers, (previous, current) => new { previous, current })
Q> .Select((value, index) => new { value.previous, value.current, index })
Q> .Where(value => value.index <= previousLength || value.previous < value.current)
Q> .Select(value => value.current)
Q> .Aggregate(0, (total, number) => total ^ number));
Q>results.OrderByDescending(result => result)
Q> .ForEach(Console.WriteLine);
Q>
А вот это и есть реальная жуть. Причём исключительно из-за желания всунуть linq туда, куда оно не подходит. На том же C# можно было написать императивный код намного короче, яснее и при этом скорее всего быстрее работающий (чем этот, а не C++ естественно ).
Тестировать быстродействие этого дела даже не буду — наверняка там что-то уже совсем печальное. ))) Да и собственно уже ни к чему. Т.к. когда у нас есть некий синтаксических сахар, позволяющий писать красивый код ценой некого падения быстродействия, то имеет смысл оценить размер этого падения (вдруг он допустимый для нашей задачи). Как было в примере на предыдущую задачку (там я не спорю, что решение на linq выглядело красиво). А тут у нас уже и код страшный — даже уже нет смысла смотреть что-то дальше.
Здравствуйте, _d_m_, Вы писали:
___>Это просто модные тенденции, которые имеют под собой в основе то, что большинство потребителей данной продукции не смогли осилить SQL.
Ну да, конечно, всякие там гуглы, амазоны, фейсбуки, яндексы — это просто неумехи. Они хотели бы на mysql построить свои системы, но не осилили просто. Поэтому пришлось городить свои велосипеды. )))
А теперь уже и мелкие системы идут по тому же пути, только используя не свои велосипеды, а коллективные разработки или же подаренные теми же корпорациями. Естественно вовсе не потому что nosql решения могут держать большую нагрузку и проще масштабироваться, а просто по глупости — обезьянничают со старших коллег. )))
