Здравствуйте, vdimas, Вы писали:
V>Оу, смотрю, запутался в собственных показаниях напрочь. ))
Не, ты похоже даже прочитать правильно не смог =)
V>Судя по твоей писанине, тебе нравится обмениваться "любезностями" с колегами. V>Показал себя еще тем любителем словесного БДСМ.
БДСМ? Не льсти себе, на сабмиссива ты не тянешь, просто жвачка на ботинке...
Здравствуйте, vdimas, Вы писали:
V>Инфа для чебурашек из далёких стран о правилах нашего мира: V>- когда по рылу в ответ, то не считается.
Ты допрыгни сначала, чтоб в ответ... =) Из твоей коленно-локтевой позы-то все больше получается зад под пинок подставить, сложно мимо такой цели пройти
V>Угу, в сортах г-на разбираюсь так себе.
Ага, видно, что жрешь все подряд
Здравствуйте, vdimas, Вы писали:
V>Ты показал умение написать слово "манипуляция" без грамматических ошибок, разве что.
Не, ну ты никогда не догоняешь, на тебя и не рассчитывал )
V>Манипуляция — это когда сознательно недоговаривают, врут, играют одновременно на неполной информации и на эмоциях.
Ага. Но я не буду здесь с тобой его обсуждать. Во первых, у тебя и за себя-то отвечать не очень получается, так что не фиг за других впрягаться. А во вторых, он большой мальчик, сможет сам за себя высказаться, если ему покажется, что я что-то обидное написал.
V>Это имеющиеся Enumerable и Queryable классы, плюс правила маппинга синтаксиса языка выражений на обычные методы или на методы расширений.
Ответ не верный. Собственно, от этого и все остальные заблуждения. Вы почему-то загоняете линк в какие-то непонятные рамки, а потом хотите от него странного.
V>Т.е., прикладной контракт при вызове select протягивать банально некуда.
Вот тут я перестал понимать что и куда ты хочешь протянуть.
V>Этот контракт можно попытаться завернуть в саму "лямбду", т.е. манипулировать контрактом при каждом обращении к элементу. V>Получается возврат на круги своя — ноль оптимизаций.
Пока ощущение, что ты что-то наизнанку вывернул. .Select() — и есть контракт, зачем и в какую лямбду его заворачивать?
V>Берем другую технику — накручиваем контракт поверх самих "коллекций", мол, тогда функциональность "контракта" работает однократно. V>Здесь спотыкаемся о необходимость стирания типов. V>Т.е., если типы не стирать, то комбинаторный взрыв из более-менее полной библиотеки оперируемых контрактов быстро улетит в бесконечность. V>А если типы стирать, то всегда будет лишний боксинг.
Ты сейчас опять с кем-то у себя в голове разговаривал? )
V>Собсно, подробно на всё это я уже отвечал, но ты мне почему-то отписывался совсем по другому поводу.
Потому что твой ответ выглядит как поток сознания, имеющий мало отношения к делу.
IB>>Даже если бы тебе удалось придумать способ, который в десять раз быстрее чем то, что предложил Антон, то это все равно бы доказало его позицию. V>При условии, если бы ему удалось придумать способ безопасного обхода массива.
Без всяких условий. Реализация целиком твоя, ему даже думать не надо.
V>Я несколько раз говорил это словами (тут же, по-идее, собрались люди, понимающие дотнете, не?) V>Пришлось даже написать в чём проблема, и внятной реакции на это до сих пор не вижу.
Да, в дотнете люди понимают, а вот в твоих тараканах желающих разбираться нет, поэтому и сидишь как дурак, обиженый и всеми не понятый.
Твои разоблачительные посты выглядят как поток сознания, и единственное что удается из них понять, что они про что-то другое. И то, только когда до кода доходит.
V>Да без проблем, если бы такое разделение не нарушало бы прикладной контракт.
Каким образом и какой прикладной контракт оно нарушает?
V>Мои хелперы показали, почему это не линк. ))
Твои хелперы не показали ничего.
V>>>А затем спросил, зачем приписали то, что сделали (а написано было, помимо решения целевой задачи, примерно в 300 раз больше кода) св-вам именно линка? IB>>А теперь вернемся к началу. Что такое "свойства именно линка"? V>Давай вернёмся. V>Это способ маппинга выражений языка запросов на методы объектов или на методы-расширения.
Вот щас совсем суть твоей претензии не ясна. Кто кому и чего по твоему приписывал?
V>Моё мнение тут простое — сам этот способ маппинга НЕ расширяемый, поэтому прикладной контракт "подавать" некуда.
Тебя не устраивает как query comprehension транслируется в вызовы методов, что ли?
Здравствуйте, IB, Вы писали:
V>>Т.е., прикладной контракт при вызове select протягивать банально некуда. IB>Вот тут я перестал понимать что и куда ты хочешь протянуть.
Ты и не понимал.
V>>Этот контракт можно попытаться завернуть в саму "лямбду", т.е. манипулировать контрактом при каждом обращении к элементу. V>>Получается возврат на круги своя — ноль оптимизаций. IB>Пока ощущение, что ты что-то наизнанку вывернул.
Продолжай делиться ощущениями.
IB>.Select() — и есть контракт
Аквариум для рыбок тоже дом, но попугаю в нём неудобно.
Дай предположу — потому что попугай не рыбка?
IB>зачем и в какую лямбду его заворачивать?
Зачем широкий контракт протягивать через узкий?
Действительно!
Хороший вопрос, кстате.
V>>Берем другую технику — накручиваем контракт поверх самих "коллекций", мол, тогда функциональность "контракта" работает однократно. V>>Здесь спотыкаемся о необходимость стирания типов. V>>Т.е., если типы не стирать, то комбинаторный взрыв из более-менее полной библиотеки оперируемых контрактов быстро улетит в бесконечность. V>>А если типы стирать, то всегда будет лишний боксинг. IB>Ты сейчас опять с кем-то у себя в голове разговаривал? )
Ты бы почитал вводную по C#, если уж решил в этом топике отметиться.
V>>Собсно, подробно на всё это я уже отвечал, но ты мне почему-то отписывался совсем по другому поводу. IB>Потому что твой ответ выглядит как поток сознания, имеющий мало отношения к делу.
Так ты почитай, почитай.
Откроешь для себя много интересного.
IB>>>Даже если бы тебе удалось придумать способ, который в десять раз быстрее чем то, что предложил Антон, то это все равно бы доказало его позицию. V>>При условии, если бы ему удалось придумать способ безопасного обхода массива. IB>Без всяких условий.
Это пусть решают более компетентные люди.
А ты пока сиди и пытайся разобраться.
V>>Я несколько раз говорил это словами (тут же, по-идее, собрались люди, понимающие дотнете, не?) V>>Пришлось даже написать в чём проблема, и внятной реакции на это до сих пор не вижу. IB>Да, в дотнете люди понимают, а вот в твоих тараканах желающих разбираться нет, поэтому и сидишь как дурак, обиженый и всеми не понятый.
"Тараканы", "дурак", "обиделся", "потоки сознания"...
Сколько беготни-то от простых вещей.
Вот простой код:
int _x;
public int x => (_x++)/100;
...
from d in data select (d[-x, 0] + d[x, 0] + ...
Судя по твоей реакции, ты его либо ниасилил, либо этот код тебе крайне неприятен.
Ни в том ни в другом признаться духа нет, страдаешь аки капризное тепличное растение.
IB>и единственное что удается из них понять, что они про что-то другое. И то, только когда до кода доходит.
Очевидно, что ты не понял вообще ничего, если продолжаешь заполнять паузу бесполезным трёпом.
Будь мужиком, скажи прямой речью: "я не понимаю, в чём заключается проблема в приведенном сниппете".
Поржом да разойдёмся.
Здравствуйте, IB, Вы писали:
V>>Инфа для чебурашек из далёких стран о правилах нашего мира: V>>- когда по рылу в ответ, то не считается. IB>Ты допрыгни сначала, чтоб в ответ...
Здравствуйте, vdimas, Вы писали:
V>Expression<Func<TSource, TResult>> selector V>vs V>Func<TSource, TResult> selector
V>В первом случае компилятор вернет дерево выражений, а во втором сгенерит код.
Да, но в обоих случаях программист напишет одну и ту же лямбду.
Здравствуйте, vdimas, Вы писали:
V>>>Это разные вещи. I>>Ты упорный нечитатель. Одно высказывание от ИТ, второе — как его понял alex_public.
V>Даже не берясь судить, что Алекс имел ввиду, его утверждение является истинной.
Это блеск!
V>>>- ввиду того, что лямбды унутре выполнены как обычные объекты-замыкания, Y-комбинатор не нужен, достаточно обычной рекурсии в методе такого объекта. V>>>Шах и мат. )) I>>Покажи код, как без Y-комбинатора писать рекурсию в лямда-выражениях.
V>Я правильно понял твой вопрос, что ты хочешь посмотреть на некий гипотетический синтаксис выражений linq и соотв. сгенерённый компилятором объект-замыкание?
Нет, конечно. Я говорю о фактическом положении дел и о причинно-следственных связях. То есть, поскольку C# не умеет такую рекурсию иначе как через Y-комбинатор, следствием является отсутствие внятного реализации CTE.
То есть, все просто — никто не хочет мучиться, выписывая непойми что. И причина никак не в Linq.
I>>Ради чего ты тужился тогда ? "Я тоже так могу" ?
V>Там чёрным по-белому написано ради чего — посмотреть, насколько это практично. V>Из-за двух лишних уровней косвенности описания, делающих невозможным автовывод типа делегата — получается абсолютно не практично.
То есть, тебе понятно, что причина не в LINQ, а в компиляторе ?
Здравствуйте, Ikemefula, Вы писали:
V>>Даже не берясь судить, что Алекс имел ввиду, его утверждение является истинной. I>Это блеск!
Это как "устами младенца ..." и далее про тексту.
Так бывает.
I>>>Покажи код, как без Y-комбинатора писать рекурсию в лямда-выражениях. V>>Я правильно понял твой вопрос, что ты хочешь посмотреть на некий гипотетический синтаксис выражений linq и соотв. сгенерённый компилятором объект-замыкание? I>Нет, конечно.
Тогда ты тоже лишь бесполезно трепешься.
I>Я говорю о фактическом положении дел и о причинно-следственных связях.
Без обсуждения технических подробностей, это примерно как лбом об пол возле иконы стучать.
Можешь стучать сколь угодно громко, толку будет ноль.
I>То есть, поскольку C# не умеет такую рекурсию иначе как через Y-комбинатор, следствием является отсутствие внятного реализации CTE.
C# умеет обычную рекурсию, этого достаточно.
С++ тоже умеет, поэтому рекурсивная лямбда на ём тривиальна:
std::function<int (int)> foo = [&foo](int k) {
return k == 1 ? 1 : k + foo(k-1);
};
I>То есть, все просто — никто не хочет мучиться, выписывая непойми что.
И что тебе непонятно в этой записи?
Func<int, int> foo = (int k) => {
return k == 1 ? 1 : k + foo(k-1);
};
Хотя видно, что вызова лямбды нет до окончания определения переменной.
I>И причина никак не в Linq.
Не отмазывайся. ))
Linq генерит теля лямбд.
САМ!
Хреново генерит.
И так во многом в C#.
Взять даже банальные IReadOnlyDictionary<>, IReadOnlyollection<>.
Не прошло и 10-ти лет как выяснилось, что нужны были именно они в кач-ве интерфейсов, а не IDictionary и не ICollection, которые теперь как гиря на ногах.
V>>Там чёрным по-белому написано ради чего — посмотреть, насколько это практично. V>>Из-за двух лишних уровней косвенности описания, делающих невозможным автовывод типа делегата — получается абсолютно не практично. I>То есть, тебе понятно, что причина не в LINQ, а в компиляторе ?
То есть ты ерунду продолжаешь говорить, сорри.
Я уже всё показал, вроде бы.
Здравствуйте, Sharov, Вы писали:
V>>В первом случае компилятор вернет дерево выражений, а во втором сгенерит код. S>Да, но в обоих случаях программист напишет одну и ту же лямбду.
Но двух таких разных случаев вынужден будет написать две копипасты. ))
Здравствуйте, vdimas, Вы писали:
S>>Да, но в обоих случаях программист напишет одну и ту же лямбду.
V>Но двух таких разных случаев вынужден будет написать две копипасты. ))
Здравствуйте, Sharov, Вы писали:
S>>>Да, но в обоих случаях программист напишет одну и ту же лямбду. V>>Но двух таких разных случаев вынужден будет написать две копипасты. )) S>Не понял...
Я говорю — нет повторного использования кода.
Каждый такую лямбду надо будет писать заново.
Поэтому, такая же она или чуть отличается — уже не принципиально.
Здравствуйте, vdimas, Вы писали:
V>- ср-ва для обхода ограничения на рекурсию лямбд в языке есть — это известный Y-комбинатор. V>- язык запросов linq вполне мог бы реализовать его прозрачно для программиста... но! даже этого не требуется! V>- ввиду того, что лямбды унутре выполнены как обычные объекты-замыкания, Y-комбинатор не нужен, достаточно обычной рекурсии в методе такого объекта.
Для записи рекурсивной лямбды на C# никакие Y-комбинаторы не нужны. Достаточно написать так:
Если данный стандартный способ "почему-то" не подходит для использования в Linq и для него требуется притаскивать кривую хрень из лямбда-исчисления под названием Y-комбинатор, то это означает только лишь проблемы в устройстве Linq, а не какие-то проблемы с рекурентными лямбдами в C#.
Кстати, этот самый Y-комбинатор задаётся в C++ в одну строчку:
auto f=y<int>([](auto n, auto self){
if(n<2) return 1;
return n*self(n-1);
});
что очевидно и менее удобно и менее эффективно (ещё больше std::function), чем вариант выше.
Современный C++ позволяет реализовать ещё одно интересное решение, с близким внешне подходом:
auto f=[](auto n){
auto impl=[](auto n, auto self){
if(n<2) return 1;
return n*self(n-1, self);
};
return impl(n, impl);
};
здесь код стал ещё чуть менее красивым, зато он намного эффективнее чем все предыдущие, т.к. вообще нет косвенности от std::function/делегатов, плюс он остался обобщённым (f — в последнем примере является полиморфной лямбдой). Т.е. здесь хотя бы есть какая-то польза от усложнения записи.
P.S. А вообще я удивляюсь твоему желанию тратить время на некоторых бесполезных персонажей данного форума.
_>Если данный стандартный способ "почему-то" не подходит для использования в Linq и для него требуется притаскивать кривую хрень из лямбда-исчисления под названием Y-комбинатор, то это означает только лишь проблемы в устройстве Linq, а не какие-то проблемы с рекурентными лямбдами в C#.
_>Кстати, этот самый Y-комбинатор задаётся в C++ в одну строчку: _>template<typename T> function<T(T)> y(function<T(T, function<T(T)>)> f) {return bind(f, placeholders::_1, bind(y<T>, f)); }
На С++14 можно просто через auto.
_>Современный C++ позволяет реализовать ещё одно интересное решение, с близким внешне подходом: _>auto f=[](auto n){
хаха
С тобой спорить не интересно, бо спора не получается, драмы нет. ))
_>P.S. А вообще я удивляюсь твоему желанию тратить время на некоторых бесполезных персонажей данного форума.
Здравствуйте, Sharov, Вы писали:
V>>Я говорю — нет повторного использования кода. V>>Каждый такую лямбду надо будет писать заново. S>Лябды идентичны, зачем заново?
Здравствуйте, vdimas, Вы писали:
_>>Для записи рекурсивной лямбды на C# никакие Y-комбинаторы не нужны. Достаточно написать так: V>Ага, именно это же я это рядом и написал: V>http://www.rsdn.org/forum/dotnet/7199059.1 V>И по плюсам тоже.
О, и даже в качестве примеров тот же факториал... Забавно. ))) Я этого твоего сообщения не видел, когда своё писал. Надо было мне подождать до вечера и тогда бы можно было вообще ничего не писать. )))
_>>Кстати, этот самый Y-комбинатор задаётся в C++ в одну строчку: _>>template<typename T> function<T(T)> y(function<T(T, function<T(T)>)> f) {return bind(f, placeholders::_1, bind(y<T>, f)); } V>На С++14 можно просто через auto.
Если ты про возвращаемое значение, то не получится, потому как bind выводит свой тип из параметров, а там опять же "y" стоит — получается кольцо. Но в данном случае это не принципиально, т.к. auto здесь только для сокращения записи было бы.
Здравствуйте, alex_public, Вы писали:
_>Для записи рекурсивной лямбды на C# никакие Y-комбинаторы не нужны. Достаточно написать так:
Ну, начнем с того, что это не рекурсивная лямбда, в строгом понимании рекурсии. Для того, чтобы быть рекурентной, функция должна вызывать саму себя, а здесь функция вызывает делегат, в котором содержится переменная со ссылкой на функцию. Это может выглядеть как пустая формальность, но в сложных сценариях возможны забавные эффекты... Но это так, мелочи.
Напомню, в оригинале требовалось написать рекурсивную лямбду в одно выражение. Здесь два.
То есть диалог опять выглядит следущим образом:
— Для записи лямбды в одно выражение нужен Y-комбинатор, это неудобно.
— Можно и без, вот же, но если ваш линк так не умеет, то это он виноват.
— Здесь два выражения, и причем тут линк?
Ну и кто здесь пытается доказать что-то странное?
_>Если данный стандартный способ "почему-то" не подходит для использования в Linq и для него требуется притаскивать кривую хрень из лямбда-исчисления под названием Y-комбинатор, то это означает только лишь проблемы в устройстве Linq, а не какие-то проблемы с рекурентными лямбдами в C#.
Я могу еще раз повторить, что и в linq данный способ подходит, он не подходит по условиям задачи. Могу еще раз ссылочки на статьи дать, где рассказывается про сложности с рекурсивной лямбдой в выражении, в C#, если в прошлый раз прочитать не получилось. Напоминаю, в C#, не в linq.
_>P.S. А вообще я удивляюсь твоему желанию тратить время на некоторых бесполезных персонажей данного форума.
Действительно, вопросы неудобные задают, на ошибки указывают, к формулировкам докапываются — что за люди?
Здравствуйте, vdimas, Вы писали:
V>Ты и не понимал.
Да уж куда мне... =) Но видишь ли в чем дело — это не моя проблема, а твоя. Это ты не в состоянии свою мысль внятно и развернуто донести.
Ну а раз не можешь — сиди и отбрехивайся... Хотя и это у тебя что-то не очень получается )
V>Будь мужиком, скажи прямой речью: "я не понимаю, в чём заключается проблема в приведенном сниппете".
Так я тебе прямо сразу и сказал — ты пишешь полную хрень, которую невозможно понять. Кто мужик? Я мужик! =)
Более того, ты не в состоянии ответить ни на один уточняющий вопрос. Все попытки выяснить что же ты имеешь ввиду, приводят к хамству и оскорблениям. Вот и сейчас — ни на один вопрос внятно не ответил, только нахамил.
Блестяще перевел разговор из технической области на личность собеседника, но тут тебе тоже ничего не светит Интересно, как быстро ты меня в гости пригласишь в этот раз? ))
V>Поржом да разойдёмся.
Я уже давно ржу и расхожусь
Мы уже победили, просто это еще не так заметно...
Это блеск!
