M>>>>Как это заказчик не определит? Задачу же не какой-то Петя с улицы ставит У нас есть задача, например, поиск отелей по заданным критериям поиска. Для сайта приемлемое время отклика — до 5-10 секунд,

PD>>>Каким образом заказчик определил, что 5-10 секунд — это приемлемо ? А он знает, что (допустим. я не о вас говорю), что при иной реализации это могло бы занимать 0.1 сек ? Кто ему и как внушил, что 5-10 — это хорошо ?

M>>Никто не внушал. Это то время, на которое он, как заказчик, согласен. Не мы это время ему внушали Если будет 0.1 сек — он только будет рад.

PD>И ? А предположим, что можно изменить вашу программу так, чтобы было 0.1 сек ? Остальные характеристики не изменятся. Будешь ли ты после создания этой новой версии считать качественной версию 1 ?

Вообще-то, пофиг, что я считаю. Заказчик просто получит более качественный продукт. Мое мнение вообще не играет роли.

PD>Понимаешь, вот ты пишешь "Это то время, на которое он, как заказчик, согласен". Верно. Не вы внушали. Тоже верно. Просто, исходя из общего уровня и не знаю чего еще он пришел к выводу, что здесь быстрее чем в 5 сек не уложишься. А оказывается, можно в 0.1 сек уложиться. Вот поэтому я и говорю, что мнение заказчика — не аргумент.. Он не в состоянии оценить, с какой это скоростью можно технически сделать. Только специалист может оценить и сказать — если вы (опять же не о вас речь, конечно) складываете 2 матрицы размером 100*100 за 1 сек, то не морочьте мне голову , потому что такие скорости надо было в досовские времена демонстрировать, а сейчас это халтура.

А сферовакуумное мнение сферовакуумного специалиста никому даром не нужно. Если он это говорит и показывает заказчику и заказчик дает пенделя нам, как разработчикам, тогда другое дело.

M>>Ну так у тебя точно такие же заявления про то, что заказчик не может решать про качественность продукта

PD>Извини, но я привел тебе ряд примеров — мост, банк, мороженое. Возражений на эти примеры я не услышал. Могу еще десяток привести. А если эти примеры принимаются, то почему в ИТ все иначе ? Только, пожалуйста, без ссылок на особый путь России


Да не особо-то они и принимаются

Серовакуумное мнение сферовакуумных специалистов никому даром не нужно.

R>тупое суммирование массива из 30,000,000 doubles.

R>LINQ Sum: 915 ms
R>обычный цикл: 134 ms
R>C++ : 61 ms

Как всегда, приводятся какие-то непонятные примеры и выдаются за быстродействие Понятно же, что никому даром не нужно ни такое суммирование, ни такое решение.

В реальных задачах понадобится от силы пара тысяч чисел, и их суммирование на всех трех языках наверняка уместится в десяток миллисекунд, что человеческому глазу незаметно (ниже исправили код на C# и уже разрыв с обычным циклом составил не 9, а 3 раза). О чем весь сыр-бор?

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

F>>Если найти в рамках имеющегося бюджета подрядчика, который сделает быстрее при сохранении фунциональности не получается — то придется признать — хотя бы на время — что скорость работы обусловлена именно сложностью задачи.

PD>Категорически не согласен. Если это так, то это скорее означает, что неправильно оценен бюджет, а вовсе не то, что скорость обусловлена сложностью. Увеличьте бюджет, наймите вместо поденщиков хороших специалистов, и они справятся с этой сложностью без проблем. Это сложность не задачи, а сложность для тех "специалистов", которые ее грамотно решать не умеют. Ну что же, хотели "числом поболее, ценю подешевле" — получайте свою халтуру, за эти деньги вы ничего иного и не получите.

А, ну если деньги бесконечные, то да. У меня, к сожалению, не такой случай

Кстати, не оставишь адресок бесконечной тумбочки с деньгами? С ней-то действительно — количество сложных задач резко сократится, и проблемными останутся только теоретически нерешенные или ограниченные мощностью самого производительного железа. А то и, глядишь, и мировой уровень технологии подтянем, с такими-то ресурсами.

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

F>При этом критерий времени отклика — он гораздо понятнее и при этом легко проверяем, чем абстрактные рассуждения некоего специалиста о "халтуре" конкурентов.
PD>Он далеко не всегда применим. У меня, к примеру, нет сайтов, нет пользователей и нет никакого отклика в обычном понимании этого слова.

Ты ж не дурак, так и не надо из себя его строить — никто не поверит.
Все равно для твоей задачи можно описать, какое время обработки (как пример, точно так же про все другие аспекты работы приложения) будет признано приемлимым. Если такого нет, и всегда надо "еще меньше" — то и нет возможности такую работу сдать заказчику (а как же так, у вас образ распознается за 0.00001 сек, а ведь наверняка можно и быстрее!? нет, я такую халтуру не приму!). Единственный способ сдать работу в таких условиях — это уговорить заказчика что все круто и круче быть не может (а то как же — mmf используется или еще какое умное слово, и вообще я авторитет и специалист, а ты кто такой, обычный пользователь, не тебе оценивать труд специалиста).

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

Кэр>>Мне больше нравится код, где никаких инструкций не нужно. И в этом конкретном примере — Linq требует дополнительных пояснений, а простейший цикл не требует.
G>Это потому что ты Linq не понимаешь, а циклы понимаешь.

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

G>Для человека, который одинаково понимает (не понимает) и то и другое, linq будет проще.

Я человек, который понимает и то, и другое — и я утверждаю, что пример с linq и сложнее, и хуже по целому ряду критериев.

Кэр>>Более того, приведенный код с Linq приносит очень много неявного поведения. Что, например, является corner case в коде с pairwiseby и данным конкретным предикатом — пустой массив, массив с одним элементом, двумя, тремя, четырьмя, пятью? Некоторые из них? Все вышеперечисленные? Нужны ли unit тесты для всех этих вариантов, чтобы сохранить жесткость этого кода?
G>Цикл требует того же самого.

Цикл не прячет это знание в библиотечной функции. Эта функция обладает вполне конкретным поведением, которое надо сначала изучить, а потом гарантировать неизменность.

G>Ты сначала для себя определи будет ли упорядоченным пустой массив и из одного элемента.

Для какого начала? Чтобы общаться с вашим высоким просвященным высочеством?

Кэр>>Почему для простейшего алгоритма вы начали требовать знания библиотечных функций, тем более не самых популярных? Я, конечно, понимаю, что синдром студента "я выучил, значит все должны выучить!" и принцип "краткость — сестра нашего брата!" — это одни из самых мощных мотиваторов в нашей профессии. Но во всем надо знать меру.
G>А чего ты пытаешься требовать знание как пишется for и думать с чего начинается индексация массива, и как вообще получить длину массива,

Это базовые навыки, которые шаряться между различными языками. Keep things as simple as possible.

G>а если там не массив, а IEnumerable<T>?

То будет foreach вместо for.

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

Кэр>Здравствуйте, gandjustas, Вы писали:

Кэр>>>Мне больше нравится код, где никаких инструкций не нужно. И в этом конкретном примере — Linq требует дополнительных пояснений, а простейший цикл не требует.
G>>Это потому что ты Linq не понимаешь, а циклы понимаешь.

Кэр>Ну конечно же все именно так просто. Все дело не в том, что код получается на ровном месте переусложненный с дополнительными зависимостями.
Где ты увидел дополнительные зависимости в двух вызовах функций.

G>>Для человека, который одинаково понимает (не понимает) и то и другое, linq будет проще.

Кэр>Я человек, который понимает и то, и другое — и я утверждаю, что пример с linq и сложнее, и хуже по целому ряду критериев.

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

Кэр>>>Более того, приведенный код с Linq приносит очень много неявного поведения. Что, например, является corner case в коде с pairwiseby и данным конкретным предикатом — пустой массив, массив с одним элементом, двумя, тремя, четырьмя, пятью? Некоторые из них? Все вышеперечисленные? Нужны ли unit тесты для всех этих вариантов, чтобы сохранить жесткость этого кода?
G>>Цикл требует того же самого.

Кэр>Цикл не прячет это знание в библиотечной функции. Эта функция обладает вполне конкретным поведением, которое надо сначала изучить, а потом гарантировать неизменность.
Циклы тоже требуют изучение. Я же говорю что в случае одинакового знания\незнания linq проще.
При этом для понимания linq не требуется изучать реализацию. Хватит сигнатуры краткого словесного описания.

G>>Ты сначала для себя определи будет ли упорядоченным пустой массив и из одного элемента.
Кэр>Для какого начала? Чтобы общаться с вашим высоким просвященным высочеством?
Нет, чтобы писать проверку на упорядоченность.

Кэр>>>Почему для простейшего алгоритма вы начали требовать знания библиотечных функций, тем более не самых популярных? Я, конечно, понимаю, что синдром студента "я выучил, значит все должны выучить!" и принцип "краткость — сестра нашего брата!" — это одни из самых мощных мотиваторов в нашей профессии. Но во всем надо знать меру.
G>>А чего ты пытаешься требовать знание как пишется for и думать с чего начинается индексация массива, и как вообще получить длину массива,
Кэр>Это базовые навыки, которые шаряться между различными языками. Keep things as simple as possible.

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

G>>а если там не массив, а IEnumerable<T>?
Кэр>То будет foreach вместо for.
Учитывая что массив реализует IEnumerable<T>, то что является более "базовым" всетаки for или foreach?

А потом вспомним про ленивость и окажется что комбинаторы и итераторы являются самыми базовыми.

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

PD>>И ? А предположим, что можно изменить вашу программу так, чтобы было 0.1 сек ? Остальные характеристики не изменятся. Будешь ли ты после создания этой новой версии считать качественной версию 1 ?

M>Вообще-то, пофиг, что я считаю. Заказчик просто получит более качественный продукт. Мое мнение вообще не играет роли.

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

PD>>Понимаешь, вот ты пишешь "Это то время, на которое он, как заказчик, согласен". Верно. Не вы внушали. Тоже верно. Просто, исходя из общего уровня и не знаю чего еще он пришел к выводу, что здесь быстрее чем в 5 сек не уложишься. А оказывается, можно в 0.1 сек уложиться. Вот поэтому я и говорю, что мнение заказчика — не аргумент.. Он не в состоянии оценить, с какой это скоростью можно технически сделать. Только специалист может оценить и сказать — если вы (опять же не о вас речь, конечно) складываете 2 матрицы размером 100*100 за 1 сек, то не морочьте мне голову , потому что такие скорости надо было в досовские времена демонстрировать, а сейчас это халтура.

M>А сферовакуумное мнение сферовакуумного специалиста никому даром не нужно. Если он это говорит и показывает заказчику и заказчик дает пенделя нам, как разработчикам, тогда другое дело.

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

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

M>>>Ну так у тебя точно такие же заявления про то, что заказчик не может решать про качественность продукта

PD>>Извини, но я привел тебе ряд примеров — мост, банк, мороженое. Возражений на эти примеры я не услышал. Могу еще десяток привести. А если эти примеры принимаются, то почему в ИТ все иначе ? Только, пожалуйста, без ссылок на особый путь России


M>Да не особо-то они и принимаются

Тогда приведи контраргументы. Я их не увидел и не услышал.

M>Серовакуумное мнение сферовакуумных специалистов никому даром не нужно.

Ну на тебе развернутое изложение одного из примеров.

Купил я мороженое и съел. Не отравился. Показалось вкусным. Я , пользователь, доволен. Это качественное мороженое ?

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

А вот одна омская газета периодически устраивает опрос экспертов по некоему продукту. Берется этот продукт от 5-6 производителей и сравнивают, по разным критериям, ставят баллы, газета приводит результат, устанавливаются места по оценкам. Это все же лучше, чем если бы я купил по банке этих продуктов и высказал свое непрофессиональное мнение.

Это , надеюсь, уже не сферовакумный конь ?

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

PD>>Категорически не согласен. Если это так, то это скорее означает, что неправильно оценен бюджет, а вовсе не то, что скорость обусловлена сложностью. Увеличьте бюджет, наймите вместо поденщиков хороших специалистов, и они справятся с этой сложностью без проблем. Это сложность не задачи, а сложность для тех "специалистов", которые ее грамотно решать не умеют. Ну что же, хотели "числом поболее, ценю подешевле" — получайте свою халтуру, за эти деньги вы ничего иного и не получите.

F>А, ну если деньги бесконечные, то да. У меня, к сожалению, не такой случай

Не обязательно бесконечные.

F>Кстати, не оставишь адресок бесконечной тумбочки с деньгами?

Пожалуйста

http://www.cbr.ru/

Потенциально бесконечная. Правда, дадут ли тебе из этой тумбочки — сомневаюсь.

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

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

F>>При этом критерий времени отклика — он гораздо понятнее и при этом легко проверяем, чем абстрактные рассуждения некоего специалиста о "халтуре" конкурентов.
PD>>Он далеко не всегда применим. У меня, к примеру, нет сайтов, нет пользователей и нет никакого отклика в обычном понимании этого слова.

F>Ты ж не дурак, так и не надо из себя его строить — никто не поверит.

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

M>>А сферовакуумное мнение сферовакуумного специалиста никому даром не нужно. Если он это говорит и показывает заказчику и заказчик дает пенделя нам, как разработчикам, тогда другое дело.

PD>Опять то же. А если заказчик не дает пенделя или (что более вероятно) ему это показывать — все равно что показывать неандертальцу ракетный двигатель, а там халтура очевидная внутри — ты все равно считаешь этот продукт качественным ?

Критерий вычисления халтуры ровно один: работает программа в рамках, поставленных заказчиком, или не работает. Технический аспект реализации вообще никого не волнует. Ну, кроме перфекционистов, естественно

PD>Купил я мороженое и съел. Не отравился. Показалось вкусным. Я , пользователь, доволен. Это качественное мороженое ?

PD>Черт его знает. Может, в нем вместо молока какая-то дрянь, а вместо масла — пальмовый жир. Может, в нем конесерванты такие, что лучше бы их не было. Может, там добавки не очень хорошие. Может, у него консистенция не та, а мой грубый вкус этого не улавливает. Может... додумай сам.

PD>А вот одна омская газета периодически устраивает опрос экспертов по некоему продукту. Берется этот продукт от 5-6 производителей и сравнивают, по разным критериям, ставят баллы, газета приводит результат, устанавливаются места по оценкам. Это все же лучше, чем если бы я купил по банке этих продуктов и высказал свое непрофессиональное мнение.

PD>Это , надеюсь, уже не сферовакумный конь ?

Я на это уже ответил

сферовакуумное мнение сферовакуумного специалиста никому даром не нужно. Если он это говорит и показывает заказчику и заказчик дает пенделя нам, как разработчикам, тогда другое дело.

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

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

PD>Тогда тебе надо новый раздел в математике завести — сложность задач как функция выделяемых на их решение средств. Правда, один Перельман разрушит все теории такого рода

Это не в математике, а в управлении проектами. И такой раздел давным давно существует.

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

M>>>А сферовакуумное мнение сферовакуумного специалиста никому даром не нужно. Если он это говорит и показывает заказчику и заказчик дает пенделя нам, как разработчикам, тогда другое дело.

PD>>Опять то же. А если заказчик не дает пенделя или (что более вероятно) ему это показывать — все равно что показывать неандертальцу ракетный двигатель, а там халтура очевидная внутри — ты все равно считаешь этот продукт качественным ?

M>Критерий вычисления халтуры ровно один: работает программа в рамках, поставленных заказчиком, или не работает. Технический аспект реализации вообще никого не волнует. Ну, кроме перфекционистов, естественно

Пора заканчивать. Увы. я надеялся от тебя какие-то аргументы получить или возражения на мои замечания. А вижу лишь декларации — это так, потому что это так.

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


PD>>Черт его знает. Может, в нем вместо молока какая-то дрянь, а вместо масла — пальмовый жир. Может, в нем конесерванты такие, что лучше бы их не было. Может, там добавки не очень хорошие. Может, у него консистенция не та, а мой грубый вкус этого не улавливает. Может... додумай сам.

PD>>А вот одна омская газета периодически устраивает опрос экспертов по некоему продукту. Берется этот продукт от 5-6 производителей и сравнивают, по разным критериям, ставят баллы, газета приводит результат, устанавливаются места по оценкам. Это все же лучше, чем если бы я купил по банке этих продуктов и высказал свое непрофессиональное мнение.

PD>>Это , надеюсь, уже не сферовакумный конь ?

M>Я на это уже ответил
M>

M>сферовакуумное мнение сферовакуумного специалиста никому даром не нужно. Если он это говорит и показывает заказчику и заказчик дает пенделя нам, как разработчикам, тогда другое дело.

M>То же и с опросами экспертов. Пока они не говорят о своих выводах заказчикам (потребителям) и, желательно, не предлагают продукт, который лучше с точки зрения потребителя, даром их выводы никому не нужны.

Почему не говорят, именно говорят. Я же сказал — одна омская газета этим занимается, привлекает экспертов и печатает их заключения. Можно считать, что они рекомендуют продукты, занявшие 1-2 место (обычно их рассматривается 5-6) и наоборот, не рекомендуют аутсайдеров. Я к их мнению прислушиваюсь, к примеру.
Так что нет здесь никакой сферовакуумности. Есть вполне конкретный пример, когда мнение специалистов о том, качественное мороженое или нет, существенно, а мое как потребителя — существенно, только если я им недоволен (вот тут да, не нравится мне это мороженое, и плевать мне на все мнения всех экспертов и производителя вместе с ними), и не существенно, если оно мне нравится. Скажу точнее — не то, чтобы вообще не существенно, но явно недостаточно, чтобы судить о его качестве.

Возрази на мой последний абзац. Только без ссылок на коней и вакуум, пожалуйста

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

0K>По мотивам: http://rsdn.ru/forum/dotnet/3900028.flat.aspx

Автор: Dog
Дата: 30.07.10

0K>Человек спросит, как с помощью Linq проверить упорядоченность массива, к примеру {1, 3, 5, 7, 9}.

0K>Теперь скажите чей вариант быстрее и понятнее? Каков смысл в вашем Linq?

Некорректная задача, для студента или с собеседования. Правильно:
1) либо нам нужно получить на выходе отсортированный массив. Тогда сортировать каждый раз будет быстрее, чем проверять, нужна ли сортировка.
2) если так волнует производительность, надо вставлять данные в упорядоченные списки на этапе пользовательского ввода.

P.S. Господа КСВшники, ну право стыдно, надо сразу в эту сторону дискуссию уводить.

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

M>Некорректная задача, для студента или с собеседования. Правильно:

Вполне корректная, упорядоченность может проверятся например по нескольким разным критериям.

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

Сортировать будет точно намного медленнее, проверка это одиночный линейный проход по массиву, с этим даже radix sort не сравняется

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

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

M>>Некорректная задача, для студента или с собеседования. Правильно:
FR>Вполне корректная, упорядоченность может проверятся например по нескольким разным критериям.

Я вот честно не сталкивался с такими задачами.
Зачем проверять упорядоченность? Если окажется неупорядоченным что потом делать?

Более вероятная задача найти монотонные подпоследовательности, как раз она на linq лучше решается.

M>>1) либо нам нужно получить на выходе отсортированный массив. Тогда сортировать каждый раз будет быстрее, чем проверять, нужна ли сортировка.
FR>Сортировать будет точно намного медленнее, проверка это одиночный линейный проход по массиву, с этим даже radix sort не сравняется
Быстрая сортировка упорядоченного массива — тоже один проход

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

FR>>Вполне корректная, упорядоченность может проверятся например по нескольким разным критериям.

G>Я вот честно не сталкивался с такими задачами.
G>Зачем проверять упорядоченность? Если окажется неупорядоченным что потом делать?

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

G>Более вероятная задача найти монотонные подпоследовательности, как раз она на linq лучше решается.

Ну это и циклом не сложно.

M>>>1) либо нам нужно получить на выходе отсортированный массив. Тогда сортировать каждый раз будет быстрее, чем проверять, нужна ли сортировка.
FR>>Сортировать будет точно намного медленнее, проверка это одиночный линейный проход по массиву, с этим даже radix sort не сравняется
G>Быстрая сортировка упорядоченного массива — тоже один проход

Угу классическим qsort с самым примитивным выбором медианы

M>>Я на это уже ответил
M>>

M>>сферовакуумное мнение сферовакуумного специалиста никому даром не нужно. Если он это говорит и показывает заказчику и заказчик дает пенделя нам, как разработчикам, тогда другое дело.

M>>То же и с опросами экспертов. Пока они не говорят о своих выводах заказчикам (потребителям) и, желательно, не предлагают продукт, который лучше с точки зрения потребителя, даром их выводы никому не нужны.

PD>Почему не говорят, именно говорят. Я же сказал — одна омская газета этим занимается, привлекает экспертов и печатает их заключения. Можно считать, что они рекомендуют продукты, занявшие 1-2 место (обычно их рассматривается 5-6) и наоборот, не рекомендуют аутсайдеров. Я к их мнению прислушиваюсь, к примеру.

Теперь перечитай то, что я процитировал. Это то же самое. В итоге все упирается в выбор пользователя/заказчика и т.п.


PD>Так что нет здесь никакой сферовакуумности. Есть вполне конкретный пример, когда мнение специалистов о том, качественное мороженое или нет, существенно, а мое как потребителя — существенно, только если я им недоволен (вот тут да, не нравится мне это мороженое, и плевать мне на все мнения всех экспертов и производителя вместе с ними), и не существенно, если оно мне нравится. Скажу точнее — не то, чтобы вообще не существенно, но явно недостаточно, чтобы судить о его качестве.

PD>Возрази на мой последний абзац. Только без ссылок на коней и вакуум, пожалуйста

Я, вообще-то, уже два раза процитировал, а ты только мои слова подтвердил. Мнение специалиста никому не нужно, пока это мнение не донесено до потребителя в стиле «у нас есть три продукта, они отличаются друг от друга по следующим критериям. Выбор за вами».

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

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

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

FR>>>Вполне корректная, упорядоченность может проверятся например по нескольким разным критериям.

G>>Я вот честно не сталкивался с такими задачами.
G>>Зачем проверять упорядоченность? Если окажется неупорядоченным что потом делать?

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

Или хотя бы мысли где такая проверка может понадобится?

G>>Более вероятная задача найти монотонные подпоследовательности, как раз она на linq лучше решается.
FR>Ну это и циклом не сложно.
linq выйграет в читабельности.

M>>>>1) либо нам нужно получить на выходе отсортированный массив. Тогда сортировать каждый раз будет быстрее, чем проверять, нужна ли сортировка.
FR>>>Сортировать будет точно намного медленнее, проверка это одиночный линейный проход по массиву, с этим даже radix sort не сравняется
G>>Быстрая сортировка упорядоченного массива — тоже один проход

FR>Угу классическим qsort с самым примитивным выбором медианы

new[] { 1, 2, 3, 4 }.Do(Console.Write).OrderBy(x => x).Run();

выводит

1234