Здравствуйте, vdimas, Вы писали:
V>Меня может тоже бесит, что котангес 𝜋 никак не может определиться — он плюс бесконечность или, всё-таки, минус бесконечность.
Что за чушь я только что прочитал? xD
Котангенс не плюс и не минус бесконечность для пай. Он там вообще не определён.
Re[75]: В России опять напишут новый объектно-ориентированны
Здравствуйте, alex_public, Вы писали:
_>Это чушь потому, что хотя сам указанный факт является верным, он при этом ни в малейшей степени не является оправданием подобного подхода в сравнение производительности. Собственно у такого подхода вообще не может быть никаких оправданий, априори. )))
Это зависит от того, как относиться к производительности. Как видно, у нас тут подходы серьезно отличаются:
"Да, в этом трудно поверить тому, кто воспринимает оптимизацию исключительно как выжать ещё пару бит из байта и ускориться аж на пол процента. Для остальных нормальным результатом оптимизации, в частности работы с БД, является ускорение работы приложения в разы. " (с) IT
_>Не развивается значит? )
Конечно нет, что PL/SQL, что TSQL и аналогичные изделия, серьезно не меняются десятилетиями. Хотя сделать из них нормальный язык нет никаких проблем, но просто нет такой потребности.
_> А кто тут совсем недавно хвастался появление возможности выполнения функций на Питоне в СУБД? )))
Во-первых, питон — не PL/SQL, во-вторых, это было сделано для совершенно конкретной задачи — аналитики, отсюда и питон с R, а не что-то другое. Ну и в третьих — все равно этой фичей толком не пользуются.
Мы уже победили, просто это еще не так заметно...
Re[71]: В России опять напишут новый объектно-ориентированны
Здравствуйте, Gt_, Вы писали:
Gt_>я бы постебался,
Чтобы стебаться и не выглядеть глупо, надо хоть немножко в предмете спора разбираться. Так что удачи )
Gt_> да ты же все равно затрешь всю переписку, как с тем oracle problem (tm)
Так там же хамство сплошное было, у вас всегда так, когда аргументы заканчиваются. Но здесь форум не профильный, цензуры нет, так что вперед, если не страшно в ответ огрести )
Gt_>MyMegaClass, spark, hadoop классы это все единая аппликация, которая стартанет в единой jvm и которая будет читать локальный файлик. на каждом узле кластера. в этом вся суть.
Суть понятна, не понятно чем это отличается от сиквела, кроме синтаксиса.
Мы уже победили, просто это еще не так заметно...
Re[71]: В России опять напишут новый объектно-ориентированны
Здравствуйте, alex_public, Вы писали:
_>Как будет выглядеть решение на SQL или Linq? )
В этой задаче необходимо создавать новые данные, а это, как я уже писал, не совсем задача сиквела, его задача — манипулировать существующими. Тем не менее, можно извернуться и на SQL пользуясь особенностями конкретной реализации. Например, так:
SELECT ROW_NUMBER() OVER(ORDER BY name) as id, STRING_SPLIT(REPLICATE(name + ', ', count), ', ') name FROM table
Не, так не правильно, забыл, что STRING_SPLIT табличная функция, а не строковая, правильно так (но сути это не меняет):
SELECT ROW_NUMBER() OVER(ORDER BY [value]) id, [value] [name] FROM table OUTER APPLY string_split(RTRIM(REPLICATE([name] + ' ', [count])), ' ')
или в более каноническом варианте, без приседаний со строками — нужно создать вспомогательную таблицу с порядковыми номерами (это можно делать на лету, используя псевдотаблицу или какую-нибудь служебную), далее простой джойн
SELECT t1.id, t2.name FROM number t1 JOIN table t2 ON t1.id BETWEEN 1 AND t2.count
На линке должно быть еще проще, там есть средства генерации данных, join такой же.
_>Гугл использует BigTable, от которой собственно и зародилось "движение" NoSQL.
Ну а до BigTable они активно гоняли MySQL. Причем, что гугл, что яндекс — не лучший пример в данной дискуссии, так как задачи у них (мы же про поиск?) сильно отличаются от того, для чего предназначался SQL.
Там поиск нужен полнотекстовый, почти нет джойнов и всем крымский мост положить на целостность данных.
_>Что-то ты сам себе противоречишь. Твоя же цитата: " В итоге получилось то что получилось, а Кодд много лет спустя написал статью Fatal Flaws in SQL, где как раз критиковал несоответствие теории и фактической реализации SQL-я в RDBMS".
У нас похоже опять проблемы, с тем кто и что написал. )) Мысль была в том, что не смотря на то, что язык получился кривой, теория на которой он таки базировался, все равно появилась раньше и позволила формально доказать, что кроме этого языка никакого доступа к внутренностям не надо. Иными словами, из того, что язык вышел неудачным, вовсе не следует, что его делали не имея никакой теоретической базы.
Здравствуйте, alex_public, Вы писали:
_>Уже 10 раз (причём включая конкретные примеры) было показано, что множество задач решаемых с помощью SQL является подмножеством задач, решение которых задаётся произвольным императивным кодом.
Да, только все эти задачи удивительным образом лежать за пределами сценариев, для которых SQL предназначен.
_>Потому что кроме указанногo по ссылке решения можно захотеть получить ещё и такое https://en.wikipedia.org/wiki/Apache_Phoenix (кстати, применяется в Cloudera, которая как раз отвоёвывает у РСУБД мир Корпоративных Хранилищ Данных) и такое https://en.wikipedia.org/wiki/Apache_Trafodion (что там говорили про транзакции?) и даже такое https://www.opencypher.org. Причём всё это заводится поверх одного и того же hadoop кластера.
Ну, то есть мы таки наворачиваем SQL и прикручиваем транзакции поверх новомодных хадупов, что и требовалось доказать, собственно ))
Мы уже победили, просто это еще не так заметно...
Re[72]: В России опять напишут новый объектно-ориентированны
Gt_>>я бы постебался, IB>Чтобы стебаться и не выглядеть глупо, надо хоть немножко в предмете спора разбираться. Так что удачи )
ну что бы над тобой постебаться было достаточно знаний первых абзацев из оракловых концептов. вот и сейчас, неужто так сложно пару абзацев о спарке прочесть ?
Gt_>> да ты же все равно затрешь всю переписку, как с тем oracle problem (tm) IB>Так там же хамство сплошное было, у вас всегда так, когда аргументы заканчиваются. Но здесь форум не профильный, цензуры нет, так что вперед, если не страшно в ответ огрести )
ну какой ответ. тебе три раза уже прожували как работает хадуп и в каком процессе исполняется мой код. ты все равно жестко тупишь.
Gt_>>MyMegaClass, spark, hadoop классы это все единая аппликация, которая стартанет в единой jvm и которая будет читать локальный файлик. на каждом узле кластера. в этом вся суть. IB>Суть понятна, не понятно чем это отличается от сиквела, кроме синтаксиса.
я уже разжувал выше, нет той пропасти в синтаксисе какая наблюдается между C#, sql и t-sql, плюс в техническом плане — мсскл гоняет терабайты между ядром мсскл и .net машиной, что тоже разительно отличается от подходов хадуп, где код апликации использует классы хадуп.
другое дело, что всех проблем это не решило. многоэтажные лямды вокруг датафреймов все так же сложно читать, понять где она вылетает почти не реально, лямду не продебажишь. плюс за масштабируемость и скорость приходиться платить гемороем с эксепшинами по памяти.
Gt_
Re[73]: В России опять напишут новый объектно-ориентированны
Здравствуйте, Gt_, Вы писали:
Gt_>ну что бы над тобой постебаться было достаточно знаний первых абзацев из оракловых концептов.
Да, сразу было видно, что дальше вы так и не заглянули )
Gt_>ну какой ответ. тебе три раза уже прожували как работает хадуп и в каком процессе исполняется мой код. ты все равно жестко тупишь. Gt_>>>MyMegaClass, spark, hadoop классы это все единая аппликация, которая стартанет в единой jvm и которая будет читать локальный файлик. на каждом узле кластера. в этом вся суть. IB>>Суть понятна, не понятно чем это отличается от сиквела, кроме синтаксиса. Gt_>я уже разжувал выше, нет той пропасти в синтаксисе какая наблюдается между C#, sql и t-sql,
С тем кто тут жестко тупит, вопросов больше нет. )
Gt_>плюс в техническом плане — мсскл гоняет терабайты между ядром мсскл и .net машиной, что тоже разительно отличается от подходов хадуп, где код апликации использует классы хадуп.
И глубина ваших технических заблуждений так же вопросов больше не вызывает ))
Мы уже победили, просто это еще не так заметно...
Re[73]: В России опять напишут новый объектно-ориентированны
Здравствуйте, alex_public, Вы писали:
IT>>Поясни и приведи примеры других вариантов в более мощных языках. Мне интересен сам подход и как он реализуется компилятором. Кстати, что за языки такие? _>Да возьми любой язык с приличным метапрограммированием, отрабатывающем в процессе компиляции.
Ну назови хотя бы один. И про примеры других вариантов не забудь.
IT>>Зачем? Я правда без понятия. Оно появилось, чтобы решить какую-нибудь проблему или как обычно, потому что это сделали не мы? _>Мдааа....
Ну вот и славненько. Главное, что по существу претензий нет.
Если нам не помогут, то мы тоже никого не пощадим.
Re[74]: В России опять напишут новый объектно-ориентированны
Gt_>>ну что бы над тобой постебаться было достаточно знаний первых абзацев из оракловых концептов. IB>Да, сразу было видно, что дальше вы так и не заглянули )
Здравствуйте, IB, Вы писали:
IB>Тем не менее, можно извернуться и на SQL пользуясь особенностями конкретной реализации.
Никаких конкретных реализаций. CTE наше всё.
create table #names
(
Name nvarchar(10),
Count int
)
insert into #names (Name, Count)
values
(N'вася', 2),
(N'петя', 3);
create table #names2
(
ID int identity,
Name nvarchar(10)
);
with cte (name,[count])
as
(
select * from #names
union all
select name, [count] - 1 as [count]
from cte
where [count] > 1
)
insert into #names2 (name)
select name
from cte
order by name
select * from #names
select * from #names2
drop table #names
drop table #names2
Если нам не помогут, то мы тоже никого не пощадим.
Re[75]: В России опять напишут новый объектно-ориентированны
бы что аналитические функции как то завязаны на анал
Да вам похоже и заглядывать бесполезно, если вы до сих пор искренне считаете, что кто-то так считал )))
"Мне всегда немного грустно, когда красноречиво, изящно и тонко оскорбляешь человека, а он слишком глуп, чтобы это понять.", капец — за четырнадцать лет до вас так и не дошло. =)
Мы уже победили, просто это еще не так заметно...
Re[74]: В России опять напишут новый объектно-ориентированны
Здравствуйте, Ночной Смотрящий, Вы писали:
_>>Под языком ты C# имеешь в виду? Что-то не слышал про проблемы с рекурсией у C#... НС>И как в выражении на C# записать рекурсию?
Здравствуйте, Ночной Смотрящий, Вы писали:
_>>Потому что кроме указанногo по ссылке решения можно захотеть получить ещё и такое https://en.wikipedia.org/wiki/Apache_Phoenix (кстати, применяется в Cloudera, которая как раз отвоёвывает у РСУБД мир Корпоративных Хранилищ Данных) НС>Это как с Линуксом. Он все время уже наконец вот вот отвоюет десктоп у винды. И уже совсем почти отвоевал, жаль только десктоп сдох, а у Линукса там так и остались его 2-3%.
Здравствуйте, Sinclair, Вы писали:
_>>Так а откуда тут появляется некая функция kernel от одного параметра (специфического типа RelativeArrayAccess2d), в то время как в твоём оригинальном Linq выражение ("from d in data group d by (d[-1, 0] + d[1, 0] + d[0, -1] + d[0, 1]) / 4;") нет никаких намёков на какие-либо параметры? S>Ну как же нету? В этом выражении d как раз имеет тип IRelativeAccess2d<int>, он и является параметром функции (IRelativeAccess2d<int> d)=>(d[-1, 0] + d[1, 0] + d[0, -1] + d[0, 1]) / 4). S>Благодаря чему я имею возможность записать ядро с более человеческим синтаксисом, чем в С++.
Так и каким образом выражение "from d in data" при data являющимся int[,] делает d с типом IRelativeAccess2d<int>?
Re[75]: В России опять напишут новый объектно-ориентированны
(скрытый код) способе не вижу никаких проблем. Причём такой способ доступен в очень многих языках программирования, включая и C#.
То есть предлагается написать собственный интерпретатор и задавать рекурсию в выражении через него? Радикальненько )) Можно и по проще, но не так просто как хотелось бы:
Здравствуйте, Sinclair, Вы писали:
_>>Алгоритмы заточенные под конкретные ситуации и данные, всегда будут эффективнее неких обобщённых решений. S>Совершенно верно. И это затачивание должна производить среда исполнения, а не программист, который мало что знает о конкретной ситуации и данных.
А программист, создающий среду исполнения, ещё меньше знает о конкретной ситуации.
Re[76]: В России опять напишут новый объектно-ориентированны
Здравствуйте, IB, Вы писали:
_>>Это чушь потому, что хотя сам указанный факт является верным, он при этом ни в малейшей степени не является оправданием подобного подхода в сравнение производительности. Собственно у такого подхода вообще не может быть никаких оправданий, априори. ))) IB>Это зависит от того, как относиться к производительности. Как видно, у нас тут подходы серьезно отличаются: IB>"Да, в этом трудно поверить тому, кто воспринимает оптимизацию исключительно как выжать ещё пару бит из байта и ускориться аж на пол процента. Для остальных нормальным результатом оптимизации, в частности работы с БД, является ускорение работы приложения в разы. " (с) IT
Ну так переход от линейного алгоритма к логарфмическому — это и есть то самое "в разы". Только вот я так и не понял, с какой стати в твоём подходе сравнения производительности мы берём для императивного кода один алгоритм, а для Linq другой. А может последуем твоему подходу, только наоборот сделаем: возьмём для linq линейный алгоритм, а для императивного кода логарифимический? Нет? А почему?
_>>Не развивается значит? ) IB>Конечно нет, что PL/SQL, что TSQL и аналогичные изделия, серьезно не меняются десятилетиями. Хотя сделать из них нормальный язык нет никаких проблем, но просто нет такой потребности.
Вообще то здесь речь шла об идее исполнения императивного кода в СУБД, а не про конкретный язык.
_>> А кто тут совсем недавно хвастался появление возможности выполнения функций на Питоне в СУБД? ))) IB>Во-первых, питон — не PL/SQL, во-вторых, это было сделано для совершенно конкретной задачи — аналитики, отсюда и питон с R, а не что-то другое. Ну и в третьих — все равно этой фичей толком не пользуются.
Так а аналитика — это что, какая-то такая особая (может ненужная?) область что ли, развитие который мы не считаем за развитие? )))
Re[77]: В России опять напишут новый объектно-ориентированны
Здравствуйте, alex_public, Вы писали:
_>Ну так переход от линейного алгоритма к логарфмическому — это и есть то самое "в разы". Только вот я так и не понял, с какой стати в твоём подходе сравнения производительности мы берём для императивного кода один алгоритм, а для Linq другой.
С такой, что этот переход можно сделать не вмешиваясь в прикладной код. И в целом эта проблема решается на качественно другом уровне, позволяя сосредоточиться на реализации прикладной задачи, а не тонкостях работы конкретного алгоритма.
_>Вообще то здесь речь шла об идее исполнения императивного кода в СУБД, а не про конкретный язык.
Ну вот я и привожу пример императивных языков в СУБД, которые не развиваются, по причине неактуальности. Добавили, поигрались в это и забыли.
_>Так а аналитика — это что, какая-то такая особая (может ненужная?) область что ли, развитие который мы не считаем за развитие? )))
Я такого не говорил. Но в таком виде аналитика что-то не очень пошла, пока все же достают данные на клиента и применяют питон там.