_>>Тебе уже несколько человек приводили разные конкретные примеры, демонстрирующие случаи, в которых SQL подход будет бесполезен, а MapReduce спокойно работает.
IB>Вот вы опять делаете вид, что не понимаете вопроса. MapReduce — это механизм, SQL — это язык запросов. SQL можно использовать, чтобы работать поверх MapReduce. Зачем в MR что-то еще помимо SQL?

я насчитал 8 попыток с примерами тебе показать что SQL не может описать и малой доли того, что может мап-редюс. по моему это сигнальчики обратиться за специализированной помощью.

мап-редюс нужен, что бы посчитать кол-во котэ на картинках в папочке. так понятней ?

Gt_

Здравствуйте, Sinclair, Вы писали:

_>>Так а я не понял, что собственно ты предлагаешь в данной ситуации? Вот смотри, я при решение подобных задач следую достаточно простому плану:
_>>1. смотрю есть ли готовая реализация в какой-то библиотек (ну например тот же Eigen) и если есть, то использую её.
_>>2. если готовой реализации нет, то пишу сам. Но не обобщённую библиотеку, а решение конкретной задачи (и соответственно записываю просто через for).
_>>А что предлагаешь ты сделать во втором случае со своим подходом? Ты предпочтёшь заняться написанием своей обобщённой реализации со сложным метапгораммированием как в Eigen (или же со сложным рантаймовым разбором AST на Link, что по сути почти тоже самое, только медленнее)? Ты понимаешь насколько порядков дольше будет решаться наша конкретная задача при таком подходе?
S>Алгоритм решения более-менее любой задачи примерно одинаков:
S>- пишем максимально понятный и короткий код. Особенно — если алгоритм, с которым мы работаем, достаточно сложен.

Это и будет тот самый тупой for в лоб.

S>- добиваемся корректности этого кода. Например, приведённый код для вычисления средних значений неверен — он теряет "крайние" элементы массива, и неверно обрабатывает переполнения. Достаточно напороться на четыре соседа по одному миллиону, чтобы на выходе получить отрицательное значение "среднего".

Этот пункт по умолчанию подразумевается во всех возможных подходах, так что его явная запись в нашей дискуссии — это просто бесполезная потеря времени.

S>- только после того, как корректность задачи достигнута, и экспериментально обнаружена недостаточная производительность, начинаем оптимизацию. При этом у нас всегда есть baseline-реализация, с которой мы можем сравнивать наши результаты, чтобы случайно не потерять корректность в результате оптимизаций.

Угу, меняем в нашем for арифметические операторы языка на интринсики для SIMD оптимизации или добавляем OpenACC директивы для ускорения на GPU.

S>- при прочих равных, оптимизации не должны затрагивать "основной" код, т.е. мы оптимизируем не "цикл", а функцию Select.
S>Это позволяет нам сохранить maintainability кода — когда через год нам придётся вернуться к задаче, мы сможем оперативно изменить логику, не теряя корректности.

Эм, а откуда у нас вообще взялась работающая функция Select? Напомню, что мы говорим о случае, когда готовой библиотеки алгоритмов нет и надо писать всё самому.

Или быть может ты реально считаешь, что идея написать ручной рантаймовый разбор AST — это и есть "пишем максимально понятный и короткий код"?

_>>Вообще то быстродействие генератора SQL'я — это вопрос актуальный далеко не для всех задач (т.к. разницу в быстродействие можно понять только на очень быстрых запросах, на которых время генерации sql строки и обработки результата оказывается сравнимым со временем исполнения запроса в СУБД). Но если уж заниматься им, то очевидно что все варианты linq к СУБД имеют существенные накладные расходы в сравнение со статическими генераторами (типа sqlpp11). Причём виновата в этом как раз реализация Linq.
S>Вы опять не понимаете значение слова "быстродействие". Задача не в том, чтобы быстро генерировать SQL. А в том, чтобы получающийся SQL был быстрым. Пользователя интересует полное время исполнения запроса. Поэтому если мы можем потратить 100мс на оптимизацию SQL, но выиграть в стоимости его исполнения 500мс, то надо так и делать. А не говорить "ой, но 100мс — это жуткие накладные расходы, я лучше просто склею строки и пусть там СУБД разбирается".

Если говорить об оптимизаторах SQL (это отдельная тема, ортогональная генераторам SQL по DSL), то мне не очень понятно почему ты считаешь, что они возможны только в реализации через Linq? Это помимо того, что есть большой вопрос в необходимости подобных оптимизаторов вне СУБД.

_>>Если делать по настоящему (с анализом AST, а не с лямбдами, как ты показал), то да, возможно и получится что-то приличное. Правда из-за существенных накладных расходов в рантайме оно будет иметь смысл только при работе с очень тяжёлыми задачами (в то время как Eigen будет всегда быстрее обычного кода, т.к. не имеет накладных расходов). А в варианте с лямбдами во-первых не получится ничего похожего, а во вторых там Linq был вообще ни к чему.
S>Анализ AST нужен не сам по себе, а для конкретной прикладной задачи. Например, в linq2db он позволяет выполнять трансформации запроса таким образом, чтобы СУБД не умерла. Любой идиот может скомбинировать две проекции вот так:
S>

S>select Id from (select Id, LastName, OrderCount from (Customers left outer join (select CustomerID, Count(OrderID) from Orders group by CustomerID) on Customers.ID == CustomerID)
S>

S>При этом ни одна известная мне СУБД не догадается скипнуть indexScan, group by и Join. По примерно тем же причинам, которые на дают дотнетовому JIT особенно развернуться в оптимизациях.
S>А вот взрослый движок в сервере приложений запросто может обнаружить семантическую эквивалентность, и на сервер уедет
S>

S>select Id from Customers
S>

Так некий абстрактный "взрослый движок в сервере приложений" в теории "может" это обнаружить или же есть конкретный движок, который вот таких образом на практике оптимизирует вот этот конкретный пример?

S>При этом надо понимать, что такая "странная" проекция, сформулированная в исходной задаче, возникает вовсе не из-за того, что программист — тупой. А, например, из-за того, что внутрненний запрос порождается в одном модуле, написанном в 2014 году командой из Испании, а внешний запрос из него строится совсем в другом модуле, который пишет команда в Сингапуре. И заставлять сингапурскую команду забить на повторное использование кода и вручную писать SQL вплоть до конкретных таблиц — контрпродуктивно. Во-первых, у них и так есть чем заняться, а во вторых это стрельнет нам ещё через год, когда испанская команда выкатит своё обновление, сохраняя, естественно, все внешние контракты.
S>Тут-то и разъедется весь "высокооптимизированный" код, написанный поклонниками идеи "я просто пишу свой собственный цикл".

Ну на мой взгляд это естественно полный бред, но я пожалуй не буду особо спорить в этом направление, т.к. далёк от реалий энтерпрайзной разработки — возможно там действительно подобное считается нормой.

_>>А по поводу AST речь была о другом. Ты вот сам называешь это хардкором, но при этом похоже предлагаешь всем заниматься написанием подобного. Или ты считаешь, что есть готовые реализации под всех существующие алгоритмы? Но в данной дискуссии мы не смогли найти готовое решение даже для банального двоичного поиска...
S>Я не согласен с вашим подходом к решению задач. Вы пишете в стиле Форт: снизу вверх. "Где тут у вас двоичный поиск"?

Не, я то как раз пишу сверху вниз, благо инструменты с нулевой ценой за абстракцию позволяют создавать произвольные архитектуры не беспокоясь о проблемах с быстродействием.

S>Я предпочитаю писать решения "сверху вниз". Тогда, возможно, и двоичный поиск не понадобится.

А вот ты пытаешься писать решения просто "сверху". И это получается в случае наличия готовых фреймворков, библиотек и т.п. Но при этом в случае отсутствия таковых и в силу наличия привычки такого написания резко наступает ступор. Как это случилось с банальным примером двоичного поиска в массиве целых чисел — ведь его правильный (с разбором выражения предикатов и т.п.) код для Linq так и не появился в данной темке...

_>>Ну давай глянем на пример работы какого-нибудь известного Linq к СУБД (на конкретный код генерации SQL по AST) и увидим есть там рефлексия или нет. И выполняется ли весь процесс нуля каждый раз или нет.
S>Вы опять путаете интерфейс и реализацию. В самом Linq обязанности использовать рефлексию нету — я показал вам пример кода, который выполняет усреднение элементов вообще без рефлексии.

Да, но мы это уже обсудили — Linq там не нужно вообще. Т.е. от него там ровно 0 пользы и тоже выражение через лямбду (собственно у тебя там по факту и есть просто извращённая запись вызова лямбды) будет выглядеть даже лаконичнее.

S>А вот здесь

Автор: Sinclair
Дата: 27.06.18

приведён пример кода, который хоть и использует рефлексию, но не требует выполнения процесса каждый раз с нуля.
S>Достаточно добавить в строчку
S>

S>public static T[,] Select<T>(this T[,] source, Kernel<T> kernel) => GenerateFilter(kernel)(source);
S>

S>кэширование, и мы будем получать готовый фильтр по его ядру за O(1):
S>

S>public static T[,] Select<T>(this T[,] source, Kernel<T> kernel) => _cache.GetFilter(kernel, GenerateFilter)(source);
S>

S>Потому что делегат, в отличие от ExpressionTree, один и тот же.
S>(Для того, чтобы покрыть все случаи, придётся незначительно усложнить эту схему — чтобы кэшировать фильтры не по всему делегату, а по указателю на метод. kernel.Target останется свободным параметром).

Собственно опять же отсутствие разбора AST и отсутствие необходимости в Linq (оно здесь опять же исполняет никчемную роль "запускателя лямбд").

Т.е. вот весь этот твой код (кстати довольно любопытный) абсолютно элементарно записывается на C# без использования Linq (но с использованием рефлексии, причём в данном случае ты хорошо показал, как можно оптимизировать её тормознутость). И будет выглядеть даже короче и понятнее.

_>>Глупости какие. Mongo умеет отлично искать во вложенных объектах. Более того, при существенных объёмах это будет ещё и намного быстрее, чем в РСУБД, т.к. мы сможем одним нажатием кнопки распараллелить такой поиск на тысячи ядер.
S>Вы опять предлагаете залить проблему деньгами. Там, где SQL выдаст результат за 200мс на сервере за $2000, вы предлагаете поставить 1000 серверов по $1000.

Опять же глупости — мы же измеряли, что по производительности на одной машине Mongo быстрее классических РСУБД (там же изначально была заточенность на работу в оперативной памяти). Так что 1000 серверов Mongo понадобится только для такой задачи, которую на РСУБД вообще невозможно решить (ну во всяком случае в классическом режиме, не переделывая её в аналог nosql с ручным шардингом).

_>>Ну т.е. в точности подход OpenACC/Numba. ))) Кстати, кинь ссылочку глянуть на реализацию.
S>https://devblogs.nvidia.com/hybridizer-csharp/
S>https://archive.codeplex.com/?p=cudafy

Ну да, тоже самое, только как-то по кривому (зачем-то генерирование отдельных dll, которые потом надо руками подгружать, передавать параметры и т.п., вместо бесшовного соединения CPU и GPU кода).

_>>Ну если ты сделаешь такое решение и при этом оно не будет отставать в производительности от "ручных" аналогов, то все будут только рады. Однако пока что ничего подобного не наблюдается...
S>Мы опять ходим по кругу. Вот пример решения в Video++:
S>

S>// Compute the average of the c4 neighborhood.
S>pixel_wise(relative_access(A), B) | [] (auto a, int& b) {
S>  b = (a(-1, 0) + a(1, 0) + a(0, 1) + a(0, -1)) / 4;
S>};
S>

S>Здесь нет никаких циклов for, никаких OpenCV прагм или SIMD-интринсиков. Тупо лямбда. Плюс визуальный мусор.

Ну так этот пример и не умеет максимальной производительности (достигаемой вручную), а умеет только автовекторизацию компилятора и плюс распараллеливание внутреннего for ( ) по системным потокам с помощью OpenMP. Если бы мы захотели максимально производительности, то пришлось бы записать этот for руками...

S>Сравнивая с

S>// Compute the average of the c4 neighborhood.
S>B = from a in A select (a[-1, 0] + a[1, 0] + a[0, 1] + a[0, -1]) / 4
S>

S>я вижу только ухудшение читаемости. При этом от "ручного аналога", написанного на том же C#, этот код не отстаёт.

А это буквально тоже самое, что и абзацем выше, только зачем-то в ненужной Linq обёртке. Если записать всё тоже самое так (без всякого Linq):

B = map2d(A, a=>a[-1, 0] + a[1, 0] + a[0, 1] + a[0, -1]) / 4);

то будет намного симпатичнее.

Здравствуйте, IB, Вы писали:

_>>Ну так если это очевидное "грязное" решение по написанию рекурсивных лямбд так же элементарно подходит и для linq, то тогда почему поддержка CTE появилось только на днях и только в одной (далекое не самой популярной) Linq библиотеке?
IB>Потому что грязное и неудобное.

Т.е. поддержка CTE в linq2db сделана грязно и неудобно, я правильно тебя понял? )

_>>Так а если кто-то уже пострадал и написал, то уж тогда то пользователю разницы нет, правильно? )
IB>То что написано для всех, называется linq. А так, каждому пользователю, приходится писать самому, свой собственный велосипед.

Мда, как ты ещё мало видел. ))) Похоже что за пределы мирка C#-Linq-SQL и не заглядывал...

Здравствуйте, IB, Вы писали:

_>>А это что по твоему?
IB>Это предложение бесплатно поработать.
_>>Тебе уже несколько человек приводили разные конкретные примеры, демонстрирующие случаи, в которых SQL подход будет бесполезен, а MapReduce спокойно работает.
IB>Вот вы опять делаете вид, что не понимаете вопроса. MapReduce — это механизм, SQL — это язык запросов. SQL можно использовать, чтобы работать поверх MapReduce. Зачем в MR что-то еще помимо SQL?
_>> Но ты продолжаешь говорить что ответ на вопрос нет.
IB>Потому что его таки нет. Вы отвечаете не на то что спрашивают, а на то что удобно отвечать. Ну и зачем тогда вообще тратить на тебя время при таком твоём подходе к общению?

М-да... Я смотрю ты продолжаешь прикидываться идиотом, лишь бы не признавать очевидного. Не вижу смысла продолжать этот разговор, т.к. ты руководствуешься в нём не техническими аргументами, а желанием защитить свою точку зрения, даже если всем (включая наверное уже и тебя самого) очевидно, что она не верна.

Здравствуйте, alex_public, Вы писали:

_>Здравствуйте, IB, Вы писали:

_>>>Ну так если это очевидное "грязное" решение по написанию рекурсивных лямбд так же элементарно подходит и для linq, то тогда почему поддержка CTE появилось только на днях и только в одной (далекое не самой популярной) Linq библиотеке?
IB>>Потому что грязное и неудобное.

_>Т.е. поддержка CTE в linq2db сделана грязно и неудобно, я правильно тебя понял? )

Ну белый зверек, по моему кто-то выдергивает слова из контекста.

Здравствуйте, alex_public, Вы писали:

S>>Сравнивая с

S>>// Compute the average of the c4 neighborhood.
S>>B = from a in A select (a[-1, 0] + a[1, 0] + a[0, 1] + a[0, -1]) / 4
S>>

S>>я вижу только ухудшение читаемости. При этом от "ручного аналога", написанного на том же C#, этот код не отстаёт.

_>А это буквально тоже самое, что и абзацем выше, только зачем-то в ненужной Linq обёртке. Если записать всё тоже самое так (без всякого Linq):
_>

_>B = map2d(A, a=>a[-1, 0] + a[1, 0] + a[0, 1] + a[0, -1]) / 4);
_>

_>то будет намного симпатичнее.

То есть, теперь дело исключительно в симпатичности, то есть, вкусовщине ? Совсем недавно ты утверждал, что Linq обваливает производительность потому что якобы вводит рефлексию. Оказалось, что это совсем не так.

Здравствуйте, alex_public, Вы писали:

_>Т.е. поддержка CTE в linq2db сделана грязно и неудобно, я правильно тебя понял? )
Такое циничное передергивание, верный признак того, что по делу сказать больше нечего )


_>Мда, как ты ещё мало видел. )))
Вот вот, переход на личности тоже )

Здравствуйте, alex_public, Вы писали:

_>М-да... Я смотрю ты продолжаешь прикидываться идиотом, лишь бы не признавать очевидного.
=) Я вижу, вы делаете все, лишь бы не ответить на прямо поставленый вопрос.

_>Не вижу смысла продолжать этот разговор, т.к. ты руководствуешься в нём не техническими аргументами,
До технических аргументов мы даже не дошли, потому что вы все время пытаетесь ответить не на то о чем спрашивают.


_>а желанием защитить свою точку зрения, даже если всем (включая наверное уже и тебя самого) очевидно, что она не верна.
Да, только этим я и могу объяснить ваше странное упорство )

Здравствуйте, IB, Вы писали:

_>>а желанием защитить свою точку зрения, даже если всем (включая наверное уже и тебя самого) очевидно, что она не верна.
IB>Да, только этим я и могу объяснить ваше странное упорство )

Тут стоит посмотреть, от чего отталкивается alex_public, он это повторяет в разных сообщениях явно и не явно.

Возникает ощущение, с его слов, что экономика проекта это вещь недостойная рассмотрения. Единтсвенно, что стоит рассмотрения, это производительность и расход ресурсов. Других критериев эффективности он не учитывает. Подход к разработке в его понимании не зависит от бюджета — сначала задау эстимируем, а потом пилим столько, сколько нужно. Архитектуру у него "получается" продумать лет на 10 вперёд. И любую вещь можно ускорить на низком уровне.
Это все с его слов в разных сообщениях в разное время.

Соотсветсвенно, если применить это "на практике", выходит, что императивный низкоуровневый подход действительно единственно возможный вариант. На самом деле это действительно работает, кто бы спорил — любой кусок кода можно доработать для частного случая руками и ускорить от процентов до сотен и тысяч процентов. Хоть в БД, хоть на клиенте.

Все аргументы, скажем, Синклера, они про экономику проекта на самом деле — опимизировать так, как предлагает alex_public, слишком дорого и непредсказуемо.

Соответсвенно, у него не бывает неожиданных изменений требований, потому что он де выдал архитектурное решение на 10 лет вперёд и аргмент "каждый первый случай модификации структуры" для него просто пустой звук.

Почему так выходит ? Потому что экономика не учитывается, она отдельно от всего остального.

На самом деле то, о чем говорит alex_public действительно было в разработке, в 90е и где то даже в начале нулевых — понавставляли ассемблерных вставок и всякой низкоуровневой механики и всё стало классно.

Именно поэтому Linq это неэффективная вещь — руками можно выжать больше. А сколько это времени займет и какой будет майнтенанс — дело десятое, экономика не в счет. Раз нету проблемы с архитектурой, то можно и строчки склеивать. Соответсвенно преимущество Linq в плане разделение концепций никакое не преимщуство.

В целом он тащит эти манты из сообщения в сообщение. До кучи уже отдельные особенности, где alex_public называет query comprehension Linq, путает реализацию с интерфейсом, видит рефлекцию там где её нет и до кучи начинает обвинять собеседника в чем угодно.

В целом же, если сделать вот те предположения, получается вполне себе стройная картинка. Другое дело, что прогресс лет двадцать назад пошел совсем по другому пути. А то бы и писали по сей день на плюсах с ассемблерными вставками и даже БД программировали так же — в реквест уходил бы С++ или сами ассемблерные вставки.
А что, вполне логично, если каждый программист это эдакий Developer God или Goddes, то нет никакой проблемы за время 0 написать код любой сложности.

Разница на самом деле в экономической целесообразности. Вот эту часть, возникает ощущение, он как будто или не слышит, или не понимает.

по факту прогресс именно туда и пошел, люди не зацикленные на sql налабали вставки на pure java, нарисовали новые схемы обработки данных, аля мап-редюс, новые форматы хранения и выпихнули чудиков "учитывающих экономику" с их sql из целого ряда задач, от DWH и аналитики до пых-пых страничек.
конечно можно изображать непонимание, но в реальном мире давно sql лишь один из способов работы с данными. при этом в этом мире никто ни кого не заставляет использовать другие подходы. тяжело что-то новое изучить, не используй всю мощь. sql даже в хадупах никто не отобрал.

Gt_

Здравствуйте, Gt_, Вы писали:

Gt_>по факту прогресс именно туда и пошел, люди не зацикленные на sql налабали вставки на pure java, нарисовали новые схемы обработки данных, аля мап-редюс, новые форматы хранения и выпихнули чудиков "учитывающих экономику" с их sql из целого ряда задач, от DWH и аналитики до пых-пых страничек.

Покажешь пример этой самой "вставки на джаве" ?

По факту ты уже не пишешь ассемблерных вставок, хотя твою жабку можно ускорить раз в 10 этими самыми вставками. "Вставки на джаве" в БД как раз возможны благодаря внятным инструментам для разделения концепций. Например, в БД ты можешь использовать функцию, писаную на джава и дотнете. Но ты большей частью не пишешь рукопашную мешанину из всего подряд пополам с бизнеслогикой в таких вот вставках.

Собтсвенно аргументы Синклера именно про это — про отделение мух от котлет ради экономики проекта, а не про сам SQL. Потому, как проект, который в экономику не вписывается, в жизни никогда и не появляется. Ну разве что кастомер придет с бесконечным терпением и таким же бесконечным бюджетом.

Gt_>конечно можно изображать непонимание, но в реальном мире давно sql лишь один из способов работы с данными. при этом в этом мире никто ни кого не заставляет использовать другие подходы. тяжело что-то новое изучить, не используй всю мощь. sql даже в хадупах никто не отобрал.

А разве это кто-то отрицал ? no-sql рулит там, где sql не летает. Но его, no-sql, слишком часто пытаются использовать тотально, вместо sql, под видом 'у нас джойны медленно работали' или 'у нас всё на монге'.

Здравствуйте, IB, Вы писали:

_>>Ну так если это очевидное "грязное" решение по написанию рекурсивных лямбд так же элементарно подходит и для linq, то тогда почему поддержка CTE появилось только на днях и только в одной (далекое не самой популярной) Linq библиотеке?
IB>Потому что грязное и неудобное.

А вот это ты мог бы пояснить примером? Я cte юзал один раз и даже непомню для чего именно.

Gt_>>по факту прогресс именно туда и пошел, люди не зацикленные на sql налабали вставки на pure java, нарисовали новые схемы обработки данных, аля мап-редюс, новые форматы хранения и выпихнули чудиков "учитывающих экономику" с их sql из целого ряда задач, от DWH и аналитики до пых-пых страничек.

I>Покажешь пример этой самой "вставки на джаве" ?

да уже все показывал и детально разжевывал чем функция на дотнете отличается
http://www.rsdn.org/forum/flame.comp/7153190.1


I>По факту ты уже не пишешь ассемблерных вставок, хотя твою жабку можно ускорить раз в 10 этими самыми вставками. "Вставки на джаве" в БД как раз возможны благодаря внятным инструментам для разделения концепций. Например, в БД ты можешь использовать функцию, писаную на джава и дотнете. Но ты большей частью не пишешь рукопашную мешанину из всего подряд пополам с бизнеслогикой в таких вот вставках.

в этой ветке все разжевано, просто до зашоренного разума не доходит. повторяю тот пост

тут декларативный sql, тут с# между ними пропасть и тучи сугубо технического геморроя подружить энжины из разных миров, нихера толком не интегрированных. зачастую это вообще три мира — процедурный t-sql бежит в цикле по курсору из декларативного мира, дергая C# процедуру из мира .net. и в каждом из миров свой синтаксис, свои типы, свои процессы и память.

у спарка же все это жава или скала код, где декларативный и императивный мир гораздо изящней интегрированы вместе в единой jvm.

        Dataset<Row> shit = vars.mapGroups(
                (MapGroupsFunction<Integer, String, String>) (key, values) -> {
                    MyMegaClass mc = new MyMegaClass(key);
                    while (values.hasNext()) {
                        mc.process(values.next());
                    }
                    return mc.toString();
                }, Encoders.STRING()) ;

        datasetCache.cache("shit", shit);

той пропасти в синтаксисе нет, все в одном енжине, где вмешаться можно хоть в кеширование. и работает хоть локально в тесте, хоть на кластере распределившись на сотни узлов.

Здравствуйте, Gt_, Вы писали:

I>>Покажешь пример этой самой "вставки на джаве" ?

Gt_>да уже все показывал и детально разжевывал чем функция на дотнете отличается
Gt_>http://www.rsdn.org/forum/flame.comp/7153190.1

Прошу прощения, но почему это "вставка" ? Я вижу только прямое воздействие на публичный API А, вот, скажем, вставка на ассемблере в языке D (из вики, мои способности писать на асме были утрачены за 20 лет неиспользования)

real tan(real x)
{
   asm
   {
       fld     x[EBP]                  ; // load x
       fxam                            ; // test for oddball values
       fstsw   AX                      ;
       sahf                            ;
       jc      trigerr                 ; // x is NAN, infinity, or empty
                                         // 387's can handle denormals
SC18:  fptan                           ;
       fstp    ST(0)                   ; // dump X, which is always 1
       fstsw   AX                      ;
       sahf                            ;
       jnp     Lret                    ; // C2 = 1 (x is out of range)
       // Do argument reduction to bring x into range
       fldpi                           ;
       fxch                            ;
SC17:  fprem1                          ;
       fstsw   AX                      ;
       sahf                            ;
       jp      SC17                    ;
       fstp    ST(1)                   ; // remove pi from stack
       jmp     SC18                    ;
   }
trigerr:
   return real.nan;
Lret:
   ;
}

I>>По факту ты уже не пишешь ассемблерных вставок, хотя твою жабку можно ускорить раз в 10 этими самыми вставками. "Вставки на джаве" в БД как раз возможны благодаря внятным инструментам для разделения концепций. Например, в БД ты можешь использовать функцию, писаную на джава и дотнете. Но ты большей частью не пишешь рукопашную мешанину из всего подряд пополам с бизнеслогикой в таких вот вставках.

Gt_>той пропасти в синтаксисе нет, все в одном енжине, где вмешаться можно хоть в кеширование. и работает хоть локально в тесте, хоть на кластере распределившись на сотни узлов.

Разумеется, только непонятно, почему ты это вставкой называешь Ты показал пример того, как ты пользуешься готовым разделением концепций, которое тебе команда спарка предложила.

Кстати говоря, для чего ты используешь этот спарк ? Я видел только всякие лайки, статистику и логи разных.

Gt_>>да уже все показывал и детально разжевывал чем функция на дотнете отличается
Gt_>>http://www.rsdn.org/forum/flame.comp/7153190.1

I>Прошу прощения, но почему это "вставка" ?

там вставка итеративных жава команд в декларативную конструкцию спаркового датафрейма. то самое о чем толдычит alex_public, что не надо нас ограничивать куцым декларативным sql из нескольких команд. есть гораздо более прогрессивные варианты, которые ничего не ограничивают и вот прямо сейчас уже дают гораздо большие возможности. например мы подобную конструкцию используем для расчета скорингов. оказалось "стандартный" набор алгоритмов spark ml достаточно куций, но поскольку это не mssql я не ограничен парой sql команд. я могу легко элегантно подключить более мощную ML библиотеку, которая будет работать в том же адресном пространстве, в той jvm. а элегантно это выглядит потому что я не ограничен декларативными конструкциями и могу итеративный код использовать наравне с декларативными конструкциями датафреймов.

I>Кстати говоря, для чего ты используешь этот спарк ? Я видел только всякие лайки, статистику и логи разных.

dwh, аналитика, cкоринги

Gt_

Здравствуйте, Gt_, Вы писали:


Gt_>там вставка итеративных жава команд в декларативную конструкцию спаркового датафрейма. то самое о чем толдычит alex_public,

Я бы поостерегся такое утверждать, потому как он меняет сказаное задним числом и намеренно выражается туманно, чтобы позхже выбрать другой ответ.

Gt_>dwh, аналитика, cкоринги

Спасибо

Здравствуйте, Danchik, Вы писали:

_>>>>Ну так если это очевидное "грязное" решение по написанию рекурсивных лямбд так же элементарно подходит и для linq, то тогда почему поддержка CTE появилось только на днях и только в одной (далекое не самой популярной) Linq библиотеке?
IB>>>Потому что грязное и неудобное.
_>>Т.е. поддержка CTE в linq2db сделана грязно и неудобно, я правильно тебя понял? )
D>Ну белый зверек, по моему кто-то выдергивает слова из контекста.

Хочу сразу заметить, что лично я не придерживаюсь этой точки зрения. Потому как на мой взгляд подход с записью рекурентных лямбд через делегаты/указатели на функции/ещё_что-то_подобное является абсолютно нормальным. Собственно этот подход используется в большинстве языков с наличием лямбд.

Однако мой собеседник придерживается именно такой точки зрения, о чём совершенно однозначно заявил. И я не вижу тут никаких выдёргиваний слов из контекста — цитата выше абсолютно точная и полная, и сделать из неё какие-либо иные выводы невозможно.

Здравствуйте, Ikemefula, Вы писали:

I>А вот это ты мог бы пояснить примером? Я cte юзал один раз и даже непомню для чего именно.
Не CTE грязное, а попытка записать рекурентную лямбду в C# грязная. С CTE все норм.

Здравствуйте, alex_public, Вы писали:

_> И я не вижу тут никаких выдёргиваний слов из контекста — цитата выше абсолютно точная и полная, и сделать из неё какие-либо иные выводы невозможно.
Казалось бы да, невозможно, но вам удалось ) Я писал про рекурсивные лямбды в шарпе, а вы сделали вид, что я пишу про поддержку CTE в конкретной библиотеке, это и есть передергивание.
И такими манипуляциями вы заниматетесь регулярно, что ни как не способствует конструктивному диалогу.

Здравствуйте, alex_public, Вы писали:

_>>>>>Ну так если это очевидное "грязное" решение по написанию рекурсивных лямбд так же элементарно подходит и для linq, то тогда почему поддержка CTE появилось только на днях и только в одной (далекое не самой популярной) Linq библиотеке?
IB>>>>Потому что грязное и неудобное.
_>>>Т.е. поддержка CTE в linq2db сделана грязно и неудобно, я правильно тебя понял? )
D>>Ну белый зверек, по моему кто-то выдергивает слова из контекста.

_>Хочу сразу заметить, что лично я не придерживаюсь этой точки зрения. Потому как на мой взгляд подход с записью рекурентных лямбд через делегаты/указатели на функции/ещё_что-то_подобное является абсолютно нормальным. Собственно этот подход используется в большинстве языков с наличием лямбд.

_>Однако мой собеседник придерживается именно такой точки зрения, о чём совершенно однозначно заявил. И я не вижу тут никаких выдёргиваний слов из контекста — цитата выше абсолютно точная и полная, и сделать из неё какие-либо иные выводы невозможно.

Вот ты переврал: "поддержка CTE в linq2db сделана грязно и неудобно, я правильно тебя понял? )"

Обычная твоя тактика