Здравствуйте, Gaperton, Вы писали:
G>>>"Изменяемое состояние" обычно связывают с отсутствием "чистоты". Связь самая прямая.
L>>Опять какая-то путаница. Понятно, что для мутабельнсости, нужно состояние, т.к. если нет состояния, то и менять нечего. Но у тебя вывод-то дурой: состояния нет, т.к. нет мутабельных операций. Причина со следствие переставлены. G>>>Я не понимаю, что ты в данном случае называешь глобальным состоянием, может быть пояснишь? L>>Поясню: массив, из кторого ты читаешь.
G>У меня никакой "путаницы" нет, я пользуюсь общепринятой терминологией среди функциональщиков. Объясняю.
Отсылки не общепринятую терминологию лучше подкреплять ссылками.
G>Первое. Массив доступен глобально, но "состоянием" он не является, именно потому, что он иммутебельный.
Почему ты ставишь знак равенства м/у состоянием и мутабельностью? Это разные вещи.
G>"Протягивание состояния" — термин, обозначающий общую технику избавления от явного состояния, состоящую в передаче и транформации данных через последовательность вызовов, передаваемых и возвращаемых отдельным параметром через все вызовы.
G>Простейший пример — у меня есть цикл, который суммирует массив во внутренней мутабельной переменной. Она — является состоянием. Как мне от него избавиться? Преобразовать цикл в рекурсию, и передовать значение текущей суммы через параметр функции. Эта переменная — и есть "протянутое состояние".
G>Протяжку состояния можно сделать и неявной, при помощи монад, например, что не меняет сути дела.
Спасибо, капитан очевидность.
G>Но в моем решении нет "протягивания состояния". Ни явного, ни скрытого. Массив не модифицируется, и не "протягивается" через вызовы. Соответственно, он не является никаким состоянием, ни явным, ни "протянутым".
Состояние != мутабельнсости.
G>>>Если да, то ты можешь сгенерировать последовательность индексов, и использовать так, как используют ключи в реляционной БД. Клеишь эти индексы к значениям а, чтобы парами шли. Дальше — джойнами работаешь, схожими приемами, как в SQL. Вообще я затрудняюсь это более понятно объяснить.
L>>Опять не понимаю. Можно кодом?
G>Можно конечно. Чуть позже.
Ok.
G>>>Не слишком эффективно, но сработать должно.
G>>>Что касается построения первых двух множеств — там все еще проще, потому как известна "глубина просмотра" назад на каждой итерации, и она постоянна. Берешь исходный массив, сдвигаешь его, клеишь с исходным, и вперед.
L>>Это и будет "простаскиванием" состояния.
G>Нет, как раз именно это и не является протаскиванием состояния. Протянутое состояние невозможно выразить в терминах comprehensions.
Расшифруй.
G>Вот если я вместо цикла напишу, например, какой-нибудь foldl, и буду транформировать массив на каждом шаге, передавая его изменения с одной итерации на другую — то это будет оно. Протянутое состояние.
Ты именно так и предлагаешь по сути делать. Только это протягивание будет не на этапе fold-а, а переде ним, там где ьы собрался делать склейку. В fold придет уже придет последовательность с нужными данными, но сформированы они как раз будет все через то же протягивание.
Здравствуйте, Геннадий Васильев, Вы писали:
IT>>Where как и любой другой метод Linq — это и есть решение с помощью yield return. Поставь в месте где у тебя foreach arr.Where и получишь с небольшими модификациями практически тоже самое. Там где у тебя yield return будет return true, в остальных местах return false.
ГВ>Хммм... А с состоянием что делать? Может, лучше ты сам покажешь?
static IEnumerable<int> Sample1C(IEnumerable<int> arr)
{
bool first = true;
int prev = 0;
return arr.Where(i =>
{
if (first)
{
first = false;
prev = i;
}
else if (i - prev == 1)
{
first = true;
return true;
}
else prev = i;
return false;
});
}
Всё в точности как у тебя.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Не так просто привязаться к позиции. Например, у нас идут вот такие записи:
ГВ>
ГВ>struct R {
ГВ> DateTime time;
ГВ> int value;
ГВ> bool mark;
ГВ> ...
ГВ>};
ГВ>
ГВ>...в порядке возрастания time. Некоторые содержат true в mark. Когда на вход поступает очередная запись с mark=true (обозначим её r0), нужно выдать на выход "самую старую" запись, пришедшую не ранее, чем за 30 минут. Задача усложняется тем, что совершенно не обязательно, что time будет выравнен по границе минуты, т.е. к индексу уже не привяжешься.
Гена, с индексами было интересней. А тут, т.к. трактовать твою постановку задачи можно довольно широко, предположим, что твоя последовательность сохраняется в базе. Тогда пишем простой запрос:
R trueMark = ...
var q =
from r in db.R
where r.time > trueMark.date.AddMinuties(-30)
orderby r.time descending select r;
var prev = q.FirstOrDefault();
Если способ хранения выбран в памяти, то вместо сортировки и First можно обойтись Last.
В общем, всё это уже становится не интересным. Где не работает Linq я тебе и сам могу сказать. Linq не работает на деревьях и иерархиях, там, где для обработки требуются рекурсивные алгоритмы.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Lloyd, Вы писали:
L>И это еще не конец. Эх, Gaperton, вроде и язык простой и задача простая, а столько ошибок на пустом месте. L>Как же так?
Что ты хотел — императивщина.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Да нет, я как раз именно протягивание состояния имею в виду. А в случае Go, кстати, состояние неплохо заворачивается в горутину. Что ты думаешь, я тут крыльями машу?
Ну, если ты поэтому машешь крыльями, то тебе стоит обратить внимание на Эрланг. Там заворачивание состояния в процесс (==goroutine) ходовая техника, ибо по другому мутабельное состояние заворачивать не то, что-бы низя. А неидеоматично. То есть, в Эрланге практика проектирования такова, что вместо объектов массово применяются процессы.
Вместо подписки на сообщения у нас будут каналы. То есть, вообще ничего писать не надо. Никаких ацких заклинаний.
Y>
Y>List<R> buffer = new List<R> { new R() };
Y>ro.Do(r =>
Y> {
Y> buffer.RemoveAll(rr => r.time - rr.time > TimeSpan.FromMilliseconds(1800));
Y> buffer.Add(r);
Y> })
Y> .Where(r => r.mark)
Y> .Subscribe(r => Console.WriteLine("mark = true at {0}, first within 1800 ms: {1}", r.time.TotalMilliseconds,
Y> buffer[0].time.TotalMilliseconds));
Y>
А это переписываем так. На простых циклах.
buffer := vector.NewIntVector( 0 )
ReceiveMessage: for x := range ro { // Это твой Do
if x.mark { // Это твой where
for i, y := range buffer {
if x.time - y.time >= 30 { // Это условие твоего RemoveAll в лямбде
out <- y; // Это твой Subscribe, который писать в лом
buffer = buffer.Cut( i, len( buffer ) - 1 ) // Это твой RemoveAll
continue ReceiveMessage
}
}
}
buffer.Push( x ) // А это твой BufferPush
}
Как-то так. Длинновато конечно. 9 строк кода против 6. Ай-ай, как у нас линк зарулил. Зато сложность алгоритма с циклом поменьше — не на каждое значение буфер целиком пробегаем на предмет RemoveAll, ловя сложность в N*глубину буфера (либо у тебя там бага с добавлением нового элемента, предполагаю первое).
А все почему? Потому, что стандартная библиотка работы с векторами в Go бедновата. Но мы, не торопясь добавлять в язык пожжержку LINQ, ее дополним. Можно? В чем там твой выигрышь-то по строкам был по сути? Элементы из буфера в одну строку удалаешь, да? Вот такая, значит, функция, должна быть в библиотеке?
func (arr IntVector) Filter( func ( x int ) bool )
И тогда, сталбыть, цикл так станет выглядеть?
buffer := vector.NewIntVector( 0 )
for x := range ro { // Это твой Do
if x.mark { // Это твой where
buffer.Filter( func ( x int ) bool { return x.time - y.time < 30 } ) // Твой RemoveAll
out <- buffer[0]; // Это твой Subscribe, который писать в лом
}
}
buffer.Push( x ) // А это твой BufferPush
}
Ну надо ж. "С циклами" те же самые 6 строк. С минимальным и вполне полезным допилом стандартной библиотеки. Только мозг у неподготовленного читателя в трубочку не сворачивается. И в чем маза?
G>buffer := vector.NewIntVector( 0 )
G>ReceiveMessage: for x := range ro { // Это твой Do
G> if x.mark { // Это твой where
G> for i, y := range buffer {
G> if x.time - y.time >= 30 { // Это условие твоего RemoveAll в лямбде
G> out <- y; // Это твой Subscribe, который писать в лом
G> buffer = buffer.Cut( i, len( buffer ) - 1 ) // Это твой RemoveAll
G> continue ReceiveMessage
G> }
G> }
G> }
G> buffer.Push( x ) // А это твой BufferPush
G>}
G>
continue c меткой отсюда надо убрать. Так — правильно. Получается 8 строк кода, а не 9.
G>buffer := vector.NewIntVector( 0 )
G>for x := range ro { // Это твой Do
G> if x.mark { // Это твой where
G> buffer.Filter( func ( x int ) bool { return x.time - y.time < 30 } ) // Твой RemoveAll
G> out <- buffer[0]; // Это твой Subscribe, который писать в лом
G> }
G> buffer.Push( x ) // А это твой BufferPush
G>}
G>
А это правильно должно выглядеть вот так. С удаленной скобкой. Плохо писать код в веб-браузере, плохо.
Здравствуйте, Gaperton, Вы писали:
G>Ну, короче, подводя промежуточные итоги. Ну, установили мы факт, что записываются циклы при помощи линка через жопу. Ну дальше-то что?
Иди расскажи о своем "факте" в "Декларативное программирование".
Тот над тобой там посмеются.
Linq — это копия хаскелевского прилю.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Gaperton, Вы писали:
G>Ну, короче, подводя промежуточные итоги. Ну, установили мы факт, что записываются циклы при помощи линка через жопу. Ну дальше-то что?
По-моему, все, что ты доказал — это то, что в go с помощью костылей можно съимитировать то, что на linq-е делается просто и красиво.
G>buffer := vector.NewIntVector( 0 )
G>for x := range ro { // Это твой Do
G> if x.mark { // Это твой where
G> buffer.Filter( func ( x int ) bool { return x.time - y.time < 30 } ) // Твой RemoveAll
G> out <- buffer[0]; // Это твой Subscribe, который писать в лом
G> }
G> }
G> buffer.Push( x ) // А это твой BufferPush
G>}
G>
G>Ну надо ж. "С циклами" те же самые 6 строк. С минимальным и вполне полезным допилом стандартной библиотеки. Только мозг у неподготовленного читателя в трубочку не сворачивается. И в чем маза?
Ок, допиливаю и я стандартную библиотеку и добавляем коллекцию, которая при вызове Add итерирует свои элементы начиная с первого (у нас входные данные бесплатно отсортированы ), применяя предоставленный предикат к элементу и если предикат выполняеться, удаляет его, и так до тех пор пока предикат не вернет false. А затем добавляет переданный элемент в конец.
Тогда код запишеться:
var buffer = new SmartBuffer<R>(x, y => x.time - y.time < 30);
ro.Do(buffer.Add(r)).Where(r => r.mark).Subscribe(r => /*Это мой Subscribe, который писать в лом*/);
Ну надо ж. "С LINQ" всего 2 строчки. С минимальным и вполне полезным допилом стандартной библиотеки. Только мозг у неподготовленного читателя в трубочку не сворачивается. И в чем маза?
З.Ы. Почему-то и предполагал что скатиться к оптимизациям.
З.З.Ы. С того времени как я сказал, что мне общаться с тобой не интересно ничего не поменялось...
Luck in life always exists in the form of an abstract class that cannot be instantiated directly and needs to be inherited by hard work and dedication.
Здравствуйте, Lloyd, Вы писали:
G>>Ну, короче, подводя промежуточные итоги. Ну, установили мы факт, что записываются циклы при помощи линка через жопу. Ну дальше-то что?
L>По-моему, все, что ты доказал — это то, что в go с помощью костылей можно съимитировать то, что на linq-е делается просто и красиво.
Не знаю, где ты видишь здесь "костыли". Я вот, например, вижу равное количество строк кода, одинаковый алгоритм, и существенно меньшие требования к подготовке читателя кода с циклами, при большей простоте языка и употребляемых конструкций. Все компактные решения через линк по сути просто переписывают циклы, не выигрывая при этом в выразительности ни капли, в отличии от comprehensions на базе честной ZF-нотации, а наоборот, вызывая у неподготовленного человека заворот мозгов на ровном месте.
То есть, на приведенных примерах, я не вижу, что полезного добавляет линк по сравнению с традиционными решениями. Его минусы — я вижу.
Может быть, примеры не самые удачные? Так приведите удачные.
Здравствуйте, Gaperton, Вы писали:
G>То есть, на приведенных примерах, я не вижу, что полезного добавляет линк по сравнению с традиционными решениями. Его минусы — я вижу.
Ну, мне остается только процитировать тебя же (извини, если не точно): человек либо понимает, либо нет.
Здравствуйте, yuriylsh, Вы писали:
Y>З.Ы. Почему-то и предполагал что скатиться к оптимизациям.
Ничего не скатилось к оптимизациям. Скатилось к вопросу наличия/отсутствия ряда простых функций в стандартной либе.
Y>З.З.Ы. С того времени как я сказал, что мне общаться с тобой не интересно ничего не поменялось...
Не интересно — не общайся, в чем проблема-то? Ты спрашивал вариант с циклом — я привел. Два варианта, в одном из которых показал влияние на результат функции Filter. Что ты так расстроился-то? Ты решив задачу через линк, никакого подвига не совершил — все что ты сделал, это записал цикл необычным образом. От этого в самом деле никакого выигрыша нет .
Здравствуйте, Lloyd, Вы писали:
G>>То есть, на приведенных примерах, я не вижу, что полезного добавляет линк по сравнению с традиционными решениями. Его минусы — я вижу.
L>Ну, мне остается только процитировать тебя же (извини, если не точно): человек либо понимает, либо нет.
Ну да, все правильно. Я совершенно искренне не понимаю, чем такая запись, как в примере выше, лучше цикла. Могу совершенно честно это сказать.
Что-тут понимать-то надо? Мне уж любопытно стало, ты меня заинтриговал. Не объяснишь? Вот прям на этом примере — чем он лучше аналогичного цикла?
Здравствуйте, Gaperton, Вы писали:
L>>Ну, мне остается только процитировать тебя же (извини, если не точно): человек либо понимает, либо нет.
G>Ну да, все правильно. Я совершенно искренне не понимаю, чем такая запись, как в примере выше, лучше цикла. Могу совершенно честно это сказать.
G>Что-тут понимать-то надо? Мне уж любопытно стало, ты меня заинтриговал. Не объяснишь? Вот прям на этом примере — чем он лучше аналогичного цикла?
Напрасный труд, ибо:
человек либо понимает, либо нет
Если не согласен с процитированным, предлагаю найти сообщение, из которого эта цитата, и подискутировать с автором оного. Удачи.
Здравствуйте, Lloyd, Вы писали:
G>>Что-тут понимать-то надо? Мне уж любопытно стало, ты меня заинтриговал. Не объяснишь? Вот прям на этом примере — чем он лучше аналогичного цикла?
L>Напрасный труд, ибо:
Согласен, труд действительно напрасный, мы вот только расходимся с тобой в трактовке причин. Я, честно, глядя на примеры кода, и сравнивая их строка к строке, не могу предположить какие либо разумные аргументы с твоей стороны, чем варианты с линком лучше. Да даже неразумных — тоже предположить не могу. Ибо код совершенно одинаков по своей сути.
L>
L>человек либо понимает, либо нет
L>Если не согласен с процитированным, предлагаю найти сообщение, из которого эта цитата, и подискутировать с автором оного. Удачи.
Почему это — не согласен. Согласен вполне. Это из меня цитата
Здравствуйте, IT, Вы писали:
L>>И это еще не конец. Эх, Gaperton, вроде и язык простой и задача простая, а столько ошибок на пустом месте. L>>Как же так?
IT>Что ты хотел — императивщина.
Я бы попросил! Тот мой код хоть и неправильный, но по своей сути чисто функциональный
Если нам не помогут, то мы тоже никого не пощадим.
