пробую так:

это работает, но возвращаемое значение не Point, а double. Как на выходе получать именно Point (ну или тип который нужен мне)?

В тупую 

хм... сработало, спасибо 

HalkaR,  о_О а просто Point maxX = points.Max(p => p.X); недостаточно?

Partizan, так Bonus же сказал, что это возвращает X, а не Point.

а....понял...

Кстати-кстати. Тут не все так просто. Это один из тонких моментов в LINQ.
Первый вариант решения, который приходит на ум, - забить на LINQ и воспользоваться старым-добрым foreach. В этом случае за O(n) операций можно найти необходимый элемент. Чем не вариант? Да тем, что после LINQ ну очень не хочется писать подобный "низкоуровневый" перебор.
Если говорить о LINQ решениях этой проблемы, то можно, например, отсортировать список по убыванию и взять первый элемент. Естественно, производительность в этом случае не выдерживает никакой критики (O log n операций и куча понапрасну использованной памяти). Если показать такое решение программисту со старой закалкой, его, наверное, инфаркт хватит 
Второй LINQ-вариант - использовать код, подобный тому, который написал HalkaR. Только вот, честно говоря, меня удивило, что

Ведь этот код возвращает не Point, а коллекцию Point'ов. У меня такой код даже не комплируется (Resharper сразу ругается):

Кстати в том кусочке кода еще одна ошибка: переменная p объявляется два раза. Такое не скомпилируется. И выражение

надо заменить на что-нибудь вроде

Ну это так, мелочи: HalkaR просто опечатался.
Чтобы заставить этот код делать именно то, что нужно, просто добавляем в конец вызов метода First:

Вот. Теперь компилятор не ругается и получает необходимый результат. Казалось бы, вот оно, счастье  Ан нет. Если присмотреться, код-то неоптимальный. На первый взгляд кажется, что выполняется 2n операций: сначала находится максимальный X, а потом элемент с этим значением X. Напомню, что классически эта задача решается за n операций (как выше через foreach). На самом деле этот код ведет себя куда хуже. Дело в том, что points.Max выполняется при каждой итерации (ну действительно, откуда LINQ знать, что это значение является константой?! "Нет, сынок, это фантастика"  ). Таким образом, этот скрипт выполняется при помощи n*n операций. Невероятно, но при некоторых n этот вариант может работать даже медленнее бредового варианта с сортировкой (n*n против n*log(n) ).
Конечно, пофиксить баг под кодовым названием "расчет point.Max при каждой итерации" не составит труда:

Все, что мы сделали, - вынесли вычисление максимального значения X за цикл. Итого, получаем 2*n операций. Лучше, конечно, но все равно попахивает законом дырявых абстракций. Но ведь если проблему нельзя решить "стандартными средствами", никто не запрещает создать свой собственный метод расширения (хвала С# 3.0).
Упрощенная версия будет выглядеть примерно так:

Используем вот так:

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

Добавлено @ 18:24
Забыл добавить, что вариант с методом расширения выполняется за n операций.

Это сообщение отредактировал(а) Idsa - 7.7.2008, 18:02

Метод расширения я немного неправильно написал. Нужно что-нибудь вроде этого:

Этот подход я позаимствовал в Reflector'е 

Дружит ли, кстати, DLinq с user-defined типами?



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

Точку с максимальным X.


Дружит.

Спасибо. Ну вот и общий ответ на первый вопрос:



А вообще, все приведенные решения в общем случае неоптимальны. Но если автору темы хватает, то и бог с ними  

Т.е. ты в "общем случае" умеешь находить максимальный элемент быстрее, чем за O(n)? Дэвид Блейн?

В каждом общем случае не могу. В конкретном общем - может получиться. Например, при частом использовании такой задачи, я бы создал индекс и делал бы выборку по нему (ага).
Предположу даже больше. Решения в общем случае как минимум не быстрее конкретных решений задач с индивидуальной спецификой. Угу?

Это сообщение отредактировал(а) akizelokro - 11.7.2008, 14:16

akizelokro, решение в общем случае - это решение задачи на условиях, озвученных топикастером. Как раз "в общем случае" приведенные решения оптимальны. А в частных - ес-но нет. И это не повод писать в каждой теме "решение неоптимально".
А потом оказалось бы что на поддержание индекса уходит больше ресурсов, чем на все выборки. Или что выборки производятся из временных результатов. Твое решение в общем случае неоптимально (с). 

Для задачи "выбрать из IEnumerable<Point> элемент с максимальным значением X" - решение оптимально в общем случае. А все предположения "а если бы задача была не такой, а другой", "а если бы мы решали частный случай, то общее решение было бы не оптимально" к решению вообще никакого отношения не имеют.