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

G>Предположение верное если на всем отрезке сумм один минимум и одни максимум, что в общем случае не так
В общем случае — один. Ты с локальными экстремумами перепутал.

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

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

b-3>Я просто напомню, что выбирать "лучшие 20" из 10000 элементов, Linq.Enumerable без загрузки в память всей коллекции и полной её сортировки не умеет ва-а-аще.
Но содержит все кубики, необходимые для сборки решения без полной сортировки в том числе. Загрузить всю коллекцию придется, но не сразу всю.

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

b-3>>Я просто напомню, что выбирать "лучшие 20" из 10000 элементов, Linq.Enumerable без загрузки в память всей коллекции и полной её сортировки не умеет ва-а-аще.
S>Но содержит все кубики, необходимые для сборки решения без полной сортировки в том числе. Загрузить всю коллекцию придется, но не сразу всю.

Пользователь будет очень рад, когда открытие окошка "♥ МОИ ЛЮБИМЫЕ ФИЛЬМЫ ♥" будет начинаться с
> Загрузить всю коллекцию придется, но не сразу всю.
секунд так на двадцать пять, и конечно же купит Ваш плеер

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

b-3>Здравствуйте, samius, Вы писали:

b-3>Пользователь будет очень рад, когда открытие окошка "♥ МОИ ЛЮБИМЫЕ ФИЛЬМЫ ♥" будет начинаться с
>> Загрузить всю коллекцию придется, но не сразу всю.
b-3>секунд так на двадцать пять, и конечно же купит Ваш плеер

Я не понял. Ты предлагаешь выдавать результат не загружая часть коллекции?

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

b-3>>Пользователь будет очень рад, когда открытие окошка "♥ МОИ ЛЮБИМЫЕ ФИЛЬМЫ ♥" будет начинаться с
>>> Загрузить всю коллекцию придется, но не сразу всю.
b-3>>секунд так на двадцать пять, и конечно же купит Ваш плеер

S>Я не понял. Ты предлагаешь выдавать результат не загружая часть коллекции?
В видеоплеере? Да, предлагаю. Но это же сложно, это же нужно код писать вместо .OrderBy(..).Take(20)

Так вы всё же расскажите, как Вы будете делать видеоплеер? Будет ли там использоваться СУБД 'для оптимизации поиска' и так далее?
А когда выяснится, что с SQLite линку работает хреново, захотите ли вы, чтоб пользователь купил Windows 7 Home Premium вместо его vista home starter, дабы можно было применить новейшие технологии микрософт?

Ещё можно провести эксперимент: спросить соседского школьника, прогающего на паскале, как сделать список из 20 самых популярных фильмов в маааленьком таком плеере?

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

b-3>Здравствуйте, samius, Вы писали:

S>>Я не понял. Ты предлагаешь выдавать результат не загружая часть коллекции?
b-3>В видеоплеере? Да, предлагаю. Но это же сложно, это же нужно код писать вместо .OrderBy(..).Take(20)

Я отвечал на пафосное утверждение о том что Linq не может обеспечить решения задачи без сортировки всей коллекции в памяти. Писать видеоплеер я не подписывался.

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

G>Даем на вход new int[] { -5 ,10, 20, -15, -30, 22 } и получаем {-5 ,10, 20}, что очевидно неверно.
G>Да, детка давай еще. Еще тест, еще порция "случайных изменений" чтобы следующий тест прошел.
G>Напиши сначала правильный вариант, потом и сам догадаешься.

Так я не понял, я собеседованике прошёл или не прошёл?

А по какой причине?

А как ответил на вопрос победивший кандидат?

G>Это очередной пример когда задача и реализация решения простые, но алгоритм сложен.

24.02.2012 11:48, Здравствуйте, Паблик Морозов :
> 1. Если человек не в состоянии обратить список, способен ли он вообще
> написать что-нибудь разумное или сразу нафиг?

И что ты намерен услышать в ответ? list.Reverse()?

Не знаю как в яве, а в шарпе нет списков в классическом виде, List
реализован через массивы. Классическая задача вырождается в убожество.
Думаю, для шарпа или жабы давать задачу или не стоит вообще или, по
крайней мере, перед постановкой задачи реализовать классический
односвязный список.

С переворотом строки та же песня -- задача на шарпе смысла не имеет

> З.Ы. На прошлой работе HR заставляла соискателей решать задачи про
> переливание воды, цветные шары и гномов в кепках.

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

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

S>Здравствуйте, b-3, Вы писали:

b-3>>Здравствуйте, samius, Вы писали:

S>>>Я не понял. Ты предлагаешь выдавать результат не загружая часть коллекции?
b-3>>В видеоплеере? Да, предлагаю. Но это же сложно, это же нужно код писать вместо .OrderBy(..).Take(20)

S>Я отвечал на пафосное утверждение о том что Linq не может обеспечить решения задачи без сортировки всей коллекции в памяти. Писать видеоплеер я не подписывался.
Linq, конечно, может обеспечить решение задачи. Дать Select, Where, Take и Aggregate

Однако на наиболее простом решении, которое придумал соседский школьник: завести мутабельный (хаскеллисты здесь падают в обморок, enterprise-critical-программеры вешаются) — да, мутабельный! — список "лучших и кандидатов" — которое замечательно продастся — Linq будет вставлять палки в колёса. Потому что Linq, порочная дочь HaskellDB и Visual Basic-а, не может в мутабельность.

И пусть школьник Вася хранит этот список в реестре, а счётчик просмотров фильма — в метаданных .avi. И может даже когда-то что-то взглюкнет, и 19 место в списке фильмов определится неправильно.
Но его плеер заработает деньги, а ваш будет требовать какую-нибудь Windows 8 или что будет модно к тем временам
А потом окажется, что на мобильник телефон ваш код, использующий SQL Server Сompact Edition, перенести никак нельзя... Что ж... Увы и ах! Хотя с точки зрения enterprise-программинга правильно завести базу данных с индексом, и не тратить дорогущий трудочас на такую глупость, как изобретение маленького кривоватого алгоритма.
Вон там ganjustas в соседней ветке уже второй юнит-тест мне написал)

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

b-3>Здравствуйте, samius, Вы писали:

S>>Я отвечал на пафосное утверждение о том что Linq не может обеспечить решения задачи без сортировки всей коллекции в памяти. Писать видеоплеер я не подписывался.
b-3>Linq, конечно, может обеспечить решение задачи. Дать Select, Where, Take и Aggregate

b-3>Однако на наиболее простом решении, которое придумал соседский школьник: завести мутабельный (хаскеллисты здесь падают в обморок, enterprise-critical-программеры вешаются) — да, мутабельный! — список "лучших и кандидатов" — которое замечательно продастся — Linq будет вставлять палки в колёса. Потому что Linq, порочная дочь HaskellDB и Visual Basic-а, не может в мутабельность.
Так ты думаешь на иммутабельности потреяешь 25 минут на 10000 элементах?

b-3> И пусть школьник Вася хранит этот список в реестре, а счётчик просмотров фильма — в метаданных .avi. И может даже когда-то что-то взглюкнет, и 19 место в списке фильмов определится неправильно.

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

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

S>Так ты думаешь на иммутабельности потреяешь 25 минут на 10000 элементах?
Прочитать 10000 файлов на хилой машине с антивирусом вполне может занимать 25 секунд. Речь не шла про минуты, понятно что 25 минут на открытие формы не бывает даже у linq-программеров с сертификатами

b-3>> И пусть школьник Вася хранит этот список в реестре, а счётчик просмотров фильма — в метаданных .avi. И может даже когда-то что-то взглюкнет, и 19 место в списке фильмов определится неправильно.

S>Мне непонятно, почему ты обвиняешь Linq в невозможности создать решение, которое ты на других технологиях даже не рассматриваешь. Может линк не позволяет тебе ходить по списку, который хранится в реестре?
Линку никак не помогает этот список ни менять, ни читать, не сохранять. Соответственно, linq не позволяет решить задачу вышеописанным способом, а только предлагает "загрузить всё и отсортировать". Можно не применять здесь linq, конечно.

Делаю вывод, что задача отобрать 20 лучших из 10000 иногда открываемых фильмов, на Linq эффективно не решается.

Делаю вывод, что бывают задачи, когда правильнее вместо linq запроса написать ужасный for.
А знаете что этот ужасный for делает? Поиск места вставки в мутабельный массив! Это в 2012-то году! Нет, это невыносимо! Пойду нарисую ещё один отчёт на Entities Framework и интегрирую его в Microsoft SharePoint...

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

b-3>Здравствуйте, samius, Вы писали:

S>>Так ты думаешь на иммутабельности потреяешь 25 минут на 10000 элементах?
b-3>Прочитать 10000 файлов на хилой машине с антивирусом вполне может занимать 25 секунд. Речь не шла про минуты, понятно что 25 минут на открытие формы не бывает даже у linq-программеров с сертификатами
ну ладно, секунд. Почему ты думаешь что использование линка даст заметный проигрыш при чтении 10000 файлов?

b-3>>> И пусть школьник Вася хранит этот список в реестре, а счётчик просмотров фильма — в метаданных .avi. И может даже когда-то что-то взглюкнет, и 19 место в списке фильмов определится неправильно.

S>>Мне непонятно, почему ты обвиняешь Linq в невозможности создать решение, которое ты на других технологиях даже не рассматриваешь. Может линк не позволяет тебе ходить по списку, который хранится в реестре?
b-3>Линку никак не помогает этот список ни менять, ни читать, не сохранять. Соответственно, linq не позволяет решить задачу вышеописанным способом, а только предлагает "загрузить всё и отсортировать". Можно не применять здесь linq, конечно.
Давай-ка прежде всего сравнивать одинаковые решения. Или ты выбираешь 20 файлов на паскале (читая и сравнивая) и сравниваешь этот подход с решением с ликном. Или ты читаешь на паскале список из реестра и сравниваешь этот подход с решением с линком.

b-3>Делаю вывод, что задача отобрать 20 лучших из 10000 иногда открываемых фильмов, на Linq эффективно не решается.
Решение на Linq может быть лишь немногим менее эффективно чем соответствующее решение на чем-нибудь другом. Конечно, если ты читаешь линком 10000 файлов а паскалем 20-и элементный список из реестра, то проблемы не в линке, а в твоей голове.

b-3>Делаю вывод, что бывают задачи, когда правильнее вместо linq запроса написать ужасный for.
Бывает.
Но я-то говорил что для того что бы выбрать 20 записей из 10000 не нужно сортировать всю коллекцию. В ответ тебя унесло черт знает куда.
b-3>А знаете что этот ужасный for делает? Поиск места вставки в мутабельный массив! Это в 2012-то году! Нет, это невыносимо! Пойду нарисую ещё один отчёт на Entities Framework и интегрирую его в Microsoft SharePoint...
успехов

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

S>Давай-ка прежде всего сравнивать одинаковые решения. Или ты выбираешь 20 файлов на паскале (читая и сравнивая) и сравниваешь этот подход с решением с ликном. Или ты читаешь на паскале список из реестра и сравниваешь этот подход с решением с линком.

S>Решение на Linq может быть лишь немногим менее эффективно чем соответствующее решение на чем-нибудь другом. Конечно, если ты читаешь линком 10000 файлов а паскалем 20-и элементный список из реестра, то проблемы не в линке, а в твоей голове.
Вот тут я категорически не соглашусь. Проблема в данном случае именно в linq, а не в голове.

Потому что как инструмент linq замечателен, и активно мной используется в работе. Это я на всяких случай поясняю: я и QueryProvier-ы писал, и решарпером его всего излазил...)

Как философия разработки linq — плоха. Потому что подязык запросов философией разработки никогда, как вы понимаете, не являлся. И то, что "должен быть только один способ сделать это", и "если можно сделать иммутабельно — делай иммутабельно", и то что "ФП лучше всего, а linq — почти ФП, нафиг думать, пишем на linq!", и тому подобные убеждения приводят к тому, что программа на линку читает 10000 файлов, а программа на паскале 20 ключей из реестра.

Кто здесь виноват — судите сами

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

A>Этот подход хорош тем, что он позволяет объективно оценить кандидатов.
A>Способ возможно и не самый лучший, но просто беседа оценить всего лишь навыки общения кандидата и то, насколько он приглянулся. Остальные выводы притянут за уши.

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

Здравствуйте, Паблик Морозов, Вы писали:

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

G>>"Постоянно" это как часто? Какой процент из них требует разворачивания списков или манипуляций с битами.

ПМ>Постоянно — это всегда. Программирование — это и есть написание алгоритмов.
Неверно. Современное программирование — комбинирование существующих алгоритмов.

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

G>>Но это все крайне редко, настолько редко что проще нагуглить когда понадобится.
ПМ>Решение реальной задачи заказчика ты не нагуглишь.
Зато нагуглишь уже готовые блоки, из которых можно склепать решение.

G>>А спрашивать на собеседовании — не более чем потешать свое самолюбие.
ПМ>Нет, это хороший способ отсеять людей, которые не могут программировать.
Нет, это способ отсеять тех кто не писал разворот списка последние полгода.

Здравствуйте, Паблик Морозов, Вы писали:

ПМ>1. Если человек не в состоянии обратить список, способен ли он вообще написать что-нибудь разумное или сразу нафиг?

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

Лучше заставлять написать АТД "дерево" на тех же рекордах с ссылками на правый и левый узел, сохраняющий сбалансированность при вставке и удалении элемента

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

H>Знаменитая история. Джоел спольски любил задавать вопрос — нарисуйте дом.

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

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

ПМ>>Постоянно — это всегда. Программирование — это и есть написание алгоритмов.
G>Неверно. Современное программирование — комбинирование существующих алгоритмов.
Так задачу на комбинирование (именно комбинирование, а не вызвать готовую функцию API) ты ж тоже завалишь

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

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

G>>Предположение верное если на всем отрезке сумм один минимум и одни максимум, что в общем случае не так
b-3>В общем случае — один. Ты с локальными экстремумами перепутал.

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

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

b-3>А как ответил на вопрос победивший кандидат?
Я такие задачи на собеседованиях не даю