Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Serginio1, Вы писали:
S>>>>Я тебя поправляю. Linq он и для IQuriable и для IEnumerable Linq. V>>>В чём суть поправки? S>> Ты говорил, что Linq для кврябля это не линк.
V>Можно мои дословные фразы?
дравствуйте, alex_public, Вы писали:
_>
Sharov>Linq используется для того, чтобы разделить стратегю исполнения и сам "запрос".
alex_public>Это полная чушь, т.к. для разделения используется банальный делегат, а linq тут не нужно в принципе.
Sharov>Чегой-то? Один интерфейс к данным (select from), а стратегия исполнения разная -- объекты в памяти, бд, xml и т.д.
vdimas > БД, XML — это уже IQueryable, другие перегруженные сигнатуры.
По сути ты не согласен с выделенным?
S>>От тот же Linq только в параметрах не делегаты а System.Linq.Expressions и в зависимости от типа применяется перегрузка операторов. S>>Сам же линк никуда не девался.
V>Всё же, мне сложно отвечать на предложения, посмотренные в форме возражений, когда они не являются возражением к моим утверждениям.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, IB, Вы писали:
V>Коллеги, кто еще не понял, в чём тут проблема: V>
V> int _x;
V> public int x => (_x++)/100;
V> ...
V> from d in data select (d[-x, 0] + d[x, 0] + ...
V>
V>?
В нефиксированном размере ядра, из-за чего unsafe оптимизации через "ограничение каймы" являются некорректными.
Ну, во-первых, давайте посмотрим на то, как выглядит этот код без линка, а с применением любого другого подхода по вашему выбору.
Во-вторых, я бы посмотрел, насколько лучше эту проблему решает video++ из соседнего форума.
В-третьих, не вполне понятен реальный сценарий, в котором на это наступишь.
Ну, то есть пока что все задачки, которые обсуждались на уровне кода, использовали статические ядра.
Так что есть искушение просто запретить такое при исполнении запроса — то есть обнаружив неконстантные выражения в IRelativeAccess<>.get_Item, сразу выкидывать IndexOutOfRange, не дожидаясь проблемы.
Можно сделать наоборот — продолжать применять проверки диапазонов при каждом обращении, кроме доказанно-константных случаев.
Я бы сосредоточился на тех случаях, когда такое реально может потребоваться, и уже там смотрел, какое поведение ожидается.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Serginio1, Вы писали:
S>Sharov>Linq используется для того, чтобы разделить стратегю исполнения и сам "запрос". S>alex_public>Это полная чушь, т.к. для разделения используется банальный делегат, а linq тут не нужно в принципе. S>Sharov>Чегой-то? Один интерфейс к данным (select from), а стратегия исполнения разная -- объекты в памяти, бд, xml и т.д. S>vdimas > БД, XML — это уже IQueryable, другие перегруженные сигнатуры. S> По сути ты не согласен с выделенным?
По сути, я поправил, что речь о разных сигнатурах, т.е. сам линк разный.
Т.е. интерфейс к объектам в памяти не точно такой же как к БД, XML и т.д.
Т.е. в общем случае нельзя повторно использовать выражения из разных миров друг в друге.
(ниже по тому обсуждению более одного раза уже раскрыл, что имелось ввиду, если с первой попытки не совсем ясно выразился)
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Serginio1, Вы писали:
S>>Sharov>Linq используется для того, чтобы разделить стратегю исполнения и сам "запрос". S>>alex_public>Это полная чушь, т.к. для разделения используется банальный делегат, а linq тут не нужно в принципе. S>>Sharov>Чегой-то? Один интерфейс к данным (select from), а стратегия исполнения разная -- объекты в памяти, бд, xml и т.д. S>>vdimas > БД, XML — это уже IQueryable, другие перегруженные сигнатуры. S>> По сути ты не согласен с выделенным?
V>По сути, я поправил, что речь о разных сигнатурах, т.е. сам линк разный. V>Т.е. интерфейс к объектам в памяти не точно такой же как к БД, XML и т.д. V>Т.е. в общем случае нельзя повторно использовать выражения из разных миров друг в друге. V>(ниже по тому обсуждению более одного раза уже раскрыл, что имелось ввиду, если с первой попытки не совсем ясно выразился)
Обычно линк пишется по мету. Если это функции то они и возвращают либо IQueryable либо IEnumrable.
Но это мало где испоьзуется.
Суть то запроса не изменилась. Да внутри вызываются разные методы, а где то вообще как в roslyn-linq-rewrite создается уже реальный код в IL с инлайнингом.
То же может относится и к IQueryable.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Sinclair, Вы писали:
S>В нефиксированном размере ядра, из-за чего unsafe оптимизации через "ограничение каймы" являются некорректными.
Во втором же своём сообщении я про это упомянул.
Потом долго испытывал странную эмоцию из разряда "я один это вижу?" (С)
S>Ну, во-первых, давайте посмотрим на то, как выглядит этот код без линка, а с применением любого другого подхода по вашему выбору.
В коде без линка никто не мешает задавать диапазон обхода непосредственно в алгоритме:
for(y = offset1, end = array.Count - offset2; y < end; y++)
...
Я не фанат конкретно итераций по массивам, бо плюсовики почти все свои алгоритмы пишут обощённо через итераторы, но когда приходилось заниматься обработкой изображений или звука, то почти всегда код "сухой", чуть ли не в духе голого С.
S>В-третьих, не вполне понятен реальный сценарий, в котором на это наступишь.
Сценарий известный — градиент размытия от центра или к центру.
Т.е. в центре самый фокус, по краям самое размытие.
Или наоборот.
S>Ну, то есть пока что все задачки, которые обсуждались на уровне кода, использовали статические ядра.
Это как раз нормально.
Ненормальной была реакция на моё предложение посмотреть на более широкий класс задач.
S>Так что есть искушение просто запретить такое при исполнении запроса — то есть обнаружив неконстантные выражения в IRelativeAccess<>.get_Item, сразу выкидывать IndexOutOfRange, не дожидаясь проблемы.
Тогда ты "займёшь" данную сигнатуру конкретной реализацией.
Впрочем, я уже повторяюсь десятикратно тут...
S>Можно сделать наоборот — продолжать применять проверки диапазонов при каждом обращении, кроме доказанно-константных случаев.
Всё можно.
Пока опять на что-то не напорешься.
Мне как раз разнесение целевого кода от "контракта" сходу и не понравилось, если уж начистоту.
Понятное дело, что запись алгоритма в пару строк — мечта любого программиста.
Но всерьёз если, то под это дело нужны специальные языки.
Под обработку звука я периодически ковыряю свой эксперимент. Но там больше графическая нотация подходит, чем текстовая.
В текстовой форме упираешься сразу в представление параметризации исходного алгоритма — оно чудовищное.
Это таблица со значениями, а лучше эдакий "девайс" с большим кол-вом крутилок.
И чтобы впрямо в реалтайме эти крутилки крутить и слушать, т.е. сосредоточиться не на подробностях реализации эффекта, а на его конкретных параметрах.
Кое-что работающее есть, но это посто хобби.
Я периодически экспериментрирую именно в области разработки языков — то под обработку звука, то под обработку изображений.
Здравствуйте, Ikemefula, Вы писали:
I>Y-комбинатор это Expression. Ты же показал Statement
Анонимную рекурсивную ф-ию создать нельзя.
Если нет имени, то как сослаться на такую ф-ию? ))
Давай присвоим ей имя:
public static class ArrayExtensions
{
public static ArraySegment<T> Slice<T>(this T[] array, int index, int count)
=> new ArraySegment<T>(array, index, count);
}
...
static void Main(string[] args)
{
var source = new int[] { 1, 3, 2, 1, 2, 1, 3 };
IEnumerable<int> func(int i) =>
(i > source.Length - 2)
? source.Slice(source.Length - 1, 1)
: from n in source.Slice(i, 2)
from m in func(i + 1)
select m * n;
foreach (var x in func(0))
Console.WriteLine(x);
}
I>Лямда рекурсивная в виде Expression возможна только и исключительно через Y-комбинатор.
Через Y-комбинатор тоже не всегда удобно, бо подаётся не рекурсивная ф-ия, а обычная, но её сигнатура усложняется за счёт протягивания её же.
Но так-то получается те же яйца вид в профиль — через имя аргумента стало возможно ссылаться на рекурсивную ф-ию по имени.
Тогда уж можно внутри неименованной лямбды сделать именованную и ву а ля.
Здравствуйте, vdimas, Вы писали:
I>>Y-комбинатор это Expression. Ты же показал Statement
V>Анонимную рекурсивную ф-ию создать нельзя. V>Если нет имени, то как сослаться на такую ф-ию? ))
Ключевое слово — Expression. Если в твоем решении statement, то соответсвенно надо писать мануал по применению присваивания. Иногда присваивание унутре допустимо — для Enumerable, иногда — недопустимо, Queryable, иногда — в зависимости от контекста.
I>>Лямда рекурсивная в виде Expression возможна только и исключительно через Y-комбинатор.
V>Через Y-комбинатор тоже не всегда удобно, бо подаётся не рекурсивная ф-ия, а обычная, но её сигнатура усложняется за счёт протягивания её же. V>Но так-то получается те же яйца вид в профиль — через имя аргумента стало возможно ссылаться на рекурсивную ф-ию по имени.
Именно — нужно городить огород.
V>Тогда уж можно внутри неименованной лямбды сделать именованную и ву а ля.
V>
V>Ты просил показать без Y-комбинатора? V>Ну и вот. ))
Цитирую себя "Лямда рекурсивная в виде Expression возможна только и исключительно через Y-комбинатор."
Ты почему то увидел "Y-комбинатор", но забыл про Expression
I>>С твоим подходом придется на ровном месте плодить простыни кода.
V>Поверх целевого кода? V>Не придётся.
Зачем же ты раз за разом приводишь примеры тех самых простынь ? Вероятно, ты утаиваешь какой то секрет — говоришь, что можно без простынь, но везде примеры про простыни
Здравствуйте, Ikemefula, Вы писали:
V>>Анонимную рекурсивную ф-ию создать нельзя. V>>Если нет имени, то как сослаться на такую ф-ию? )) I>Ключевое слово — Expression.
Дудки.
Ключевое — нет имени.
"Трюк" с Y-комбинатором прост до безобразия — он даёт безымянной ф-ии имя.
V>>Тогда уж можно внутри неименованной лямбды сделать именованную и ву а ля. V>>
V>>Ты просил показать без Y-комбинатора? V>>Ну и вот. ))
I>Цитирую себя "Лямда рекурсивная в виде Expression возможна только и исключительно через Y-комбинатор." I>Ты почему то увидел "Y-комбинатор", но забыл про Expression
Ты глаза-то открой, все подробности спрятаны за неименованой ламбдой.
I>Зачем же ты раз за разом приводишь примеры тех самых простынь ?
Здравствуйте, vdimas, Вы писали:
V>И что помешало спросить у Синклера, если не жмёт?
А чего это Антон должен в твоем сумрачном сознании ковыряться?
V>Ну, блин, Семён Семёныч, а что же ты раньше молчал-то?
Гы, я как раз, похоже, единственный, кто не молчит, ну и Антону еще не лень )
V>Я не до конца понимаю, что ему не понятно,
А, так ты у нас тоже не все на свете понимаешь все таки?
V>а он сам колоться не желает, хотя я его и подталкиваю.
Это ты так подталкиваешь? Вот посмотри на другой ответ и поучись как надо )
V>ХЗ, может именно это было не понятно, я не доктор.
Да уж, ты точно не доктор, и в целом кто ты, стало понятно уже давно =)
V>Как много слов вместо простого твоего признания "простите, но я ни хрена не понимаю!"
Ты опять ничего не понял, не "простите, не понимаю", а "достань голову из задницы, и начинай объяснять нормально, а то так и будешь ходить обиженым и униженым"
V>RTFM до просветления!
Опять умные слова не по делу?
Я вообще считаю,что у него светлая голова — одна из самых светлых здесь.
Но в упор не понимаю его регулярные порывы запихать самого себя в какие-то рамки/догмы и пытаться выруливать уже внутри этих рамок.
Тесно же.
И скучно.
V>>Ну, блин, Семён Семёныч, а что же ты раньше молчал-то? IB>Гы, я как раз, похоже, единственный, кто не молчит
Открыл рот — не значит что-то сказал.
V>>Я не до конца понимаю, что ему не понятно, IB>А, так ты у нас тоже не все на свете понимаешь все таки?
Это ты, типа, "поймал" меня на недостаточном понимании чужих тараканов?
Вот уж уделал.
V>>а он сам колоться не желает, хотя я его и подталкиваю. IB>Это ты так подталкиваешь? Вот посмотри на другой ответ и поучись как надо )
А что же ты не ответил как надо?
Форум-то публичный.
Если ты такой знаток чужих душ, дык помог бы человеку, не?
Или всё-таки жмет?
Здравствуйте, vdimas, Вы писали:
V>Для него оно не сумрачное:
Я за него судить не берусь, но уж точно не хочу утруждать его разбираться в том что там из тебя вылетело =)
V>Я вообще считаю,что у него светлая голова — одна из самых светлых здесь.
Это правда, почти как у меня )
V>Но в упор непонимаю его регулярные порывы запихать самого себя в какие-то рамки/догмы и пытаться выруливать уже внутри этих рамок. V>Тесно же. V>И скучно.
Это ты скучный, а Антон интересный =)
V>Открыл рот — не значит что-то сказал.
Да, по тебе это хорошо видно ))
V>Это ты, типа, "поймал" меня на недостаточном понимании чужих тараканов?
Ну ты же ждешь, что твои тараканы будут понимать? Так сделай над собой усилие, разберись в чужих.
V>Вот уж уделал.
Наконец-то ты это понял )))
V>А что же ты не ответил как надо?
Так я тоже не понял, что ты там себе придумал. Я даже до конца не уверен, что ты именно это и имел ввиду... Но разгадывать твои ребусы я точно не нанимался )
V>Если ты такой знаток чужиш душ, дык помог бы человеку, не?
Не, знаток душ это у нас ты, всю правду по фотографии выдаешь, я же даже не претендую )
Здравствуйте, IB, Вы писали:
V>>Я вообще считаю,что у него светлая голова — одна из самых светлых здесь. IB>Это правда, почти как у меня )
У тебя лень ума.
V>>Но в упор непонимаю его регулярные порывы запихать самого себя в какие-то рамки/догмы и пытаться выруливать уже внутри этих рамок. V>>Тесно же. V>>И скучно. IB>Это ты скучный, а Антон интересный
Это тебе, бо ты ленив, — тебе интересней, когда тебе подыгрывают.
V>>Это ты, типа, "поймал" меня на недостаточном понимании чужих тараканов? IB>Ну ты же ждешь, что твои тараканы будут понимать?
Я жду прозрачности ситуации: непонятно — спроси.
Но тебе жмёт.
Здравствуйте, vdimas, Вы писали:
V>>>Анонимную рекурсивную ф-ию создать нельзя. V>>>Если нет имени, то как сослаться на такую ф-ию? )) I>>Ключевое слово — Expression.
V>Дудки. V>Ключевое — нет имени.
Expression это определенные ограничения, которые позволяют легко транслировать код и одновременно внятный конвеншн для сообщества. Кроме того, лямбда это упрощенный синтаксис и связывание по месту требования.
Есть тут имя или нет, дело абсолютно десятое. Но вот для рекурсии все становится иначе — и все ради этого самого экспрешна, что бы легко было анализировать, транслировать, выводить тип и тд и тд.
V>"Трюк" с Y-комбинатором прост до безобразия — он даёт безымянной ф-ии имя.
Спасибо, капитан! Если ты пороешься в этом форуме, то увидишь мои посты про этот Y-комбинатор десятилетней давности, ну или близко к этому.
V>>>Ты просил показать без Y-комбинатора? V>>>Ну и вот. ))
I>>Цитирую себя "Лямда рекурсивная в виде Expression возможна только и исключительно через Y-комбинатор." I>>Ты почему то увидел "Y-комбинатор", но забыл про Expression
V>Ты глаза-то открой, все подробности спрятаны за неименованой ламбдой.
У тебя стейтмент торчит снаружи, а значит надо писать мануал, какие стейтменты можно/нельзя использовать, и отдельно описать присваивания. С экспрешном ничего такого делать не надо.
I>>Зачем же ты раз за разом приводишь примеры тех самых простынь ?
V>Привёди пример короче или слил.
Алё! С текущей версией языка ничего лучше недоступно — об чем и речь. То, что ты показал, никто в своём уме не применяет.
Я эти вещи еще где-то лет десять назад насовал в либу, потом замучился от них избавляться.
Здравствуйте, vdimas, Вы писали:
V>У тебя лень ума.
Опяь диагнозы по фотографии ставишь? =))
V>Это тебе, бо ты ленив, — тебе интересней, когда тебе подыгрывают.
Мне не интересно, когда на пустом месте интригу разводят и играют в загадочнось, чтобы умнее казаться.
V>Я жду прозрачности ситуации: непонятно — спроси.
Начни с себя. Как только будешь разговаривать нормально, тебя сразу чморить перестанут и ясность появится )
Здравствуйте, vdimas, Вы писали:
V>Во втором же своём сообщении я про это упомянул. V>Потом долго испытывал странную эмоцию из разряда "я один это вижу?" (С)
Не было такого. Или сформулировано слишком туманно. Код рулит.
V>В коде без линка никто не мешает задавать диапазон обхода непосредственно в алгоритме: V>
V>for(y = offset1, end = array.Count - offset2; y < end; y++)
V> ...
V>
ну вот опять. Напишите полный код — чтобы было понятно, каким именно волшебным способом мы вычисляем диапазон обхода так, чтобы он гарантировал безопасность.
Тогда уже можно будет поискать возможность обобщить этот способ, не требуя задавать границы вручную. V>Я не фанат конкретно итераций по массивам, бо плюсовики почти все свои алгоритмы пишут обощённо через итераторы, но когда приходилось заниматься обработкой изображений или звука, то почти всегда код "сухой", чуть ли не в духе голого С.
S>>В-третьих, не вполне понятен реальный сценарий, в котором на это наступишь.
V>Сценарий известный — градиент размытия от центра или к центру. V>Т.е. в центре самый фокус, по краям самое размытие. V>Или наоборот.
С размытием вообще подход «с каемкой» в принципе не подходит.
Для него должен использоваться алгоритм усечения ядра. Придётся обрабатывать два случая: стационарный и динамический. Потому, что в стационарном возможно больше оптимизаций; общий подход будет в разы медленнее чем специфический.
S>>Ну, то есть пока что все задачки, которые обсуждались на уровне кода, использовали статические ядра.
V>Это как раз нормально. V>Ненормальной была реакция на моё предложение посмотреть на более широкий класс задач.
Предложения должны быть конструктивными. То есть пишем пример кода — обсуждаем варианты. Пишем хамство — обсуждения нет.
S>>Так что есть искушение просто запретить такое при исполнении запроса — то есть обнаружив неконстантные выражения в IRelativeAccess<>.get_Item, сразу выкидывать IndexOutOfRange, не дожидаясь проблемы.
V>Тогда ты "займёшь" данную сигнатуру конкретной реализацией. V>Впрочем, я уже повторяюсь десятикратно тут...
Надо улучшать не количество ответов, а качество. Потому что непонятно, что такое «конкретная сигнатура» в данном контексте. Пока что видно, что стоит вместо from d писать from d.AsRelative(Bounds.Cut). А короткую сигнатуру задефолтить на самый частый случай.
V>Всё можно. V>Пока опять на что-то не напорешься.
Ну так жить поэтому и интересно. V>Мне как раз разнесение целевого кода от "контракта" сходу и не понравилось, если уж начистоту. V>Понятное дело, что запись алгоритма в пару строк — мечта любого программиста. V>Но всерьёз если, то под это дело нужны специальные языки.
Ну, интересно же, насколько далеко можно зайти в рамках дотнета и шарпа. V>Под обработку звука я периодически ковыряю свой эксперимент. Но там больше графическая нотация подходит, чем текстовая. V>В текстовой форме упираешься сразу в представление параметризации исходного алгоритма — оно чудовищное. V>Это таблица со значениями, а лучше эдакий "девайс" с большим кол-вом крутилок. V>И чтобы впрямо в реалтайме эти крутилки крутить и слушать, т.е. сосредоточиться не на подробностях реализации эффекта, а на его конкретных параметрах. V>Кое-что работающее есть, но это посто хобби.
Ну так и мне за это денег не платят. V>Я периодически экспериментрирую именно в области разработки языков — то под обработку звука, то под обработку изображений.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Пока что видно, что стоит вместо from d писать from d.AsRelative(Bounds.Cut).
Можно, но компилятор не подскажет.
Ведь никогда не стоит вопрос "просто убрать лишний код" (тем более, что убираемый код тривиален).
В кавычках лишь следствие цели.
Целью является "убрать из головы разработчика лишние подробности, дав ему возможность решать задачу на более высоком уровне".
В твоём варианте подобные подробности всё-равно надо держать в голове.
V>>Понятное дело, что запись алгоритма в пару строк — мечта любого программиста. V>>Но всерьёз если, то под это дело нужны специальные языки. S>Ну, интересно же, насколько далеко можно зайти в рамках дотнета и шарпа.
Так и у меня часть системы на шарпе, которая графы визуально строит.
Но там подход чуть другой — на шарпе строится "модель" алгоритма из "кубиков".
Каждый кубик имеет кучу параметров, в том числе тип данных (целый, удвоенный целый, плавающий, удвоенный плавающий).
Параметры можно связывать с константами, с выходами других "кубиков" внутри схемы их, либо с назначеными внешими входами "девайса".
После этого из модели строится код на плюсах, где "объемный" граф объектов превращается в плоский в памяти (все тела объектов "сливаются" в одно тело), виртуальная передача данных через абстрактные "пины" превращается в непосредственную подачу аргументов при вычислениях, все константы распространяются по всем вычислениям, сокращая таким образом объем вычислений в реалтайм.
Участки вычислений, ограничивающие сигнал, тоже "поглощают" друг друга. Грубо, вот есть усечение, потом умножение на больше 1, потом опять усечение — первое усечение является избыточным, оно уходит. При этом усечение сигнала — это одна из самых затратных операций, бо делается через условное ветвление. Как раз перекликается с деталями нашего обсуждения.
Для обработки изображений такой подход тоже вполне — из базовых "операторов" можно было бы составить полный алгоритм, покрутить крутилки, какие-то параметры оставить параметрами, какие-то сделать константами и при генерации конечного результата подобная система сама могла бы отделить код, имеющий дело с "каёмкой", от безопасного основного тела.
Т.е., если уж ставить вопрос насчёт автоматизации детектирования граничных случаев, то эта задача в пределе решается примерно так.
Всё остальное — полумеры. ))
Здравствуйте, IB, Вы писали:
V>>Это тебе, бо ты ленив, — тебе интересней, когда тебе подыгрывают. IB>Мне не интересно, когда на пустом месте интригу разводят и играют в загадочнось, чтобы умнее казаться.
Тем не менее, Синклер вашей братии часто подыгрывает, расплачиваясь за это лишней степенью свободы.
Чудовищная глупость, как по мне.
Это же не политика, в конце концов, а просто технологии.
V>>Я жду прозрачности ситуации: непонятно — спроси. IB> Начни с себя. Как только будешь разговаривать нормально, тебя сразу чморить перестанут и ясность появится )
В том обсуждении, с которого мы несколько месяцев назад зацепились, я общался более чем нормально.
Все ходы записаны, можешь освежить.