Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Или ты думаешь что человек, не справившийся с разворотом списка, топосорт при этом легко напишет?
Чушь полная, что "топосорты", что "развороты списка". Доказывают они ровно то, что HR и малейшего понятия не имеет, зачем он сидит с программистом и задаёт эти смехотворные вопросы.
Алгоритмы — это просто собранные в кучу решения каких-то задач. Их знание или незнание — всего лишь вопрос опыта и МИНУТЫ ГУГЛЕНИЯ.
Если я впервые решаю задачу, даденую на работе, я в офисе даже палец о палец не ударю, потому что тупо не могу думать в офисной помойке — я собираю материал, приношу домой и в тишине и спокойствии начинаю думать. Ну и что умного ты хочешь выяснить о человеке, когда он на нервах сидит в кабинете незнакомой организации и какое-то существо в свитере и с бородой задаёт с прищуром ему вопросы! Я и возраст-то вспоминаю секунд пять, что уж говорить про красно-чёрные деревья и ряды Фурье!
Просто в России, как типичной диктаторской стране чморения и выпежонства, принято, что соискатель — "никто и звать его никак", а работодатель — "и бог, и царь", отсюда абсолютно неадекватная обстановка "мальчик на экзамене", которая ещё больше усиливает тщеславные позывы вопрошающего на унижение "испытуемого".
В реальности есть контора, у которой есть задачи и есть люди, которые эти задачи могут выполнить. Рынок "купил-сделал", никто не выше другого. И если человек знает своё дело, он не обязан оправдываться перед упомянутыми прыщавыми "сеньорами" почему он не может написать потокобезопасный стек — просто дай задачу и не мозоль глаза; за пару дней можно решить любую среднюю задачу и по коду будет видно, что человек будет выдавать в продакшн.
При нынешнем маразме принятия на работу есть большой шанс, что как раз хороший спец (один на сто) пролетит, а "специалист по собеседованиям" будет сосать из вас зарплату до следующего собеседования. А всё лишь потому, что дилетант в HR прочёл про "задачки на собеседовании" и не применив даже капли мозга поехал "отсеивать". А контора, за свою расхлябанность при наёме "отдела кадров", терпит убытки и сортирует УГ, нанятое "по всем правилам". Что ж, кесарю — кесарево.
Мы выяснили, что головоломки — пустая трата времени. Они не могут ничего предсказать, и в процесс собеседования включены только для того, чтобы дать возможность интервьюеру почувствовать себя умнее
Вот оказывается для чего все эти 23-летние сеньоры задают шандарахнутые вопросы про гномиков и разворот списков.
Кстати в конце статьи описан новый подход гугла к найму, который так не нравится многим программистам, верящим в свою уникальность.
Здравствуйте, Ikemefula, Вы писали:
H>>...люди просто РЕШАЛИ ЗАДАЧИ. Сами. Без "банды четырёх".
I>В винде можно найти практически все паттерны, которые есть у "банды четырех" и целая куча других, не менее популярных.
Вот именно — паттерны "получились сами", их применили, потому что они были нужны. Сейчас всё ровно наоборот — бегает куча "списиалистов", которые знают шаблоны и так и ждёшь от них "хелловорлд" на 20 экранов — "а ларчик просто открывался".
I>Если человек мало чем интересуется, то как правило, он всякие паттерны вряд ли будет знать.
А что в знании ваших паттернов такого важного?? Я же специально дал вначале пример винды — вы что, прочли и так ничего и не поняли? Тогда какой смысл "всем интересоваться" как любопытный дельфин?
I>Как он будет общаться с коллегами по цеху — не ясно.
Да как веками это делали — на родном языке. Только вот из моего опыта я даже и не вспомню, хоть раз была ли у меня потребность разжёвывать "а вот тут я при помощи паттерна "фасад"..." — как правило, нормальному программисту объясняешь всё "в квадратиках", остальное он легко допирает сам.
I> Как минимум, паттерны нужо знать, ибо почти во всех источниках используется этот язык паттернов.
гыг Ну если только читать книги со словом "паттерны" — да, без них никуда! А так, в нормальной литературе, я не встречаю этого шарлатанства. Наверное, потому что не все авторы заражены Паттернами Головного Мозга. Поверьте мне, ещё лет 5-10 и про ваши шаблоны никто и не вспомнит, это просто сейчас раскрутили базворд, да деньжат на лохах книгах подняли — типичная преходящая мода. А главное, мода-то ни на что! Всё равно, что назвать чесание уха "ирскрэтчем", а все, кто просто говорит "я почесал ухо" — еретик и не следует канонам старейшин.
Здравствуйте, Undying, Вы писали:
U>На самом деле в данной задаче и от всего перечисленного толку немного. Классическая ЦОС заточена под часто снимаемые сигнала. А когда данные идут раз в десять секунд работает это все кое как.
Блин, с каждым днем, я все больше и больше в шоке от кывта, точнее от современных программистов. Обычно я всегда тут нахожу, что ответить, но сейчас я ступоре, у меня просто нет слов.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, gandjustas, Вы писали:
G>>Вот оказывается для чего все эти 23-летние сеньоры задают шандарахнутые вопросы про гномиков и разворот списков.
PD>Что за разворот списка ? Перевернуть линейный список ? PD>Если уж эта задача стала головоломкой — все, приехали. PD>Впрочем, судя по http://rsdn.ru/forum/java/5303570.1
Любая задача на собеседовании, которая:
1) Не имеет отношения к потенциальной работе
2) Требует знания конкретных алгоритмов
3) Требует решения на бумажке
Фактически является головоломкой, которая нужна только для удовлетворения самолюбия собеседующего.
Здравствуйте, -n1l-, Вы писали:
N>Пффф, пока вы тут писали эту простыню, я взял листочек....
Зря не помял — так удобнее использовать.
N>...и решил задачу двумя разными способами.
Я так понимаю, ты ждёшь медаль "главный переворачиватель списков"?
N>Эта метода: N>- Я специалсит, я не буду писать велосипед, я могу дома сделать так, как хочу, все уже написано, давайте подставим стопицотую библиотеку в код, плевать, что мы ее будем использовать на 3% максимум.
Мне кажется, или ты только что на меня наехал?
N>Знание алгоритмов и структур данных позволяет решать задачу более элегантно и понятно.
Ну так слушай:
1. Ты ни струя ни знаешь ни первого, ни второго, иначе бы решил эту, с позволения сказать, "задачу" не "на бумажке", а сходу из головы — она тривиальна и тому, кто "знает алгоритмы", бумажки не нужны. Ты же себя таким всезнайкой выставляешь, правильно?
2. "Более элегантно" только шорты расстёгиваются, твоё решение — обычное, сотню раз описанное и непонятно, кому ты хотел его написать "более понятно".
3. Рукав вытри — в чём-то коричневом.
Здравствуйте, gandjustas, Вы писали:
G>А что есть "умение программировать как таковое"?
Качества программиста, инвариантные относительно используемой технологии.
IO>>Может лучше брать просто программистов, а не "SharePoint программистов"? G>Нет, не лучше. Слишком многому надо научить до того как пользу принесет.
Просто я работал с этим вашим Шарепоинтом, поэтому интересуюсь. По-моему там бессмысленно пытаться
выучить всё нюансы. Всегда вылезет что-то неожиданное. Нужно постоянно лезть туда рефлектором, чтобы
понять как оно работает, или в лучшем случае гуглить не решил ли уже какой народный умелец проблему.
Или вы делаете типовые проекты обходя все острые углы? Тогда это получается вроде "программиста/дизайнера jQuery"
ИМХО, тупиковое направление. Выучить стопицот подробностей о монстрообразной системе, которые имеют крайне узкое применение...
Завтра Микрософт переведёт всё это на чистый AJAX (уже наполовину сделали), и значительная доля этих знаний станет мёртвым грузом.
И если говорить о найме: людей, которые всё это знают всегда будет слишком мало, и что самое плохое, среди них будут
доминировать кадры с закостеневшим мышлением, привыкшие решать задачи шаблонами.
Откуда же его [независимый суд] взять, если в нем такие же как мы? (c) VladD2
Здравствуйте, SimpleQuestion, Вы писали:
SQ>Примерно так: рекурсивно уходим в Next, на текущей итерации достаем Name. Условие выхода — Next == null. Оптимизируем в цикл, если нужно.
Я вроде конкурс на самый извратный алгоритм не объявлял
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Потом они пишут код , от которого уши вянут. ... Потом такой код становится нормой . Потом объяснить, что это не норма, а бог знает что, становится невозможным : тебя просто не понимают, все же так пишут.
О! Хорошо сказал! Вот примерно так я чувствую себя при общении с апологетами "паттернов проектирования" — думаешь, "где ж вы все такие умные были, когда 20 лет назад писали Винду?!" — ведь тогда никто не жаловался "ты не используешь фабрику!", люди просто РЕШАЛИ ЗАДАЧИ. Сами. Без "банды четырёх". А сейчас каждый задрот мне тыкает ехидно: "Какие паттерны ты знаешь?" (это я работу недавно искал) А я им: "Понятия не имею! Я пишу при помощи мозгов." — посмеялись, разошлись. Так, наверное, до сих пор и ищут "специалистов по паттернам"!
Здравствуйте, gandjustas, Вы писали:
I>>В сложных проектах часто встречаются структуры отличные от List. Например всевозможные оптимизации или сложные структуры навроде списковых, графовых, древовидных и тд. Здесь уметь всякие преобразования и обходы крайне необходимо.
G>Тебе лично сколько раз приходилось писать разворот списка в настоящем проекте? G>Вот мне ровно 0. Думаю подавляющему большинству посетителей форума — также.
Правильно ! И дело в том, что во время работы нужно решать целую кучу всяких частных случаев, которые встречаются не чаще раза в жизни.
Нет необходимости писать код который пишут все, такой код в 99% уже написан.
Ответь внятно на вопрос: "Если человек не может сделать обход такой простой структуры, как список, то на каком основании можно считать, что он сможет обойти граф или дерево ? "
А если обходить надо будет не список, а дерево, и, вдобавок, асинхронно, и, вдобавок, впихнуть дерево в N-представлений, что бы отразить самые разные аспекты ?
Я сильно сомневаюьс, что человек сможет обойти дерево, если не смог обойти список.
Обход дерева — xml, json, файловая система, реестр, урлы на сайте и тд и тд.
Собтсвенно в этой задаче нет ничего, что бы могло поставить хорошего кандидата в тупик.
Если решения нет, то однозначно кандидат не интересует, ибо
1. вообще не работал со списковыми структурами (может всю жизнь матрицы умножал)
2. малый опыт (вчера научился программировать)
3. умеет решать только стандартные задачи (вызубрил одну книгу и больше ничего не умеет)
4. не понимает указатели (WTF ???)
в этой задаче нужно уметь
1 сделать простейший обход
2 использовать указатели-ссылки
Если не понимает указатели-ссылки, то на каком основании он называется программистом ?
Вобщем, я не видел сильных девелоперов, которые не могли бы решить такое. Есть люди, которые отказываются решать подобные задачи. Есть люди которые волнуются во время собеседования.
Обычно несколько подсказок и достаточное количество времени помогает во втором случае.
А если человек отказывается решать такое — пусть идет работать к конкурентам, тут я ничего не могу поделать
Ну и надо понимать самое главное — у специалиста, скажем, по звуку нет смысла спрашивать такое, ибо есть вещи намного более важные.
У лида или архитекта так же незачем спрашивать такое, т.к. есть вещи более важные.
Это разговор ни о чем.
Вы никогда не переубедите ни меня, ни Ночного смотрящего, ни какого-либо другого грамотного специалиста в том, что переворот списка — это ненужная абракадабра.
Потому, что в этой задаче заложены многие основы современного программирования и это факт.
На работах со ссылками основаны все нынешние паттерны ООП.
Яркий пример — декоратор.
На тех же ссылках основаны все нынешние высокоуровневые яп, так как вы не работаете на прямую с данными, вы работаете с ссылками на них.
Это понимание делает возможным программирование с использованием языка, а не на языке.
В итоге вы становитесь независимым от конкретного яп и спокойно можете переключатся с одного на другой.
Но самая главная ирония в том, что вы и некоторые товарищи выше, просто демонстрируете зазубривание конкретного языка, платформы, фреймворка.
И после всего этого называете зубрилами других людей, которые много работали и трудились, что бы разбираться в сути.
G>>Мы выяснили, что головоломки — пустая трата времени. Они не могут ничего предсказать, и в процесс собеседования включены только для того, чтобы дать возможность интервьюеру почувствовать себя умнее
G>>Вот оказывается для чего все эти 23-летние сеньоры задают шандарахнутые вопросы про гномиков и разворот списков.
I>Разворот списка это _не_ головоломка, а в стате говорится именно про головоломки.
Зависит от контекста.
Если берут человека кодить webui или приложения для Андроида, то это будет головоломкой.
Здравствуйте, herethere, Вы писали:
H>О! Хорошо сказал! Вот примерно так я чувствую себя при общении с апологетами "паттернов проектирования" — думаешь, "где ж вы все такие умные были, когда 20 лет назад писали Винду?!" — ведь тогда никто не жаловался "ты не используешь фабрику!", люди просто РЕШАЛИ ЗАДАЧИ. Сами. Без "банды четырёх".
В винде можно найти практически все паттерны, которые есть у "банды четырех" и целая куча других, не менее популярных.
Например фабрики можно найти в виде ClassFactory в COM, там же можно найти локатор в виде моникеров, chain of responsibility в xml/html dom, composite там же, command во всех библиотеках и тд и тд и тд.
>А сейчас каждый задрот мне тыкает ехидно: "Какие паттерны ты знаешь?" (это я работу недавно искал) А я им: "Понятия не имею! Я пишу при помощи мозгов." — посмеялись, разошлись. Так, наверное, до сих пор и ищут "специалистов по паттернам"!
Если человек мало чем интересуется, то как правило, он всякие паттерны вряд ли будет знать. Как он будет общаться с коллегами по цеху — не ясно. Как минимум, паттерны нужо знать, ибо почти во всех источниках используется этот язык паттернов. Вместо погружения в сотни тысяч строк кода можно описать достаточно адекватную модель задачи при помощи паттернов и это будет просто и понятно.
Здравствуйте, Undying, Вы писали:
U>Односвязный список это экзотика. Его переворот тем более. Адресная арифметика в C# это антинавык. Накладывать маски уметь желательно, но не критично, т.к. если человек этого не умеет, но умеет программировать обучение занимает минут 15.
Нужны не конкретные знания, а умение их применить правильно и быстро.
Односвязный список это ни разу не экзотика, это основы структур данных. Не бывает человека, который хорошо понимает структуры данных и не знает что такое связный список.
U>Вопрос по маскам на собеседовании будет нормальным, если кандидат утверждает, что, например, программировал парсеры бинарных протоколов. Если же человек говорит, что занимался допустим чисто программированием форм, то вопрос будет странным.
Ничего странного. Часто люди отвечают на такие вопросы и это всегда большой плюс.
Здравствуйте, Ikemefula, Вы писали:
I>Отдохни уже — мы давно выяснили что кроме твоей области всё остальное говно.
Не только всё, но и все.
А так да, тут я отдыхаю.
Здравствуйте, -n1l-, Вы писали:
N>Пффф, пока вы тут писали эту простыню, я взял листочек и ручку набросал схему ссылок и решил задачу двумя разными способами. N>Первый способ O(n) с использованием нескольких вспомогательных ссылок. N>Второй способ O(n*n)с использованием стека, чисто как эксперимент, так что публиковать его не буду.
N>
N> static void ReverseOne(ref Element list)
N> {
N> Element current = list;
N> Element previous = null;
N> Element result = null;
N> while (current!=null)
N> {
N> previous = current;
N> current = current.Next;
N> previous.Next = result;
N> result = previous;
N> }
N> list = result;
N> }
N>
N>Знание алгоритмов и структур данных позволяет решать задачу более элегантно и понятно.
Это называется "элегантно и понятно"?!
я смотрю на этот говнокод и вижу кучу присваиваний, какую-то мешанину из previous current Next.
это нифига непонятно, и уж точно не элегантно.
каждая примитивная операция должа иметь свое имя, тогда код становится понятным.
что характерно, никакого знания алгоритмов и структур данных тут не нужно.
у односвязного списка есть только две операции — отрезание головы и добавление в начало.
и так уж получилось, что как их не комбинируй, список всегда будет разворачиваться
так что для разворота списка, вместо заучивания структур данных, надо просто написать интерфейс списка, и задача решится сама собой
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, gandjustas, Вы писали:
G>>На качество и эффективность самое большое влияние оказывают умение читать код, а не писать. НС>Это связанные умения.
Практика показывает что не связанные.
Очень мнгого программистов видел, которые генерируют тонны кода. Обрабатывают сотни кейсов, которые никогда не встретятся из-за особенностей api, закладывают гибкость, там где она не нужна итп. почти весь код бесполезен.
Писать код они точно умеют.
G>>На втором месте — знание среды, в которой работает. Тройку замыкает усидчивость и внимательность. НС>Это не объясняет, почему у разных программистов с одинаковым опытом производительность может отличаться на порядок.
Именно объясняет. Исследования проводились как раз на предмет как пишут. Считали количество программ, багов итд. А вот как раз умения за пределами кодинга и отладки не проверяли. Моя практика показывает, что наиболее эффективные программисты могу за час просмотреть кода на 500+ строк и рассказать потом как он работает, какие проблемы и как улучшить.
G>>Умение жонглировать ссылками оказывает настолько маленькое влияние в enterprise разработке, что даже упоминать смешно.
НС>Нет, смешно это когда человек, претендующий на работу программиста, не в состоянии справится с примитивной ссылочной конструкцией. И энтерпрайз, он очень разный, не обобщай шерпоинт на все остальное.
Да не нужно это умение. Как бы ты не пытался доказать обратное. У тебя нет ни фактов, ни адекватных доводов. Везде только твое неподкрепленное ничем мнение.
НС>>>Компьютер еще дизайн софта самостоятельно делать не научился. Так что пока только головой. G>>Но можно писать так, чтобы минимум удерживать в голове.
НС>Иногда нельзя. В DSL, к примеру, без понимания таких конструкций просто делать нечего, там косвенность в 3-4 уровня — норма. И никакие алгоритмы тебя не спасут, только полномасштабные средства, которые сделают за тебя вообще все.
О да, каждый день программисты пишут dsl_и 😃
G>>Поэтому самый лучший разворот списка:
НС>Чем он лучший? Тем что кода в два раза больше надо писать?
Тем что не надо ничего держать в голове. Нету циклов со сложными инвариантами, и с точки зрения платформы это оптимальный способ.
НС>>>Практика именно это и показывает. G>>У нс разная практика.
НС>Это я уже понял. Кто то под шерпоинт пишет, а кто то и сам шерпоинт.
Сам шарепонт написан индусами. Под капотом такой страшный код, что иногда удивительно как он работает. Статический анализ на сборках sp выдает миллионы замечаний. Тем не менее МС говорит что у sp 120M пользователей по всему миру.
И это не только sp такой. каждая корпоративная платформа такая. Где-то чуть лучше, где-то хуже. Это не потому что разработчики плохие. Это экономика разработки enterprise софта такая.
Здравствуйте, Undying, Вы писали:
U>Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>По условиям задачи исходный список — однонаправленный. Предлагаешь загонять односвязный список в List, а потом после реверса выгружать?
U>Можно узнать для каких практических задач целесообразно использовать однонаправленный список? Я вот за десять лет практики не видел ни одной такой задачи. На практике в 99,9% случаев использование однонаправленного списка это и синтаксический и производительный оверхед. Так в чем смысл спрашивать на собеседовании задачу, не встречающуюся на практике?
Ну я использую односвязные списки для хранения полилиний, проводников на печатных платах, иногда для контуров полигонов.
На некоторых моих задачах односвязный список незаменим, а двусвязный — избыточен.
Стандартный std::list здесь непригоден, списки реализованы на основе массивов, вместо указателей используются индексы, поэтому оверхед по памяти минимальный.
Задача разворота односвязного списка в моем случае используется для объединения пары проводников в один.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
G>>>>Не правильно, разворот списка не имеет отношения к реальной программе. I>>>Объясняю еще раз — кроме ссыдлк-указателей и тд, в каждой программе всегда и везде будет уникальный код, который пишется практически каждый день. G>>И что?
I>Это и нужно проверять, как человек умеет писать такой уникальный код, который не сводится к типовым задачам.
Не понял, зачем?
I>Умение писать такой код это умение обучаться, умение решать проблемы.
Нет, умение обучаться не связано с умением писать код.
I>>>Нужны способности писать этот уникальный код, а не пытаться всё свести к типовой задаче. G>>Нужны способности писать этот уникальный код, а не пытаться всё свести к развороту списка. I>И ты проверяешь способности писать уникальный код с помощью типовой задачи. Я правильно тебя понял ?
Нет, я же говорю, что писать уникальный код приходится редко. Незачем проверять это умение на собеседовании.
G>>>>Или по итеративному вычислению квадратного корня? I>>>Фильтруют, не переживай. G>>Не видел. I>Мало видел.
Много видел.
I>>>Оставшиеся 20% задач как раз и создают бОльшую часть проблем. Если кандидат начнет сводить их к типовым, получится хаос. G>>Нет. Как раз проблемы возникают в совершенно типовом коде. То есть плотность ошибок примерно одинаковая, но типового кода тупо больше. I>Наверное это особенности Шарепоинта или тех людей которых ты нанял, раз в типовом коде плотность ошибок такая же как и в остальном коде
Нет, эта статистика постоянная и устойчивая во времени, практически не зависит от языка и среды. Скорее всего предел человеческой внимательности.
I>>>Естественно, ты же и асп-нетчиков брал точно так же — по типовым задачам. А если человек умеет решать нестандартные задачи, то как правило ему разбираться будет легко. G>>Нет, как раз их брали по-другому. I>Конечно по другому — давали типовые задачи для асп-нета.
Нет, как раз давали головоломки.
I>>>Ты похоже начал сам с собой спорить: "человек может подойти к нетиповой задаче с типовым решением в голове, а потом долго биться. И даже не поймет где он неправ" G>>Да. Просто человек заранее не понял что задача нетиповая. Если бы заранее понял, то её проще к типовой свести, чем решать как есть. I>Если задача сводится к типовой, это просто типовая задача.
Нет. Иногда можно условия поменять.
I>>>Смысл в том, что типовые задачи создают меньше всего проблем в силу того, что они отработаны чуть не до автоматизма. А остальные задачи создают бОльшую часть проблем. G>>Нет, типовые задачи создают столько же проблем. Плотность ошибок одинаковая. Так как типовых задач больше, то и ошибок в них больше. I>Это чушь. Типовые пишутся даже пьяным без ошибок.
Статистика говорит обратное.
G>>С чего ты взял? Как раз большая часть любых задач решается именно комбинированием существующих кусочков. G>>Реализация алгоритма, который не разлагается на другие, требуется крайне редко. I>Разлагается на другие и типовая задача это две большие разницы.
Почему же? На каком-то уровне декомпозиции будут кусочки, которые ты уже писал. Поэтому задача резко становится типовой.
Иногда бывает что не все кусочки ты уже писал, и если по внешней похожести твой мозг определил задачу как типовую, то ты даже не поймешь что не так сделал.
Мозг тебя очень часто обманывает. Большую часть решений человек принимает неосознано, грубо говоря на уровне рефлексов.
тобы рефлексы работали правильно — их надо тренировать. Можно натренировать человека решать нестандартные задачи. Но для него тогда большая часть задач будет нестандартными и получится велосипедостроитель. Причем у стремление решать нестандартные задачи будет так велико (неосознано конечно), что даже в уже решенной задаче он будет видеть нестандартную.
Увы для работы такие люди очень вредны, зато они успешно разворачивают списки и спасают гномиков, а некоторые даже гору фудзи передвигать умеют.
I>>> Операцией добавления N Элементов в дерево можно значит пренебречь ? у тебя уже на ровном месте O(n log(n)) + дополнительная память O(n) + отдавать данные вместо O(1) почему то O(n) G>>Конечно можно, потому что она делается бесконечно малое время, по сравнению с получением данных их внужного источника. I>Ты прав с точностью до наоборот.
Почему? У тебя данные из ничего появляются в памяти?
G>>Например при загрузке программы построить дерево. При небольших изменениях в него даже вставлять можно за log(n). I>Есть мир вне Шарепоинта.
А причем тут SharePoint? Ты считаешь что сбалансированное дерево только в SharePoint можно посторить?
U>>Т.е. ты умеешь учиться только на своих ошибках
НС>Нет, я просто знаю что доказательства по аналогии логически некорректны.
Кажись тебе хочется выдать за доказательство суждение по методу аналогии.
Пару цитат известных математиков:
«Математик — это тот, кто умеет находить аналогии между утверждениями, лучший математик — тот, кто устанавливает аналогии доказательств, более сильный математик — тот, кто замечает аналогии теорий; но можно представить себе и такого, кто между аналогиями видит аналогии». Стефан Банах.
«Возможно не существует открытий ни в элементарной, ни в высшей математике, ни даже, пожалуй, в любой другой области, которые могли бы быть сделаны без аналогии». Дьёрдь Пойа.
То есть, не надо бояться аналогий.
Здравствуйте, gandjustas, Вы писали:
НС>>Разворот списка, по сути проверяющий понимание концепции указателя не имеет отношения к работе? G>Чаще всего да.
Ясно. Лично нам такие программисты не нужны.
G>Если используется ЯВУ, то правильный ответ всегда List.Reverse
По условиям задачи исходный список — однонаправленный. Предлагаешь загонять односвязный список в List, а потом после реверса выгружать?
G>Указатели далеко не везде есть и далеко не всегда используются так, так думают, задающие вопрос про разворот списка.
Здравствуйте, Ikemefula, Вы писали:
I>Ответь внятно на вопрос: "Если человек не может сделать обход такой простой структуры, как список, то на каком основании можно считать, что он сможет обойти граф или дерево ? "
Если человек не может что-то сделать СЕЙЧАС, это не значит, что он это не может сделать вообще. Более того — если даже он может обойти ваш @$#^ список, почему вы так уверены, что он так же легко разрулит, скажем, сбалансированное дерево?? Гарантии — никакой.
Ну и вообще по проблеме: отнеситесь к найму человека как.... к ВЫБОРУ ДЕВУШКИ! Это не делается за час. Это невозможно выяснить до булевого "хороший/плохой". Нельзя залезть в мозги и измерить. Это вообще глупость — ТЕСТИРОВАТЬ УМ! Даже всем известный "тест IQ" — и тот оказался лажей (тоже мне, удивили!), а что вы хотите от собеседования в режиме "мы ща тебя заспрашиваем до икоты, а ты нам выдай продакшн код!".
Человек должен проявить себя в естественной среде — среди коллег или уж дома. И без подгонялова "вот вам час" (даже если задача решается за минуту) — человек просто по сути своей — живое существо и не может резко стать спокойным, особенно если он — "начинающий" или "середнячок".
Я даже "тугодума" взял бы с большей уверенностью, потому что выскочки-всезнайки (типа вот этой обидчивой девочки, которая тут с листочком и карандашом перевернула список) абсолютно не пригодны там, где требуется скрупулёзность и выверенность идей. Тут всё непросто, это на 99% психология и только 1% — какие-то технические банальности.
Здравствуйте, gandjustas, Вы писали:
G>99% смогут написать разворот списка имея компьютер и час времени. Обход дерева — 4 часа, ни раз не писав обходы до этого.
Я, конечно, извиняюсь, но о каком дереве речь идет ? Если об обычном двоичном дереве, то 4 часа — гм... Примерно по строчке в час получается.
Здравствуйте, Undying, Вы писали:
U>И переворот дерева это извращение какое-то, а не практически востребованная операция.
Почему извращение? Такое может быть, к примеру, полезно при анализе зависимостей — переворот дерева сформирует обратные зависимости.
U>Производительность работника в первую очередь снижает решение простых задач сложными методами. Например, применением рекурсии там где можно обойтись циклами.
Давно рекурсия сложнее цикла стала? По мне так в большинстве случаев все наоборот, рекурсивное решение проще, а развертыванием его в цикл пусть компиляторы занимаются.
U> И по хорошему именно умение работника решать задачи просто надо проверять на собеседовании.
Это невозможно ввиду крайне ограниченного времени собеседования. И уж тем более невозможно его использовать в качестве входного фильтра. Умение решать реальные задачи проверяется на испытательном сроке.
Здравствуйте, TK, Вы писали:
TK>Не расстраивайтесь, junior разработчики тоже бывают нужны
Прикольнее, когда в итоге на конторе одни такие юниор-сеньеры оказываются.
Здравствуйте, Undying, Вы писали: U>Если заказчиков много, то это всегда не так по совершенно объективным причинам.
Индусский аутсорс в расчет не берем.
Здравствуйте, noone, Вы писали:
N>Я погляжу на твое пренебрежение, когда от сложности сортировки будет зависеть время отклика авионики самолета или хотя бы плавность проигрывания видеофайла.
Так сколько лет и где нужно учится, чтобы ответы на все вопросы возникающие при программирование авионики и проигрывании видеофайла были у вас в голове уже после окончания обучения?
Где бы вы и сколько бы не учились, ответов на большинство возникающих вопросов у вас не будет. Т.к. вопросов возникает очень много и самых разных. Так почему вы такое значение придаете именно сортировке, которая составит малюсенькую долю возникающих вопросов? А не умению решать возникающие задачи с неизвестным ответом?
зы
А зачем при проигрывании видеофайла сортировка? Никогда не занимался этим, просто интересно.
Здравствуйте, Undying, Вы писали:
U>Критерием истины является практика. Соответственно невозможно создать теорию не пользуясь эмпирическим методом. Умозрительно можно максимум сформулировать гипотезу.
Вообще-то теория временных рядов и цос разраработаны вдоль и поперек и в твоем случае, только безграмотность предыдущих привела к плачевному результату. А, есть еще один момент, не безграмотность, а требование руководства: "прилепи чего побыстрее (вчера) и пофиг на клиента".
Здравствуйте, Ночной Смотрящий, Вы писали:
U>>Т.е. условия задачи определяется Делом. НС>Кто такой Дел и почему он у нас определяет условие задачи?
Если тебе не понятно, что такое дело, значит, у вас и в работе условия задачи определяются не ее нужностью пользователям, а чьими-то тараканами. Искренне вам сочувствую.
НС>А ты не видишь? Впрочем, если ты про односвязные списки только здесь услышал, то охотно верю что не видишь.
Что кривого-то? Прямо ответить-то никак, только юлить можешь? Ну лишние копирование памяти. Ой ужас какой — на целую микросекунду код отработает медленнее в задаче, которая выполняется сотню миллисекунд.
В стандартные хелперы, да, подобный код убирать плохо. А по месту, если очевидно, что на производительность он не повлияет, что в подобном коде плохого-то?
НС>А нам вот не нужно писать код на автопилоте в принципе, лучше вообще ничего не писать, чем потом этот автопилотный код вылавливать и переписывать. А если человек даже на собеседовании пишет код без включения моска, то чего от него можно ожидать в продакшене?
Как раз меня бы очень насторожило, если бы на собеседовании человек бросился писать оптимальным код. Так как весьма вероятно, что в реальной работе он будет делать тоже самое. И вместо того, чтобы, понимая что данное место не является критичным, свести задачу к известной и решить пусть неоптимально, но быстро и надежно, будет долго и упорно фигачить оптимальный вариант.
Здравствуйте, Undying, Вы писали:
T>>Наверное предпочел бы обсуждать сами явления, а не продираться через новые термины для старых вещей.
U>Понимание явлений теснейшим образом связано с терминологией. Т.е. изменение понимания всегда сопровождается изменением смысла терминов. Соответственно если человек не умеет работать с непривычным пониманием терминов, то он не сможет ничему научиться у людей иначе понимающих явление.
Изобретение велосипедов прогрессирует настолько, что велосипеды начинаются изобретаться даже в терминологии.
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, Ikemefula, Вы писали:
I>>Ты похоже не слышишь, что я говорю. Нет необходимости в таких спецах, если у тебя есть некотрая база. Если хорошо понимаешь, что такое "разделяй и властвуй", то легкой поймешь любой алгоритм и сможешь проанализировать его. Еще раз — любой.
E>Что, правда что ли? Расскажи нам на базе "разделяй и властвуй", почему работает генетическая диф. эволюция например?..
Здравствуйте, Ikemefula, Вы писали:
E>>Я бы, как минимум, если бы просил людей разворачивать списки, явно указал бы, что надо без памяти и быстро Или хотя бы что по возможности так. I>И тем самым ты понизишь уровень задачи ниже плинтуса.
Слушайте, не надоело еще?
Все определяется только одним, предложением программистов и спросом на них. Сейчас спрос меньше предложения, по крайней мере в Минске. Отсюда работодатель может как угодно развлекаться, когда набирает народ.
Было бы наоборот, не до развлечения с соискателями было бы, брали бы тех, кто хоть что-то умеет и доучивали бы.
Здравствуйте, gandjustas, Вы писали:
G>на хабре появилась небольшая, но фактически меняющая картину мира, статья:
гыгы Подростки вдруг осознали истину? Вообще-то даже здесь найдётся пяток толковых ребят, считающих собеседования полным фуфлом. Ничего нового гугл не открыл, просто кто-то, доведённый до отчаяния своей тупостью, вдруг осознал, что применяет совершенно левую методику и НАКОНЕЦ-ТО сказал: "А король-то голый!".
G>Мы выяснили, что головоломки — пустая трата времени.
...и не только они. Вся эта лажа "кем вы хотите себя видеть?", "какое вы животное?", "опишите недостатки предыдущих проектов" — струйня на постном масле. Уже не раз говорилось — только реальный проект (или тестовое задание, близкое к реальной работе) может более-менее показать перспективность человека. Именно "перспективность" в будущих решениях, а не "вот щас он придёт и напишет".
G>Вот оказывается для чего все эти 23-летние сеньоры...
Вот именно Понабрали студоты, пальцами крутят, проектами понтуются, а снаружи гугла народ думает: "Жираф большой — ему видней!". Хотя целая куча их проектов — мёртворождённое фуфло.
G>Кстати в конце статьи описан новый подход гугла к найму, который так не нравится многим программистам, верящим в свою уникальность.
Люди действительно уникальны. Тупизм HR-ов в том и состоит, что они хотят поставить плюсики напротив всех вопросов и сказать: "Годен!". Не всё так просто...
Здравствуйте, Undying, Вы писали:
U>Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>>Ты, видимо, ничего не понял, либо я плохо объяснил. То, что элементы лежат в массиве не значит, что их порядок совпадает с порядком следования в массиве. Это полноценный список со всеми его плюсами и минусами.
U>А в чем тогда смысл использования? Как я понимаю, список может оказаться наилучшим решением, когда производительность вставок в середину важна, а скорость прохода по коллекции нет. Вроде и полилинии, и проводники, и контуры полигонов намного чаще обходятся, чем изменяются. Минусом же является и производительность и усложнение кода — рекурсию сложнее читать чем циклы. Соответственно непонятно в чем выгода от использования списков для решения этих задач.
Почему именно список?
Списки я использую для хранения отношения "многие ко многим". Проводники состоят из сегментов, полигоны — из вершин (или сегментов, зависит от задачи) и т.д.
Количество элементов часто меняется — сегменты могут подразбиваться, объединяться, переходить из одного проводника в другой.
А как ты верно заметил, главный (+) списка — возможность быстрой вставки в середину, достаточно поправить значение поля Next.
Для добавления нового элемента не надо сдвигать все элементы массива, достаточно новый элемент добавить в конец и настроить ссылки на него. Это при условии, что свободных ячеек нет. Если они есть, то достаточно вынуть индекс вакантной позиции из одного списка и вставить в другой.
При всем этом редактировании необходимо сохранить идентификаторы сегментов, поэтому хранение в традиционном массиве непригодно — добавление элемента в середину потянет перестраивание связей между объектами.
Хранение каждого объекта независимо, как в учебнике (Объект "полигон", внутри массив вершин) неприменимо, т.к. во-первых дорого, а во-вторых необходимо, чтобы была однозначная идентификация объекта и связь его с коллекцией с минимальными накладными расходами.
Теперь о моих структурах.
Их придумал не я, в gamedev'е они применяются со времен DOS. Правда в литературе что-то подобное я встречал только в книжке Ульмана 80-х годов.
Достоинства: все данные лежат плотно и обычно целиком попадают в кеш процессора. Т.е. прыгать по такому списку получается быстрее, чем по "традиционному". Накладные расходы на выделение памяти сокращаются. Бинарная сериализация выполняется моментально, т.к. записывается не каждый элемент по отдельности, а весь массив за один вызов.
Если требуется для каждого элемента списка построить временные данные, то с традиционным списком возникают проблемы — как связать элемент списка с данными. В моем списке это решается элементарно — строится массив с размером, разным числу элементов списка. Получается отношение 1:1 без всяких хешей.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Ikemefula, Вы писали:
I>Рекурсия проще в написании, ты про это забыл ?
То что проще в написании не может быть сложнее в отладке. Сложнее в отладке может быть то, что лаконичнее в написании. Простота и лаконичность это совершенно разные, а зачастую и прямо противоположные вещи.
Здравствуйте, gandjustas, Вы писали:
G>Кстати в конце статьи описан новый подход гугла к найму, который так не нравится многим программистам, верящим в свою уникальность.
Я вот не понимаю, откуда вообще все эти дебаты? Лично мне на собеседованиях уже довольно давно вообще не задавали технических вопросов... Когда я собеседую кандидатов к себе в команду, то в первую и самую главную очередь пытаюсь понять, сумею я сработаться с человеком или нет, и посему мои вопросы направлены именно на выяснение этого факта, т.к. я не смогу нормально работать в команде с человеком, у которого проблемы с коммуникацией, будь он хоть самым распрекрасным гением.
G>>Мы выяснили, что головоломки — пустая трата времени. Они не могут ничего предсказать, и в процесс собеседования включены только для того, чтобы дать возможность интервьюеру почувствовать себя умнее
G>>Вот оказывается для чего все эти 23-летние сеньоры задают шандарахнутые вопросы про гномиков и разворот списков. IS>а может быть просто они вошли в ту стадию когда им больше нужны люди которые могут херачить стабильный код, чем те которые могут придумать что-то кардинально новое (новые проблемы) или новый подход решения старых проблем?
Я выше писал как обычно гугл принимает такие решения. Это не мнение одного человека. Обычно это база данных по сотрудникам за 10 лет и корреляция между метриками и результатами собеседования. Корреляция маленькая — гномики неэффективны.
IS>p.s. личное мнение — что на собеседовании есть место и гномикам и разговору по делу.
В том-то и дело что личное мнение. А практика обычно отличается.
D>односвязный список -- это крайне неудачный термин (в русском языке). Потому что квалификатор "односвязный" уже давно прочно занят под совершенно другое понятие "simply connected". D>А тут это слово используется в совершенно другом смысле "singly linked".
Там где (и тогда, когда) я учился, это называлось "однонаправленный" или, короче, "прямой" список. И, соответственно был "двунаправленный" или "двойной" список. Но это было давно и русской терминологии особо не было ещё.
Здравствуйте, Undying, Вы писали:
U>Ты на собеседованиях собрался только гроссов, т.е. людей с очень хорошими способностями всю жизнь посвятившими одной специализации, набирать? Во-первых, через собеседования таких людей найти не реально. Во-вторых, только гроссы на проекте малоэффективны. И даже не столько потому, что набрать только гроссов очень дорого и трудноосуществимо, сколько из-за того, что рояль за гроссами все равно носить кто-то должен.
Я говорю о том, что если хочешь полностью заменить человека, т.е. решать все его задачи так же хорошо как и он, тебе придется потратить столко же времени. По другому не бывает.
Хочешь опровергнуть — покажи как можно стать уровня гроссов менее чем за 10 лет. Не надо носить рояль, покажи эту серебряную пульку. Ну хотя бы е гроссов, но по ЭЛО что бы было близко.
U>А почему надо понимать именно производную?
Ты лучше читать научись. Я на примере производной показал тот же принцип — понимаешь базу, можешь применить её сколь угодно широков.
Знаешь ты критерий Вилкоксона — значит тебе не надо запоминать случаи его применения.
Сумел прочесть одну книгу — сумешь прочесть и другую.
U>Если у человека есть способности, то он сможет понять принцип "разделять и властвуй", даже если ранее его не знал и соответственно не понимал.
Ага, само собой появится в голове знание такое. Пока что нет способа замерить способности, потому проверяют знания и умения. О способностях можно предполагать, если есть хороший период для наблюдения.
U>Т.е. проблемой проверки конкретного понимания на собеседовании является то, что невозможно понять почему человек не понимает какой-то принцип: 1) из-за того, что у него способностей 2) из-за того, что у вас просто разная терминология 3) из-за того, что человек с такими задачами не сталкивался
Во, чую, скоро ты выдаешь еще одну новую хронологию терминологию
U>Также очень сложно отличить знание от понимания. А человек много знающий, но не имеющий способностей для того, чтобы понять как эти знания применять это худший выбор. Т.к. для таких людей характерна завышенная самооценка. А такие люди не только приносят мало пользы, но еще могут принести и массу вреда.
С запоминанием есть одна проблема — мелочи никогда не запоминаются без понимания и без применения. Если человек сел в лужу из за тривиального цикла на односвязных списках, то есть сильные сомнения в том что он понимает как применять
1. циклы
2. списки
3. ссылки-указатели
И в общей массе, удя по собеседованиям за без малого 10 лет, люди, которые не могут решить такую задачу, ничего впечатляющего показать не могут. Регулярно появляется товарищ который отвчает на все вопросы, но на задаче сваливается.
Как правило, причины простые, я это обязательно проверяю. Это может быть "летун", т.е. любитель менять работы или просто постоянно ходит по собеседованиям, ище ЗП на 100$ больше. Или человек с хорошей памятью, которй, скажем, прочитал за неделю всего Рихтера и знанием деталей может ужаснуть. Это может быть новичек который еле-еле освоил ровно одну область небольшую и в ней еще ничего не успел забыть. Есть люди которые искаропки говорят очень гладко и стройно, аж заслушаться можно.
Вот с такими людьми единственое средство борьбы это написание кода. Прочитал Рихтера — покажи кодом, как ты умеешь применить эти знания. Бегаешь по собеседованиям — вот тебе уникальная задачка. Освоил область небольшую — продемонстрируй, насколько ты освоился. Говоришь гладко — изложи мысли так же гладко и в коде.
Есть подтверждение — хорошо. Нет — до свидания. И я даю обычно больше одной задачи, просто одна большая по времени, строчек на 10-15 от силы, остальные можно и устно или просто картинкой изобразить и тд.
G>Мы выяснили, что головоломки — пустая трата времени. Они не могут ничего предсказать, и в процесс собеседования включены только для того, чтобы дать возможность интервьюеру почувствовать себя умнее
G>Вот оказывается для чего все эти 23-летние сеньоры задают шандарахнутые вопросы про гномиков и разворот списков.
а может быть просто они вошли в ту стадию когда им больше нужны люди которые могут херачить стабильный код, чем те которые могут придумать что-то кардинально новое (новые проблемы) или новый подход решения старых проблем?
p.s. личное мнение — что на собеседовании есть место и гномикам и разговору по делу.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Что за разворот списка ? Перевернуть линейный список ?
С какой радости, ты узнаешь про то, какой список, только задав кучу уточняющих вопросов. А так чаще речь про некий абстрактный "список".
G>Мы выяснили, что головоломки — пустая трата времени. Они не могут ничего предсказать, и в процесс собеседования включены только для того, чтобы дать возможность интервьюеру почувствовать себя умнее
G>Вот оказывается для чего все эти 23-летние сеньоры задают шандарахнутые вопросы про гномиков и разворот списков.
Разворот списка это _не_ головоломка, а в стате говорится именно про головоломки.
Гугл говорит про "structured behavioral interviews". И вот "разворот списка" при правильном применении идеально вписывается в этот подход. Скажем если ты ждешь результата "написал — не написал", то лучше вообще собеседование не проводить, а брать только по резюме и рекомендациям.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
НС>>>Разворот списка, по сути проверяющий понимание концепции указателя не имеет отношения к работе?
G>>Чаще всего да. G>>Если делается низукоуровневый код на C, то задача может быть релевантна. Если используется ЯВУ, то правильный ответ всегда List.Reverse, все остальное является плюсом, только если кандидат умеет успешно пользоваться List.Reverse.
I>В сложных проектах часто встречаются структуры отличные от List. Например всевозможные оптимизации или сложные структуры навроде списковых, графовых, древовидных и тд. Здесь уметь всякие преобразования и обходы крайне необходимо.
Тебе лично сколько раз приходилось писать разворот списка в настоящем проекте?
Вот мне ровно 0. Думаю подавляющему большинству посетителей форума — также.
Здравствуйте, gandjustas, Вы писали:
G>Тебе лично сколько раз приходилось писать разворот списка в настоящем проекте? G>Вот мне ровно 0. Думаю подавляющему большинству посетителей форума — также.
Да причем тут это? Есть большая толпа что хочет крутую зарплату. Ка прикажешь их отсеивать? По сути для работы пофиг кого брать.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Беда в том, что они сплошь и рядом. Про List.Reverse знают, как работает — их не интересует, а для суммы арифметической прогрессии ищут класс ArithmeicProgression, а не найдя — встают в тупик и постят запросы в форум.
Ну и понимают, что это смешно и программируют "бедную формулу". Но каково возиться в говне(коде), когда вместо reverse начинают фантазировать различные извращения.
Здравствуйте, Ikemefula, Вы писали:
I>В сложных проектах часто встречаются структуры отличные от List. Например всевозможные оптимизации или сложные структуры навроде списковых, графовых, древовидных и тд. Здесь уметь всякие преобразования и обходы крайне необходимо.
Да не в этом вовсе дело. Если бы были интересны какие то алгоритмы по графам, это еще полбеды. Но разворот списка выбран потому алгоритм прост как 3 копейки. Т.е. проверяется даже не алгоритмика, а способность моска понять концепцию ссылки. И если человек даже это не способен понять, то программист из него как из говна пуля.
Здравствуйте, herethere, Вы писали:
H>Чушь полная, что "топосорты", что "развороты списка".
Сильный аргумент.
H> Доказывают они ровно то, что HR и малейшего понятия не имеет, зачем он сидит с программистом и задаёт эти смехотворные вопросы.
При чем тут ХР? Я не ХР даже близко.
H>Алгоритмы — это просто собранные в кучу решения каких-то задач. Их знание или незнание — всего лишь вопрос опыта и МИНУТЫ ГУГЛЕНИЯ.
Так речь то не про алгоритмы, а про то что надо понять, умеет ли моск собеседуемого нормально работать с концепцией ссылок.
H>Просто в России, как типичной диктаторской стране чморения и выпежонства, принято
В России, между прочим, в среднем интервью намного менее формальны, чем, к примеру, в США. Если ты даже в РФ собеседования не тянешь — тут уж не работодатели виноваты.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
I>>>В сложных проектах часто встречаются структуры отличные от List. Например всевозможные оптимизации или сложные структуры навроде списковых, графовых, древовидных и тд. Здесь уметь всякие преобразования и обходы крайне необходимо.
G>>Тебе лично сколько раз приходилось писать разворот списка в настоящем проекте? G>>Вот мне ровно 0. Думаю подавляющему большинству посетителей форума — также.
I>Правильно ! И дело в том, что во время работы нужно решать целую кучу всяких частных случаев, которые встречаются не чаще раза в жизни. I>Нет необходимости писать код который пишут все, такой код в 99% уже написан.
То есть ответ "ни разу"? Я не сомневался.
I>Ответь внятно на вопрос: "Если человек не может сделать обход такой простой структуры, как список, то на каком основании можно считать, что он сможет обойти граф или дерево ? "
Так и спрашивай про граф или дерево, в чем проблема? Если только это нужно для работы.
I>Я сильно сомневаюьс, что человек сможет обойти дерево, если не смог обойти список.
Обход списка и разворот а месте — разные операции. Кроме того мы не про абстрактные навыки говорим, а про код на бумажке.
99% смогут написать разворот списка имея компьютер и час времени. Обход дерева — 4 часа, ни раз не писав обходы до этого.
I>Если не понимает указатели-ссылки, то на каком основании он называется программистом ?
Указатели далеко не везде есть. Более того, сейчас больше языков, где указателей нет.
Здравствуйте, gandjustas, Вы писали:
I>>Правильно ! И дело в том, что во время работы нужно решать целую кучу всяких частных случаев, которые встречаются не чаще раза в жизни. I>>Нет необходимости писать код который пишут все, такой код в 99% уже написан. G>То есть ответ "ни разу"? Я не сомневался.
Правильно, вещи которые люди пишут часто и по многу, на раз находятся в гугле.
I>>Ответь внятно на вопрос: "Если человек не может сделать обход такой простой структуры, как список, то на каком основании можно считать, что он сможет обойти граф или дерево ? " G>Так и спрашивай про граф или дерево, в чем проблема? Если только это нужно для работы.
Задача на граф или дерево слишком сложная, что бы давать её на собеседовании. Если скажем для отбора есть один день, как скажем делают в некоторых организациях, то можно дать и граф и дерево вместе взятые.
I>>Я сильно сомневаюьс, что человек сможет обойти дерево, если не смог обойти список. G>Обход списка и разворот а месте — разные операции. Кроме того мы не про абстрактные навыки говорим, а про код на бумажке. G>99% смогут написать разворот списка имея компьютер и час времени. Обход дерева — 4 часа, ни раз не писав обходы до этого.
Это заблуждение.
I>>Если не понимает указатели-ссылки, то на каком основании он называется программистом ? G>Указатели далеко не везде есть. Более того, сейчас больше языков, где указателей нет.
"указатели-ссылки" — нет указателей, значит есть ссылки. В приведеной задаче про реверс списка указатель ничем от ссылки не отличается, там не нужна адрсная арифметика и тд и тд.
Здравствуйте, gandjustas, Вы писали:
G>Мы берем SharePoint программистов, просим написать SharePoint код. Буквально 7 строк, но куча тонкостей, 30% на нем и отсеивается.
Вот интересно, неужели эти тонкости настолько важнее умения программировать как такового?
Сколько нужно, чтобы ввести в них человека, который немного ориентируется в ASP.NET, пару месяцев?
Может лучше брать просто программистов, а не "SharePoint программистов"?
Откуда же его [независимый суд] взять, если в нем такие же как мы? (c) VladD2
Здравствуйте, Ikemefula, Вы писали:
H>>Ну и вообще по проблеме: отнеситесь к найму человека как.... к ВЫБОРУ ДЕВУШКИ! Это не делается за час.
I>Для коммерческой организаци это слишком дорого, а надежность всё та же
Вот это я вам и повторяю — независимо от ваших глупых собеседований, всё равно вы не можете достоверно сказать, что наняли лучшего программиста. Зато рассуждений о списках — целая простыня! Тогда какой смысл во всех этих хитродуманных задачах? Отсеять ламеров? Так это вы должны уметь уже по CV и первым трём предложениям.
I>Вот как научишься разрешать такие проблемы, приходи, будешь советы давать
Если я научусь давать такие советы, ты без квартиры останешься оплачивая моё время.
Я же сказал — это СЛОЖНО, это психология (а я всего лишь прогер). Так что типичный отсев можно свести к отбору наиболее опытных (5+ лет разработки коммерческих систем) и "рассуждательных беседах" типа "как вы подступитесь к задаче такой-то". Думаю, никакие ваши смешные указатели не заменят умения видеть и описывать глобальные проблемы.
Вот задача, например, написать "торговую систему" для международной корпорации — за 5 минут можно выяснить на каком уровне думает собеседник и может ли он предвидеть подводные камни. А что можно увидеть, "оборачивая список"??
I>Умение взять в себя в руки очень важно. Умение работать в критической ситуации так же очень важно.
Та... это вы "Матрицу" пересмотрели — не должно быть у программиста таких авралов. И даже если они есть, решаются они не написанием вычурного алгоритма, а тупо либо фиксеньем проблемы (если нашлась), либо врéменными подпорками. Никто и никогда при мне не бегал по офису "всё пропало!", люди просто садятся и решают. Хотя признаю, софт для атомных реакторов или биржи не писал. Впрочем, как и многие из нас.
G>>>Мы выяснили, что головоломки — пустая трата времени. Они не могут ничего предсказать, и в процесс собеседования включены только для того, чтобы дать возможность интервьюеру почувствовать себя умнее
G>>>Вот оказывается для чего все эти 23-летние сеньоры задают шандарахнутые вопросы про гномиков и разворот списков. IS>>а может быть просто они вошли в ту стадию когда им больше нужны люди которые могут херачить стабильный код, чем те которые могут придумать что-то кардинально новое (новые проблемы) или новый подход решения старых проблем?
G>Я выше писал как обычно гугл принимает такие решения. Это не мнение одного человека. Обычно это база данных по сотрудникам за 10 лет и корреляция между метриками и результатами собеседования. Корреляция маленькая — гномики неэффективны.
т.е. им 15 лет понадобилось чтобы понять это ... метрики все время меняли или люди научились подстраиваться под метрики (сюрприз, сюрприз но если у тебя не сток опшенс — надо как то зарабатывать бонус, нет?) или это просто новый главный HR решил отличиться? неубедительно. и еще не надо забывать что гугл большая компания — то что им подходит может не подходить в средних и мелких компаниях которыйх большинство.
IS>>p.s. личное мнение — что на собеседовании есть место и гномикам и разговору по делу. G>В том-то и дело что личное мнение. А практика обычно отличается.
практика и есть реализация личного мнения. или ты что-то другое хотел сказать.
по поводу боязнии гномиков и разворота списков — а код вы писать то не боитесь? или ищите на стековерфлоу?
личное мнение и подверждение из уже непалой практики — человек который не может писать код на собеседовании не должен быть программистом.
пускай он будет дизайнером, аналитиком, менеждером, поддержкой, тестером но не программистом.
Здравствуйте, Undying, Вы писали: U>Дерево это другая структура данных.
Да тоже самое. Только листьев больше чем 1.
U>Не понял. Зачем для того, чтобы понимать, что многократное сложение при последующем делении может привести к переполнению, знать что "умножение в двоичной системе счисления считается через цикл и сдвиг"? Первое со вторым вообще не связано.
Потому, что нет в компьютере десятичных чисел.
Если относится к этому поверхностно, не вникая можно очень долго решать тривиальные проблемы.
U>Производительность работника в первую очередь снижает решение простых задач сложными методами. Например, применением рекурсии там где можно обойтись циклами. И по хорошему именно умение работника решать задачи просто надо проверять на собеседовании. Вы же пытаетесь проверять обратное — умеет ли работник видеть в мухе слона.
Переворот списка — это вообще не сложно. Тут нет ни мух ни слонов.
Есть основы, которые нужно знать.
Здравствуйте, -n1l-, Вы писали:
N>Принципиально как вы будете хранить в одном элементе хеш-таблицы несколько значений?
Считаем позицию на основе вторичного хэша, если и она занята, то считаем третичный хэш и т.д.
N>С помощью массива? И постоянно его ресайзить?
Зачем постоянно ресайзить массив?
N>Это не то, что оптимизация, это способ, самый распространенный.
Это именно оптимизация. Т.е. без списка код хеш таблицы будет проще, хоть и несколько проиграет в производительности и памяти. Но т.к. хэш таблицы это стандартные структуры данных, то все оптимизации в коде их реализации уже сделаны.
Здравствуйте, Undying, Вы писали:
N>>Св хештаблице напрямую.
U>В реализациях хештаблиц, да, список используется. Но и там задача переворота списка абсурдна.
На собеседованиях нет смысла давать стандартные задачи. От программиста в первую очередь требуется умение решать новые задачи.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
I>>>Задача на граф или дерево слишком сложная, что бы давать её на собеседовании. G>>Да ну? А как тогда проверить что кандидат таки умеет работать с графами? Это ведь нужно в первую очередь.
I>Ну да. Если человек умеет кодить, то он сумеет закодить любой алгоритм. При этом знания алгоритмов проверяется несколько другим способом.
С чего ты взял что человек, не умеющий написать на бумаге разворот списка на собеседовании не умеет кодить?
G>>>>99% смогут написать разворот списка имея компьютер и час времени. Обход дерева — 4 часа, ни раз не писав обходы до этого. I>>>Это заблуждение. G>>Что именно?
I>'99% смогут написать разворот списка имея компьютер и час времени.' I>'Обход дерева — 4 часа, ни раз не писав обходы до этого.'
I>Если человек не писал ни одного обхода, это примерно студент 1го курса университета или по скилам приравненый к такому студенту.
И? Все равно он может с помощью гугла написать код на нужном языке за полдня.
Если не умеет гуглить, то ему в ИТ вообще нельзя.
Здравствуйте, gandjustas, Вы писали:
I>>Ну да. Если человек умеет кодить, то он сумеет закодить любой алгоритм. При этом знания алгоритмов проверяется несколько другим способом. G>С чего ты взял что человек, не умеющий написать на бумаге разворот списка на собеседовании не умеет кодить?
Из опыта.
I>>'99% смогут написать разворот списка имея компьютер и час времени.' I>>'Обход дерева — 4 часа, ни раз не писав обходы до этого.'
I>>Если человек не писал ни одного обхода, это примерно студент 1го курса университета или по скилам приравненый к такому студенту. G>И? Все равно он может с помощью гугла написать код на нужном языке за полдня.
Ага, у гугла есть такая функция "код который обходит мою структуру".
Когда делается обход, всегда нужно знать свойства этого обхода и всякие разные нюансы. Гугл тебе ничего такого не даст.
G>Если не умеет гуглить, то ему в ИТ вообще нельзя.
Умение находить решения с гуглом плохо стыкуется. Решение находится в уме, а вот с реализацией конкретного варианта кое где может помочь гугл.
Для того, что бы найти решение, в голове должно быть много всего и сразу. Без этого поиск решения не работает.
Если ты ничего не знаешь про некоторое семейство алгоритмов, то ты никогда не найдешь вариант, который сводится к такому алгоритму.
Всё — приехали. Гугл тебе не поможет. Поможет только другой специалист, возможно на форуме.
Скажем, если человек хорошо умеет всевозможные сортировки, то практически искаропки он будет как минимум представлять что такое пирамиды, дерамиды и всякие деревья запросто так, включая сбалансированые, B, R, квадро и прочие.
Отсюда ясно, почему Кнут написал целый том про сортировки.
Здравствуйте, Undying, Вы писали:
U>Тогда получается, что алгоритмические задачи на практике не встречаются, т.к. все они уже давным-давно решены в стандартных библиотеках. И знание алгоритмов не нужно тем более.
Встречаются, очень редко, но встречаются.
Сейчас там самый мейнстрим — это bigdata.
Здравствуйте, -n1l-, Вы писали:
U>>Это как? У нас чудеса уже стали возможны?
N>Вот именно, что по идее в Hashtable должен существовать метод Add(key, value), который без ошибок мог выполнять вот такой код:
N>
Здравствуйте, -n1l-, Вы писали:
N>То я могу невзначай спросить, как организована оперативная память компьютера, за счет чего данные сохраняются и доступный для обработки. N>Могу даже коснуться триггера шмитта. И вы, по идее, должны хотя бы на общем уровне ответить.
Т.е. ты типичный зубрила, который спрашивает на собеседованиях всякую муть вместо того, что реально нужно для дела. Отличником был в школе и вузе?
Здравствуйте, -n1l-, Вы писали:
U>>В реальной работе условия задачи определяется Делом. N>А не тараканами ли заказчика?
Кстати, даже если у вас условия задачи определяются тараканами заказчика, то на выяснение этих тараканов у специально обученных людей уходят многие дни. А от программиста вы почему-то требуете выяснить тараканов собеседователя за считанные минуты.
Здравствуйте, -n1l-, Вы писали:
U>>В реальной работе условия задачи определяется Делом. N>А не тараканами ли заказчика?
Нет. У заказчика, кроме товарища Попила тараканов нет. Есть вполне конкретная задача, которую надо решить.
Здравствуйте, Undying, Вы писали:
U>Понимание в первую очередь означает умение подобрать структуру данных под реальную задачу по критериям простоты, надежности и производительности. Знание 25 способов сортировки пониманию никак не помогает.
Я тебе больше скажу для задачи выше о топливе пофиг на эти структуры, достаточно и обычных массивов со структурами, главное придумать правильные фильтры и алгоритмы принятия решения.
I>Для этой может хватит и массивов, а вот обработка сигналов да в реалтайме очень часто требует работу с огромными массивами данных. Скажем, объемы данных могут быть больше чем любой непрерывный фрагмента адресного пространства.
Не знаешь не пиши — это смешно. И да, у меня такие были и не раз и не влазили много куда, и что, сортировки и т.п. детские алгоритмы (переворот списка, обращения гномика, обход дерева, не помню уже все извращения, что на кывте приводились) к этому отношения не имеют. Модифицируешь алгоритм, чтобы он стал блочным и вперед к поиску "бутылочных горлышек", а они обычно или в скорости сетки (уменьшим обмен) или лишних расчетов (много чего можно закешировать, но иногда лучше пересчитать, чем кешировать — по разному бывает) или в том, что нужно использовать MKL, а не извращаться с велосипедами или просто нужно более мощное железо (ибо выше головы не прыгнешь).
I>Как тут обойтись массивами — совершенно непонятно. Наверное у тебя массивы специальные, которые не требуют адресного пространства
Порезать их на части и сделать блочный алгоритм. А вот тобой предлагаемые извраты с хитрыми контейнерами могут сильно усугубить ситуацию — баги искать задолбаешься, у уж про распараллеливание и не говорю.
Здравствуйте, Undying, Вы писали:
U>Я, например, прекрасно понимаю структуры данных. При этом если бы на форуме не тусовался об односвязном списке не знал бы ничего.
Здравствуйте, gandjustas, Вы писали:
I>>Ну значит с реверсом списка все в порядке — это не требует знания конкретного алгоритма, более того, задача выбрана предельно простой что бы чел придумал алгоритм если не сталкивался. G>Разворот списка на месте требует именно определенного алгоритма
Тогда любой код это "определенный алгоритм".
Этот алгоритм настолько тривиален, что не придумать его просто невозможно.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Ну попробуй тогда обосновать свое решение. Сколько проходов, какая сложность, есть ли ограничения на длину цепочки.
N проходов, O(N), длина цепочки ограничена емкостью стека. Но разве я где-то писал, что это оптимальный алгоритм?
И вы проигнорировали вопрос насчет извратности.
Здравствуйте, Vzhyk, Вы писали:
V>Здравствуйте, Undying, Вы писали:
U>>На самом деле в данной задаче и от всего перечисленного толку немного. Классическая ЦОС заточена под часто снимаемые сигнала. А когда данные идут раз в десять секунд работает это все кое как. V>Блин, с каждым днем, я все больше и больше в шоке от кывта, точнее от современных программистов. Обычно я всегда тут нахожу, что ответить, но сейчас я ступоре, у меня просто нет слов.
А как вы хотели. Для них уже Си — низкоуровневый язык!
А все почему? Потому, что есть типа идиома какая-то или закон, звучит так — "Нельзя писать велосипед!!!".
Любая задача сводится к тому, что она уже написана и надо просто погуглить и скопипастить код.
То, что этот код может быть неправильным, неподходящим для задачи или просто переусложненным игнорируется полностью.
Отсюда имеем плачевный результат, забери у такого "спеца" его платформу или интернет и он не способен решить ни одной проблемы.
Здравствуйте, Undying, Вы писали:
U>До меня был вариант с использованием теории фильтров и т.п. Работал не очень. Через некоторое время переписал его на свой алгоритм, взятый не из умных книжек. Работать стало отлично, хоть с объективной, хоть с субъективной (т.е. лучше чем у конкурентов) точки зрения. Так что я делаю не так?
Любым инструментов можно себе нанести увечья, разве это говорит о том, что инструмент такой? Это говорит лишь о кривизне рук использующего.
Ты просто угадал с эмпирикой — это часто работает, но не говорит о том, что эмпирика и полное отрицание науки (что ты озвучил) — это разумно.
И вообще-то мне, как человеку с высшим образованием, было бы стыдно за подобные высказывания, но, я, это уже давно понял, — динозавр в современном мире.
Здравствуйте, -n1l-, Вы писали:
N>А как вы хотели. Для них уже Си — низкоуровневый язык! N>А все почему? Потому, что есть типа идиома какая-то или закон, звучит так — "Нельзя писать велосипед!!!".
Если бы ты умел понимать прочитанное, а не развешивать ярлыки, то заметил бы, что Vzhyk ужаснулся как раз тому, что я посмел написать свой алгоритм обработки вместо того, чтобы взять готовый из книжки.
Здравствуйте, Undying, Вы писали:
U>Что значит угадал с эмпирикой? А теория ЦОС по твоему откуда появилась? Ее бог что ли написал или марсиане? Ее писали такие же люди как я и ты, но в отличие от тебя не боявшиеся сами находить решения, а не пользоваться готовыми. Если бы все мыслили так как ты люди до сих пор бы с деревьев не слезли.
Хорошо сказано. На этом можно поставить точку. Теперь точно нет слов.
Здравствуйте, Undying, Вы писали:
U>Если бы ты умел понимать прочитанное, а не развешивать ярлыки, то заметил бы, что Vzhyk ужаснулся как раз тому, что я посмел написать свой алгоритм обработки вместо того, чтобы взять готовый из книжки.
И читать ты не умеешь:
"Любым инструментов можно себе нанести увечья, разве это говорит о том, что инструмент такой? Это говорит лишь о кривизне рук использующего.
Ты просто угадал с эмпирикой — это часто работает, но не говорит о том, что эмпирика и полное отрицание науки (что ты озвучил) — это разумно.
И вообще-то мне, как человеку с высшим образованием, было бы стыдно за подобные высказывания, но, я, это уже давно понял, — динозавр в современном мире."
Здравствуйте, Undying, Вы писали:
U>Любую теорию, и ЦОС не исключение, пишут под конкретные задачи. Сбивать ракеты, к примеру, да, ей получается замечательно, лучше придумать сложно. А контролировать топливо ей в то время никто не собирался, не было технологических возможностей для этого тогда. Поэтому теория контроля топлива сейчас только создается. И создают ее не какие сверхчеловеки, а обычные инженеры, но умеющие и не боящиеся думать своей головой.
Лучше уж молчи и не позорься.
Здравствуйте, Ikemefula, Вы писали:
I>Для начала это знание помогло задетектить проблему. Скажем, большинство людей просто не в курсе особенностей быстрой сортировки и пока они будут таращить глаза и искать причину, пройдет много времени.
Даже под профайлером скорей всего источник проблемы будет виден. А уж трассировкой установить, что источник проблемы именно Sort точно удастся быстро.
I>Потом это знание помогло проанализировать причины и определиться с тем, в каком направлении копать — "стабильная сортировка с временем близком к линейному которая не будет требовать дополнительной памяти"
Полагаю, что гуглением такую информацию удалось бы найти достаточно быстро. И качество найденного решения главным образом определялось бы умениями разработчика, а не его начальными знаниями по теме сортировки.
I>К слову — до меня эта проблема висела несколько лет и фича была заморожена ибо "сортировка слишком долгая операция".
Просто люди работать не хотели или не умели. Твое принципиальное отличие от них это умение и желание решать проблемы, а вовсе не знание стопяцот методов сортировки.
Здравствуйте, Ikemefula, Вы писали:
I>В науке два основных метода — эмпирический и теоретический. Эмпирический — эксперимент. ЦОС появилась из того, что ктото нашел что преобразования Фурье применимы к дискретным функциям. А вот Фурье в основном пользовался теоретическим методом.
В ЦОС гораздо больше, чем Фурье. Это всего-лишь маленькая, но необходимая часть.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
I>>>Ну значит с реверсом списка все в порядке — это не требует знания конкретного алгоритма, более того, задача выбрана предельно простой что бы чел придумал алгоритм если не сталкивался. G>>Разворот списка на месте требует именно определенного алгоритма
I>Тогда любой код это "определенный алгоритм".
Нет. Определенный алгоритм, означает что нужно в определенном порядке написать операторы, чтобы получить верный результат.
Разворот списка на месте только одним образом можно сделать.
Мы такого никогда не требуем. Требуем чтобы работало. Хоть как-нибудь, дальше уже вопросы задаим.
В этом и суть проверки умений писать код, а не решать головоломки.
I>Этот алгоритм настолько тривиален, что не придумать его просто невозможно.
За 10 минут на собеседовании, при рисовании на бумажке? Ты слишком хорошего мнения о способностях программистов.
Человек должен быть специально натренирован решать такие задачи или он просто нагуглил.
Увы обе характеристики нерелевантны для тех, кого мы ищем.
Здравствуйте, gandjustas, Вы писали:
G>Нет. Определенный алгоритм, означает что нужно в определенном порядке написать операторы, чтобы получить верный результат. G>Разворот списка на месте только одним образом можно сделать.
Минимальные требования — умение придумать решение и его закодить. Всё.
I>>Этот алгоритм настолько тривиален, что не придумать его просто невозможно. G>За 10 минут на собеседовании, при рисовании на бумажке? Ты слишком хорошего мнения о способностях программистов.
Ну мы же не ищем специалистов по написанию типовых задач для шарепоинта.
G>Человек должен быть специально натренирован решать такие задачи или он просто нагуглил.
Именно так — "умение придумать решение и его закодить". Типовые задачи никогда не создают большого количетсва проблем и потому их не надо спрашивать на собеседовании.
Здравствуйте, Undying, Вы писали:
U>Т.е. условия задачи определяется Делом.
Кто такой Дел и почему он у нас определяет условие задачи?
НС>>В таком разрезе человек, которому надо даже для такой примитивной задачи явно указывать на то, что кривой код писать не надо, нам не нужен. U>А что в приведенном тобой коде особо кривого?
А ты не видишь? Впрочем, если ты про односвязные списки только здесь услышал, то охотно верю что не видишь.
U> На автопилоте я бы весьма вероятно написал бы примерно такой же код
А нам вот не нужно писать код на автопилоте в принципе, лучше вообще ничего не писать, чем потом этот автопилотный код вылавливать и переписывать. А если человек даже на собеседовании пишет код без включения моска, то чего от него можно ожидать в продакшене?
U>И в продакшене меня бы подобный код вполне устроил
Здравствуйте, Vzhyk, Вы писали:
I>>Профайлер скажет тебе "сортировка слишком долгая операция". Если у тебя есть познания в алгоритмах, то ты скорее всего усомнишься в этом, если нет — тупо согласишься с профайлером. V>Это если глуп (таких очень мало) или опыт пол-года(это студенты еще).
Не понял идею.
I>>Если буквально, то я не знаю наизусть ни одного алгоритма сортировки и никогда не знал. V>А "пузырек"? Его и самому придумать можно, если в школе не проходили.
Я его каждый раз и придумаваю заново, если спрашивают
Здравствуйте, Undying, Вы писали:
U>Где бы вы и сколько бы не учились, ответов на большинство возникающих вопросов у вас не будет. Т.к. вопросов возникает очень много и самых разных. Так почему вы такое значение придаете именно сортировке, которая составит малюсенькую долю возникающих вопросов? А не умению решать возникающие задачи с неизвестным ответом?
Сортировка хорошо детектит разрабов вроде "у нас всё в базу упирается", "шо тут думать, трясти надо", "такое нигде не пишут"
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Вот только там очень много математики. Преобразование Адамара там, не? Или настоящие практики это все не используют?
И куда это преобразование Адамара в бинд топлива совать? Предлагаешь с начала значения с датчика сжать что ли? Это сильный ход.
Здравствуйте, gandjustas, Вы писали:
G>Про ref не спрашиваем. Он слишком редко в дикой природе встречается.
У кого как, но тогда разбор ссылочных и значимых типов будет неполным.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, gandjustas, Вы писали:
I>>>Это и нужно проверять, как человек умеет писать такой уникальный код, который не сводится к типовым задачам. G>>Не понял, зачем? НС>В рамочку и на стенку.
То есть доводов у тебя нет?
G>>Нет, я же говорю, что писать уникальный код приходится редко.
НС>Надо говорить "мне приходится редко"
Тебе надо? Ну говори.
А вообще обрати внимание. Тебя просят дать оценку. Ты называешь цифру или диапазон, на основании чего? Обычно мозг пытается сопоставить задачу с теми, которые ты уже решал. Когда ты пишешь код, мозг работает также. Ты неосознано генерируешь код, который ты уже писал. А иногда очень осознанно делаешь копипасту.
G>> Незачем проверять это умение на собеседовании. НС>Мы уже поняли, что тебе программисты не нужны. О чем тогда ты споришь?
Это ты споришь о сущности умения разворачивать списки, пытаясь доказать что это практически Умение писать код. Но у тебя нет ни доводов, ни фактов, ничего...
Здравствуйте, Undying, Вы писали:
U>В очередной раз убеждаюсь, что больше умных слов употребляет в речи человек, тем меньше он способен думать. Я привел конкретные проблемы применения фильтров. В ответ ты ничего по существу сказать не смог. Т.к. зазубрить умные методы тебя в вузе заставили, а вот их пониманию, в частности пониманию когда их применение правильно и оптимально, а когда нет, не научили.
Ты ничего конкретного не привел, кроме того, что кто-то что-то прилепил и оно не работало.
G>Мы выяснили, что головоломки — пустая трата времени. Они не могут ничего предсказать, и в процесс собеседования включены только для того, чтобы дать возможность интервьюеру почувствовать себя умнее
G>Вот оказывается для чего все эти 23-летние сеньоры задают шандарахнутые вопросы про гномиков и разворот списков. G>Кстати в конце статьи описан новый подход гугла к найму, который так не нравится многим программистам, верящим в свою уникальность.
Для меня — точно бесполезны. Мозг у всех людей работает по-разному. Например, я тормоз в ментальном смысле, но это не значит, что я болван. Помню, было интервью в Микрософте и там задали вопрос про перфокарты, как за один проход определить, что все они уникальные в колоде. Не смог ответить. Потом придумал способ, но было уже поздняк метаться.
Но главное — все эти головоломки не имеют никакого отношения к реальной работе.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, gandjustas, Вы писали:
I>>Чисто как пример — рендеринг используется очень часто во всяких тулах которые чтото визуализируют. Тут всегда вагон оптимизаций. САПР, моделирование, визуализация, сложные вычисления — перечислять можно до понедельника. G>Чувак, 90% компаний этим не занимается.
Чтото в этом есть. Современный веб это все меньше и меньше программирования, а в кое где это уже сегодня на 100% конфигурирование. В такие компании программисты не нужны. И Шейрпоинт твой где то в этой окрестности. Поэтому навыки программировани уже неактуальны, необходимо и достаточно выяснить знание основного набора инструментов — копипаст, справочник, гугл и умение разобраться в том, что нужно сделать и в том что уже сделано.
Здравствуйте, Ночной Смотрящий, Вы писали:
U>>Я, например, прекрасно понимаю структуры данных. При этом если бы на форуме не тусовался об односвязном списке не знал бы ничего. НС>Ух жесть то какая.
А чего, тут вон был какой-то дядька, всё рассказывал про "монитор" в многопоточности. Пришлось в википедию смотреть, хотя я вроде многопоточно пишу уже лет десять. Не был бы на форуме, не знал бы, что такое монитор.
Здравствуйте, Undying, Вы писали:
U>В чем смысл частотного фильтра?
Где я говорил, что нужен обязательно и исключительно частотный фильтр?
U>Заучить методы ты сумел
А еще я их сумел использовать в реальных устройствах посложнее датчика уровня топлива в баке.
U>, а вот понять их смысл и границы применимости так и не смог.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
I>И часто очень важно обосновать правильный выбор. Есть случаи, когда можно и нужно использовать быструю сортировку, а есть случаи, когда ни в коем случае этого нельзя делать.
Зависит от области применения. Скажем, там где я сижу,
"часто" нужно написать List.Sort() и всё
"очень редко" правильный выбор обосновывает профайлер
и ни разу я не обосновывал ничего до замера.
Здравствуйте, Tanker, Вы писали:
T>Здравствуйте, gandjustas, Вы писали:
I>>>Чисто как пример — рендеринг используется очень часто во всяких тулах которые чтото визуализируют. Тут всегда вагон оптимизаций. САПР, моделирование, визуализация, сложные вычисления — перечислять можно до понедельника. G>>Чувак, 90% компаний этим не занимается.
T>Чтото в этом есть. Современный веб это все меньше и меньше программирования, а в кое где это уже сегодня на 100% конфигурирование. В такие компании программисты не нужны.
Между конфигурированием и программированием тонкая грань. Написание кода для 1С это программирование или конфигурирование?
С одной стороны конфигурирование, так как сама платформа не меняется. С другой стороны — программирование, ибо язык полн по тьюрингу и написать можно что угодно.
Но программирование это связано не связано с созданием приложения с нуля, разбиением на слои и реализацией алгоритмов. Оно связано с максимально эффективным использованием существующих возможностей платформы и расширением там где необходимо. Скорее похоже на создание плагинов, чем на разработку приложений с нуля.
Причем большая часть enterprise разработки именно такая.
T>Поэтому навыки программировани уже неактуальны, необходимо и достаточно выяснить знание основного набора инструментов — копипаст, справочник, гугл и умение разобраться в том, что нужно сделать и в том что уже сделано.
Это смотря что считать "навыкам программирования". Программирование уже давно не реализация с нуля приложений, это именно комбинирование существующих функций для достижения результата.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
I>>>Наоборот, именно там и важно понимать все эти ссылки и многое другое. G>>Нет, ссылки не нужны. Более того, часто бывает что G>>Object.ReferenceEquals(x.A,x.A) == false
I>Это как раз и требует понимания, что такое ссылки. Скажем ссылка требует уверенного понимания идентити и хотя бы представляения о том, что есть референс тайпы и валюе тайпы.
Ну ок. Человек понимает что такое value и ref типы. ИМХО без этого нельзя писать на .NET.
Что ему ее нужно? Разворачивать список на месте на бумажке? Я так и не понял зачем это умение.
Понимание identity? Что это вообще такое? Как выражается?
G>>В такой ситуации жонглирование ссылками — рассадник багов. I>После "каждый десятый пишет" твои аргументы даже слушать смешно.
Ну посмейся и приходи, серьезно продолжим разговаривать.
Ты ведь так и не сказал зачем нужен разворот списка. Вроде свелось к пониманию value и ref, но это не головоломка (см определение выше).
I>>>Судя по тому, как ты не задав ни одного вопроса предложил наихудшее решение да еще начал доказывать, что оно будет работать на раз, сильно сомневаюсь, что у тебя адекватная практика. G>>Обоснуй что худшее. Начни с твоих "особенностей". I>Хороший инженер обязан узнавать особенности до того, как начнет решения выдвигать. В противном случае это не инженер а изобретатель велосипедов.
Пффф... Ты откуда такую глупость придумал?
Есть исследование, которое показывает что инженеры обычно генерируют кучи решений и отсекают неподходящие. Причем критерий "подходящести" обычно меняется при рассмотрении новых вариантов.
Увы ссылку не найду быстро, можешь погуглить если интересно.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
I>>>Это и нужно проверять, как человек умеет писать такой уникальный код, который не сводится к типовым задачам. G>>Не понял, зачем? I>Затем, что такой код и дает больше всего ошибок.
Я же тебе писал что ты неправ. В среднем плотность ошибок одинаковая. Типовой код пишется чще, следовательно ошибок в нем больше.
Кроме того нетиповой код скорее всего пройдет формальное review и ошибки будут устранены. А весь типовой код не проходит.
I>>>Наверное это особенности Шарепоинта или тех людей которых ты нанял, раз в типовом коде плотность ошибок такая же как и в остальном коде G>>Нет, эта статистика постоянная и устойчивая во времени, практически не зависит от языка и среды. Скорее всего предел человеческой внимательности.
I>Дай уже эту статистику. I>Как то очень странно — качество решения задачи вдруг перестаёт зависеть от того, берется ли готовое решение или его надо еще родить I>Парадокс какой то.
Ты не подменяй понятия "готовое" и "типовое". Если ты 100500 раз писал обходы графов, то любой обход для тебя будет типовой. Даже если ты его с нуля пишешь.
Так вот ты пишешь таким образом 80% типового кода. Пишешь его быстро и обычно у тебя 20-50 ошибок на 1000 строк. Просто из-за невнимательности.
20% кода не типовые, ты тратишь на них большую часть времени, проверяешь несколько раз, и получаешь те же 20-50 ошибок на 1000 строк.
Вот только ты написал типового кода 200 строк, а не типового — 40. И где суммарно будет больше ошибок?
I>Но в принципе есть объяснение — твои разрабы, если ты не путаешь, не могут ни строчки написать без ошибок.
Я вот консалтингом подрабатываю, в том числе занимаюсь внедрением процессов контроля качества кода. Так вот почти у всех в только что написаном коде примерно один дефект на 6-10 строк.
Это я наблюдал в дсятке мест.
I>>>Конечно по другому — давали типовые задачи для асп-нета. G>>Нет, как раз давали головоломки. I>Кто ж вам доктор теперь ?
Ну вот перестали давать, как-то лучше стало.
I>>>Если задача сводится к типовой, это просто типовая задача. G>>Нет. Иногда можно условия поменять. I>Покажи такое изменение условия.
Как показать? Это варианты архитектуры, оценка value, переговоры с заказчиком.
I>>>Это чушь. Типовые пишутся даже пьяным без ошибок. G>>Статистика говорит обратное. I>Покажи уже эту статистику.
МакКонелла читай.
Увы ссылку на оригинальное исследование не могу найти.
I>>>Разлагается на другие и типовая задача это две большие разницы. G>>Почему же? На каком-то уровне декомпозиции будут кусочки, которые ты уже писал. Поэтому задача резко становится типовой. I>Ну, поздравляю, ты доказал что вообще все задачи в программировании типовые.
Нет, не все.
G>>Иногда бывает что не все кусочки ты уже писал, и если по внешней похожести твой мозг определил задачу как типовую, то ты даже не поймешь что не так сделал. I>Ты уже сам себе начал противоречить. Выше ты доказал что все задачи типовые.
Я говорю что два случая бывает. Но мозг тебя часто обманывает, выдавая второй за первый.
I>Но вообще ты прав — всегда есть вещи, которые ты пишешь крайне редко, но так получается, что все редкие случаи вместе взятые составляют значительный процент и создают наибольшее количество проблем.
Это только кажется. Потому что твой мозг напрягается при решении гораздо больше. А за время проведения codereview я разницы не заметил, да и наш TFS говорит о том, что разницы в принципе нет.
G>>тобы рефлексы работали правильно — их надо тренировать. Можно натренировать человека решать нестандартные задачи. Но для него тогда большая часть задач будет нестандартными и получится велосипедостроитель. Причем у стремление
I>Велосипедостроитель получается не из умения решать нестандартные задачи, а из нежелания учиться или хотя бы смотреть изредка по сторонам или хотя бы задавать вопросы.
Еще раз. Это все неосознано. От квалификации программистов не зависит.
I>Плюс ко всему между людьми есть разница примерно такая — одни лучше решают типовые задачи(быстрее и эффективнее), другие лучше решают уникальные(быстрее и эффективнее).
Не может один и тот же программист все время решать уникальные задачи. Они просто кончатся. Поэтому достоверную статистику собрать непонятно как.
Обычно распределение решаемых задач — 80\20. Как только программист натренируется решать определенные задачи — они становятся типовым для него, он их решет быстрее и у него появляется время решать другие задачи, которые для него нетиповые.
I>Велосипедостроителей примерно одинаково и там и там, причины я описал.
Я так и не понял как ты их поделил.
G>>>>Конечно можно, потому что она делается бесконечно малое время, по сравнению с получением данных их внужного источника. I>>>Ты прав с точностью до наоборот. G>>Почему? У тебя данные из ничего появляются в памяти?
I>Данные всегда в памяти.
Откуда они берутся? Они зашиты в исполняемый модуль?
I>>>Есть мир вне Шарепоинта. G>>А причем тут SharePoint? Ты считаешь что сбалансированное дерево только в SharePoint можно посторить? I>Вещи про которые я говорил, встречаются много чаще чем тебе кажется.
У тебя? Не сомневаюсь.
Здравствуйте, Undying, Вы писали:
U>Здравствуйте, Tanker, Вы писали:
T>>В данной ветке проблема не в аналогиях, а в том что Undying выдумывает терминологию для уже имеющихся вещей.
U>А ты бы предпочел термины из википедии обсудить? И что интересно нового и полезного из такой дискуссии можно было бы вынести?
Наверное предпочел бы обсуждать сами явления, а не продираться через новые термины для старых вещей.
Здравствуйте, Tanker, Вы писали:
T>Наверное предпочел бы обсуждать сами явления, а не продираться через новые термины для старых вещей.
Понимание явлений теснейшим образом связано с терминологией. Т.е. изменение понимания всегда сопровождается изменением смысла терминов. Соответственно если человек не умеет работать с непривычным пониманием терминов, то он не сможет ничему научиться у людей иначе понимающих явление.
Здравствуйте, gandjustas, Вы писали:
I>>Затем, что такой код и дает больше всего ошибок. G>Я же тебе писал что ты неправ. В среднем плотность ошибок одинаковая. Типовой код пишется чще, следовательно ошибок в нем больше. G>Кроме того нетиповой код скорее всего пройдет формальное review и ошибки будут устранены. А весь типовой код не проходит.
Ты сначала говорил про какую то статистику, а теперь оказывается, что статистики у тебя нет
I>>Дай уже эту статистику. I>>Как то очень странно — качество решения задачи вдруг перестаёт зависеть от того, берется ли готовое решение или его надо еще родить I>>Парадокс какой то. G>Ты не подменяй понятия "готовое" и "типовое". Если ты 100500 раз писал обходы графов, то любой обход для тебя будет типовой. Даже если ты его с нуля пишешь.
Обход графа это готовое решение, его только записать надо, оно же и готовое. На одном обходе ты никуда не уедешь, это всего лишь необходимая часть. Поэтому задачи
G>Так вот ты пишешь таким образом 80% типового кода. Пишешь его быстро и обычно у тебя 20-50 ошибок на 1000 строк. Просто из-за невнимательности. G>20% кода не типовые, ты тратишь на них большую часть времени, проверяешь несколько раз, и получаешь те же 20-50 ошибок на 1000 строк. G>Вот только ты написал типового кода 200 строк, а не типового — 40. И где суммарно будет больше ошибок?
" а теперь оказывается, что статистики у тебя нет"
I>>Но в принципе есть объяснение — твои разрабы, если ты не путаешь, не могут ни строчки написать без ошибок. G>Я вот консалтингом подрабатываю, в том числе занимаюсь внедрением процессов контроля качества кода. Так вот почти у всех в только что написаном коде примерно один дефект на 6-10 строк. G>Это я наблюдал в дсятке мест.
"а теперь оказывается, что статистики у тебя нет"
К консультантам обычно особое отношене — пока их науишь, дешевле, быстрее и качественнее самому научиться. КОнсультатны эт эдакие продавцы своих велосипедов, вырастают из вчерашних велосипедистов.
I>>Кто ж вам доктор теперь ? G>Ну вот перестали давать, как-то лучше стало.
Головоломки нельзя давать, если ты не понимаешь, как интерпретировать ответ. В большинстве случаев с головоломками ожидания простые — раз решил, значит крут. И это основная проблема.
Можно давать головоломки, но в большой конторе будут применять по принципу "вопрос-ответ"
I>>>>Если задача сводится к типовой, это просто типовая задача. G>>>Нет. Иногда можно условия поменять. I>>Покажи такое изменение условия. G>Как показать? Это варианты архитектуры, оценка value, переговоры с заказчиком.
Как задачи на графах решать, так там все типовое ибо сводится к обходу а он типовой. А как пример привести, так какой то value, заказчик и прочий булшыт.
"а теперь оказывается, что статистики у тебя нет"
I>>Покажи уже эту статистику. G>МакКонелла читай.
Пудозреваю, ты как то прочел его особым образом.
G>Увы ссылку на оригинальное исследование не могу найти.
"а теперь оказывается, что статистики у тебя нет"
I>>>>Разлагается на другие и типовая задача это две большие разницы. G>>>Почему же? На каком-то уровне декомпозиции будут кусочки, которые ты уже писал. Поэтому задача резко становится типовой. I>>Ну, поздравляю, ты доказал что вообще все задачи в программировании типовые. G>Нет, не все.
"Как показать? Это варианты архитектуры, оценка value, переговоры с заказчиком."
"а теперь оказывается, что статистики у тебя нет"
G>>>Иногда бывает что не все кусочки ты уже писал, и если по внешней похожести твой мозг определил задачу как типовую, то ты даже не поймешь что не так сделал. I>>Ты уже сам себе начал противоречить. Выше ты доказал что все задачи типовые. G>Я говорю что два случая бывает. Но мозг тебя часто обманывает, выдавая второй за первый.
I>>Но вообще ты прав — всегда есть вещи, которые ты пишешь крайне редко, но так получается, что все редкие случаи вместе взятые составляют значительный процент и создают наибольшее количество проблем. G>Это только кажется. Потому что твой мозг напрягается при решении гораздо больше. А за время проведения codereview я разницы не заметил, да и наш TFS говорит о том, что разницы в принципе нет.
Чудеса да и только. Отработаные решения не надо даже дебажить. А вот новые задачи съеают вагон времени на отладку. Похоже, в Шарепоинте как то все наоборот — отработаные решения так же сложные, как и новые
"а теперь оказывается, что статистики у тебя нет"
G>>>тобы рефлексы работали правильно — их надо тренировать. Можно натренировать человека решать нестандартные задачи. Но для него тогда большая часть задач будет нестандартными и получится велосипедостроитель. Причем у стремление I>>Велосипедостроитель получается не из умения решать нестандартные задачи, а из нежелания учиться или хотя бы смотреть изредка по сторонам или хотя бы задавать вопросы. G>Еще раз. Это все неосознано. От квалификации программистов не зависит.
Это слишком сильное утвреждение, что бы принимать без доказательства.
G>Не может один и тот же программист все время решать уникальные задачи. Они просто кончатся. Поэтому достоверную статистику собрать непонятно как. G>Обычно распределение решаемых задач — 80\20. Как только программист натренируется решать определенные задачи — они становятся типовым для него, он их решет быстрее и у него появляется время решать другие задачи, которые для него нетиповые.
Если свести все задачи к вбиванию символа, то 100% задач станут типовыми, прикинь, все что надо — гнать код.
I>>Велосипедостроителей примерно одинаково и там и там, причины я описал. G>Я так и не понял как ты их поделил.
Если читать, то помогает.
I>>Данные всегда в памяти. G> G>Откуда они берутся? Они зашиты в исполняемый модуль?
Ты лучше спроси что за приложение, тогда дурацкие вопросы отпадут сами собой.
Данные берутся
1. с диска
2. из сети
3. от пользователя
4. создаются самой программой
T>>Поэтому навыки программировани уже неактуальны, необходимо и достаточно выяснить знание основного набора инструментов — копипаст, справочник, гугл и умение разобраться в том, что нужно сделать и в том что уже сделано. G>Это смотря что считать "навыкам программирования". Программирование уже давно не реализация с нуля приложений, это именно комбинирование существующих функций для достижения результата.
Оно и заметно — такие комбинаторы и выдают вместо реверса списка реверс строки через стрингбилдер.
Считай это навыками программирования, а я буду считать таких людей бездарями, которые нахватались баззвордов.
Здравствуйте, gandjustas, Вы писали:
I>>Ты собеседование что ли хочеш пройти или как ? Ты его не пройдешь, ибо предлагаешь решения нисколько не интересуясь контекстом.
G>Нет, мы у себя впишем требования и посмотрим кто придет
Тогда надо и бренд сменить на наш, и зп поднять и тд и тд и тд.
Здравствуйте, gandjustas, Вы писали:
T>>Если язык полон по тьюрингу, то в программистов надо записать и тестировщиков, и тех кто с xml-xslt работает G>По сути оно так и есть.
Значит в таком признаке как полнота по Тьюрингу смысла нт никакого, а разделять надо по задачам.
T>>и поголовно всех админов и целую тучу людей которые к разработке не имеют отношения. G>Админы, которые пишут одноразовые скрипты, программистами не являются, ибо не владеют всеми средствами комбинирования.
Это какие то не те админы еще есть безопасники, билд-инженеры....
Здравствуйте, gandjustas, Вы писали:
G>>>Нет, мы у себя впишем требования и посмотрим кто придет
I>>Тогда надо и бренд сменить на наш, и зп поднять и тд и тд и тд.
G>Да ЗП и так нормальные, бренд тоже ниче так. G>Ты не юли, дай ссылку на вакансию или просто текст, если сейчас нигде не опубликована.
Все стандартно — ищется разработчик, опыт такой то, профиль такой то, на проект такой то, специфика такая то, соцпакет, зп, желательные требования — перечень баззвордов.
Здравствуйте, Ikemefula, Вы писали:
I>Я говорю о том, что если хочешь полностью заменить человека, т.е. решать все его задачи так же хорошо как и он, тебе придется потратить столко же времени. По другому не бывает.
Т.е. ты утверждаешь, что все люди обучаются с одинаковой скоростью?
Что-то повезло мне в топике с собеседниками. Для Ночного смотрящего оказалось новостью, что аналогии между явлениями можно проводить. Ты тоже отжог не хуже.
I>Хочешь опровергнуть — покажи как можно стать уровня гроссов менее чем за 10 лет. Не надо носить рояль, покажи эту серебряную пульку. Ну хотя бы е гроссов, но по ЭЛО что бы было близко.
Если тебе так милы гроссмейстеры, то Карякин стал гроссом в 12 лет.
Тезис о том, что для решения большинства реальных задач найти гроссов не удастся, да и не нужны они в большинстве случаев, ты естественно поскипал.
I>Ты лучше читать научись. Я на примере производной показал тот же принцип — понимаешь базу, можешь применить её сколь угодно широков. I>Знаешь ты критерий Вилкоксона — значит тебе не надо запоминать случаи его применения.
Проблема в том, что на практике оказывается не нужны ни понимание производной, ни понимание критерия Вилкоксона. Зато нужно понимание других вещей, которым нигде не учат.
I>Ага, само собой появится в голове знание такое. Пока что нет способа замерить способности, потому проверяют знания и умения. О способностях можно предполагать, если есть хороший период для наблюдения.
Т.е. ищут не там где потеряли, а там где светло. Замечательный подход.
I>Во, чую, скоро ты выдаешь еще одну новую хронологию терминологию
Т.е. ты считаешь, что твоя терминология заведомо правильная? И если собеседумый пользуется другой, то он заведомо не подходит?
I>И в общей массе, удя по собеседованиям за без малого 10 лет, люди, которые не могут решить такую задачу, ничего впечатляющего показать не могут. Регулярно появляется товарищ который отвчает на все вопросы, но на задаче сваливается.
Согласен, что по сравнению со проверкой знаний, задача гораздо лучший метод отбора. Но задача должна быть понятной, несложной, иметь много вариантов решения, оптимальное решение не должно являться обязательным.
I>Или человек с хорошей памятью, которй, скажем, прочитал за неделю всего Рихтера и знанием деталей может ужаснуть. Это может быть новичек который еле-еле освоил ровно одну область небольшую и в ней еще ничего не успел забыть. Есть люди которые искаропки говорят очень гладко и стройно, аж заслушаться можно.
В том числе и поэтому проверять знания на собеседовании бессмысленно.
I>Вот с такими людьми единственое средство борьбы это написание кода. Прочитал Рихтера — покажи кодом, как ты умеешь применить эти знания. Бегаешь по собеседованиям — вот тебе уникальная задачка. Освоил область небольшую — продемонстрируй, насколько ты освоился. Говоришь гладко — изложи мысли так же гладко и в коде.
Т.е. ты даешь задачу, основанную на опыте кандидата? Если заявил, что знаток Рихтера, то задачу по Рихтеру? Если так, то это очень правильный подход. Уважаю.
Здравствуйте, gandjustas, Вы писали:
НС>>А я бы порекомендовал тебе начать с Гради Буча. G>Я его лет 10 назад прочитал, увы не самая достойная книга.
А чел 1 год назад, вот теперь всех и достает.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Это задача на собеседовании. Только полный имбецил не понимает, что такие задачи дают с целью выяснить наличие определенных умений. Постоянное утягивание обсуждений в сторону прямой практической полезности этой задачи показывают узость мышления
Цели на собеседованиях бывают очень разные. Эта твоя задача может быть, как ловушкой на тех, кто пишет код стандартно, так и на тех, кто занят преждевременной оптимизацией...
Правда тут соискатель тоже может действовать двояко. Он может хотеть получить это место в любом случае, а может дать такое решение, которое, на его взгляд, лучше характеризует контору, как будущее место работы
НС>Скажи лучше, что в нем хорошего?
Ну ты же сам написал, что его пишут и понимают большинство программистов в отличии от...
Он проще, надёжнее и понятнее. Особенно если понятность измерять в секундах, нужных незнакомому с алгоритмом, что бы въехать.
НС>Знаешь, меня вот пугают все время преждевременными оптимизациями, но на практике я таких вижу только на форуме. Чтобы что то не делать, человека уговаривать долго не надо.
Я имею несколько случаев на практике... Вообще, современные инженеры от программирования имеют такую систему ценностей, что типа усложнение не беда...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
НС>>Ни в каком случае этот код не есть правильный. E>Это очень сложный вопрос.
В данном случае это простой вопрос.
E>Вот, например, давай я задам тебе похожую, но другую задачу?
Зачем?
E>Есть твой список и надо его на месте отсортировать...
Это существенно сложнее. С таким на собеседовании уже 99% не справятся.
E>Я бы вот принял и правильное решение в духе, делаем массив ссылок, сортируем, потом делаем из него список, и в духе сортируем на месте сляиниями, например. А ты?..
А я не люблю доказательства по аналогии.
E>>>А разворот списка на месте -- неготовая к исключениям и непотокобезопасная преждевременная оптимизация таки... НС>>Это не оптимизация, а при чем тут потокобезопасность вообще непонятно. E>Ну, как бы вот представь, что на предыдущем собеседовании нормального кандидата завернули на том, что он пишет непотокобезопасно, например...
Зачем мне это представлять? Ты пытаешься довести до абсурда, но цель этого непонятна.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Дороже, это когда куча наколбашенного кода плодит стадо багов, а отрефакторить все это гавно крайне тяжело.
Ну и какие проблемы плодит код обращения списка через массив?
НС>Это совсем совсем другой скилл, и его надо совсем другими задачками и вопросами проверять.
Я вот чего не понимаю, если у тебя в задании есть требование не использовать доп. память, то это полностью делает неверным ответ с массивом, так как это ответ на ДРУГОЙ вопрос.
но ты его обсуждаешь уже не как неверный ответ, не соответствующий формальным требования упомянутым в вопросе, а как просто "код, который хуже", так вот, по критерию "проще модифицировать" он, как раз, лучше, а не хуже...
НС>Нет, не значит. Иммутабельный код, к примеру, обычно проще и надежнее кода с инвариантами, но неумелые программисты, если у них нет нужного бекграунда, пишут именно инварианты. Еще один пример — парсеры правильно пишут только те, кто хотя бы немного знаком с темой, а остальные 99% без профильного образования пишут страшных каракатиц, мутных и падучих, при том что с другими задачками они худо-бедно справляются.
Но понять тоже проще тот, что с массивом, и, главное, его проще менять...
НС>С обсуждаемой задачкой все тоже самое, только на более примитивном уровне. Если человек рисует в резюме какие то весьма непростые проекты, а на практике пишет код что я привел, это означает что у человека нет даже базового бекграунда.
Либо он не понял твоего вопроса.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Ночной Смотрящий, Вы писали:
E>>2) Давай нам надо мнемного модифицировать задание? НС>Нет, не давай. Доказательства по аналогии идут в сад, потому что таким способом можно доказать что угодно.
Это у тебя невроз такой, да? Аллергия на аналогии?
Ты просил метрику простоты кода? Ну так вот, простой код просто модифицировать. Так что смотрим насколько просто модифицировать тот и другой код, в случае, если требования немного поменяются, и сразу понимаем где проще, а где сложнее
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
НС>>Дороже, это когда куча наколбашенного кода плодит стадо багов, а отрефакторить все это гавно крайне тяжело. E>Ну и какие проблемы плодит код обращения списка через массив?
Я вот, честно, уже не знаю как с тобой разговаривать. Никаких проблем он не плодит, он вообще имеет довольно опосредованное отношение к коду реальному. Потому что он не предназначен для проверки вообще всех возможных навыков написания кода, это всего лишь простенькая задачка-фильтр, позволяющая понять кто сидит перед нами — программист или человек, который пытается его имитировать.
E>но ты его обсуждаешь уже не как неверный ответ, не соответствующий формальным требования упомянутым в вопросе
Можно цитату где я подобное делаю?
E>, а как просто "код, который хуже", так вот, по критерию "проще модифицировать" он, как раз, лучше, а не хуже...
Их вообще невозможно по этому критерию сравнивать, потому что такой код лично у меня легко целиком умещается в голове весь в подробностях, поэтому такой крошечный кусочек, если специально не извращаться, по легкости модификации абсолютно одинаков при всех способах решения. Если что не так, он просто переписывается за пару минут.
НС>>Нет, не значит. Иммутабельный код, к примеру, обычно проще и надежнее кода с инвариантами, но неумелые программисты, если у них нет нужного бекграунда, пишут именно инварианты. Еще один пример — парсеры правильно пишут только те, кто хотя бы немного знаком с темой, а остальные 99% без профильного образования пишут страшных каракатиц, мутных и падучих, при том что с другими задачками они худо-бедно справляются.
E>Но понять тоже проще тот, что с массивом, и, главное, его проще менять...
Нет, не проще понять и не проще менять. Понишь каким образом я тебе описал, почему твои объекты-механизмы не самый удачный дизайн? Вот попробуй в таком же духе объяснить, почему неправильный вариант проще модифицировать. Там меньше зависимостей? Там выше связность кода? Там меньше контракты? Там меньше внутренних связей? Меньше функциональных точек? Меньше цикломатическая сложность? Назови хотя бы одну объективную метрику или принцип дизайна, под который подходит неправильный вариант, и не подходит правильный.
E>Либо он не понял твоего вопроса.
Ну, если человек не может понять такого простого вопроса, то и говорить с ним дальше не о чем.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>А еще есть дядька в Киеве. Еще раз, следи за губами — эта задачка предназначена для тестирования строго определенного скила, и это не технологичность и не стандартность. Ты же, подменяешь задачу (потому что исходная специально так подобрана, чтобы по минимуму затрагивать другие скилы), а потом на основании этой подмены пытаешься доказать, что неверный ответ к исходной задаче на самом деле верный. Это, мой друг, демагогия.
Демогогия -- это то, что ты тут пишешь.
Если в твоей задаче есть В УСЛОВИИ требование не использовать доп. память, то ответ с массивом НЕ ВЕРНЫЙ по ФОРМАЛЬНЫМ причинам.
НС>Ну да, и вместо того чтобы прямо спросить о том что ты не понял ты начал что то фантазировать и на основании этих фантазий спорить.
Я вообще никак не оценивал твои собеседования. Я оспариваю то, что код с массивом -- плохой. Он просто написан исходя из другой системы ценностей. Он не является решением твоей задачи и мне странно, что ты не упомянул это, когда приводил его...
НС>Да потому что не может по другому.
Тогда, конечно, это не ваши кандидаты.
НС>Никак. Это задача не на легкость модификации, она, как минимум, слишком маленькая для оценки этого. Ты же, надеюсь, еще помнишь, что здесь обсуждается именно конкретная задача, а не что то еще?
Я оспариваю твоё утверждение, что один код переупорядочивый односвязанный список хуже другого.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Если в твоей задаче есть В УСЛОВИИ требование не использовать доп. память, то ответ с массивом НЕ ВЕРНЫЙ по ФОРМАЛЬНЫМ причинам.
Меня формальные причины не особо интересуют.
E>Я вообще никак не оценивал твои собеседования. Я оспариваю то, что код с массивом -- плохой.
Он плохой в контексте этой задачи. А так да, почти всегда можно придумать как так переиначить задачу, чтобы любой плохой код было проще исправить, чем хороший, особенно если код такой коротенький.
E> Он просто написан исходя из другой системы ценностей. Он не является решением твоей задачи и мне странно, что ты не упомянул это, когда приводил его...
Я его и привел как пример неверного решения. С кем ты споришь?
Да не напишет он и с помощью гугла. Больше половины на обсуждаемую задачку не задумываясь пишут примерно такой код ...
НС>>Никак. Это задача не на легкость модификации, она, как минимум, слишком маленькая для оценки этого. Ты же, надеюсь, еще помнишь, что здесь обсуждается именно конкретная задача, а не что то еще? E>Я оспариваю твоё утверждение, что один код переупорядочивый односвязанный список хуже другого. E>
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Меня формальные причины не особо интересуют.
Ну тебя может и не интересуют, но соискатели-то отвечают на тот вопрос, который ты им задал, а не на то, что тебя интересует.
То есть, если ты просишь их "сделайте без доп. памяти", а они тулят массив, то они НЕ РЕШИЛИ ЗАДАЧУ.
так же, как кто-то тут предлагал в рекурсивной процедуре возвращать имена узлов, вместо того, что бы получить на выходе обращённый списко из тех же узлов...
НС>Он плохой в контексте этой задачи. А так да, почти всегда можно придумать как так переиначить задачу, чтобы любой плохой код было проще исправить, чем хороший, особенно если код такой коротенький.
Ну, давай так, пусть у нас целый класс операций над списком, типа мы контейнер пишем. И если все операции переупорядочения сделаны похоже, то это лучше, правда это может быть слишком дорого, а может и не быть...
НС>
НС>Да не напишет он и с помощью гугла. Больше половины на обсуждаемую задачку не задумываясь пишут примерно такой код ...
Мне не понятно, что за имбицилы к вам идут, что они "не задумываясь пишут такий код", когда их явно попросили без доп. памяти?..
IMHO, ты чего-то тут не договариваешь...
НС>В контексте этой задачи он таки хуже.
В контексте этой задачи он не то что бы хуже там или лучше, а один является решением, а другой нет
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
надо вообще отдельную комнату "о собеседованиях" сделать, а также подразделы ксв "Windows vs *nix", "iвсе vs android" и "C# vs java vs c++",
а то сложно стало разбираться куда писать и где искать.
Здравствуйте, matumba, Вы писали:
M>Здравствуйте, gandjustas, Вы писали:
G>>на хабре появилась небольшая, но фактически меняющая картину мира, статья:
M>гыгы Подростки вдруг осознали истину? Вообще-то даже здесь найдётся пяток толковых ребят, считающих собеседования полным фуфлом. Ничего нового гугл не открыл, просто кто-то, доведённый до отчаяния своей тупостью, вдруг осознал, что применяет совершенно левую методику и НАКОНЕЦ-ТО сказал: "А король-то голый!".
Обычно гугл делает проще: берет статистику и считает корреляцию.
Здравствуйте, gandjustas, Вы писали:
G>Кстати в конце статьи описан новый подход гугла к найму, который так не нравится многим программистам, верящим в свою уникальность.
G>Мы выяснили, что головоломки — пустая трата времени. Они не могут ничего предсказать, и в процесс собеседования включены только для того, чтобы дать возможность интервьюеру почувствовать себя умнее
А все почему? Потому что система образования, основанная на тестах, не может предложить людей, способных думать. Тесты на головоломки не могут выявить таких людей, потому как их процент стал стремиться к нулю, вот и решено убрать неэффективный инструмент. И в результате имеем застой, серость и убогость во всех областях.
Здравствуйте, gandjustas, Вы писали:
IS>>p.s. личное мнение — что на собеседовании есть место и гномикам и разговору по делу. G>В том-то и дело что личное мнение. А практика обычно отличается.
Да нормальная практика, если нужно показать начальству свою деятельность и поток кандидатов большой.
G>Любая задача на собеседовании, которая: G>1) Не имеет отношения к потенциальной работе G>2) Требует знания конкретных алгоритмов G>3) Требует решения на бумажке
G>Фактически является головоломкой, которая нужна только для удовлетворения самолюбия собеседующего.
Я же в subject написал — offtopic.
Независимо от чего бы то ни было, задача типа "У Пети было 2 яблока, а у Миши на 3 яблока больше, сколько всего яблок было у обоих ?" может считаться головоломкой только для старшей группы детского сада. А задача про переворот списка — максимум для студента 1 курса, и то при условии, что он не учился в школе с углубленным изучением программирования.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, gandjustas, Вы писали:
G>>1) Не имеет отношения к потенциальной работе
НС>Разворот списка, по сути проверяющий понимание концепции указателя не имеет отношения к работе?
Чаще всего да.
Если делается низукоуровневый код на C, то задача может быть релевантна. Если используется ЯВУ, то правильный ответ всегда List.Reverse, все остальное является плюсом, только если кандидат умеет успешно пользоваться List.Reverse.
Указатели далеко не везде есть и далеко не всегда используются так, так думают, задающие вопрос про разворот списка.
Здравствуйте, gandjustas, Вы писали:
НС>>Разворот списка, по сути проверяющий понимание концепции указателя не имеет отношения к работе?
G>Чаще всего да. G>Если делается низукоуровневый код на C, то задача может быть релевантна. Если используется ЯВУ, то правильный ответ всегда List.Reverse, все остальное является плюсом, только если кандидат умеет успешно пользоваться List.Reverse.
В сложных проектах часто встречаются структуры отличные от List. Например всевозможные оптимизации или сложные структуры навроде списковых, графовых, древовидных и тд. Здесь уметь всякие преобразования и обходы крайне необходимо.
Здравствуйте, Ikemefula, Вы писали:
I>Гугл говорит про "structured behavioral interviews". И вот "разворот списка" при правильном применении идеально вписывается в этот подход. Скажем если ты ждешь результата "написал — не написал", то лучше вообще собеседование не проводить, а брать только по резюме и рекомендациям.
Вообще при формальном, буквальном применении "structured behavioral interviews" результат будет такой же как и с гномиками.
Здравствуйте, Vzhyk, Вы писали:
G>>Тебе лично сколько раз приходилось писать разворот списка в настоящем проекте? G>>Вот мне ровно 0.
+0 — в смысле мне тоже ни разу
V>Есть большая толпа что хочет крутую зарплату. Ка прикажешь их отсеивать?
То есть если человек не знает КАК, то можно запросто взять любую дебильную, но "официальную" методику и ею прикрывать собственную некомпетентность, так штоле?
V>По сути для работы пофиг кого брать.
Вот именно, что gandjustas и говорит. Нет смысла во всех этих обезьяньих ужимках и жалких попытках "чисто теоретически" отсеивать людей. ОСОБЕННО когда приходят люди с приличным опытом, а им выкатывают ушат "головоломок", маразм которых просто никак не сопоставим с его практической работой.
При всех равных (опыт, разнообразие задач, кругозор), брать надо просто первого понравившегося кандидата — да, именно "личный фактор". Потому что если ты в ИТ хотя бы 10 лет, ты уже заслужил быть прогером и не хуже других сможешь решать задачи (тем более, как правило это делается в команде). А вот найти человека, с которым тебе приятно будет работать — вот это действительно проблема! И решать её — не ссыкухе из HR, а непосредственно твоей команде (даже не боссу).
Здравствуйте, herethere, Вы писали:
H>Вот именно, что gandjustas и говорит. Нет смысла во всех этих обезьяньих ужимках и жалких попытках "чисто теоретически" отсеивать людей. ОСОБЕННО когда приходят люди с приличным опытом, а им выкатывают ушат "головоломок", маразм которых просто никак не сопоставим с его практической работой. H>При всех равных (опыт, разнообразие задач, кругозор), брать надо просто первого понравившегося кандидата — да, именно "личный фактор". Потому что если ты в ИТ хотя бы 10 лет, ты уже заслужил быть прогером и не хуже других сможешь решать задачи (тем более, как правило это делается в команде). А вот найти человека, с которым тебе приятно будет работать — вот это действительно проблема! И решать её — не ссыкухе из HR, а непосредственно твоей команде (даже не боссу).
это ты мне рассказываешь? Это моим оппонентам расскажы.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>Разворот списка, по сути проверяющий понимание концепции указателя не имеет отношения к работе? G>>Чаще всего да.
НС>Ясно. Лично нам такие программисты не нужны.
Беда в том, что они сплошь и рядом. Про List.Reverse знают, как работает — их не интересует, а для суммы арифметической прогрессии ищут класс ArithmeicProgression, а не найдя — встают в тупик и постят запросы в форум.
Здравствуйте, gandjustas, Вы писали:
G>Тебе лично сколько раз приходилось писать разворот списка в настоящем проекте?
А ты лично можешь этот разворот написать?
G>Вот мне ровно 0. Думаю подавляющему большинству посетителей форума — также.
И? К примеру, мне несколько раз приходилось топосорт писать, далеко не во всех платформах он стандартный имеется. В дотнете, к примеру, его нет. Только если дать задачку на топосорт, то уже требуется знание хоть и простенького, но уже не тривиального алгоритма, а вот это как раз уже значения особого не имеет — можнооткрыть педивикию и почитать.
Поэтому, естественно, задачка сильно проще того, что приходится писать в реальном коде.
Или ты думаешь что человек, не справившийся с разворотом списка, топосорт при этом легко напишет? Опять же, а как проверять знание азов программирования? Твои варианты задачек на отсеивание полных нулей какие?
Здравствуйте, herethere, Вы писали:
H>То есть если человек не знает КАК, то можно запросто взять любую дебильную, но "официальную" методику и ею прикрывать собственную некомпетентность, так штоле?
1) Считаешь ли ты человека, который не в состоянии написать разворот списка, способным работать программистом?
2) Предложи недибильную методику
3) Когда задачка на разворот списка успела стать официальной методикой?
V>>По сути для работы пофиг кого брать. H>Вот именно, что gandjustas и говорит.
gandjustas давно уже код не пишет, так что непонятно что он пытается доказать.
H>При всех равных (опыт, разнообразие задач, кругозор), брать надо просто первого понравившегося кандидата — да, именно "личный фактор".
При десятке кандидатов в день и необходимости отобрать одного — ьты только этим и будешь заниматься, причем пару месяцев минимум, как показывает практика.
H> Потому что если ты в ИТ хотя бы 10 лет, ты уже заслужил быть прогером
Предлагаешь ввести выслугу лет? Сдается мне, не ту ты профессию выбрал.
H>И решать её — не ссыкухе из HR, а непосредственно твоей команде (даже не боссу).
Ага, вся команда, вместо того чтобы делать продукт, будет несколько месяцев заниматься наймом нового человека. Спасибо, насмешил.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Ну а ты как задачу это решил бы в реальном коде, а?
reverse. И только после того, как профилирование показало бы облом, начал бы чего фантазировать (для начала читать).
Но, я древний программист с опытом 20 лет, на таких дряхлых ориентироваться глупо и не эффективно, так что я не показатель.
Современный мир требует другого — много кода и быстро.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Как это оправдывает того, кто эту задачу решить не в состоянии?
Нет таких людей, кто окончил ВУЗ по технической специальности (кроме варианта купил диплом).
Здравствуйте, Vzhyk, Вы писали:
НС>>Как это оправдывает того, кто эту задачу решить не в состоянии? V>Нет таких людей, кто окончил ВУЗ по технической специальности (кроме варианта купил диплом).
Здравствуйте, gandjustas, Вы писали: G>Вот оказывается для чего все эти 23-летние сеньоры задают шандарахнутые вопросы про гномиков и разворот списков.
Ну гномики понятно, а списки то тут причем?
PS
В одной презентации Линус Торвальдс называет всех работников гугла некомпитентными.
Вот я бы лучше узнал, как бы он проводил собеседования.
А то, что до гугла вдруг доперло, что программист должен решать задачи, так этого следовало ожидать.
Все взрослеют же.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Давай подробнее. На входе — односвязный список, никакого метода reverse у него нет.
А что у него есть?
НС>Предлагаешь на собеседовании давать задачку на многакодаибыстро?
Ну, вообще то так и делается нынче. Это я тут странный со своим побеседовать, поговорить.
Здравствуйте, Vzhyk, Вы писали:
V>Среди русскоязычных.
Среди русскоязычных "таких людей, кто окончил ВУЗ по технической специальности (кроме варианта купил диплом)"?
А ты, прости за нескромный вопрос, с гуманитарным образованием, купил диплом или нерусскоязычный?
Здравствуйте, herethere, Вы писали:
H> и какое-то существо в свитере и с бородой
Вот не надо позорить нормальных людей.
H> ряды Фурье!
Ну если ты будешь занимать именно ЦОС, то вопрос логичный.
H>При нынешнем маразме принятия на работу есть большой шанс, что как раз хороший спец (один на сто) пролетит, а "специалист по собеседованиям" будет сосать из вас зарплату до следующего собеседования. А всё лишь потому, что дилетант в HR прочёл про "задачки на собеседовании" и не применив даже капли мозга поехал "отсеивать". А контора, за свою расхлябанность при наёме "отдела кадров", терпит убытки и сортирует УГ, нанятое "по всем правилам". Что ж, кесарю — кесарево.
Выживают те, кто лучше всего умеет приспосабливать к условиям окружающей среды.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>95% приходящих на собеседование не справляются.
И вы их не берете. А другие берут. Потом они пишут код , от которого уши вянут. Потом этого кода становится много. Потом такой код становится нормой . Потом объяснить, что это не норма, а бог знает что, становится невозможным : тебя просто не понимают, все же так пишут.
Здравствуйте, herethere, Вы писали:
H>О! Хорошо сказал! Вот примерно так я чувствую себя при общении с апологетами "паттернов проектирования"
Веселее, когда они это в код вляпывают.
Пффф, пока вы тут писали эту простыню, я взял листочек и ручку набросал схему ссылок и решил задачу двумя разными способами.
Первый способ O(n) с использованием нескольких вспомогательных ссылок.
Второй способ O(n*n)с использованием стека, чисто как эксперимент, так что публиковать его не буду.
class Element
{
public int Value { get; set; }
public Element Next { get; set; }
public Element(int val, Element next)
{
Value = val;
Next = next;
}
}
class Program
{
static void Main(string[] args)
{
Element list = new Element(1,new Element(2,new Element(3,new Element(4,null))));
ReverseOne(ref list);
Element root = list;
while (root != null)
{
Console.WriteLine(root.Value);
root = root.Next;
}
}
static void ReverseOne(ref Element list)
{
Element current = list;
Element previous = null;
Element result = null;
while (current!=null)
{
previous = current;
current = current.Next;
previous.Next = result;
result = previous;
}
list = result;
}
}
Эта метода:
— Я специалсит, я не буду писать велосипед, я могу дома сделать так, как хочу, все уже написано, давайте подставим стопицотую библиотеку в код, плевать, что мы ее будем использовать на 3% максимум.
Лично у меня уже в горле сидит. Знание алгоритмов и структур данных позволяет решать задачу более элегантно и понятно.
Я вообще изучая новый язык нынче всегда пытаюсь написать на нем связанный список.
Задача просто то, что надо, что бы быстро въехать в основную суть.
Поработать с объектами, с коллекциями, с ссылками(указателями если есть), модулями, интерфейсами,
собрать маленький проект, поработать со средой разработки и стандартными функциями.
Это вообще детские задачи. Вот я на работе решал задачку.
Нужно было создать коллекцию с динамическим ключом для хранения данных в памяти.
Производительность критически важна, так как данные поступают очень быстро, размер стека очень мал и что бы он не переполнился внезапно, нужно было реагировать практически молниеносно. Т.е. при добавлении нового значения все ключи у коллекции должны меняться.
Как это сделать? Я решил задачу где-то за день, но времени додуматься до решения мне потребовалось не очень много.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>И вы их не берете. А другие берут.
Подсобными рабочими, ага. В надежде что доучатся. У нас, к сожалению, на тот момент была очень скромная по размерам команда с довольно высокими требованиями. Впрочем, мы тоже пробовали брать — результат отрицательный.
PD> Потом они пишут код , от которого уши вянут. Потом этого кода становится много. Потом такой код становится нормой . Потом объяснить, что это не норма, а бог знает что, становится невозможным : тебя просто не понимают, все же так пишут.
Code review сильно помогает в такой ситуации. При наличии обратной связи человек либо быстро учится, либо уходит. Но это довольно дорогое удовольствие.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, gandjustas, Вы писали:
G>>Тебе лично сколько раз приходилось писать разворот списка в настоящем проекте?
НС>А ты лично можешь этот разворот написать?
Лично я могу, а что это меняет?
G>>Вот мне ровно 0. Думаю подавляющему большинству посетителей форума — также.
НС>И? К примеру, мне несколько раз приходилось топосорт писать, далеко не во всех платформах он стандартный имеется. В дотнете, к примеру, его нет. Только если дать задачку на топосорт, то уже требуется знание хоть и простенького, но уже не тривиального алгоритма, а вот это как раз уже значения особого не имеет — можнооткрыть педивикию и почитать.
Если у тебя в работе постоянно используется топосорт, то спрашивай на собеседовании, прямо проси написать код или, хотя бы, псевдокод. Если в работе не нужно, то зачем спашивать?
Я вот на собеседованиях спрашиваю как написать клиентский(jquery+ajax) и серверный(asp.net) код. Такое как минимум придется писать раз в неделю.
А вот разворот списков и топологические сортировки не спрашиваю, они не нужны.
НС>Или ты думаешь что человек, не справившийся с разворотом списка, топосорт при этом легко напишет? Опять же, а как проверять знание азов программирования? Твои варианты задачек на отсеивание полных нулей какие?
Мы используем разворот строки на C#. Причем любой. В зависимости от того что напишет — дополнительные вопросы.
Ведущим еще задачку — увеличение на 1 числа, хранящегося в массиве поциферно или превращение потока символов в поток слов IEnuerable<char> -> IEnumerable<string>. Вторая задача на практике полезнее.
Здравствуйте, Vzhyk, Вы писали:
V>Здравствуйте, gandjustas, Вы писали:
G>>Тебе лично сколько раз приходилось писать разворот списка в настоящем проекте? G>>Вот мне ровно 0. Думаю подавляющему большинству посетителей форума — также. V>Да причем тут это? Есть большая толпа что хочет крутую зарплату. Ка прикажешь их отсеивать? По сути для работы пофиг кого брать.
Давайте задачу близкую к реальной работе.
Мы берем SharePoint программистов, просим написать SharePoint код. Буквально 7 строк, но куча тонкостей, 30% на нем и отсеивается.
Здравствуйте, herethere, Вы писали:
H>Алгоритмы — это просто собранные в кучу решения каких-то задач. Их знание или незнание — всего лишь вопрос опыта и МИНУТЫ ГУГЛЕНИЯ.
Вряд ли в гугле ты найдешь нужную тебе модификацию алгоритма или структуру данных. Общие вещи — запросто, специализированые — уже вряд ли. И, скажем, что бы правильно модифицирвать алгоритм или структуру данных нужно чтото больше чем гугление, потому что кроме решения надо еще доказать что решение обладает нужными тебе свойствами.
H>Если я впервые решаю задачу, даденую на работе, я в офисе даже палец о палец не ударю, потому что тупо не могу думать в офисной помойке — я собираю материал, приношу домой и в тишине и спокойствии начинаю думать.
Периодически бывают авраалы, фиксить приходится быстро, за минуты после обнаружения проблемы. Если ты в офисе думать не можешь, значит авраалы придется разгребать твоим товарищам.
Ну и непонятно,как ты будешь работать в команде. Если ктото зависит от тебя, то он каждый раз должен ждать "до завтра", пока ты созреешь.
>Ну и что умного ты хочешь выяснить о человеке, когда он на нервах сидит в кабинете незнакомой организации и какое-то существо в свитере и с бородой задаёт с прищуром ему вопросы! Я и возраст-то вспоминаю секунд пять, что уж говорить про красно-чёрные деревья и ряды Фурье!
Если ты решил,что специалист по алгоритмам, структурам данных и ЦОС, то крайне странно, что тебя поставят в тупик такие вопросы.
Здравствуйте, herethere, Вы писали:
I>>Ответь внятно на вопрос: "Если человек не может сделать обход такой простой структуры, как список, то на каком основании можно считать, что он сможет обойти граф или дерево ? "
H>Если человек не может что-то сделать СЕЙЧАС, это не значит, что он это не может сделать вообще. Более того — если даже он может обойти ваш @$#^ список, почему вы так уверены, что он так же легко разрулит, скажем, сбалансированное дерево?? Гарантии — никакой.
Над таким задачами думать более 15-20 нет смысла Никому не нуже кандидат, который в тривиальный случай списка вникает часами.
Задача показывает, что кандидат знает и понимает списки, ссылки-указатели, умеет писать код, умеет делать обход.
Все, что ему не будет хватать в задаче про сбалансированое дерево, это просто конкретные знания собственн про эти деревья.
Вот эту часть можно и нужно проверить отдельно от списков. Код писать необязательно, но если требуется, можно задть вопрос типа: "где вы применяли красно-черное дерево и чем был обоснован выбор"
H>Ну и вообще по проблеме: отнеситесь к найму человека как.... к ВЫБОРУ ДЕВУШКИ! Это не делается за час.
Мне кажется, свю девушку тебе еще выбирать много лет а то десятилетий Для коммерческой организаци это слишком дорого, а надежность всё та же — вот найдешь ты девушку, а она уйдет от тебя к любовнику положе, побогаче. Вот как научишься разрешать такие проблемы, приходи, будешь советы давать
H>Человек должен проявить себя в естественной среде — среди коллег или уж дома. И без подгонялова "вот вам час" (даже если задача решается за минуту) — человек просто по сути своей — живое существо и не может резко стать спокойным, особенно если он — "начинающий" или "середнячок".
Умение взять в себя в руки очень важно. Умение работать в критической ситуации так же очень важно.
H>Я даже "тугодума" взял бы с большей уверенностью, потому что выскочки-всезнайки (типа вот этой обидчивой девочки, которая тут с листочком и карандашом перевернула список) абсолютно не пригодны там, где требуется скрупулёзность и выверенность идей.
Правильно, бери тугодумов, мне меньше фильтровать придется
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
I>>>Ответь внятно на вопрос: "Если человек не может сделать обход такой простой структуры, как список, то на каком основании можно считать, что он сможет обойти граф или дерево ? " G>>Так и спрашивай про граф или дерево, в чем проблема? Если только это нужно для работы.
I>Задача на граф или дерево слишком сложная, что бы давать её на собеседовании.
Да ну? А как тогда проверить что кандидат таки умеет работать с графами? Это ведь нужно в первую очередь.
I>>>Я сильно сомневаюьс, что человек сможет обойти дерево, если не смог обойти список. G>>Обход списка и разворот а месте — разные операции. Кроме того мы не про абстрактные навыки говорим, а про код на бумажке. G>>99% смогут написать разворот списка имея компьютер и час времени. Обход дерева — 4 часа, ни раз не писав обходы до этого. I>Это заблуждение.
Что именно?
I>>>Если не понимает указатели-ссылки, то на каком основании он называется программистом ? G>>Указатели далеко не везде есть. Более того, сейчас больше языков, где указателей нет. I>"указатели-ссылки" — нет указателей, значит есть ссылки. В приведеной задаче про реверс списка указатель ничем от ссылки не отличается, там не нужна адрсная арифметика и тд и тд.
А что нужно понимать в ссылках? Что после a=b; Object.ReferenceEquals(a,b)==true?
А причем тут разворот списка? Тебя уже сильно в сторону унесло. А ты даже близко не подошел к обоснованию полезности этой задачи.
Здравствуйте, ins-omnia, Вы писали:
IO>Здравствуйте, gandjustas, Вы писали:
G>>Мы берем SharePoint программистов, просим написать SharePoint код. Буквально 7 строк, но куча тонкостей, 30% на нем и отсеивается.
IO>Вот интересно, неужели эти тонкости настолько важнее умения программировать как такового?
А что есть "умение программировать как таковое"?
Мы ведь смотрим на опыт человека. Опытный человек с большей вероятностью умеет программировать, чем неопытный.
Задачи на программирование и на проектирование даем с учетом конкретной технологии. Не нужен человек, который умеет MVC в разработке для SharePoint.
IO>Сколько нужно, чтобы ввести в них человека, который немного ориентируется в ASP.NET, пару месяцев?
Практика показывает что от года.
IO>Может лучше брать просто программистов, а не "SharePoint программистов"?
Нет, не лучше. Слишком многому надо научить до того как пользу принесет.
Здравствуйте, ins-omnia, Вы писали:
IO>Здравствуйте, gandjustas, Вы писали:
G>>А что есть "умение программировать как таковое"? IO>Качества программиста, инвариантные относительно используемой технологии.
Например? Так чтобы не было привязано ни к .NET, ни к SharePoint.
IO>>>Может лучше брать просто программистов, а не "SharePoint программистов"? G>>Нет, не лучше. Слишком многому надо научить до того как пользу принесет.
IO>Просто я работал с этим вашим Шарепоинтом, поэтому интересуюсь. По-моему там бессмысленно пытаться IO>выучить всё нюансы. Всегда вылезет что-то неожиданное. Нужно постоянно лезть туда рефлектором, чтобы IO>понять как оно работает, или в лучшем случае гуглить не решил ли уже какой народный умелец проблему.
Вот как раз пример почему гуглить не всегда поможет http://www.gotdotnet.ru/forums/5/145950/.
Лезть рефлектором дело благородное, если знаешь куда. Обычно не знаешь.
IO>Или вы делаете типовые проекты обходя все острые углы? Тогда это получается вроде "программиста/дизайнера jQuery"
Как раз типовых проектов почти нет. Слишком дорого берем и типовые проекты проходят мимо нас. Зато можем брать лучших спецов.
IO>ИМХО, тупиковое направление. Выучить стопицот подробностей о монстрообразной системе, которые имеют крайне узкое применение...
В том то и дело, что тупо все выучить не поможет. Даже нету всех особенностей в одном месте. Нужно понимать как устроено внутри.
IO>Завтра Микрософт переведёт всё это на чистый AJAX (уже наполовину сделали), и значительная доля этих знаний станет мёртвым грузом.
Ага, лет 5 так говорят. А ajax все еще оооочеь мало. Меньше чем могло бы быть.
И, скорее всего, ситуация не поменяется.
IO>И если говорить о найме: людей, которые всё это знают всегда будет слишком мало, и что самое плохое, среди них будут IO>доминировать кадры с закостеневшим мышлением, привыкшие решать задачи шаблонами.
Я же говорю, знать все невозможно. Нужно понимать.
Здравствуйте, gandjustas, Вы писали:
G>>>А что есть "умение программировать как таковое"? IO>>Качества программиста, инвариантные относительно используемой технологии. G>Например? Так чтобы не было привязано ни к .NET, ни к SharePoint.
В контексте такой специализированной области как Шарепоинт трудно даже сказать.
Ну хотя бы умение разобраться в неожиданной/нетривиальной ситуации когда
ничего не работает, а что и где именно — не понятно.
G>Вот как раз пример почему гуглить не всегда поможет http://www.gotdotnet.ru/forums/5/145950/. G>Лезть рефлектором дело благородное, если знаешь куда. Обычно не знаешь.
Для чего и как работает камл это ж вроде самые основы, нет?
IO>>Завтра Микрософт переведёт всё это на чистый AJAX (уже наполовину сделали), и значительная доля этих знаний станет мёртвым грузом. G>Ага, лет 5 так говорят. А ajax все еще оооочеь мало. Меньше чем могло бы быть. G>И, скорее всего, ситуация не поменяется.
Однако ж в последней версии ввели DisplayTemplate'ы на чистом JS.
G>Я же говорю, знать все невозможно. Нужно понимать.
Да, понятно. И всё же, ИМХО, обучить человека с общими знаниями о .NET можно гораздо быстрее чем за год.
Откуда же его [независимый суд] взять, если в нем такие же как мы? (c) VladD2
Здравствуйте, gandjustas, Вы писали:
G>Лично я могу
Тогда непонятно, в чем проблема.
G>Если у тебя в работе постоянно используется топосорт, то спрашивай на собеседовании
Зачем? Мне не нужно знание топосорта, я его уже написал, я просто тебе реальный пример привел. Мне нужно, чтобы человек умел в голове оперировать ссылками.
G>Мы используем разворот строки на C#. Причем любой.
Здравствуйте, herethere, Вы писали:
H>Я так понимаю, ты ждёшь медаль "главный переворачиватель списков"?
Нет, но я категорически против того, что бы считать алгоритмы и структуры данных — "фитчей для всезнаек".
H>Ну так слушай: H>1. Ты ни струя ни знаешь ни первого, ни второго, иначе бы решил эту, с позволения сказать, "задачу" не "на бумажке", а сходу из головы — она тривиальна и тому, кто "знает алгоритмы", бумажки не нужны. Ты же себя таким всезнайкой выставляешь, правильно?
Нет. Я не зазубриваю алгоритмы переворотов списков, потому, что бы решить задачу, сначала я перевожу свои мысли на листочек. Так делают все хорошие программисты.
Потому, что на этом этапе уже можно разглядеть некоторые ошибки в своей логике. H>2. "Более элегантно" только шорты расстёгиваются, твоё решение — обычное, сотню раз описанное и непонятно, кому ты хотел его написать "более понятно".
В задаче переворота списков, да. А что там можно еще выдумать?
Но если брать что-то более сложное...
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>По условиям задачи исходный список — однонаправленный. Предлагаешь загонять односвязный список в List, а потом после реверса выгружать?
Можно узнать для каких практических задач целесообразно использовать однонаправленный список? Я вот за десять лет практики не видел ни одной такой задачи. На практике в 99,9% случаев использование однонаправленного списка это и синтаксический и производительный оверхед. Так в чем смысл спрашивать на собеседовании задачу, не встречающуюся на практике?
Уж лучше обход дерева спросите, это хоть реально бывает нужно.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>По условиям задачи исходный список — однонаправленный. Предлагаешь загонять односвязный список в List, а потом после реверса выгружать?
Это не говоря уж о проблеме разного понимания терминологии на собеседовании. Т.к. в шарпе термин "список" всеми понимается как List, т.е. динамический массив. В классическом значении им никто не пользуется, т.к. на практике классические списки это никому не нужная экзотика.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Code review сильно помогает в такой ситуации. При наличии обратной связи человек либо быстро учится, либо уходит. Но это довольно дорогое удовольствие.
Code review помогает, когда архитектура проекта (с высоты птичьего полета) и используемые алгоритмы изначально правильные, но что-то реализовано не так, надо отрефакторить и т.д. А уж если изначально взят неверный подход, то CR может быть только один : выбросить и начать с начала.
Здравствуйте, Undying, Вы писали:
U>Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>По условиям задачи исходный список — однонаправленный. Предлагаешь загонять односвязный список в List, а потом после реверса выгружать?
U>Можно узнать для каких практических задач целесообразно использовать однонаправленный список? Я вот за десять лет практики не видел ни одной такой задачи.
Связанный список используется в других структурах данных, в том же дереве косвенно и в хештаблице напрямую.
Нынче это больше задача для обучения основам программирования нежели что-то практическое. Но то, что эта структура данных используется на практике(хоть и скрыто от глаз) — факт.
Просто напрямую уже не используется.
Вот как умножение в двоичной системе счисления считается через цикл и сдвиг и напрямую уже не используется, но необходимо знать принцип, что бы в практической задаче типа нахождения среднего арифметического избежать переполнения.
Возможно, что задача для собеседования не из лучших, но непонимание таких основ уменьшает производительность работника в разы.
Здравствуйте, Igor Sukhov, Вы писали:
IS>т.е. им 15 лет понадобилось чтобы понять это ... метрики все время меняли или люди научились подстраиваться под метрики (сюрприз, сюрприз но если у тебя не сток опшенс — надо как то зарабатывать бонус, нет?) или это просто новый главный HR решил отличиться? неубедительно. и еще не надо забывать что гугл большая компания — то что им подходит может не подходить в средних и мелких компаниях которыйх большинство.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, gandjustas, Вы писали:
G>>Если у тебя в работе постоянно используется топосорт, то спрашивай на собеседовании НС>Зачем? Мне не нужно знание топосорта, я его уже написал, я просто тебе реальный пример привел. Мне нужно, чтобы человек умел в голове оперировать ссылками.
не понял, в чем реальность? Нужная сортировка гуглится максимум за час. Зачем спрашивать на собеседовании то, что не используется?
G>>Мы используем разворот строки на C#. Причем любой. НС>Там нет ссылок.
Нет, они и не нужны.
Задаем вопрос про value и reference типы в .NET.
На этом вопросе 20% отваливаются.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, gandjustas, Вы писали:
G>>99% смогут написать разворот списка имея компьютер и час времени. Обход дерева — 4 часа, ни раз не писав обходы до этого.
PD>Я, конечно, извиняюсь, но о каком дереве речь идет ? Если об обычном двоичном дереве, то 4 часа — гм... Примерно по строчке в час получается.
Здравствуйте, ins-omnia, Вы писали:
IO>Здравствуйте, gandjustas, Вы писали:
G>>>>А что есть "умение программировать как таковое"? IO>>>Качества программиста, инвариантные относительно используемой технологии. G>>Например? Так чтобы не было привязано ни к .NET, ни к SharePoint. IO>В контексте такой специализированной области как Шарепоинт трудно даже сказать. IO>Ну хотя бы умение разобраться в неожиданной/нетривиальной ситуации когда IO>ничего не работает, а что и где именно — не понятно.
Это наоборот наиболее привязно к технологии.
G>>Вот как раз пример почему гуглить не всегда поможет http://www.gotdotnet.ru/forums/5/145950/. G>>Лезть рефлектором дело благородное, если знаешь куда. Обычно не знаешь. IO>Для чего и как работает камл это ж вроде самые основы, нет?
Нет. Особенно с тех пор как в студию дизайнеры встроили.
IO>>>Завтра Микрософт переведёт всё это на чистый AJAX (уже наполовину сделали), и значительная доля этих знаний станет мёртвым грузом. G>>Ага, лет 5 так говорят. А ajax все еще оооочеь мало. Меньше чем могло бы быть. G>>И, скорее всего, ситуация не поменяется. IO>Однако ж в последней версии ввели DisplayTemplate'ы на чистом JS.
Это очень маленькая часть.
G>>Я же говорю, знать все невозможно. Нужно понимать. IO>Да, понятно. И всё же, ИМХО, обучить человека с общими знаниями о .NET можно гораздо быстрее чем за год.
У тебя имха а у меня практика. Быстрее чем за год не получается. Хороший специалист по SharePoint не только знаниями программирования обладает. Поэтому так долго.
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Ну я использую односвязные списки для хранения полилиний, проводников на печатных платах, иногда для контуров полигонов. SVZ>Стандартный std::list здесь непригоден, списки реализованы на основе массивов, вместо указателей используются индексы, поэтому оверхед по памяти минимальный.
Т.е. список просто обертка над динамическим массивом. А на собеседовании Ночной Смотрящий вовсе не это требует. Тот же разворот твоего списка будет выглядеть как разворот массива, а Ночному Смотрящему нужна вместо этого какая-то мутотень с работой со ссылками.
Здравствуйте, -n1l-, Вы писали:
N>Связанный список используется в других структурах данных, в том же дереве косвенно и в хештаблице напрямую. N>Нынче это больше задача для обучения основам программирования нежели что-то практическое. Но то, что эта структура данных используется на практике(хоть и скрыто от глаз) — факт.
Дерево это другая структура данных. И переворот дерева это извращение какое-то, а не практически востребованная операция. А в реализации хэш таблиц где списки используются?
N>Вот как умножение в двоичной системе счисления считается через цикл и сдвиг и напрямую уже не используется, но необходимо знать принцип, что бы в практической задаче типа нахождения среднего арифметического избежать переполнения.
Не понял. Зачем для того, чтобы понимать, что многократное сложение при последующем делении может привести к переполнению, знать что "умножение в двоичной системе счисления считается через цикл и сдвиг"? Первое со вторым вообще не связано.
N>Возможно, что задача для собеседования не из лучших, но непонимание таких основ уменьшает производительность работника в разы.
Производительность работника в первую очередь снижает решение простых задач сложными методами. Например, применением рекурсии там где можно обойтись циклами. И по хорошему именно умение работника решать задачи просто надо проверять на собеседовании. Вы же пытаетесь проверять обратное — умеет ли работник видеть в мухе слона.
Здравствуйте, Undying, Вы писали:
U>Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>>Ну я использую односвязные списки для хранения полилиний, проводников на печатных платах, иногда для контуров полигонов. SVZ>>Стандартный std::list здесь непригоден, списки реализованы на основе массивов, вместо указателей используются индексы, поэтому оверхед по памяти минимальный.
U>Т.е. список просто обертка над динамическим массивом. А на собеседовании Ночной Смотрящий вовсе не это требует. Тот же разворот твоего списка будет выглядеть как разворот массива, а Ночному Смотрящему нужна вместо этого какая-то мутотень с работой со ссылками.
Ты, видимо, ничего не понял, либо я плохо объяснил. То, что элементы лежат в массиве не значит, что их порядок совпадает с порядком следования в массиве. Это полноценный список со всеми его плюсами и минусами. В процессе редактирования элементы могут переключаться из одного списка в другой, физически оставаясь на своем месте. Т.е. индекс элемента остается постоянным, а значение поля next меняется. Ссылка на следующий элемент ("Next") может находиться внутри элемента списка, а может храниться в отдельном параллельном массиве.
Собственно, вот начинка коллекции списков:
std::vector<typename IT> m_Item_List; // Индекс первого элемента списка
std::vector<typename VT> m_Item; // Элементы списков
std::vector<typename IT> m_NextItem; // Индекс следующего элемента в списке
IT m_FreeList; // Список удаленных
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>Code review сильно помогает в такой ситуации. При наличии обратной связи человек либо быстро учится, либо уходит. Но это довольно дорогое удовольствие.
PD>Code review помогает, когда архитектура проекта (с высоты птичьего полета) и используемые алгоритмы изначально правильные, но что-то реализовано не так, надо отрефакторить и т.д. А уж если изначально взят неверный подход, то CR может быть только один : выбросить и начать с начала.
Здравствуйте, Ikemefula, Вы писали:
I> 1. вообще не работал со списковыми структурами (может всю жизнь матрицы умножал)
Прикольно и показательно для местного форума: матрицы здесь не умножают.
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Ты, видимо, ничего не понял, либо я плохо объяснил. То, что элементы лежат в массиве не значит, что их порядок совпадает с порядком следования в массиве. Это полноценный список со всеми его плюсами и минусами.
А в чем тогда смысл использования? Как я понимаю, список может оказаться наилучшим решением, когда производительность вставок в середину важна, а скорость прохода по коллекции нет. Вроде и полилинии, и проводники, и контуры полигонов намного чаще обходятся, чем изменяются. Минусом же является и производительность и усложнение кода — рекурсию сложнее читать чем циклы. Соответственно непонятно в чем выгода от использования списков для решения этих задач.
Здравствуйте, gandjustas, Вы писали:
G>>>99% смогут написать разворот списка имея компьютер и час времени. Обход дерева — 4 часа, ни раз не писав обходы до этого.
PD>>Я, конечно, извиняюсь, но о каком дереве речь идет ? Если об обычном двоичном дереве, то 4 часа — гм... Примерно по строчке в час получается.
G>Ключевое выделено.
Тогда уж добавь — "никогда не слышавший про деревья". Как можно хоть что-то знать про деревья и не знать про самый простой алгоритм в дереве — не понимаю.
А если он и впрямь о них никогда не слышал — так учиться надо. Впрочем, изучение темы двоичных деревьев с нуля и до способов обхода едва ли и в этом случае потребует 4 часов. Максимум час.
Принципиально как вы будете хранить в одном элементе хеш-таблицы несколько значений?
С помощью массива? И постоянно его ресайзить?
Это не то, что оптимизация, это способ, самый распространенный.
Здравствуйте, Undying, Вы писали:
U>Здравствуйте, -n1l-, Вы писали:
N>>Св хештаблице напрямую.
U>В реализациях хештаблиц, да, список используется. Но и там задача переворота списка абсурдна.
Вовсе нет.
И вы видимо буквально все воспринимаете.
Здравствуйте, -n1l-, Вы писали:
N>Да тоже самое. Только листьев больше чем 1.
Не то же самое. Т.к. переворот дерева представить очень сложно.
N>Потому, что нет в компьютере десятичных чисел. N>Если относится к этому поверхностно, не вникая можно очень долго решать тривиальные проблемы.
Все равно не понял. Как десятичность/двоичность представления числа влияет на возможность/невозможность переполнения?
N>Переворот списка — это вообще не сложно. Тут нет ни мух ни слонов. N>Есть основы, которые нужно знать.
Зачем знать? Придумать самому при необходимости, да, это полезный навык. Знание экзотики бесполезный.
Здравствуйте, Vzhyk, Вы писали:
I>> 1. вообще не работал со списковыми структурами (может всю жизнь матрицы умножал) V>Прикольно и показательно для местного форума: матрицы здесь не умножают.
Вообще то умножают. Один из умножателей даже отметился в этом треде.
Здравствуйте, Undying, Вы писали:
U>Здравствуйте, -n1l-, Вы писали:
N>>Да тоже самое. Только листьев больше чем 1.
U>Не то же самое. Т.к. переворот дерева представить очень сложно.
Да что вы на этом перевороте зациклились? Список, что только переворотом одним отличается от других струкутур данных?
U>Все равно не понял. Как десятичность/двоичность представления числа влияет на возможность/невозможность переполнения?
Ооо....
U>Зачем знать? Придумать самому при необходимости, да, это полезный навык. Знание экзотики бесполезный.
Что придумать самому? Наложение маски, адресную арифметику, базовые алгоритмы?
Что экзотичного в обходе списка по средствам ссылок?
Типичное незнание указателей приводит например вот к такому коду:
List<Objects> objects = new List<Objects>();
List<Objects> objects = repository.getObjectList().ToList();
И таких ляпов полно. Хорошо еще, что ляпы, так ведь бывают же и ошибки.
public static void MyMethod(List<int> list)
{
list = Enumerable.Range(0,100).ToList();
}
Потом начинается долгая отладка, вопли и неожиданные открытия.
Тратится уйма времени в итоге, на всякую хрень.
Здравствуйте, herethere, Вы писали:
H>Вот это я вам и повторяю — независимо от ваших глупых собеседований, всё равно вы не можете достоверно сказать, что наняли лучшего программиста. Зато рассуждений о списках — целая простыня! Тогда какой смысл во всех этих хитродуманных задачах? Отсеять ламеров? Так это вы должны уметь уже по CV и первым трём предложениям.
У тебя какая то неправильная дифференциация — или лучший или ламеры. Если предположить, что все люди именно такие, то у тебя все правильно — по CV и первым трём предложениям. Дальше останутся лучшие
H>Я же сказал — это СЛОЖНО, это психология (а я всего лишь прогер). Так что типичный отсев можно свести к отбору наиболее опытных (5+ лет разработки коммерческих систем) и "рассуждательных беседах" типа "как вы подступитесь к задаче такой-то". Думаю, никакие ваши смешные указатели не заменят умения видеть и описывать глобальные проблемы.
Есть мнение, что хорошие программисты свободно владеют инструментом — ЯП.
H>Вот задача, например, написать "торговую систему" для международной корпорации — за 5 минут можно выяснить на каком уровне думает собеседник и может ли он предвидеть подводные камни. А что можно увидеть, "оборачивая список"??
Я уже ответил достаточно подробно на этот вопрос.
I>>Умение взять в себя в руки очень важно. Умение работать в критической ситуации так же очень важно.
H>Та... это вы "Матрицу" пересмотрели — не должно быть у программиста таких авралов.
А они бывают. Это особенность конкретного бизнеса. В некоторых областях все спокойно. В некоторых время от времени случаются авраалы. В некоторых, как геймдев, авраал это естественное состояние.
>И даже если они есть, решаются они не написанием вычурного алгоритма, а тупо либо фиксеньем проблемы (если нашлась), либо врéменными подпорками.
Подразумевается, что авраал есть, но проблема может и найтись ? Сказки какие то. Я не знаю, что такое "фиксеньем проблемы". Вот обход xml определенного вида и генерация по ём некоторых данных сгодится ?
Здравствуйте, Undying, Вы писали: U>Считаем позицию на основе вторичного хэша, если и она занята, то считаем третичный хэш и т.д.
Слишком медленно. Плюс нужно иметь в кармане свободное место.
U>Зачем постоянно ресайзить массив?
Потому, что он не динамический.
U>Это именно оптимизация.
Это именно способ.
Здравствуйте, gandjustas, Вы писали:
I>>Задача на граф или дерево слишком сложная, что бы давать её на собеседовании. G>Да ну? А как тогда проверить что кандидат таки умеет работать с графами? Это ведь нужно в первую очередь.
Ну да. Если человек умеет кодить, то он сумеет закодить любой алгоритм. При этом знания алгоритмов проверяется несколько другим способом.
G>>>99% смогут написать разворот списка имея компьютер и час времени. Обход дерева — 4 часа, ни раз не писав обходы до этого. I>>Это заблуждение. G>Что именно?
'99% смогут написать разворот списка имея компьютер и час времени.'
'Обход дерева — 4 часа, ни раз не писав обходы до этого.'
Если человек не писал ни одного обхода, это примерно студент 1го курса университета или по скилам приравненый к такому студенту.
Пудозреваю, если искать скажем лисперов, хаскелистов и прочих функциональщиков, то результат будет все 100%
I>>>>Если не понимает указатели-ссылки, то на каком основании он называется программистом ? G>>>Указатели далеко не везде есть. Более того, сейчас больше языков, где указателей нет. I>>"указатели-ссылки" — нет указателей, значит есть ссылки. В приведеной задаче про реверс списка указатель ничем от ссылки не отличается, там не нужна адрсная арифметика и тд и тд. G>А что нужно понимать в ссылках? Что после a=b; Object.ReferenceEquals(a,b)==true?
Например присваивание ссылки это совсем не то же самое, что присваивание значения.
G>А причем тут разворот списка? Тебя уже сильно в сторону унесло. А ты даже близко не подошел к обоснованию полезности этой задачи.
Здравствуйте, herethere, Вы писали:
H>Вот именно — паттерны "получились сами", их применили, потому что они были нужны. Сейчас всё ровно наоборот — бегает куча "списиалистов", которые знают шаблоны и так и ждёшь от них "хелловорлд" на 20 экранов — "а ларчик просто открывался".
А еще трава была зеленее, люди знали способ превращения травы в ТРАВУ, а так же владели секретом бессмертия, но унесли его в могилу.
I>>Если человек мало чем интересуется, то как правило, он всякие паттерны вряд ли будет знать.
H>А что в знании ваших паттернов такого важного?? Я же специально дал вначале пример винды — вы что, прочли и так ничего и не поняли? Тогда какой смысл "всем интересоваться" как любопытный дельфин?
Любознательность очень важное свойства любого профессионала. Знание паттернов не сводится к перечислению названий и сведений вроде "разница между прокси и адаптером".
I>>Как он будет общаться с коллегами по цеху — не ясно.
H>Да как веками это делали — на родном языке. Только вот из моего опыта я даже и не вспомню, хоть раз была ли у меня потребность разжёвывать "а вот тут я при помощи паттерна "фасад"..." — как правило, нормальному программисту объясняешь всё "в квадратиках", остальное он легко допирает сам.
Каменный век.
I>> Как минимум, паттерны нужо знать, ибо почти во всех источниках используется этот язык паттернов.
H>гыг Ну если только читать книги со словом "паттерны" — да, без них никуда! А так, в нормальной литературе, я не встречаю этого шарлатанства.
Приведи пяток примеров этой нормальной литературы. Если нечего сказать — ничего не говори.
Здравствуйте, gandjustas, Вы писали:
G>>>Если у тебя в работе постоянно используется топосорт, то спрашивай на собеседовании НС>>Зачем? Мне не нужно знание топосорта, я его уже написал, я просто тебе реальный пример привел. Мне нужно, чтобы человек умел в голове оперировать ссылками. G>не понял, в чем реальность? Нужная сортировка гуглится максимум за час. Зачем спрашивать на собеседовании то, что не используется?
На сортировке отлично проверяются алгоритмические скилы. Если ты гуглишь сортировки, то сильно вряд ли ты в курсе, что есть сортировки за линейное время или близкое к нему.
А еще у каждой сортировки целая куча разных особенностей, таких, как лучший и худший случаи.
И часто очень важно обосновать правильный выбор. Есть случаи, когда можно и нужно использовать быструю сортировку, а есть случаи, когда ни в коем случае этого нельзя делать.
Кроме того, если нужно будет модифицировать алгоритм, то гугл не скажет тебе, как изменяется вычислительная сложность.
Вообще сортировка это практически дедушка всех алгоритмов, если специалист по алгоритмам здесь плавает, то дальше его можно и не спрашивать.
G>Задаем вопрос про value и reference типы в .NET. G>На этом вопросе 20% отваливаются.
А задача навроде реверса отфильтровывает примерно 80% и вот с остальными имеет смысл толковать про более важные вещи.
Здравствуйте, Pavel Dvorkin, Вы писали:
G>>99% смогут написать разворот списка имея компьютер и час времени. Обход дерева — 4 часа, ни раз не писав обходы до этого.
PD>Я, конечно, извиняюсь, но о каком дереве речь идет ? Если об обычном двоичном дереве, то 4 часа — гм... Примерно по строчке в час получается.
Ну вот такие у него и работают — в час по чайной ложке выдают.
Здравствуйте, gandjustas, Вы писали:
G>>>Тебе лично сколько раз приходилось писать разворот списка в настоящем проекте? G>>>Вот мне ровно 0. Думаю подавляющему большинству посетителей форума — также. V>>Да причем тут это? Есть большая толпа что хочет крутую зарплату. Ка прикажешь их отсеивать? По сути для работы пофиг кого брать. G>Давайте задачу близкую к реальной работе.
G>Мы берем SharePoint программистов, просим написать SharePoint код. Буквально 7 строк, но куча тонкостей, 30% на нем и отсеивается.
Опаньки ! Практически аналог реверса для SharePoint — программиста.
Ты похоже делаешь выводы по своему частному случаю. Баззворд SharePoint в вакансии сам по себе фильтрует неплохо и на собеседования новички практически не приходят.
Здравствуйте, -n1l-, Вы писали:
U>>Все равно не понял. Как десятичность/двоичность представления числа влияет на возможность/невозможность переполнения? N>Ооо....
Что ооо?
U>>Зачем знать? Придумать самому при необходимости, да, это полезный навык. Знание экзотики бесполезный. N>Что придумать самому? Наложение маски, адресную арифметику, базовые алгоритмы?
Односвязный список это экзотика. Его переворот тем более. Адресная арифметика в C# это антинавык. Накладывать маски уметь желательно, но не критично, т.к. если человек этого не умеет, но умеет программировать обучение занимает минут 15.
Вопрос по маскам на собеседовании будет нормальным, если кандидат утверждает, что, например, программировал парсеры бинарных протоколов. Если же человек говорит, что занимался допустим чисто программированием форм, то вопрос будет странным.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
G>>>>Тебе лично сколько раз приходилось писать разворот списка в настоящем проекте? G>>>>Вот мне ровно 0. Думаю подавляющему большинству посетителей форума — также. V>>>Да причем тут это? Есть большая толпа что хочет крутую зарплату. Ка прикажешь их отсеивать? По сути для работы пофиг кого брать. G>>Давайте задачу близкую к реальной работе.
G>>Мы берем SharePoint программистов, просим написать SharePoint код. Буквально 7 строк, но куча тонкостей, 30% на нем и отсеивается.
I>Опаньки ! Практически аналог реверса для SharePoint — программиста.
Да, но разница только в том, что это реально используется в работе. Я же говорил что подобный код минимум пару раз в неделю писать приходится.
В отличие от разрворотов списка.
I>Ты похоже делаешь выводы по своему частному случаю.
Причем тут частый случай? Основной криетрий полезности той или иной задачи — насколько она близка к той работе, которую нужно делать.
Развороты списка в реальном приложении не пишет никто.
Рукопашную сортировку видел один раз, и что потому что программист был не в курсе что такое comparer.
Поэтому спрашивают все это на собеседовании чтобы потешить самолюбие собеседующего, не более того.
I>Баззворд SharePoint в вакансии сам по себе фильтрует неплохо и на собеседования новички практически не приходят.
А вот ценник притягивает тех, кто полкнижки только успел прочитать.
Здравствуйте, Undying, Вы писали:
U>Можно узнать для каких практических задач целесообразно использовать однонаправленный список?
Ни для каких. Эта задача предназначена для выяснения того, насколько собеседуемый способен в голове держать концепцию ссылок. Иногда стоит прочесть весь топик, прежде чем задавать вопросы, ответы на которые в топике уже есть.
НС>Ни для каких. Эта задача предназначена для выяснения того, насколько собеседуемый способен в голове держать концепцию ссылок.
Время занимательных историй. Одолевали меня раньше рекрутеры из Люксофта, к пятому собеседованию уже вызубрил все их логические головоломки, к концу пятого собеседования в очередной раз задают разворот списка, и тут силы меня покинули. Как потом оказалось начинал грипповать. Минут 10 протупил и зафейлил. Больше они ко мне не звонили.
Здравствуйте, gandjustas, Вы писали:
G>не понял, в чем реальность?
В том, что этот алгоритм точно так же требует опририрование ссылками.
G>>>Мы используем разворот строки на C#. Причем любой. НС>>Там нет ссылок. G>Нет, они и не нужны.
Значит умение оперировать ссылками этой задачкой не проверяется.
G>Задаем вопрос про value и reference типы в .NET.
Здравствуйте, Undying, Вы писали:
U>Это не говоря уж о проблеме разного понимания терминологии на собеседовании. Т.к. в шарпе термин "список" всеми понимается как List, т.е. динамический массив. В классическом значении им никто не пользуется, т.к. на практике классические списки это никому не нужная экзотика.
Если работодятел ожидает, что его мысли прочитают или просто не задумывается о таком варианте это уже клиника.
Такой случай проходит уже по другой статье чем "неэффективные методы собеседование".
Откуда же его [независимый суд] взять, если в нем такие же как мы? (c) VladD2
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, gandjustas, Вы писали:
G>>не понял, в чем реальность? НС>В том, что этот алгоритм точно так же требует опририрование ссылками.
G>>>>Мы используем разворот строки на C#. Причем любой. НС>>>Там нет ссылок. G>>Нет, они и не нужны. НС>Значит умение оперировать ссылками этой задачкой не проверяется.
G>>Задаем вопрос про value и reference типы в .NET. НС>Это другое, это знание платформы.
Так именно знание платформы и нужно, а не абстрактное умение "оперировать ссылками". Вообще не очень понимаю зачем нужно это абстрактное знание\умение.
Здравствуйте, Ikemefula, Вы писали:
I>Вообще сортировка это практически дедушка всех алгоритмов, если специалист по алгоритмам здесь плавает, то дальше его можно и не спрашивать.
А зачем вы ищете специалистов по алгоритмам, а не специалистов по решению алгоритмических задач?
Здравствуйте, Undying, Вы писали:
I>>Вообще сортировка это практически дедушка всех алгоритмов, если специалист по алгоритмам здесь плавает, то дальше его можно и не спрашивать.
U>А зачем вы ищете специалистов по алгоритмам, а не специалистов по решению алгоритмических задач?
А в чем разница ? Я чтото не понимаю твоей терминологии.
Здравствуйте, gandjustas, Вы писали:
I>>Опаньки ! Практически аналог реверса для SharePoint — программиста. G>Да, но разница только в том, что это реально используется в работе. Я же говорил что подобный код минимум пару раз в неделю писать приходится. G>В отличие от разрворотов списка.
Если надо писать пару раз в неделю, что 100% это есть в гугле.
I>>Ты похоже делаешь выводы по своему частному случаю. G>Причем тут частый случай? Основной криетрий полезности той или иной задачи — насколько она близка к той работе, которую нужно делать.
Задача близка и задачу надо решь пару раз в неделю это вещи мягко говоря разные.
G>Развороты списка в реальном приложении не пишет никто.
Код он большей частью весь уникальный. Типовые задачи смысла давать решать, проще задать несколько вопросов.
G>Рукопашную сортировку видел один раз, и что потому что программист был не в курсе что такое comparer.
Так что, обсуждать 'широту' твоего опыта ?
G>Поэтому спрашивают все это на собеседовании чтобы потешить самолюбие собеседующего, не более того.
Вероятно это у тебя такая цель.
I>>Баззворд SharePoint в вакансии сам по себе фильтрует неплохо и на собеседования новички практически не приходят. G>А вот ценник притягивает тех, кто полкнижки только успел прочитать.
Здравствуйте, cosimo, Вы писали:
НС>>Ни для каких. Эта задача предназначена для выяснения того, насколько собеседуемый способен в голове держать концепцию ссылок. C>Время занимательных историй. Одолевали меня раньше рекрутеры из Люксофта, к пятому собеседованию уже вызубрил все их логические головоломки, к концу пятого собеседования в очередной раз задают разворот списка, и тут силы меня покинули. Как потом оказалось начинал грипповать. Минут 10 протупил и зафейлил. Больше они ко мне не звонили.
Здравствуйте, Undying, Вы писали:
U>Это именно оптимизация. Т.е. без списка код хеш таблицы будет проще, хоть и несколько проиграет в производительности и памяти. Но т.к. хэш таблицы это стандартные структуры данных, то все оптимизации в коде их реализации уже сделаны.
Наоборот, хештаблица по методу цепочек, т.е. код со списком будет проще, ибо
1. хеширование проще
2. список оформлен явно
Метод прямой адресации сложнее, ибо
1. хеширование намного сложнее и надо понимать как именно разрешаются коллизии
2. список так же есть, только он оформлен неявно, например переход к следующему элементу не по прямой ссылке, а через вычисление хешкода.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Тогда уж добавь — "никогда не слышавший про деревья". Как можно хоть что-то знать про деревья и не знать про самый простой алгоритм в дереве — не понимаю.
PD>А если он и впрямь о них никогда не слышал — так учиться надо. Впрочем, изучение темы двоичных деревьев с нуля и до способов обхода едва ли и в этом случае потребует 4 часов. Максимум час.
Час на изучение и от силы 5 минут что бы продемонстрировать это знание. На собеседовании обычно дается 15-20 минут аккурат из за стресса, бумаги и непривычной обстановки. Если решения нет, то деревья если и есть, то пользоваться ими кандидат не умеет или устойчивость к стрессу ниже плинтуса.
Здравствуйте, gandjustas, Вы писали:
G>И? Все равно он может с помощью гугла написать код на нужном языке за полдня.
Да не напишет он и с помощью гугла. Больше половины на обсуждаемую задачку не задумываясь пишут примерно такой код (и это еще самый приличный вариант, чаще идея похожая, да еще и нормально не реализована):
var head = ...;
var current = head;
var list = new List<Item>();
while (current != null)
{
list.Add(current);
current = current.Next;
}
list.Reverse();
for (int i = 0; i < list.Count - 1; i++)
list[i].Next = list[i + 1];
list[list.Count - 1].Next = null;
Этим гугль не поможет, они и рабочий код будут писать по принципу "фигли тут думать, трясти надо".
Здравствуйте, Undying, Вы писали:
U>Дерево это другая структура данных. И переворот дерева это извращение какое-то, а не практически востребованная операция. А в реализации хэш таблиц где списки используются?
"в реализации хэш таблиц где списки используются" это хороший вопрос на собеседовании. А если это такая форма удивления-несогласия, то за такое не худо бы надавать по шее и вытолкать за дверь.
U>Не понял. Зачем для того, чтобы понимать, что многократное сложение при последующем делении может привести к переполнению, знать что "умножение в двоичной системе счисления считается через цикл и сдвиг"? Первое со вторым вообще не связано.
Если есть задачи оптимизации производительности, то на таких небольших кусочках можно много чего соптимизировать.
U>Производительность работника в первую очередь снижает решение простых задач сложными методами. Например, применением рекурсии там где можно обойтись циклами. И по хорошему именно умение работника решать задачи просто надо проверять на собеседовании. Вы же пытаетесь проверять обратное — умеет ли работник видеть в мухе слона.
Здесь проверяется умение решать простую задачу простым методом, + задача для неподготовленого достаточно новая, нужно немного приложить мозг.
Рекурсия обычно проще циклов. Сложнее в отладке, но проще в написании.
Скажем решения задач навроде реверса списка и похожих рекурсивным методом дают в среднем меньше количетсво ошибок относительно решения с циклом.
Здравствуйте, gandjustas, Вы писали:
G>Любая задача на собеседовании, которая: G>1) Не имеет отношения к потенциальной работе G>2) Требует знания конкретных алгоритмов G>3) Требует решения на бумажке
G>Фактически является головоломкой, которая нужна только для удовлетворения самолюбия собеседующего.
Подставляем в формулу твою задачку по шарепоинту на 7 строчек и согласно п.3. получаем результат — "головоломка, которая нужна только для удовлетворения самолюбия собеседующего"
Здравствуйте, Undying, Вы писали:
N>>Переворот списка — это вообще не сложно. Тут нет ни мух ни слонов. N>>Есть основы, которые нужно знать.
U>Зачем знать? Придумать самому при необходимости, да, это полезный навык. Знание экзотики бесполезный.
Есть одна проблема — нет никакой гарантии, что из постановки задачи будет однозначно очевиден способ её решения.
Даже люди занимающиеся математикой крайне плохо решают такие прикладные задачи, если их область не прикладная математика.
Переворот списка это просто громкие слова. Реально здесь нужно уметь обходить список. А вот задач, похожих на обход списка есть везде выше крыши.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
I>>>Опаньки ! Практически аналог реверса для SharePoint — программиста. G>>Да, но разница только в том, что это реально используется в работе. Я же говорил что подобный код минимум пару раз в неделю писать приходится. G>>В отличие от разрворотов списка.
I>Если надо писать пару раз в неделю, что 100% это есть в гугле.
Когда знаешь что гуглить, да. Но мы специально подобрали задачу, чтобы в одном месте не гуглилась. Надо именно понимать чтобы такое написать.
Ели человек не понимает этих вещей, то нам не подходит.
Причем это не абстрактные знания, которые никогда могут не пригодиться. Эти знания пригождаются почти каждый день.
I>>>Ты похоже делаешь выводы по своему частному случаю. G>>Причем тут частый случай? Основной криетрий полезности той или иной задачи — насколько она близка к той работе, которую нужно делать. I>Задача близка и задачу надо решь пару раз в неделю это вещи мягко говоря разные.
Почему?
G>>Развороты списка в реальном приложении не пишет никто. I>Код он большей частью весь уникальный. Типовые задачи смысла давать решать, проще задать несколько вопросов.
Не-а. Статистика говорит что по большей части люди пишут код, который на 80% повторят уже написанный ими же.
Это кстати проблема, потому что человек может подойти к нетиповой задаче с типовым решением в голове, а потом долго биться. И даже не поймет где он неправ.
G>>Рукопашную сортировку видел один раз, и что потому что программист был не в курсе что такое comparer. I>Так что, обсуждать 'широту' твоего опыта ?
А ты сколько раз рукопашную сортировку видел в реальном проекте? И зачем она там была?
G>>Поэтому спрашивают все это на собеседовании чтобы потешить самолюбие собеседующего, не более того. I>Вероятно это у тебя такая цель.
Я такие вопросы не задаю
I>>>Баззворд SharePoint в вакансии сам по себе фильтрует неплохо и на собеседования новички практически не приходят. G>>А вот ценник притягивает тех, кто полкнижки только успел прочитать. I>Тогда странно, почему отсев только 30%
Это одним вопросом. А мы много вопросов задаем.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, gandjustas, Вы писали:
G>>Так именно знание платформы и нужно НС>Базовые навыки важнее.
Какие именно? Почему важнее?
G>>, а не абстрактное умение "оперировать ссылками" НС>Оно не абстрактное, оно очень практичное.
В каком месте?
G>>Вообще не очень понимаю зачем нужно это абстрактное знание\умение. НС>Код писать.
Ко писать можно и не очень умея разворачивать списки, не находишь?
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
G>>Любая задача на собеседовании, которая: G>>1) Не имеет отношения к потенциальной работе G>>2) Требует знания конкретных алгоритмов G>>3) Требует решения на бумажке
G>>Фактически является головоломкой, которая нужна только для удовлетворения самолюбия собеседующего.
I>Подставляем в формулу твою задачку по шарепоинту на 7 строчек и согласно п.3. получаем результат — "головоломка, которая нужна только для удовлетворения самолюбия собеседующего"
I>
Все 3 надо, а не одно из них.
В нашем случае только 3 и есть, 1 и 2 нет.
Здравствуйте, gandjustas, Вы писали:
НС>>Базовые навыки важнее. G>Какие именно?
В данном случае — понимание что такое ссылка и умение удерживать несложные ссылочные конструкции в голове.
G> Почему важнее?
Потому что этому научить намного сложнее.
НС>>Оно не абстрактное, оно очень практичное. G>В каком месте?
В месте программирования. Не все ж какой нибудь 1С подпиливают, некторые и посложнее задачки решают.
G>>>Вообще не очень понимаю зачем нужно это абстрактное знание\умение. НС>>Код писать. G>Ко писать можно и не очень умея разворачивать списки, не находишь?
Не нахожу. Человек, не способный решить эту задачку, нормальный код писать неспособен.
Здравствуйте, Undying, Вы писали:
U>Он при любой реализации хэш таблицы не динамический и его нужно ресайзить при переполнении.
Он при любой реализации языка не динамический.
Его всегда нужно ресайзить, а вот список не нужно.
Размер списка ограничивает только доступная оперативная память.
Здравствуйте, -n1l-, Вы писали:
U>>Он при любой реализации хэш таблицы не динамический и его нужно ресайзить при переполнении. N>Он при любой реализации языка не динамический.
Реализация словаря на шарпе:
private int[] buckets;
private Dictionary<TKey, TValue>.Entry[] entries;
private void Resize()
{
int prime = HashHelpers.GetPrime(this.count * 2);
int[] numArray = new int[prime];
for (int index = 0; index < numArray.Length; ++index)
numArray[index] = -1;
Dictionary<TKey, TValue>.Entry[] entryArray = new Dictionary<TKey, TValue>.Entry[prime];
Array.Copy((Array) this.entries, 0, (Array) entryArray, 0, this.count);
for (int index1 = 0; index1 < this.count; ++index1)
{
int index2 = entryArray[index1].hashCode % prime;
entryArray[index1].next = numArray[index2];
numArray[index2] = index1;
}
this.buckets = numArray;
this.entries = entryArray;
}
И где тут отсутствие ресайзов и списки в их классическом понимании?
Идея цепочки ссылок, да, используется и в хэштаблицах, и в тех задачах, которые Stanislav V. Zudin приводил. Но список в его классической реализации на практике никому не нужен, ибо зело тормозит. На практике для хранения цепочки ссылок используют массивы и ресайзят их при необходимости.
Здравствуйте, Ikemefula, Вы писали:
U>>А зачем вы ищете специалистов по алгоритмам, а не специалистов по решению алгоритмических задач? I>А в чем разница ? Я чтото не понимаю твоей терминологии.
Для того, чтобы найти специалиста по алгоритмам на собеседовании нужно спрашивать сколько алгоритмов человек вызубрил. Для того, чтобы найти специалиста по решению алгоритмических задач на собеседовании нужно спрашивать какие алгоритмические задачи человек решил в своей профессиональной деятельности.
Например, бинд топлива, т.е. фильтрация шумов, выделение заправок и сливов в сигнале идущего с датчика измеряющего уровень топлива в баке. Задача какая? Несомненно алгоритмическая. И чем тут может помочь знание наизусь всех известных сортировок и их тонкостей?
Здравствуйте, gandjustas, Вы писали:
G>>>Мы используем разворот строки на C#. Причем любой. НС>>Там нет ссылок. G>Нет, они и не нужны.
Где нет ссылок? В C# нет ссылок?
G>Задаем вопрос про value и reference типы в .NET.
Эпично, спрашивать про ссылочные типы и при этом не интересоваться разворотом списка. Это просто эпично.
Здравствуйте, Ikemefula, Вы писали:
I>"в реализации хэш таблиц где списки используются" это хороший вопрос на собеседовании. А если это такая форма удивления-несогласия, то за такое не худо бы надавать по шее и вытолкать за дверь.
Идиотский вопрос, совершенно бесполезный для практики. Полезное знание это формирование хэша объекта для его использования в хэштаблице.
I>Рекурсия обычно проще циклов. Сложнее в отладке, но проще в написании.
Ты издеваешься? Код пишется для того, чтобы он а) работал б) легко модифицировался при необходимости. Если код сложнее в отладке, значит, его тяжелее заставить работать и сложнее модифицировать. Т.е. по определению такой код является более сложным и соответственно худшим при прочих равных.
Здравствуйте, Undying, Вы писали:
U>Для того, чтобы найти специалиста по алгоритмам на собеседовании нужно спрашивать сколько алгоритмов человек вызубрил. Для того, чтобы найти специалиста по решению алгоритмических задач на собеседовании нужно спрашивать какие алгоритмические задачи человек решил в своей профессиональной деятельности.
Нет, вот "зубрилки" и "люди понимающие структуры данных и алгоритмы" — понятия разные.
U>Например, бинд топлива, т.е. фильтрация шумов, выделение заправок и сливов в сигнале идущего с датчика измеряющего уровень топлива в баке. Задача какая? Несомненно алгоритмическая.
Нет, это просто задача. U>И чем тут может помочь знание наизусь всех известных сортировок и их тонкостей?
Только по таким знаниям сложно сказать.
Но вот если нужно строго последовательно обрабатывать данные, то очередь или стек очень пригодятся.
Здравствуйте, Undying, Вы писали: U>Какая задача такой и ответ. В условии хоть указываете, что решение должно быть максимально оптимизировано?
Задача нормальная, ответ идиотский.
Налицо незнание структур данных, не оптимальный и сложный код.
Оверхед в использовании памяти.
Магические числа в коде.
О ссылках я вообще молчу.
Код уровня джуниора максимум.
Здравствуйте, -n1l-, Вы писали:
U>>Например, бинд топлива, т.е. фильтрация шумов, выделение заправок и сливов в сигнале идущего с датчика измеряющего уровень топлива в баке. Задача какая? Несомненно алгоритмическая. N>Нет, это просто задача.
Тогда получается, что алгоритмические задачи на практике не встречаются, т.к. все они уже давным-давно решены в стандартных библиотеках. И знание алгоритмов не нужно тем более.
Здравствуйте, Ikemefula, Вы писали:
I>Односвязный список это ни разу не экзотика, это основы структур данных. Не бывает человека, который хорошо понимает структуры данных и не знает что такое связный список.
Я, например, прекрасно понимаю структуры данных. При этом если бы на форуме не тусовался об односвязном списке не знал бы ничего. Понимать и знать термины это вообще разные вещи.
Здравствуйте, -n1l-, Вы писали:
N>Словарь и хештаблица принципиально разные вещи. Это раз.
А в чем разница? В шарпе вообще только словарь есть. Предлагаешь на собеседовании заворачивать всех шарпистов не знающих чем словарь отличается от хэштаблицы?
Здравствуйте, Undying, Вы писали:
I>>"в реализации хэш таблиц где списки используются" это хороший вопрос на собеседовании. А если это такая форма удивления-несогласия, то за такое не худо бы надавать по шее и вытолкать за дверь.
U>Идиотский вопрос, совершенно бесполезный для практики. Полезное знание это формирование хэша объекта для его использования в хэштаблице.
Значит ты плохо представляешь, что такое хеш-таблицы.
I>>Рекурсия обычно проще циклов. Сложнее в отладке, но проще в написании.
U>Ты издеваешься? Код пишется для того, чтобы он а) работал б) легко модифицировался при необходимости. Если код сложнее в отладке, значит, его тяжелее заставить работать и сложнее модифицировать. Т.е. по определению такой код является более сложным и соответственно худшим при прочих равных.
Если код пишется легче, то и заработает он раньше и модифицировать его будет проще и отлаживать его будет меньше.
Сложность отладки сильно слабо корелирует со сложностью написания и модификации.
Здравствуйте, Undying, Вы писали:
U>Здравствуйте, Ikemefula, Вы писали:
U>>>А зачем вы ищете специалистов по алгоритмам, а не специалистов по решению алгоритмических задач? I>>А в чем разница ? Я чтото не понимаю твоей терминологии.
U>Для того, чтобы найти специалиста по алгоритмам на собеседовании нужно спрашивать сколько алгоритмов человек вызубрил.
Это чушь. Специалист по алгоритмам в первую очередь умеет анализировать алгоритмы. Если человек чего то зазубрил, это никогда не сделает его специалистом ни в одной области.
>Для того, чтобы найти специалиста по решению алгоритмических задач на собеседовании нужно спрашивать какие алгоритмические задачи человек решил в своей профессиональной деятельности.
И здесь тоже самое — в первую очередь надо уметь анализировать алгоритмы. Если ты умеешь
U>Например, бинд топлива, т.е. фильтрация шумов, выделение заправок и сливов в сигнале идущего с датчика измеряющего уровень топлива в баке. Задача какая? Несомненно алгоритмическая. И чем тут может помочь знание наизусь всех известных сортировок и их тонкостей?
Скажи пожалуйста а кто определил специалиста по алгоритмам как зубрилу ?
Я как раз и говорю, что зазубривать наизусть алгоритмы не нужно.
А вот владение соответсвующей математикой это уже серьезная заявка.
Здравствуйте, gandjustas, Вы писали:
G>>>Любая задача на собеседовании, которая: G>>>1) Не имеет отношения к потенциальной работе G>>>2) Требует знания конкретных алгоритмов G>>>3) Требует решения на бумажке
G>>>Фактически является головоломкой, которая нужна только для удовлетворения самолюбия собеседующего.
I>>Подставляем в формулу твою задачку по шарепоинту на 7 строчек и согласно п.3. получаем результат — "головоломка, которая нужна только для удовлетворения самолюбия собеседующего"
I>>
G>Все 3 надо, а не одно из них. G>В нашем случае только 3 и есть, 1 и 2 нет.
Ну значит с реверсом списка все в порядке — это не требует знания конкретного алгоритма, более того, задача выбрана предельно простой что бы чел придумал алгоритм если не сталкивался.
Отношение к потенциальной работе вполне конкретное
1. демонстрация понимание ссылок-указателей
2. понимание списковых структур данных
3. умение закодировать придуманое решение
Здравствуйте, gandjustas, Вы писали:
I>>Если надо писать пару раз в неделю, что 100% это есть в гугле.
G>Когда знаешь что гуглить, да. Но мы специально подобрали задачу, чтобы в одном месте не гуглилась. Надо именно понимать чтобы такое написать.
Практически все как с реверсом списка, только он сам по себе избитая задача и гуглится. Пудозреваю, если другие конторы начнут задавать такие же задачи, как у тебя, решений будет валом в интернете.
G>Ели человек не понимает этих вещей, то нам не подходит.
Правильно,и с реверсом тоже самое — нет решения, не подходит.
G>Причем это не абстрактные знания, которые никогда могут не пригодиться. Эти знания пригождаются почти каждый день.
Это типовые задачи. Все что ты прверишь — умение решать типовые задачи. Это умение ни о чем.
I>>Задача близка и задачу надо решь пару раз в неделю это вещи мягко говоря разные. G>Почему?
Потому, что это типовая задача. С такими нет никаких проблем разобраться, если есть некоторая база в программировании. Проблема с другими задачами, которые только похожи на типовые или вовсе уникальные.
I>>Код он большей частью весь уникальный. Типовые задачи смысла давать решать, проще задать несколько вопросов. G>Не-а. Статистика говорит что по большей части люди пишут код, который на 80% повторят уже написанный ими же.
Не повторяет, а всего лишь похож. Ты слишком вольно трактуешь статистику. Если у тебя люди на 80% повторяют код писаный ими же самими, то это значит, что ты набрал не разработчиков, а копипастеров.
G>Это кстати проблема, потому что человек может подойти к нетиповой задаче с типовым решением в голове, а потом долго биться. И даже не поймет где он неправ.
Правильно ! Потому надо и проверять такое умение, как раз на уникальных задачах, которые только похожи на типовые.
G>А ты сколько раз рукопашную сортировку видел в реальном проекте? И зачем она там была?
Всего не перечислишь. Например нужна гарантия, что сортировка никогда не отработает за n^2. Как ты понимаешь, быстрая сортировка здесь неприменима, а вот фокус, в стандартных алгоритмах нужна именно она.
Есть оптимизации основаные на свойствах конкретных данных и их количестве. Используя эти оптимизации можно получить время линейное или близкое к этому.
I>>Тогда странно, почему отсев только 30% G>Это одним вопросом. А мы много вопросов задаем.
И это странно. Хорошая задача сделает отсев гораздо лучше.
Здравствуйте, Undying, Вы писали:
U>Здравствуйте, Ikemefula, Вы писали:
I>>Односвязный список это ни разу не экзотика, это основы структур данных. Не бывает человека, который хорошо понимает структуры данных и не знает что такое связный список.
U>Я, например, прекрасно понимаю структуры данных.
Понимание структур данных это в первую очередь умение их анализировать и, далее, умение модифицировать и строить новые.
Умение анализировать структуры данных приенимо вообще ко всем структурам данных. Примерно как умение читать применимо ко всем книгам на родном языке, а не к той конкретной, котору ты прочел самой первой.
Соответсвенно все такие вещи прокачиваются на базовых вещах, вроде списков. В алгоритмах эти базовые вещи в основном сортировки. Если у тебя нет специального образования, ну например, ты не заканчивал факультет прикланой математики, то эти умения ты мог прокачат на других вещах.
При этом крайне странно заявлять, что экзотика требует каких то специальных знаний-умений. Если есть знания-умения, то они, как и чтение, применимы даже вещам навроде ревеса строки, списка, дерева и чего угодно.
Если этого у тебя нет, то, извини, ты не понимаешь ни структур данных ни алгоритмов.
Здравствуйте, Undying, Вы писали:
НС>>Этим гугль не поможет, они и рабочий код будут писать по принципу "фигли тут думать, трясти надо".
U>Какая задача такой и ответ. В условии хоть указываете, что решение должно быть максимально оптимизировано?
У инженера большей частью все задачи с неполным условием.
Есть общая проблема — большее количество кода гарантровано создаёт большее количество проблем.
Такое условие никто никогда в техническое задание не вводит, а оно есть.
Еще одна общая проблема — код больше читают, чем пишут. И этого условия в ТЗ не будет, а оно есть.
Еще одна проблема — ожидается, что он понимает, в какой области работает.
Скажем энтерпрайз это как в сказке про Федота стрельца из сборника Афанасьева — "поди туда, незнамо куда, да принеси то, незнамо что"
Итого — инженер обязан уметь решать задачи с неполным условием, даже если они выглядят как то иначе и учитывать общие проблемы присущие коду вообще
1. уточнять задание, уточнять результат и тд
2. размер желательно поменьше, ибо короткая программа при равных свойствах лучше длинной
3. код желательно иметь предельно понятным, ибо понятная программа при равны свойствах лучше запутаной
Поэтому если человек пишет на собеседовании решение по принципу "фигли тут думать, трясти надо", то он нахрен никому не упал, он вообще не инженер
Здравствуйте, Undying, Вы писали:
U>И где тут отсутствие ресайзов и списки в их классическом понимании?
А почему списки должны быть в классческм понимании ?
U>Идея цепочки ссылок, да, используется и в хэштаблицах, и в тех задачах, которые Stanislav V. Zudin приводил. Но список в его классической реализации на практике никому не нужен, ибо зело тормозит. На практике для хранения цепочки ссылок используют массивы и ресайзят их при необходимости.
Практика она разная. В некоторых случаях я бы предпочел иметь цепочку в виде связного списка,что бы не иметь проблем связанных с ресайзом массива.
Здравствуйте, Undying, Вы писали:
U>Тогда получается, что алгоритмические задачи на практике не встречаются, т.к. все они уже давным-давно решены в стандартных библиотеках. И знание алгоритмов не нужно тем более.
Встречаются, просто люди большей частью решают их по методу "трясти надо".
Здравствуйте, Undying, Вы писали: U>А в чем разница? В шарпе вообще только словарь есть. Предлагаешь на собеседовании заворачивать всех шарпистов не знающих чем словарь отличается от хэштаблицы?
Отличие хештаблицы от словаря — это наличие|отсутствие коллизий соответсвтенно.
Вообще хештаблица в шарпе как бы есть, но технически это тоже словарь.
Здравствуйте, Ikemefula, Вы писали:
I>Скажи пожалуйста а кто определил специалиста по алгоритмам как зубрилу ?
Ты на собеседовании спрашиваешь знание алгоритмов, а не опыт по решению реальных алгоритмических задач. Если человек знает алгоритмы, но не применяет их на практике, то он зубрила по определению.
Здравствуйте, Ikemefula, Вы писали:
I>Если код пишется легче, то и заработает он раньше и модифицировать его будет проще и отлаживать его будет меньше.
Ты только что прямо заявил, что рекурсия сложнее в отладке.
Рекурсия обычно проще циклов. Сложнее в отладке, но проще в написании.
Т.е., продолжая твою мысль, рекурсия заработает позже и будет сложнее в модифицировании. Мой опыт это прекрасно подтверждает. Твой опыт, судя по твоему первому утверждению, тоже.
Здравствуйте, Undying, Вы писали: U>Ты на собеседовании спрашиваешь знание алгоритмов, а не опыт по решению реальных алгоритмических задач.
В этой ссылке посмотрите с чего начинается выяснение уровня кандидата. U>Если человек знает алгоритмы, но не применяет их на практике, то он зубрила по определению.
Как можно зная алгоритмы не применять их на практике? Как?
Если вы работаете в высокоуровневом языке, то вы их применяете, но ,чаще всего, не реализуете самостоятельно.
По хорошему, если на минутку представить, что я провожу собеседование и задаю вам вопрос.
То я могу невзначай спросить, как организована оперативная память компьютера, за счет чего данные сохраняются и доступный для обработки.
Могу даже коснуться триггера шмитта. И вы, по идее, должны хотя бы на общем уровне ответить.
А уж что касается списков, то это закон.
Здравствуйте, -n1l-, Вы писали:
N>Вот именно, что по идее в Hashtable должен существовать метод Add(key, value), который без ошибок мог выполнять вот такой код:
И при чем здесь коллизии? Т.е. все-таки хэштаблица и словарь ничем принципиально не отличаются.
Здравствуйте, Undying, Вы писали: U>И при чем здесь коллизии? Т.е. все-таки хэштаблица и словарь ничем принципиально не отличаются.
Что такое коллизии?
Здравствуйте, Sinix, Вы писали:
S>Это не хэш-таблица, а http://en.wikipedia.org/wiki/Multimap вообще-то. И, раз уж не хочется брать внешние библиотеки, что мешает написать самому?
Это хештаблица, где коллизии разрешены методом цепочек.
Дабы было предельно понятно, то ключ я задал через простое число.
Плюс в той же статье есть вот такой текст:
and SGI's STL extension provides the hash_multimap container, which implements a multimap using a hash table.
И да, мне никто не мешает написать это.
Меня напрягает отсутствие этого.
Здравствуйте, Undying, Вы писали: U>Т.е. ты типичный зубрила, который спрашивает на собеседованиях всякую муть вместо того, что реально нужно для дела. Отличником был в школе и вузе?
Нет, я еще слишком молод, что бы проводить собеседования.
Я говорю о том, что если человек получил высшее образование, то как то стыдно в таком случае полагаться только на платформу.
А что если ее будет недостаточно или по задаче нельзя будет ее использовать?
Что тогда? Увольняться и искать другую работу?
Или долго и муторно изучать другую платформу?
Что если используется opensource компонент и его возможностей недостаточно?
Или они работают не совсем так?
Переходить на другой?
Лично я считаю такое отношение к решению задач — плохим тоном.
Здравствуйте, Undying, Вы писали:
I>>У инженера большей частью все задачи с неполным условием.
U>В реальной работе условия задачи определяется Делом. На собеседовании — тараканами в голове собеседователя. Разницы никакой не замечаешь?
И там и там надо уточнять условие, результат, в обоих случаях нужно выбрать более короткое и прозрачное решение.
Сам подумай — если ты умеешь читать, значит ли это, что ты умеешь читать только одну единственную книгу которую прочел первой ?
Здравствуйте, Undying, Вы писали:
U>Ты только что прямо заявил, что рекурсия сложнее в отладке.
U>
U>Рекурсия обычно проще циклов. Сложнее в отладке, но проще в написании.
U>Т.е., продолжая твою мысль, рекурсия заработает позже и будет сложнее в модифицировании. Мой опыт это прекрасно подтверждает. Твой опыт, судя по твоему первому утверждению, тоже.
Рекурсия проще в написании, ты про это забыл ? Модифицировать проще по этой же причине. Вот если ты накосячил в рекурсии и написал её так, что сам не понимаешь, то рекурсия станет адом.
Здравствуйте, Undying, Вы писали:
I>>Скажи пожалуйста а кто определил специалиста по алгоритмам как зубрилу ?
U>Ты на собеседовании спрашиваешь знание алгоритмов, а не опыт по решению реальных алгоритмических задач. Если человек знает алгоритмы, но не применяет их на практике, то он зубрила по определению.
И то и другое в первую очередь это умение анализировать алгоритмы. Знает но не применяет — этот вариант отсеется после конкретной задачи.
Здравствуйте, Undying, Вы писали: U>Кстати, даже если у вас условия задачи определяются тараканами заказчика, то на выяснение этих тараканов у специально обученных людей уходят многие дни. А от программиста вы почему-то требуете выяснить тараканов собеседователя за считанные минуты.
Да что там смотреть высматривать в связанном списке?
Это настолько тривиально, что без вопросов должно решаться.
Да и на собеседованиях, лично я, редко встречаю задачи до понимания сути которых сложно докопаться.
Здравствуйте, -n1l-, Вы писали:
U>>И при чем здесь коллизии? Т.е. все-таки хэштаблица и словарь ничем принципиально не отличаются. N>Что такое коллизии?
Ты ж специалист по алгоритмам, а не я, ты и должен знать.
Коллизия это когда хэш объекта попал в ячейку уже занятую другим объектом.
Здравствуйте, Ikemefula, Вы писали:
U>>Например, бинд топлива, т.е. фильтрация шумов, выделение заправок и сливов в сигнале идущего с датчика измеряющего уровень топлива в баке. Задача какая? Несомненно алгоритмическая. И чем тут может помочь знание наизусь всех известных сортировок и их тонкостей?
Никак — оно вообще к этой задаче отношения не имеет. Здесь всего-лишь нужен ЦОС, немного ТВиМС и основ матана.
I>А вот владение соответсвующей математикой это уже серьезная заявка.
Не смеши а, никто вам такую задачу не даст ибо не решите, потому как кроме стандартных алгоритмов ничего не знаете и достаете всех этим. И да, в Минске есть нынче человек 20, кто эту задачу решит — образование нынче такое.
Здравствуйте, Undying, Вы писали:
U>Ты на собеседовании спрашиваешь знание алгоритмов, а не опыт по решению реальных алгоритмических задач. Если человек знает алгоритмы, но не применяет их на практике, то он зубрила по определению.
А ничего другого и не надо "индусом меньше, индусом больше".
Здравствуйте, Ikemefula, Вы писали:
I>Понимание структур данных это в первую очередь умение их анализировать и, далее, умение модифицировать и строить новые.
Понимание в первую очередь означает умение подобрать структуру данных под реальную задачу по критериям простоты, надежности и производительности. Знание 25 способов сортировки пониманию никак не помогает.
Здравствуйте, Ikemefula, Вы писали:
I>Скажи пожалуйста а кто определил специалиста по алгоритмам как зубрилу ? I>Я как раз и говорю, что зазубривать наизусть алгоритмы не нужно.
Как это не нужно зубрить? Ты сам писал:
На сортировке отлично проверяются алгоритмические скилы. Если ты гуглишь сортировки, то сильно вряд ли ты в курсе, что есть сортировки за линейное время или близкое к нему.
А еще у каждой сортировки целая куча разных особенностей, таких, как лучший и худший случаи.
И часто очень важно обосновать правильный выбор. Есть случаи, когда можно и нужно использовать быструю сортировку, а есть случаи, когда ни в коем случае этого нельзя делать.
Кроме того, если нужно будет модифицировать алгоритм, то гугл не скажет тебе, как изменяется вычислительная сложность.
Вообще сортировка это практически дедушка всех алгоритмов, если специалист по алгоритмам здесь плавает, то дальше его можно и не спрашивать.
Так чем знание всех сортировок и их лучших/худших случаев поможет написать бинд топлива? Т.е. решить реально востребованную бизнесом алгоритмическую задачу?
Кстати, для общего развития в каких случаях ни в коем случае нельзя использовать быструю сортировку?
Здравствуйте, Undying, Вы писали:
U>Так чем знание всех сортировок и их лучших/худших случаев поможет написать бинд топлива? Т.е. решить реально востребованную бизнесом алгоритмическую задачу?
Не знание всех, а умение строить и анализировать алгоритмы.
U>Кстати, для общего развития в каких случаях ни в коем случае нельзя использовать быструю сортировку?
У ней n*log(n) это среднее время работы, худший случай — n^2
Когда есть некоторые сведения о характере и количестве сортируемых данных, можно подобрать более подходящий алгоритм, часто даже O(n).
Здравствуйте, Undying, Вы писали:
I>>Понимание структур данных это в первую очередь умение их анализировать и, далее, умение модифицировать и строить новые.
U>Понимание в первую очередь означает умение подобрать структуру данных под реальную задачу по критериям простоты, надежности и производительности. Знание 25 способов сортировки пониманию никак не помогает.
Правильно, а ты мне талдычишь про зубрение и гугление. Что бы правильно подобрать алгоритм надо уметь анализировать. Когда ты это умеешь, то найдешь нужный вариант даже если ты про него никогда не слышал.
Здравствуйте, Undying, Вы писали:
U>Здравствуйте, Ikemefula, Вы писали:
I>>Рекурсия проще в написании, ты про это забыл ?
U>То что проще в написании не может быть сложнее в отладке.
Может, запросто. Большинство рекурсивных алгоритмов на порядок сложнее обычной версии с циклами и приседаниями.
> Сложнее в отладке может быть то, что лаконичнее в написании.
Для отладки важна возможность поставить бряк, получить стек, лог и тд. В рекурсивной версии эти вещи часто приходится обеспечивать дополнительно.
Например в версии с циклами у тебя есть переменная цикла. А в рекурсивной версии она запросто может отсутствовать. Conditional break тебе больше не поможет.
>Простота и лаконичность это совершенно разные, а зачастую и прямо противоположные вещи.
Я честно говоря не знаю что ты подразумеваешь под этими терминами.
Здравствуйте, Vzhyk, Вы писали:
U>>>Например, бинд топлива, т.е. фильтрация шумов, выделение заправок и сливов в сигнале идущего с датчика измеряющего уровень топлива в баке. Задача какая? Несомненно алгоритмическая. И чем тут может помочь знание наизусь всех известных сортировок и их тонкостей? V>Никак — оно вообще к этой задаче отношения не имеет. Здесь всего-лишь нужен ЦОС, немного ТВиМС и основ матана.
Эту математику еще нужно будет уложить в правильные структуры данных и тд, что бы не было мучительно больно. Здесь как раз теория алгоритмов и сгодится.
I>>А вот владение соответсвующей математикой это уже серьезная заявка. V>Не смеши а, никто вам такую задачу не даст ибо не решите, потому как кроме стандартных алгоритмов ничего не знаете и достаете всех этим. И да, в Минске есть нынче человек 20, кто эту задачу решит — образование нынче такое.
Не понял, ты не согласен с тем, что математика важна или просто хотел попонтоваться ?
Если первое, то пудозреваю, тебе надо поспать, если второе, то не боись, я в такие области лезу ровно настолько, насколько я знаю математику. Скажем в обработку звука я не лезу — нет у меня этой математики.
Здравствуйте, Vzhyk, Вы писали:
U>>>В реальной работе условия задачи определяется Делом. N>>А не тараканами ли заказчика? V>Нет. У заказчика, кроме товарища Попила тараканов нет. Есть вполне конкретная задача, которую надо решить.
Это у твоих заказчиков. А у других это может быть автоматизация бизнеса, выход на новый рынок и тд.
Здравствуйте, Ikemefula, Вы писали:
I>Эту математику еще нужно будет уложить в правильные структуры данных и тд, что бы не было мучительно больно. Здесь как раз теория алгоритмов и сгодится.
Реально пофиг. Главное, чтобы то, что запрограммировал делало именно то что нужно. А вот какая там сортировка, вообще не интересно, главное, чтобы правильная была.
I> Скажем в обработку звука я не лезу — нет у меня этой математики.
А разница в обработке звука или других сигналов не велика, используется все тот же ЦОС, ТВиМС и чуть-чуть матана (большей частью, чтобы понимать первые два). Есть некоторые особенности, которые осознаются только с опытом в конкретной области.
Да, и кстати, еще совсем недавно все это делали на фортране и без всяких извращений. Кстати, до сих пор многие расчетные библиотеки так на фортране и остались.
Здравствуйте, Vzhyk, Вы писали:
U>>Понимание в первую очередь означает умение подобрать структуру данных под реальную задачу по критериям простоты, надежности и производительности. Знание 25 способов сортировки пониманию никак не помогает. V>Я тебе больше скажу для задачи выше о топливе пофиг на эти структуры, достаточно и обычных массивов со структурами, главное придумать правильные фильтры и алгоритмы принятия решения.
Для этой может хватит и массивов, а вот обработка сигналов да в реалтайме очень часто требует работу с огромными массивами данных. Скажем, объемы данных могут быть больше чем любой непрерывный фрагмента адресного пространства. Как тут обойтись массивами — совершенно непонятно. Наверное у тебя массивы специальные, которые не требуют адресного пространства
Здравствуйте, Vzhyk, Вы писали:
I>> Скажем в обработку звука я не лезу — нет у меня этой математики. V>А разница в обработке звука или других сигналов не велика, используется все тот же ЦОС, ТВиМС и чуть-чуть матана (большей частью, чтобы понимать первые два). Есть некоторые особенности, которые осознаются только с опытом в конкретной области.
И в обработку сигналов я тоже не лезу по той же причине.
Вот скажи, приходит чел и говорит — я знаю матан, твимс и цос, и вдруг оказывается, что он умеет только обработку каких то сигналов, а со звуком у него проблемы. Что ты ему скажешь на собеседовании ?
V>Да, и кстати, еще совсем недавно все это делали на фортране и без всяких извращений. Кстати, до сих пор многие расчетные библиотеки так на фортране и остались.
Про офртран. Я как то сбоку следил, как развивалась софтина где ядро было на фортране. Количество фортранового кода по тем временам было около 15-20мб. Поверх ядра прикрутили НЕЧТО, эмулирующее гигантский массив, раз в десять больше чем адресное пространство, ибо программа на фортране ни с чем кроме обычных массивов работать не умела и ей нужны были конские массивы. И как то так вышло, что это НЕЧТО оказалось напичканым алгоритмами и структурами данных не хуже движка СУБД.
Здравствуйте, Vzhyk, Вы писали:
I>>Для этой может хватит и массивов, а вот обработка сигналов да в реалтайме очень часто требует работу с огромными массивами данных. Скажем, объемы данных могут быть больше чем любой непрерывный фрагмента адресного пространства. V>Не знаешь не пиши — это смешно. И да, у меня такие были и не раз и не влазили много куда, и что, сортировки и т.п. детские алгоритмы (переворот списка, обращения гномика, обход дерева, не помню уже все извращения, что на кывте приводились) к этому отношения не имеют. Модифицируешь алгоритм, чтобы он стал блочным и вперед к поиску "бутылочных горлышек", а они обычно или в скорости сетки (уменьшим обмен) или лишних расчетов (много чего можно закешировать, но иногда лучше пересчитать, чем кешировать — по разному бывает) или в том, что нужно использовать MKL, а не извращаться с велосипедами или просто нужно более мощное железо (ибо выше головы не прыгнешь).
Кеширование да без структур данных — это новость !
I>>Как тут обойтись массивами — совершенно непонятно. Наверное у тебя массивы специальные, которые не требуют адресного пространства V>Порезать их на части и сделать блочный алгоритм. А вот тобой предлагаемые извраты с хитрыми контейнерами могут сильно усугубить ситуацию — баги искать задолбаешься, у уж про распараллеливание и не говорю.
А что хитрого может быть в кешировании которое ты сам же и упомянул ? Для распараллеливания, кстати, как раз и нужны всякие структуры данных.
Здравствуйте, Ikemefula, Вы писали:
I>Вот скажи, приходит чел и говорит — я знаю матан, твимс и цос, и вдруг оказывается, что он умеет только обработку каких то сигналов, а со звуком у него проблемы. Что ты ему скажешь на собеседовании ?
Скажу, что фигня, за пару месяцев войдешь в тему. Я кстати так и говорю, если хотят от меня не мою специализацию. У меня опыт с низкочастотными речевыми сигналами с их особенностями, а вот в сигналах того же кардиографа я лох и мне надо несколько месяцев будет читать статьи и литературу в той области (в т.ч. и медицинскую), чтобы начать что-то серьезное делать мочь. Да и желательно, чтобы был наставник. А если пропустить простейшие вещи с фильтрацией и уйти дальше, то там вообще сильно разные научные подходы используются и нескольких месяцев недостаточно. Но, о чем это я, нынче бери и кудай код отсюда и сюда, сортируй гномиков.
V>>Да, и кстати, еще совсем недавно все это делали на фортране и без всяких извращений. Кстати, до сих пор многие расчетные библиотеки так на фортране и остались.
I>Про офртран. Я как то сбоку следил, как развивалась софтина где ядро было на фортране. Количество фортранового кода по тем временам было около 15-20мб. Поверх ядра прикрутили НЕЧТО, эмулирующее гигантский массив, раз в десять больше чем адресное пространство, ибо программа на фортране ни с чем кроме обычных массивов работать не умела и ей нужны были конские массивы. И как то так вышло, что это НЕЧТО оказалось напичканым алгоритмами и структурами данных не хуже движка СУБД.
Для начала известные всем блас с лапаком. Но да, я понимаю, недостаток опыта и знаний виден и ничем я тебе не смогу помочь. Ну нет в РБ и РФ уже спроса на специалистов нужны только "индусы", а так года за 3 ты чему-нибудь научился.
Здравствуйте, Undying, Вы писали:
НС>>Этим гугль не поможет, они и рабочий код будут писать по принципу "фигли тут думать, трясти надо". U>Какая задача такой и ответ.
Задача — нормальная.
U> В условии хоть указываете, что решение должно быть максимально оптимизировано?
Что значит максимально оптимизировано? У того кода, что я написал — у него есть хоть в чем то преимущество перед нормальным решением?
Тут видишь ли какое дело — всегда ведь можно спросить, почему сделано так а не иначе. И если какой то код окажется менее оптимальным, но, к примеру, короче и проще, это можно обсудить. Но когда приводится вариант, который хуже по всем параметрам, то я не вижу ни одного оправдания такого.
Это один момент. А второй — мы не ищем людей, которые должны лопатить от забора до обеда по строгому ТЗ. У нас даже менее опытным программистам задачка дается в стиле "решить такую то проблему". Если проблема сложная, я еще могу накидать какой то предварительный дизайн и указать на принципиальные моменты, а если там нет каких то особых челленджей, то этим все и заканчивается, дальше надо применять активно свой моск. Единственное где тут можно сэкономить — составить список конкретных вопросов по функционалу и нефункциональным требованиям и отдать список аналитику.
В таком разрезе человек, которому надо даже для такой примитивной задачи явно указывать на то, что кривой код писать не надо, нам не нужен. Так что пускай он идет куда нибудь в другое место рассказывать про ужасные задачи на собеседовании, авось где нибудь на допиливание готовых платформ типа 1С или шерпоинта пригодится.
Но это все совсем совсем другой уровень, нежели решение примитивных задачек.
Здравствуйте, Undying, Вы писали:
U>Кстати, даже если у вас условия задачи определяются тараканами заказчика, то на выяснение этих тараканов у специально обученных людей уходят многие дни.
О, это отдельный скилл, тоже важный начиная с определенного уровня разработчика. Но тут уже от конкретной фирмы зависит. Как то довольно давно я был на собеседовании в одной известной конторе, мне задали вопрос в стиле "спроектируйте ка дизайн вот под такую задачку", видимо ожидая некий более менее стандартный ответ сразу. И когда я начал фиксировать нефункциональные требования (необходимость расширяемости, временные и бюджетные рамки, предполагаемое время жизни проекта и т.п.) это их поставило в тупик, потому что в эту сторону они даже не думали.
А весь этот флейм в основном раздувается некоторыми товарищами, которые пытаются придумать причину почему эти 9 значащих строк ну никак невозможно на собеседовании написать без гугла и спецподготовки.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
I>>>Если надо писать пару раз в неделю, что 100% это есть в гугле.
G>>Когда знаешь что гуглить, да. Но мы специально подобрали задачу, чтобы в одном месте не гуглилась. Надо именно понимать чтобы такое написать. I>Практически все как с реверсом списка, только он сам по себе избитая задача и гуглится.
Задача не алгоритмическая. Нужно знать 3 класса, 4 функции и понимать как они работают. Все эти функции обычно программисты пишут каждый день. В интернетах все есть.
Но вот люди невнимательно читают и часто не понимают почему пишут именно так.
I>Пудозреваю, если другие конторы начнут задавать такие же задачи, как у тебя, решений будет валом в интернете.
Не-а. На русском про SharePoint пишут человек пять. Один уехал, одн работает со мной, а еще двое были на собеседовании.
G>>Ели человек не понимает этих вещей, то нам не подходит. I>Правильно,и с реверсом тоже самое — нет решения, не подходит.
Не правильно, разворот списка не имеет отношения к реальной программе.
Почему например людей не фильтруют по незнанию преобразования числа в строку?
Или по итеративному вычислению квадратного корня?
G>>Причем это не абстрактные знания, которые никогда могут не пригодиться. Эти знания пригождаются почти каждый день. I>Это типовые задачи. Все что ты прверишь — умение решать типовые задачи. Это умение ни о чем.
Я же писал, что 80% задач на работе — типовые. Это у всех. Более того, люди сами стремятся так работать — сводить все к типовым задачам. Ибо так мозг меньше напрягается.
I>>>Задача близка и задачу надо решь пару раз в неделю это вещи мягко говоря разные. G>>Почему? I>Потому, что это типовая задача. С такими нет никаких проблем разобраться, если есть некоторая база в программировании.
Практика показывает что есть. Раньше брали asp.net программистов, в надежде что разберутся. Увы, разбираться сложно, а писать на asp.net легко. Только value added получался отрицательным.
I>Проблема с другими задачами, которые только похожи на типовые или вовсе уникальные.
Они обычно сводятся к типовым. Потому что так дешевле.
I>>>Код он большей частью весь уникальный. Типовые задачи смысла давать решать, проще задать несколько вопросов. G>>Не-а. Статистика говорит что по большей части люди пишут код, который на 80% повторят уже написанный ими же.
I>Не повторяет, а всего лишь похож. Ты слишком вольно трактуешь статистику. Если у тебя люди на 80% повторяют код писаный ими же самими, то это значит, что ты набрал не разработчиков, а копипастеров.
"всего лишь похож" это и есть типовые задачи. То есть на входе примерно одно и тоже, а выходе тоже примерно одинаковое, вариативность логики небольшая. С точки зрения бизнеса задачи могут быть сильно разные. С точки зрения решения — очень похожи друг на друга.
G>>Это кстати проблема, потому что человек может подойти к нетиповой задаче с типовым решением в голове, а потом долго биться. И даже не поймет где он неправ. I>Правильно ! Потому надо и проверять такое умение, как раз на уникальных задачах, которые только похожи на типовые.
Нет, это бессмысленно. Какой смысл решать уникальную задачу? Угадал — не угадал? Что это может сказать о человеке?
Суть программирования — комбинирование решения из готовых кусочков. Для комбинирования надо понимать как кусочки устроены и собственно навык комбинирования.
Этот навык очень далек от разворота списка. Хотя и разворот списка можно через комбинирование написать, но это уже сложнее.
G>>А ты сколько раз рукопашную сортировку видел в реальном проекте? И зачем она там была? I>Всего не перечислишь. Например нужна гарантия, что сортировка никогда не отработает за n^2. Как ты понимаешь, быстрая сортировка здесь неприменима, а вот фокус, в стандартных алгоритмах нужна именно она.
Я спросил сколько. 1-2-3-10-100 раз?
Выделенное кстати зачем? Value какой?
I>Есть оптимизации основаные на свойствах конкретных данных и их количестве. Используя эти оптимизации можно получить время линейное или близкое к этому.
А зачем это все? Вставляй в сбалансированное дерево при получении данных, далее за o(n) доставай упорядоченное.
Вообще не пойму в чем поинт оптимизации алгоритмов, если большую часть времени процессор спит, а когда работает — клеит строки.
HFT и разработкой бд тут мало кто не занимается.
I>>>Тогда странно, почему отсев только 30% G>>Это одним вопросом. А мы много вопросов задаем.
I>И это странно. Хорошая задача сделает отсев гораздо лучше.
Нет. SharePoint слишком большой, чтобы одной задачей покрыть. А минимальный скиллсет требуется большой.
Здравствуйте, Ikemefula, Вы писали:
I>Ну значит с реверсом списка все в порядке — это не требует знания конкретного алгоритма, более того, задача выбрана предельно простой что бы чел придумал алгоритм если не сталкивался.
Разворот списка на месте требует именно определенного алгоритма
Здравствуйте, -n1l-, Вы писали:
N>Здравствуйте, gandjustas, Вы писали:
G>>>>Мы используем разворот строки на C#. Причем любой. НС>>>Там нет ссылок. G>>Нет, они и не нужны. N>Где нет ссылок? В C# нет ссылок?
В задаче на разворот строки.
G>>Задаем вопрос про value и reference типы в .NET. N>Эпично, спрашивать про ссылочные типы и при этом не интересоваться разворотом списка. Это просто эпично.
Разница между ссылочными и размерными типами — особенность платформы, которую стоит знать. Особенные проблемы получаются у тех, кто раньше на C++ писал.
А разворот списка для нас бесполезен. Да и для всех остальных тоже.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, gandjustas, Вы писали:
НС>>>Базовые навыки важнее. G>>Какие именно? НС>В данном случае — понимание что такое ссылка и умение удерживать несложные ссылочные конструкции в голове.
Зачем?
Пуст лучше компьютер удерживает, у него памяти много и она не дырявая, как в програиистов.
G>> Почему важнее? НС>Потому что этому научить намного сложнее.
Как раз легче. Но все равно не зачем.
НС>>>Оно не абстрактное, оно очень практичное. G>>В каком месте? НС>В месте программирования. Не все ж какой нибудь 1С подпиливают, некторые и посложнее задачки решают.
Ну вот, ты уже сам пришел к выводу, что это не всем надо.
G>>>>Вообще не очень понимаю зачем нужно это абстрактное знание\умение. НС>>>Код писать. G>>Ко писать можно и не очень умея разворачивать списки, не находишь? НС>Не нахожу. Человек, не способный решить эту задачку, нормальный код писать неспособен.
Практика показывает обратное.
Здравствуйте, Undying, Вы писали:
U>Коллизия это когда хэш объекта попал в ячейку уже занятую другим объектом.
Коллизия — это явление при котором хеш-функция получает для двух разных объектов одинаковый хеш-код.
В словарь невозможно добавить два объекта с одинаковым хеш-кодом, а в хеш-таблицу возможно.
Здравствуйте, gandjustas, Вы писали: G>Разница между ссылочными и размерными типами — особенность платформы, которую стоит знать. Особенные проблемы получаются у тех, кто раньше на C++ писал. G>А разворот списка для нас бесполезен. Да и для всех остальных тоже.
Интересно, как ваши кандидаты, не зная что такое ссылка, растолковывают вам отличие передачи ссылочного типа с|без ключевого слова ref.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Это один момент. А второй — мы не ищем людей, которые должны лопатить от забора до обеда по строгому ТЗ.
И мне не нужен.
НС>У нас даже менее опытным программистам задачка дается в стиле "решить такую то проблему".
Т.е. условия задачи определяется Делом. А не чьими-то тараканами в голове. Задачи на собеседовании не связаны с делом, их условия определяются чисто собеседователем. А пришедший на собеседование его в первый раз в жизни видит, и без понятия что от него хотят — чтобы он просто решил задачу, чтобы он сделал это быстро, чтобы он сделал это оптимально.
НС>В таком разрезе человек, которому надо даже для такой примитивной задачи явно указывать на то, что кривой код писать не надо, нам не нужен.
А что в приведенном тобой коде особо кривого? На автопилоте я бы весьма вероятно написал бы примерно такой же код, разве что без list.Reverse. И в продакшене меня бы подобный код вполне устроил, при условии что он не работает с большими объемами данных. Соответственно если бы человек на собеседовании написал бы подобный код, заметив при этом что код не оптимален по производительности, я бы посчитал что он хорошо справился с задачей.
Здравствуйте, Ikemefula, Вы писали:
I>У ней n*log(n) это среднее время работы, худший случай — n^2
Есть подозрение, что вероятность этого худшего случая на большой коллекции данных пренебрежимо мала.
I>Когда есть некоторые сведения о характере и количестве сортируемых данных, можно подобрать более подходящий алгоритм, часто даже O(n).
А конкретный пример и характера данных, и алгоритма можешь привести?
Здравствуйте, Vzhyk, Вы писали:
V> Здесь всего-лишь нужен ЦОС, немного ТВиМС и основ матана.
На самом деле в данной задаче и от всего перечисленного толку немного. Классическая ЦОС заточена под часто снимаемые сигнала. А когда данные идут раз в десять секунд работает это все кое как.
Здравствуйте, -n1l-, Вы писали:
U>>Если у вас условия задачи определяются тараканами в голове заказчика, то я вам искренне сочувствую. N>Так это в итоге всегда так.
Если заказчиков много, то это всегда не так по совершенно объективным причинам.
Здравствуйте, gandjustas, Вы писали:
G>Задача не алгоритмическая. Нужно знать 3 класса, 4 функции и понимать как они работают. Все эти функции обычно программисты пишут каждый день. В интернетах все есть. G>Но вот люди невнимательно читают и часто не понимают почему пишут именно так.
То есть — не надо.
I>>Пудозреваю, если другие конторы начнут задавать такие же задачи, как у тебя, решений будет валом в интернете. G>Не-а. На русском про SharePoint пишут человек пять. Один уехал, одн работает со мной, а еще двое были на собеседовании.
А почему надо только русский язык учитывать ?
I>>Правильно,и с реверсом тоже самое — нет решения, не подходит. G>Не правильно, разворот списка не имеет отношения к реальной программе.
Объясняю еще раз — кроме ссыдлк-указателей и тд, в каждой программе всегда и везде будет уникальный код, который пишется практически каждый день.
Нужны способности писать этот уникальный код, а не пытаться всё свести к типовой задаче.
G>Почему например людей не фильтруют по незнанию преобразования числа в строку? G>Или по итеративному вычислению квадратного корня?
Фильтруют, не переживай.
I>>Это типовые задачи. Все что ты прверишь — умение решать типовые задачи. Это умение ни о чем. G>Я же писал, что 80% задач на работе — типовые. Это у всех. Более того, люди сами стремятся так работать — сводить все к типовым задачам. Ибо так мозг меньше напрягается.
Оставшиеся 20% задач как раз и создают бОльшую часть проблем. Если кандидат начнет сводить их к типовым, получится хаос.
I>>Потому, что это типовая задача. С такими нет никаких проблем разобраться, если есть некоторая база в программировании. G>Практика показывает что есть. Раньше брали asp.net программистов, в надежде что разберутся. Увы, разбираться сложно, а писать на asp.net легко. Только value added получался отрицательным.
Естественно, ты же и асп-нетчиков брал точно так же — по типовым задачам. А если человек умеет решать нестандартные задачи, то как правило ему разбираться будет легко.
I>>Проблема с другими задачами, которые только похожи на типовые или вовсе уникальные. G>Они обычно сводятся к типовым. Потому что так дешевле.
Ты похоже начал сам с собой спорить: "человек может подойти к нетиповой задаче с типовым решением в голове, а потом долго биться. И даже не поймет где он неправ"
Ты определись, таки дешевле или он не прав.
I>>Правильно ! Потому надо и проверять такое умение, как раз на уникальных задачах, которые только похожи на типовые. G>Нет, это бессмысленно. Какой смысл решать уникальную задачу? Угадал — не угадал? Что это может сказать о человеке?
Смысл в том, что типовые задачи создают меньше всего проблем в силу того, что они отработаны чуть не до автоматизма. А остальные задачи создают бОльшую часть проблем.
G>Суть программирования — комбинирование решения из готовых кусочков. Для комбинирования надо понимать как кусочки устроены и собственно навык комбинирования. G>Этот навык очень далек от разворота списка. Хотя и разворот списка можно через комбинирование написать, но это уже сложнее.
Одним комбинированием новую задачу не решить.
I>>Всего не перечислишь. Например нужна гарантия, что сортировка никогда не отработает за n^2. Как ты понимаешь, быстрая сортировка здесь неприменима, а вот фокус, в стандартных алгоритмах нужна именно она. G>Я спросил сколько. 1-2-3-10-100 раз?
В среднем раз в год, и кое какие даже сам писал.
G>Выделенное кстати зачем? Value какой?
Требования, естественно, на время отклика. Правда это было в проекте которым я не занимался.
I>>Есть оптимизации основаные на свойствах конкретных данных и их количестве. Используя эти оптимизации можно получить время линейное или близкое к этому. G>А зачем это все? Вставляй в сбалансированное дерево при получении данных, далее за o(n) доставай упорядоченное.
Операцией добавления N Элементов в дерево можно значит пренебречь ? у тебя уже на ровном месте O(n log(n)) + дополнительная память O(n) + отдавать данные вместо O(1) почему то O(n)
Обожаю таких специалистов — никогда не задают вопросов ни про требования, ни про ограничения, ни про особенности модуля, но всегда знают лучше всех.
Предложи решение которое даст O(n) без дополнительной памяти.
G>Вообще не пойму в чем поинт оптимизации алгоритмов, если большую часть времени процессор спит, а когда работает — клеит строки.
Ты это, прекращай по себе мерить, а то ты выглядишь как вчерашний джуниор. Я про склеивание строк и спящий процессор нигде не говорил.
G>HFT и разработкой бд тут мало кто не занимается.
Чисто как пример — рендеринг используется очень часто во всяких тулах которые чтото визуализируют. Тут всегда вагон оптимизаций. САПР, моделирование, визуализация, сложные вычисления — перечислять можно до понедельника.
Здравствуйте, Undying, Вы писали:
U>Декоратор это антипаттерн. Но тебе этого не понять, потому что зубришь и повторяешь за авторитетами, а не думаешь и не понимаешь сам.
Декоратор, это не антипаттерн. Антипаттернов вообще не бывает. Есть их не правильное применение.
Но это не важно. Я вас о другом спрошу.
Вы читаете хабрахабр?
Здравствуйте, Undying, Вы писали:
U>Здравствуйте, Ikemefula, Вы писали:
I>>У ней n*log(n) это среднее время работы, худший случай — n^2
U>Есть подозрение, что вероятность этого худшего случая на большой коллекции данных пренебрежимо мала.
Я погляжу на твое пренебрежение, когда от сложности сортировки будет зависеть время отклика авионики самолета или хотя бы плавность проигрывания видеофайла.
Еще быстрая сортировка неустойчивая, то есть иногда ее нельзя использовать даже в оперденях, в местах где есть таблицы с упорядочиванием по колонкам.
В микроконтроллерах быстрая сортировка моментально сожрет весь стек (если его программно не эмулировать).
Здравствуйте, Vzhyk, Вы писали:
V>Блин, с каждым днем, я все больше и больше в шоке от кывта, точнее от современных программистов. Обычно я всегда тут нахожу, что ответить, но сейчас я ступоре, у меня просто нет слов.
До меня был вариант с использованием теории фильтров и т.п. Работал не очень. Через некоторое время переписал его на свой алгоритм, взятый не из умных книжек. Работать стало отлично, хоть с объективной, хоть с субъективной (т.е. лучше чем у конкурентов) точки зрения. Так что я делаю не так?
В любой нетривиальной задаче надо думать своей головой, а не надеяться, что кто-то за тебя в умной книжке задачу решил.
Здравствуйте, Undying, Вы писали:
I>>У ней n*log(n) это среднее время работы, худший случай — n^2
U>Есть подозрение, что вероятность этого худшего случая на большой коллекции данных пренебрежимо мала.
Вероятность зависит не от размера а от порядка следования и в случаях близких к наихудшему глубина рекурсии слишком высока, т.е. там где время близко O(n^2) память израсходуется O(n).
I>>Когда есть некоторые сведения о характере и количестве сортируемых данных, можно подобрать более подходящий алгоритм, часто даже O(n).
U>А конкретный пример и характера данных, и алгоритма можешь привести?
Рендеринг некоторой сцены. Понадобилась стабильная сортировка с временем близком к линейному которая не будет требовать дополнительной памяти. Фактически, z-order, количество элементов в сцене от 100К и отсечения неприменимы, т.к. элементы слишком сложные. Стандартная сортировка во первых, нестабильная, давала периодически небольшие лаги, иногда длительное замерзание, и пару раз было переполнение стека.
Теоретически, 100К элементов не надо рисовать, но вот алгоритм, который подскажет более менее адекватную картинку в таком случае работает слишком медленно. Проще было взять и нарисовать всё с учетом z-order.
Здравствуйте, Undying, Вы писали:
U>Здравствуйте, -n1l-, Вы писали:
N>>Декоратор, это не антипаттерн. Антипаттернов вообще не бывает. Есть их не правильное применение.
U>Бывают и их очень много.
На хабрахабре прочли?
N>>Вы читаете хабрахабр?
U>По очень большим праздникам.
N>А все почему? Потому, что есть типа идиома какая-то или закон, звучит так — "Нельзя писать велосипед!!!".
Это правильная идиома. Нельзя писать велосипед, пока не доказано, что имеющиеся стандартные решения не удовлетворяют требованиям задачи.
N>Любая задача сводится к тому, что она уже написана и надо просто погуглить и скопипастить код.
Действительно уже много задач написано и в 90% процентах случаев программистской работы можно скопипастить. Но есть 10% (или сколько там процентов), где такое не пройдет.
N>То, что этот код может быть неправильным, неподходящим для задачи или просто переусложненным игнорируется полностью. N>Отсюда имеем плачевный результат, забери у такого "спеца" его платформу или интернет и он не способен решить ни одной проблемы.
Если у вас все задачи на конторе попадают исключительно в 10% R&D — что невозможно.
Здравствуйте, Ikemefula, Вы писали:
I>Вероятность зависит не от размера а от порядка следования и в случаях близких к наихудшему глубина рекурсии слишком высока, т.е. там где время близко O(n^2) память израсходуется O(n).
С этим согласен. Но просто было интересно есть ли вероятностные оценки столкновения с проблемой на случайных данных.
I>Рендеринг некоторой сцены. Понадобилась стабильная сортировка с временем близком к линейному которая не будет требовать дополнительной памяти. Фактически, z-order, количество элементов в сцене от 100К и отсечения неприменимы, т.к. элементы слишком сложные. Стандартная сортировка во первых, нестабильная, давала периодически небольшие лаги, иногда длительное замерзание, и пару раз было переполнение стека.
Так чем тебе помогло твое знание сортировок? Ты все равно с начала столкнулся с проблемой, а потом уже начал ее решать. Т.е. это еще одно подтверждение того, что ключевой навык программиста это умение быстро разобраться в возникшей проблеме, а вовсе не наличие горы мусора в голове выученной на всякий случай.
Здравствуйте, Vzhyk, Вы писали:
V>Любым инструментов можно себе нанести увечья, разве это говорит о том, что инструмент такой? Это говорит лишь о кривизне рук использующего. V>Ты просто угадал с эмпирикой — это часто работает, но не говорит о том, что эмпирика и полное отрицание науки (что ты озвучил) — это разумно.
Что значит угадал с эмпирикой? А теория ЦОС по твоему откуда появилась? Ее бог что ли написал или марсиане? Ее писали такие же люди как я и ты, но в отличие от тебя не боявшиеся сами находить решения, а не пользоваться готовыми. Если бы все мыслили так как ты люди до сих пор бы с деревьев не слезли.
Здравствуйте, Undying, Вы писали:
I>>Вероятность зависит не от размера а от порядка следования и в случаях близких к наихудшему глубина рекурсии слишком высока, т.е. там где время близко O(n^2) память израсходуется O(n). U>С этим согласен. Но просто было интересно есть ли вероятностные оценки столкновения с проблемой на случайных данных.
У меня таких оценок нет
I>>Рендеринг некоторой сцены. Понадобилась стабильная сортировка с временем близком к линейному которая не будет требовать дополнительной памяти. Фактически, z-order, количество элементов в сцене от 100К и отсечения неприменимы, т.к. элементы слишком сложные. Стандартная сортировка во первых, нестабильная, давала периодически небольшие лаги, иногда длительное замерзание, и пару раз было переполнение стека.
U>Так чем тебе помогло твое знание сортировок? Ты все равно с начала столкнулся с проблемой, а потом уже начал ее решать. Т.е. это еще одно подтверждение того, что ключевой навык программиста это умение быстро разобраться в возникшей проблеме, а вовсе не наличие горы мусора в голове выученной на всякий случай.
Для начала это знание помогло задетектить проблему. Скажем, большинство людей просто не в курсе особенностей быстрой сортировки и пока они будут таращить глаза и искать причину, пройдет много времени.
Потом это знание помогло проанализировать причины и определиться с тем, в каком направлении копать — "стабильная сортировка с временем близком к линейному которая не будет требовать дополнительной памяти"
И вот здесь уже я был в курсе про возможность сортировки за линейное время без расхода памяти.
Все вместе это заняло у меня от силы неделю и это время включает в себя полное переписывание кода завязаного на z-order, со всеми оптимизациями, что бы сортировка в конечном результате работала в среднем за линейное время.
К слову — до меня эта проблема висела несколько лет и фича была заморожена ибо "сортировка слишком долгая операция".
Сама сортировка сильно упрощала рендеринг. В конце концов алгоритм визуализации естественным путем усложнился до безобразия, после изменения UI я снова соптимизировал, при чем снова сэкономил на сортировке — я заменил самопал на обычную стабильную(Enumerable.OrderBy) . Сэкономил на том, что все приседания для линейной сортиовки получилось выбросить. В этом случае новая версия уже не сортировала все >100К элементов, а где то пару тысяч.
Собтсвенно упрощение UI я проталкивал именно для того, что бы можно было ускорить рендеринг в т.ч. из за сортировки. Теоретически можно было сразу ввести изменения в UI, но дело в том, что первый раз я оптимизировал эту хрень буквально за пару недель до релиза — никто в своем уме не вносит радикальные изменения в UI на таком сроке.
Здравствуйте, Vzhyk, Вы писали:
V>И вообще-то мне, как человеку с высшим образованием, было бы стыдно за подобные высказывания, но, я, это уже давно понял, — динозавр в современном мире.
Ты не динозавр, ты просто д'Артаньян С твоей математикой уже давно положено продукт-овнером быть, а ты в девелоперах бегаешь от багадельни к багадельне.
Здравствуйте, Vzhyk, Вы писали:
U>>Что значит угадал с эмпирикой? А теория ЦОС по твоему откуда появилась? Ее бог что ли написал или марсиане? Ее писали такие же люди как я и ты, но в отличие от тебя не боявшиеся сами находить решения, а не пользоваться готовыми. Если бы все мыслили так как ты люди до сих пор бы с деревьев не слезли. V>Хорошо сказано. На этом можно поставить точку. Теперь точно нет слов.
Т.е. теорию ЦОС писали сверхчеловеки? А нынешним недочеловекам это недоступно и даже сомневаться в этом кощунственно? Или что тебя так пугает?
Любую теорию, и ЦОС не исключение, пишут под конкретные задачи. Сбивать ракеты, к примеру, да, ей получается замечательно, лучше придумать сложно. А контролировать топливо ей в то время никто не собирался, не было технологических возможностей для этого тогда. Поэтому теория контроля топлива сейчас только создается. И создают ее не какие сверхчеловеки, а обычные инженеры, но умеющие и не боящиеся думать своей головой.
Здравствуйте, Ikemefula, Вы писали:
I>Ты не динозавр, ты просто д'Артаньян С твоей математикой уже давно положено продукт-овнером быть, а ты в девелоперах бегаешь от багадельни к багадельне.
Библию почитать послать?
Здравствуйте, Ikemefula, Вы писали:
I>Ты не динозавр, ты просто д'Артаньян С твоей математикой уже давно положено продукт-овнером быть, а ты в девелоперах бегаешь от багадельни к багадельне.
А так для продукта его сделать — это очень и очень мало. Это раз.
Два. В одиночку продукт сделать практически невозможно за разумное время.
Три. Даже, если что-то сделать, это еще нужно продать, раскрутить и т.д.
В реальности — это невозможно одному человеку, который разработчик. Реально, если есть кто-то, кто возьмет на себе поиск клиентов, заказов, продвижение и т.д. И даже в этом случае результат — всего-лишь место и время.
А если сюда добавить возрастные изменения с холестеринами, сердцем, сосудами, то все становится еще хуже. Что-то нужно успевать делать до 33-35.
Ну ладно, чей-то я расписался, смысла в оном никакого.
Здравствуйте, Undying, Вы писали:
U>Что значит угадал с эмпирикой? А теория ЦОС по твоему откуда появилась? Ее бог что ли написал или марсиане? Ее писали такие же люди как я и ты, но в отличие от тебя не боявшиеся сами находить решения, а не пользоваться готовыми. Если бы все мыслили так как ты люди до сих пор бы с деревьев не слезли.
В науке два основных метода — эмпирический и теоретический. Эмпирический — эксперимент. ЦОС появилась из того, что ктото нашел что преобразования Фурье применимы к дискретным функциям. А вот Фурье в основном пользовался теоретическим методом.
Здравствуйте, Vzhyk, Вы писали:
I>>Ты не динозавр, ты просто д'Артаньян С твоей математикой уже давно положено продукт-овнером быть, а ты в девелоперах бегаешь от багадельни к багадельне. V>Библию почитать послать?
Здравствуйте, Vzhyk, Вы писали:
V>А если сюда добавить возрастные изменения с холестеринами, сердцем, сосудами, то все становится еще хуже. Что-то нужно успевать делать до 33-35. V>Ну ладно, чей-то я расписался, смысла в оном никакого.
Смысл есть — теперь лучше понятны пораженческие настроения.
Здравствуйте, Undying, Вы писали:
I>>Для начала это знание помогло задетектить проблему. Скажем, большинство людей просто не в курсе особенностей быстрой сортировки и пока они будут таращить глаза и искать причину, пройдет много времени.
U>Даже под профайлером скорей всего источник проблемы будет виден. А уж трассировкой установить, что источник проблемы именно Sort точно удастся быстро.
Профайлер скажет тебе "сортировка слишком долгая операция". Если у тебя есть познания в алгоритмах, то ты скорее всего усомнишься в этом, если нет — тупо согласишься с профайлером.
I>>Потом это знание помогло проанализировать причины и определиться с тем, в каком направлении копать — "стабильная сортировка с временем близком к линейному которая не будет требовать дополнительной памяти"
U>Полагаю, что гуглением такую информацию удалось бы найти достаточно быстро. И качество найденного решения главным образом определялось бы умениями разработчика, а не его начальными знаниями по теме сортировки.
Гуглением найдешь что сортировка это в лучшем случае O(n*log(n)), а про конкретный случай тебе гугл ничего не скажет.
I>>К слову — до меня эта проблема висела несколько лет и фича была заморожена ибо "сортировка слишком долгая операция".
U>Просто люди работать не хотели или не умели. Твое принципиальное отличие от них это умение и желание решать проблемы, а вовсе не знание стопяцот методов сортировки.
Если буквально, то я не знаю наизусть ни одного алгоритма сортировки и никогда не знал.
Здравствуйте, Vzhyk, Вы писали:
I>>В науке два основных метода — эмпирический и теоретический. Эмпирический — эксперимент. ЦОС появилась из того, что ктото нашел что преобразования Фурье применимы к дискретным функциям. А вот Фурье в основном пользовался теоретическим методом. V>В ЦОС гораздо больше, чем Фурье. Это всего-лишь маленькая, но необходимая часть.
Здравствуйте, Undying, Вы писали:
U>Любую теорию, и ЦОС не исключение, пишут под конкретные задачи. Сбивать ракеты, к примеру, да, ей получается замечательно, лучше придумать сложно. А контролировать топливо ей в то время никто не собирался, не было технологических возможностей для этого тогда. Поэтому теория контроля топлива сейчас только создается. И создают ее не какие сверхчеловеки, а обычные инженеры, но умеющие и не боящиеся думать своей головой.
Теорию создают совсем не инженеры а большей частью математики. Но вообще странный вывод — раз раз теорию, по твоим словам, создают инженеры, значит там используется эмпирический метод
Почему инженер не может использовать теоретический метод ? Или подразумевается, что теоретический метод доступен только марсианам и богам ?
Здравствуйте, Ikemefula, Вы писали:
I>Посылай Библию, пусть будет.
Не проворным достается успешный бег, не храбрым — победа, не мудрым — хлеб, и не у разумных — богатство, и не искусным — благорасположение, но время и случай для всех их.
(Еккл. IX, 11)
Здравствуйте, Ikemefula, Вы писали:
I>Смысл есть — теперь лучше понятны пораженческие настроения. )))))))))))))) Это точно. За пивом я бы тебе мог много веселого рассказать. Если бы я не пытался, но... как там по эклезиасту.
Здравствуйте, Ikemefula, Вы писали:
I>Профайлер скажет тебе "сортировка слишком долгая операция". Если у тебя есть познания в алгоритмах, то ты скорее всего усомнишься в этом, если нет — тупо согласишься с профайлером.
Это если глуп (таких очень мало) или опыт пол-года(это студенты еще).
I>Если буквально, то я не знаю наизусть ни одного алгоритма сортировки и никогда не знал.
А "пузырек"? Его и самому придумать можно, если в школе не проходили.
Здравствуйте, Ikemefula, Вы писали:
I>Почему инженер не может использовать теоретический метод ? Или подразумевается, что теоретический метод доступен только марсианам и богам ? I>Поясни, а то непонятно.
Критерием истины является практика. Соответственно невозможно создать теорию не пользуясь эмпирическим методом. Умозрительно можно максимум сформулировать гипотезу.
Здравствуйте, Ikemefula, Вы писали:
I>Профайлер скажет тебе "сортировка слишком долгая операция". Если у тебя есть познания в алгоритмах, то ты скорее всего усомнишься в этом, если нет — тупо согласишься с профайлером.
Насколько я понял проблема была не в том, что сортировка всегда работала медленно, а в том что она работала медленно иногда.
I>Гуглением найдешь что сортировка это в лучшем случае O(n*log(n)), а про конкретный случай тебе гугл ничего не скажет.
Даже статья в Википедии говорит, что нормальное время O(n*log(n)), а худшее — О(n2). Уже этого в купе с замерами времени достаточно, чтобы определиться в каком направлении копать.
I>Если буквально, то я не знаю наизусть ни одного алгоритма сортировки и никогда не знал.
А сколько названий методов сортировки с их нормальными и худшими случаями ты знал до того как сам столкнулся с проблемой порожденной сортировкой?
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
I>>>Пудозреваю, если другие конторы начнут задавать такие же задачи, как у тебя, решений будет валом в интернете. G>>Не-а. На русском про SharePoint пишут человек пять. Один уехал, одн работает со мной, а еще двое были на собеседовании. I>А почему надо только русский язык учитывать ?
А по ангийски такой запрос даже не напишут.
I>>>Правильно,и с реверсом тоже самое — нет решения, не подходит. G>>Не правильно, разворот списка не имеет отношения к реальной программе. I>Объясняю еще раз — кроме ссыдлк-указателей и тд, в каждой программе всегда и везде будет уникальный код, который пишется практически каждый день.
И что?
I>Нужны способности писать этот уникальный код, а не пытаться всё свести к типовой задаче.
Нужны способности писать этот уникальный код, а не пытаться всё свести к развороту списка.
G>>Почему например людей не фильтруют по незнанию преобразования числа в строку? G>>Или по итеративному вычислению квадратного корня? I>Фильтруют, не переживай.
Не видел.
I>>>Это типовые задачи. Все что ты прверишь — умение решать типовые задачи. Это умение ни о чем. G>>Я же писал, что 80% задач на работе — типовые. Это у всех. Более того, люди сами стремятся так работать — сводить все к типовым задачам. Ибо так мозг меньше напрягается. I>Оставшиеся 20% задач как раз и создают бОльшую часть проблем. Если кандидат начнет сводить их к типовым, получится хаос.
Нет. Как раз проблемы возникают в совершенно типовом коде. То есть плотность ошибок примерно одинаковая, но типового кода тупо больше.
I>>>Потому, что это типовая задача. С такими нет никаких проблем разобраться, если есть некоторая база в программировании. G>>Практика показывает что есть. Раньше брали asp.net программистов, в надежде что разберутся. Увы, разбираться сложно, а писать на asp.net легко. Только value added получался отрицательным. I>Естественно, ты же и асп-нетчиков брал точно так же — по типовым задачам. А если человек умеет решать нестандартные задачи, то как правило ему разбираться будет легко.
Нет, как раз их брали по-другому.
I>>>Проблема с другими задачами, которые только похожи на типовые или вовсе уникальные. G>>Они обычно сводятся к типовым. Потому что так дешевле. I>Ты похоже начал сам с собой спорить: "человек может подойти к нетиповой задаче с типовым решением в голове, а потом долго биться. И даже не поймет где он неправ"
Да. Просто человек заранее не понял что задача нетиповая. Если бы заранее понял, то её проще к типовой свести, чем решать как есть.
I>>>Правильно ! Потому надо и проверять такое умение, как раз на уникальных задачах, которые только похожи на типовые. G>>Нет, это бессмысленно. Какой смысл решать уникальную задачу? Угадал — не угадал? Что это может сказать о человеке? I>Смысл в том, что типовые задачи создают меньше всего проблем в силу того, что они отработаны чуть не до автоматизма. А остальные задачи создают бОльшую часть проблем.
Нет, типовые задачи создают столько же проблем. Плотность ошибок одинаковая. Так как типовых задач больше, то и ошибок в них больше.
G>>Суть программирования — комбинирование решения из готовых кусочков. Для комбинирования надо понимать как кусочки устроены и собственно навык комбинирования. G>>Этот навык очень далек от разворота списка. Хотя и разворот списка можно через комбинирование написать, но это уже сложнее. I>Одним комбинированием новую задачу не решить.
С чего ты взял? Как раз большая часть любых задач решается именно комбинированием существующих кусочков.
Реализация алгоритма, который не разлагается на другие, требуется крайне редко.
I>>>Всего не перечислишь. Например нужна гарантия, что сортировка никогда не отработает за n^2. Как ты понимаешь, быстрая сортировка здесь неприменима, а вот фокус, в стандартных алгоритмах нужна именно она. G>>Я спросил сколько. 1-2-3-10-100 раз? I>В среднем раз в год, и кое какие даже сам писал.
Зачем?
G>>Выделенное кстати зачем? Value какой? I>Требования, естественно, на время отклика. Правда это было в проекте которым я не занимался.
Время отклика кого\чего?
I>>>Есть оптимизации основаные на свойствах конкретных данных и их количестве. Используя эти оптимизации можно получить время линейное или близкое к этому. G>>А зачем это все? Вставляй в сбалансированное дерево при получении данных, далее за o(n) доставай упорядоченное.
I> Операцией добавления N Элементов в дерево можно значит пренебречь ? у тебя уже на ровном месте O(n log(n)) + дополнительная память O(n) + отдавать данные вместо O(1) почему то O(n)
Конечно можно, потому что она делается бесконечно малое время, по сравнению с получением данных их внужного источника.
Например при загрузке программы построить дерево. При небольших изменениях в него даже вставлять можно за log(n).
I>Обожаю таких специалистов — никогда не задают вопросов ни про требования, ни про ограничения, ни про особенности модуля, но всегда знают лучше всех.
Ну ты как-бы сам шифруешься вечно. Уже было с десяток тем, где ты всегда уходил в "особенности", про которые никому не сказал.
Видимо не очень особенные эти особенности.
I>Предложи решение которое даст O(n) без дополнительной памяти.
Зачем?
G>>Вообще не пойму в чем поинт оптимизации алгоритмов, если большую часть времени процессор спит, а когда работает — клеит строки. I>Ты это, прекращай по себе мерить, а то ты выглядишь как вчерашний джуниор. Я про склеивание строк и спящий процессор нигде не говорил.
Это я говорю. В серверной разработке абсолютно нет смысла заниматься оптимизацией алгоритмов, которые работают быстрее нескольких часов.
I>Чисто как пример — рендеринг используется очень часто во всяких тулах которые чтото визуализируют. Тут всегда вагон оптимизаций. САПР, моделирование, визуализация, сложные вычисления — перечислять можно до понедельника.
Чувак, 90% компаний этим не занимается.
Здравствуйте, Vzhyk, Вы писали:
V>Вообще-то теория временных рядов и цос разраработаны вдоль и поперек и в твоем случае, только безграмотность предыдущих привела к плачевному результату.
Не сотвори себе кумира (с) Библия
Поклонение алгоритмам это новое слово в идолопоклончестве.
V>А, есть еще один момент, не безграмотность, а требование руководства: "прилепи чего побыстрее (вчера) и пофиг на клиента".
Телепат из тебя хреновый. Но зато можешь теперь порадоваться за наших клиентов, я уже забыл когда последний раз по контролю топлива вопросы возникали.
Здравствуйте, -n1l-, Вы писали:
N>Здравствуйте, gandjustas, Вы писали: G>>Разница между ссылочными и размерными типами — особенность платформы, которую стоит знать. Особенные проблемы получаются у тех, кто раньше на C++ писал. G>>А разворот списка для нас бесполезен. Да и для всех остальных тоже. N>Интересно, как ваши кандидаты, не зная что такое ссылка, растолковывают вам отличие передачи ссылочного типа с|без ключевого слова ref.
Про ref не спрашиваем. Он слишком редко в дикой природе встречается.
Здравствуйте, Undying, Вы писали:
I>>Профайлер скажет тебе "сортировка слишком долгая операция". Если у тебя есть познания в алгоритмах, то ты скорее всего усомнишься в этом, если нет — тупо согласишься с профайлером. U>Насколько я понял проблема была не в том, что сортировка всегда работала медленно, а в том что она работала медленно иногда.
И что ?
I>>Гуглением найдешь что сортировка это в лучшем случае O(n*log(n)), а про конкретный случай тебе гугл ничего не скажет. U>Даже статья в Википедии говорит, что нормальное время O(n*log(n)), а худшее — О(n2). Уже этого в купе с замерами времени достаточно, чтобы определиться в каком направлении копать.
Задним числом, когда я все тебе разжевал — конечно всего этого достаточно.
Это было задолго до появления этой статьи в Википедии.
I>>Если буквально, то я не знаю наизусть ни одного алгоритма сортировки и никогда не знал. U>А сколько названий методов сортировки с их нормальными и худшими случаями ты знал до того как сам столкнулся с проблемой порожденной сортировкой?
Я знал основные подходы в сортировках, а конкретных алгоритмов только пузырёк и быструю.
Здравствуйте, Ikemefula, Вы писали:
U>>Насколько я понял проблема была не в том, что сортировка всегда работала медленно, а в том что она работала медленно иногда. I>И что ?
То что очевидно, что проблему можно решить.
I>Задним числом, когда я все тебе разжевал — конечно всего этого достаточно.
Что ты разжевал? Что тормоза в некоторых случаях сортировки объясняются плохим случаем данных? Это даже Википедия знает.
I>Это было задолго до появления этой статьи в Википедии.
Все течет, все меняется. Лет двадцать назад ценность конкретных знаний была сильно больше, сейчас упала. Зато умение решать задачи с неизвестным ответом всегда в цене.
I>Я знал основные подходы в сортировках, а конкретных алгоритмов только пузырёк и быструю.
Так что ты хочешь услышать на собеседовании на вопрос о сортировках?
Вообще сортировка это практически дедушка всех алгоритмов, если специалист по алгоритмам здесь плавает, то дальше его можно и не спрашивать.
Здравствуйте, gandjustas, Вы писали:
НС>>В данном случае — понимание что такое ссылка и умение удерживать несложные ссылочные конструкции в голове. G>Зачем?
Затем что это напрямую влияет на качество и эффективность программиста.
G>Пуст лучше компьютер удерживает, у него памяти много и она не дырявая, как в програиистов.
Компьютер еще дизайн софта самостоятельно делать не научился. Так что пока только головой.
НС>>В месте программирования. Не все ж какой нибудь 1С подпиливают, некторые и посложнее задачки решают. G>Ну вот, ты уже сам пришел к выводу, что это не всем надо.
Конечно не всем. Это надо программистам. Ну так мы и собеседуем не вообще, а для конкретных вакансий.
НС>>Не нахожу. Человек, не способный решить эту задачку, нормальный код писать неспособен. G>Практика показывает обратное.
Здравствуйте, Undying, Вы писали:
I>>Почему инженер не может использовать теоретический метод ? Или подразумевается, что теоретический метод доступен только марсианам и богам ? I>>Поясни, а то непонятно.
U>Критерием истины является практика. Соответственно невозможно создать теорию не пользуясь эмпирическим методом. Умозрительно можно максимум сформулировать гипотезу.
Не пользуюясь теоретическим методом, тоже невозможно создать теорию.
Здравствуйте, Undying, Вы писали:
U>>>Насколько я понял проблема была не в том, что сортировка всегда работала медленно, а в том что она работала медленно иногда. I>>И что ?
U>То что очевидно, что проблему можно решить.
Её и в другом случае можно решить
I>>Задним числом, когда я все тебе разжевал — конечно всего этого достаточно.
U>Что ты разжевал? Что тормоза в некоторых случаях сортировки объясняются плохим случаем данных? Это даже Википедия знает.
Я выложил все что нужно и теперь тебе все очевидно
U>Все течет, все меняется. Лет двадцать назад ценность конкретных знаний была сильно больше, сейчас упала. Зато умение решать задачи с неизвестным ответом всегда в цене.
Правильно и здесь помогают базовые знания. Чем шире база, тем быстрее поиск решения. В уме гораздо быстрее решаются уникальные задачи, быстрее чем гугл результаты выдает.
I>>Я знал основные подходы в сортировках, а конкретных алгоритмов только пузырёк и быструю. U>Так что ты хочешь услышать на собеседовании на вопрос о сортировках? U>
U> Вообще сортировка это практически дедушка всех алгоритмов, если специалист по алгоритмам здесь плавает, то дальше его можно и не спрашивать.
Специалист по алгоритмам обязан уметь анализировать алгоритм и быть в курсе свойств метода. Скажем, не надо нигде гуглить если ты видишь алгоритм "разделяй и властвуй". Совершенно не важно, сортировка это или бпф, у него вполне определенная сложность.
Теоретически можно и нагуглить, но есть люди, которые могут решать такие задачи в уме. Их и надо брать, если тебе важны именно алгоритмы, а не кодинг для Шарепоинта.
И вот представь, приходит кандидат и в курсе сложности быстрой сортировки, а сложность метода "разделяй и властвуй" не знает. Это значит, что он просто зазубрил алгоритмы и будет гуглить. Для сложной проблемы каждая секунда решения в уме будем помножена на минуты и часы гугления.
Здравствуйте, Ikemefula, Вы писали:
I>Почему инженер не может использовать теоретический метод ? Или подразумевается, что теоретический метод доступен только марсианам и богам ?
Инженер может и использовать теоретический метод и создать/дополнить теорию. Это Vzhyk считает, что теоретический метод это нечто данное инженерам свыше и доработке не подлежащее.
I>Не пользуюясь теоретическим методом, тоже невозможно создать теорию.
Разумеется. Поэтому и нужно уметь использовать и теорию, и эмпирику.
Здравствуйте, Undying, Вы писали:
U>Если тебе не понятно, что такое дело, значит, у вас и в работе условия задачи определяются не ее нужностью пользователям
У нас нет пользователей как таковых, пользователи — прикладные программисты, существенно ниже уровнем.
U>Что кривого-то?
Код жрет лишнюю память, больше размером, его сложнее читать и сложнее рефакторить. И совершенно непонятно, есть ли у него хоть один плюс по сравнению с нормальным вариантом.
U> Прямо ответить-то никак, только юлить можешь? Ну лишние копирование памяти. Ой ужас какой — на целую микросекунду код отработает медленнее в задаче, которая выполняется сотню миллисекунд.
Это задача на собеседовании. Только полный имбецил не понимает, что такие задачи дают с целью выяснить наличие определенных умений. Постоянное утягивание обсуждений в сторону прямой практической полезности этой задачи показывают узость мышления
U>В стандартные хелперы, да, подобный код убирать плохо. А по месту, если очевидно, что на производительность он не повлияет, что в подобном коде плохого-то?
Скажи лучше, что в нем хорошего?
U>Как раз меня бы очень насторожило, если бы на собеседовании человек бросился писать оптимальным код.
Тебя бы насторожило что на собеседовании человек написал бы код с использованием моска? Однако.
U> Так как весьма вероятно, что в реальной работе он будет делать тоже самое.
Знаешь, меня вот пугают все время преждевременными оптимизациями, но на практике я таких вижу только на форуме. Чтобы что то не делать, человека уговаривать долго не надо.
Ну а если тебя этот факт так беспокоит, это легко выясняется небольшой устной задачкой на проектирование прямо по ходу собеседования. Но это уже совсем потом, обсуждаемая же задачка это просто входной фильтр. У нас до каких либо бесед человеку просто дают простенький тест на основы шарпа с вариантами ответов и эту задачку. И когда человек, который требует зарплату сильно выше рынка, в тесте с трудом отвечает на половину вопросов, и пишет просто нерабочий код, то и разговаривать с ним уже не имеет никакого смысла.
Здравствуйте, gandjustas, Вы писали:
G>Задача не алгоритмическая.
А задача разворота списка что, алгоритмическая? Т.е. переворот списка по принципу ханойской башни это алгоритм, который надо придумать? Жесть.
I>>Правильно,и с реверсом тоже самое — нет решения, не подходит. G>Не правильно, разворот списка не имеет отношения к реальной программе.
А строку ты часто в реальных программах разворачиваешь?
Здравствуйте, Vzhyk, Вы писали:
V>Блин, с каждым днем, я все больше и больше в шоке от кывта, точнее от современных программистов. Обычно я всегда тут нахожу, что ответить, но сейчас я ступоре, у меня просто нет слов.
После заявления о том, что про односвязный список он услышал только здесь, тебя еще что то удивляет? Просто делай выводы.
Здравствуйте, Undying, Вы писали:
U>А теория ЦОС по твоему откуда появилась? Ее бог что ли написал или марсиане? Ее писали такие же люди как я и ты, но в отличие от тебя не боявшиеся сами находить решения, а не пользоваться готовыми.
Вот только там очень много математики. Преобразование Адамара там, не? Или настоящие практики это все не используют?
U> Если бы все мыслили так как ты люди до сих пор бы с деревьев не слезли.
Да вот непонятно только кто на деревьях сидит, кто математикой пользуется или кто исключительно методом научного тыка палкой.
Здравствуйте, gandjustas, Вы писали:
G>>>Не правильно, разворот списка не имеет отношения к реальной программе. I>>Объясняю еще раз — кроме ссыдлк-указателей и тд, в каждой программе всегда и везде будет уникальный код, который пишется практически каждый день. G>И что?
Это и нужно проверять, как человек умеет писать такой уникальный код, который не сводится к типовым задачам.
Умение писать такой код это умение обучаться, умение решать проблемы.
I>>Нужны способности писать этот уникальный код, а не пытаться всё свести к типовой задаче. G>Нужны способности писать этот уникальный код, а не пытаться всё свести к развороту списка.
И ты проверяешь способности писать уникальный код с помощью типовой задачи. Я правильно тебя понял ?
G>>>Или по итеративному вычислению квадратного корня? I>>Фильтруют, не переживай. G>Не видел.
Мало видел.
I>>Оставшиеся 20% задач как раз и создают бОльшую часть проблем. Если кандидат начнет сводить их к типовым, получится хаос. G>Нет. Как раз проблемы возникают в совершенно типовом коде. То есть плотность ошибок примерно одинаковая, но типового кода тупо больше.
Наверное это особенности Шарепоинта или тех людей которых ты нанял, раз в типовом коде плотность ошибок такая же как и в остальном коде.
I>>Естественно, ты же и асп-нетчиков брал точно так же — по типовым задачам. А если человек умеет решать нестандартные задачи, то как правило ему разбираться будет легко. G>Нет, как раз их брали по-другому.
Конечно по другому — давали типовые задачи для асп-нета.
I>>Ты похоже начал сам с собой спорить: "человек может подойти к нетиповой задаче с типовым решением в голове, а потом долго биться. И даже не поймет где он неправ" G>Да. Просто человек заранее не понял что задача нетиповая. Если бы заранее понял, то её проще к типовой свести, чем решать как есть.
Если задача сводится к типовой, это просто типовая задача.
I>>Смысл в том, что типовые задачи создают меньше всего проблем в силу того, что они отработаны чуть не до автоматизма. А остальные задачи создают бОльшую часть проблем. G>Нет, типовые задачи создают столько же проблем. Плотность ошибок одинаковая. Так как типовых задач больше, то и ошибок в них больше.
Это чушь. Типовые пишутся даже пьяным без ошибок.
G>С чего ты взял? Как раз большая часть любых задач решается именно комбинированием существующих кусочков. G>Реализация алгоритма, который не разлагается на другие, требуется крайне редко.
Разлагается на другие и типовая задача это две большие разницы.
I>>В среднем раз в год, и кое какие даже сам писал. G>Зачем?
Смотри рядом, там пример конкретный.
G>>>Выделенное кстати зачем? Value какой? I>>Требования, естественно, на время отклика. Правда это было в проекте которым я не занимался. G>Время отклика кого\чего?
Системы. Можешь посмотреть пример рядом для Undying.
I>> Операцией добавления N Элементов в дерево можно значит пренебречь ? у тебя уже на ровном месте O(n log(n)) + дополнительная память O(n) + отдавать данные вместо O(1) почему то O(n) G>Конечно можно, потому что она делается бесконечно малое время, по сравнению с получением данных их внужного источника.
Ты прав с точностью до наоборот.
G>Например при загрузке программы построить дерево. При небольших изменениях в него даже вставлять можно за log(n).
Есть мир вне Шарепоинта.
I>>Обожаю таких специалистов — никогда не задают вопросов ни про требования, ни про ограничения, ни про особенности модуля, но всегда знают лучше всех. G>Ну ты как-бы сам шифруешься вечно. Уже было с десяток тем, где ты всегда уходил в "особенности", про которые никому не сказал. G>Видимо не очень особенные эти особенности.
I>>Предложи решение которое даст O(n) без дополнительной памяти. G>Зачем?
G>>>Вообще не пойму в чем поинт оптимизации алгоритмов, если большую часть времени процессор спит, а когда работает — клеит строки. I>>Ты это, прекращай по себе мерить, а то ты выглядишь как вчерашний джуниор. Я про склеивание строк и спящий процессор нигде не говорил. G>Это я говорю. В серверной разработке абсолютно нет смысла заниматься оптимизацией алгоритмов, которые работают быстрее нескольких часов.
I>>Чисто как пример — рендеринг используется очень часто во всяких тулах которые чтото визуализируют. Тут всегда вагон оптимизаций. САПР, моделирование, визуализация, сложные вычисления — перечислять можно до понедельника. G>Чувак, 90% компаний этим не занимается.
Здравствуйте, Undying, Вы писали:
I>>Почему инженер не может использовать теоретический метод ? Или подразумевается, что теоретический метод доступен только марсианам и богам ?
U>Инженер может и использовать теоретический метод и создать/дополнить теорию. Это Vzhyk считает, что теоретический метод это нечто данное инженерам свыше и доработке не подлежащее.
Не Вжик, а именно ты.
I>>Не пользуюясь теоретическим методом, тоже невозможно создать теорию.
U>Разумеется. Поэтому и нужно уметь использовать и теорию, и эмпирику.
На счет теории ты не продемонстрировал ничего особенного. Все что ты показал это удачный метод тыка.
Здравствуйте, gandjustas, Вы писали:
I>>Обожаю таких специалистов — никогда не задают вопросов ни про требования, ни про ограничения, ни про особенности модуля, но всегда знают лучше всех. G>Ну ты как-бы сам шифруешься вечно. Уже было с десяток тем, где ты всегда уходил в "особенности", про которые никому не сказал. G>Видимо не очень особенные эти особенности.
Ты хочешь что бы я выложил 10мб спецификаций ?
I>>Предложи решение которое даст O(n) без дополнительной памяти. G>Зачем?
Для того, что бы сошлись концы с концами.
G>>>Вообще не пойму в чем поинт оптимизации алгоритмов, если большую часть времени процессор спит, а когда работает — клеит строки. I>>Ты это, прекращай по себе мерить, а то ты выглядишь как вчерашний джуниор. Я про склеивание строк и спящий процессор нигде не говорил. G>Это я говорю. В серверной разработке абсолютно нет смысла заниматься оптимизацией алгоритмов, которые работают быстрее нескольких часов.
Представляю — рендеринг картинки вместо пол-секунды займет пол-часа. Похоже это про тебя: "у нас всё в базу упирается"
I>>Чисто как пример — рендеринг используется очень часто во всяких тулах которые чтото визуализируют. Тут всегда вагон оптимизаций. САПР, моделирование, визуализация, сложные вычисления — перечислять можно до понедельника. G>Чувак, 90% компаний этим не занимается.
Здравствуйте, Undying, Вы писали:
V>> Здесь всего-лишь нужен ЦОС, немного ТВиМС и основ матана.
U>На самом деле в данной задаче и от всего перечисленного толку немного. Классическая ЦОС заточена под часто снимаемые сигнала. А когда данные идут раз в десять секунд работает это все кое как.
Похоже, ты близок к Нобелевской премии и это не шутка.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>У нас нет пользователей как таковых, пользователи — прикладные программисты, существенно ниже уровнем.
Т.е. вы занимаетесь преимущественно технологической работой (написанием кода, который упрощает решение задач другим программистам)? Так бы сразу и сказал. Если вы ищете технологов, то согласен это нормальная задача для собеседования. Тем не менее то, что вы ждете оптимального решения лучше проговаривать явно, т.к. технологи тоже телепатией не владеют.
НС>Знаешь, меня вот пугают все время преждевременными оптимизациями, но на практике я таких вижу только на форуме. Чтобы что то не делать, человека уговаривать долго не надо.
Признаю твою правоту. Я думал вы так специалистов-кодеров отбираете, а учитывая, что они вам не нужны, то это хорошая задача для первичного отбора.
Здравствуйте, Ikemefula, Вы писали:
U>>Инженер может и использовать теоретический метод и создать/дополнить теорию. Это Vzhyk считает, что теоретический метод это нечто данное инженерам свыше и доработке не подлежащее. I>Не Вжик, а именно ты.
Когда это я сказал? Цитату в студию.
I>На счет теории ты не продемонстрировал ничего особенного. Все что ты показал это удачный метод тыка.
Я метод решения задачи вообще не показывал. Так что домыслы насчет тыка это твоя телепатия, а телепат из тебя хреновый.
Здравствуйте, Ikemefula, Вы писали:
I>Сортировка хорошо детектит разрабов вроде "у нас всё в базу упирается", "шо тут думать, трясти надо", "такое нигде не пишут"
Может ты и прав. Так-то согласен таких тоже как-то фильтровать надо.
Здравствуйте, Undying, Вы писали:
U>И куда это преобразование Адамара в бинд топлива совать?
Его не надо совать в топливо, это теория. На основании этого преобразования считается матрица ВЧ фильтра или любой другой потребной функции, которую нужно наложить на сигнал.
Здравствуйте, Undying, Вы писали:
U>Т.е. вы занимаетесь преимущественно технологической работой
У тебя какое то странное понимание терминов. Нет, технологической работой занимаются отдельные люди, в чью задачу входит настройка технологических моментов программирования — VCS, CI и т.п.
U>(написанием кода, который упрощает решение задач другим программистам)? Так бы сразу и сказал.
А никто и не спрашивал.
U> Если вы ищете технологов
Нет, мы не ищем технологов, мы ищем программистов.
U>то согласен это нормальная задача для собеседования
Не вижу принципиальных отличий на таком мелком уровне.
U>Тем не менее то, что вы ждете оптимального решения лучше проговаривать явно
Мы не ждем какого то супероптимального решения, мы ждем хороший приличный код. И это не очевидно только имбецилам, которые все равно не нужны.
U>Признаю твою правоту. Я думал вы так специалистов-кодеров отбираете
Мне кажется с самого начала было понятно, что речь не идет об найме обезьянок для шаблонного кода.
Здравствуйте, Undying, Вы писали:
U>Инженер может и использовать теоретический метод и создать/дополнить теорию. Это Vzhyk считает, что теоретический метод это нечто данное инженерам свыше и доработке не подлежащее.
Где ты такое вычитал? Может хватит придумывать призраков и бороться с ними.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>После заявления о том, что про односвязный список он услышал только здесь, тебя еще что то удивляет? Просто делай выводы.
Да, делаю, точно убедите.
Здравствуйте, Ikemefula, Вы писали:
U>>То что очевидно, что проблему можно решить. I>Её и в другом случае можно решить
Возможно. Но в другом случае это уже было бы неочевидно.
I>Правильно и здесь помогают базовые знания. Чем шире база, тем быстрее поиск решения. В уме гораздо быстрее решаются уникальные задачи, быстрее чем гугл результаты выдает.
Если умеешь и стремишься решать задачи, то базовые знания быстро появляются, даже в изначально незнакомой области.
I>Специалист по алгоритмам обязан уметь анализировать алгоритм и быть в курсе свойств метода. Скажем, не надо нигде гуглить если ты видишь алгоритм "разделяй и властвуй". Совершенно не важно, сортировка это или бпф, у него вполне определенная сложность.
I>Теоретически можно и нагуглить, но есть люди, которые могут решать такие задачи в уме.
Спрашивая подобные вещи ты на собеседование отберешь не тех кто умеет, а тех кто помнит.
I>Их и надо брать, если тебе важны именно алгоритмы, а не кодинг для Шарепоинта.
Не вижу принципиальной разницы между отбором по знанию алгоритмов и отбором по знанию Шарепоинта. И то и другое это отбор по знаниям, а не по способностям.
I>И вот представь, приходит кандидат и в курсе сложности быстрой сортировки, а сложность метода "разделяй и властвуй" не знает. Это значит, что он просто зазубрил алгоритмы и будет гуглить. Для сложной проблемы каждая секунда решения в уме будем помножена на минуты и часы гугления.
Эти какие задачи у вас программисты решают за секунды? Отдел фантастики в другой ветке. Мало-мальски сложная задача, как правило, обдумывается несколько дней (хоть обычно и параллельно с какой-нибудь рутиной). Соответственно пара часов гугления по нетривиальной задаче не стоит вообще ничего.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Его не надо совать в топливо, это теория. На основании этого преобразования считается матрица ВЧ фильтра или любой другой потребной функции, которую нужно наложить на сигнал.
Старый алгоритм так и работал, т.е. первоначально накладывал фильтр на сигнал. В результате терялась(загрублялась) информация о точности данных — уровень топлива фильтр возвращает, а дисперсию уже нет, о времени начала/конца события — реальная точка начала заправки/слива замусорена последующим поднятием/снижением уровня топлива, о уровне топлива на начало/конец события — по той же причине. Там, конечно, и алгоритм верхнего уровня был выбран принципиально неудачно, но и при наилучшем алгоритме из изначально загрубленного сигнала много не выжмешь.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>У тебя какое то странное понимание терминов. Нет, технологической работой занимаются отдельные люди, в чью задачу входит настройка технологических моментов программирования — VCS, CI и т.п.
Программистскую спесь поубавь. В любой производственной деятельности работники делятся на конструкторов (люди, которые видят задачу целиком и умеют разбить ее на более простые части), технологов (люди, которые видят типовые задачи и умеют сделать их решение тривиальным) и рабочих (тех кто собственно воплощает продукт в реальность). И только программисты считают себя уникальными и гордо называют себя программистами, а не какими-то там инженерами, технологами, или упаси господь рабочими. Хотя на самом деле программирование это такая же производственная деятельность и работа программистов точно также разделяется на конструкторскую, инженерную и рабочую. Разница только в том, что т.к. программисты отказываются это признавать, то в их проектах зачастую процветает кустарщина и бардак.
Так что вы занимаетесь именно технологической деятельностью. И это вовсе не ругательство, а весьма полезная деятельность.
НС>Мне кажется с самого начала было понятно, что речь не идет об найме обезьянок для шаблонного кода.
Здравствуйте, Undying, Вы писали:
I>>Правильно и здесь помогают базовые знания. Чем шире база, тем быстрее поиск решения. В уме гораздо быстрее решаются уникальные задачи, быстрее чем гугл результаты выдает.
U>Если умеешь и стремишься решать задачи, то базовые знания быстро появляются, даже в изначально незнакомой области.
Все правильно, только время надо как то учитывать. Если ты хочешь решать сложные задачи скажем в области цифровой обработки сигналов так же быстро и качественно, как и человек, который там варится 10 лет, то теб надо будет потратить сравнимое время.
I>>Теоретически можно и нагуглить, но есть люди, которые могут решать такие задачи в уме. U>Спрашивая подобные вещи ты на собеседование отберешь не тех кто умеет, а тех кто помнит.
Я большей частью даю задачи, усные и письменные и они подобраты так, что бы их нужно было решать. Шансы, что ктото их будет знать заранее, стремятся к нулю.
U>Не вижу принципиальной разницы между отбором по знанию алгоритмов и отбором по знанию Шарепоинта. И то и другое это отбор по знаниям, а не по способностям.
Способности большей частью трансформируются в прочные знания. По другому не бывает. Умение решать задачи показывает именно способности.
U>Эти какие задачи у вас программисты решают за секунды?
Разные.
>Отдел фантастики в другой ветке. Мало-мальски сложная задача, как правило, обдумывается несколько дней (хоть обычно и параллельно с какой-нибудь рутиной). Соответственно пара часов гугления по нетривиальной задаче не стоит вообще ничего.
А я где то сказал, что любые задачи решаются за секунды ? Если тебе на каждый чих гуглить надо, то я боюсь сложные задачи потребуют годы на решение.
Здравствуйте, Undying, Вы писали:
I>>Сортировка хорошо детектит разрабов вроде "у нас всё в базу упирается", "шо тут думать, трясти надо", "такое нигде не пишут"
U>Может ты и прав. Так-то согласен таких тоже как-то фильтровать надо.
Сортировка просто удачный пример, хотя и заезженый.
Здравствуйте, Undying, Вы писали:
I>>Похоже, ты близок к Нобелевской премии и это не шутка.
U>Нобелевка нынче награда политическая, а не научная и тем более не инженерная. Так что не переживай мне она точно не грозит.
Здравствуйте, Vzhyk, Вы писали:
V>Здравствуйте, -n1l-, Вы писали:
N>>А все почему? Потому, что есть типа идиома какая-то или закон, звучит так — "Нельзя писать велосипед!!!". V>Это правильная идиома. Нельзя писать велосипед, пока не доказано, что имеющиеся стандартные решения не удовлетворяют требованиям задачи.
N>>Любая задача сводится к тому, что она уже написана и надо просто погуглить и скопипастить код. V>Действительно уже много задач написано и в 90% процентах случаев программистской работы можно скопипастить. Но есть 10% (или сколько там процентов), где такое не пройдет.
N>>То, что этот код может быть неправильным, неподходящим для задачи или просто переусложненным игнорируется полностью. N>>Отсюда имеем плачевный результат, забери у такого "спеца" его платформу или интернет и он не способен решить ни одной проблемы. V>Если у вас все задачи на конторе попадают исключительно в 10% R&D — что невозможно.
Почему не возможно? Очень даже возможно.
А с первым высказыванием я согласен.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
I>>>Обожаю таких специалистов — никогда не задают вопросов ни про требования, ни про ограничения, ни про особенности модуля, но всегда знают лучше всех. G>>Ну ты как-бы сам шифруешься вечно. Уже было с десяток тем, где ты всегда уходил в "особенности", про которые никому не сказал. G>>Видимо не очень особенные эти особенности.
I>Ты хочешь что бы я выложил 10мб спецификаций ?
Нет, ты просто по русски напиши.
I>>>Предложи решение которое даст O(n) без дополнительной памяти. G>>Зачем? I>Для того, что бы сошлись концы с концами.
А почему так не сходятся? Память нинче дешевая. 4гб стоят дешевле моего дня работы. Причем сильно дешевле.
G>>>>Вообще не пойму в чем поинт оптимизации алгоритмов, если большую часть времени процессор спит, а когда работает — клеит строки. I>>>Ты это, прекращай по себе мерить, а то ты выглядишь как вчерашний джуниор. Я про склеивание строк и спящий процессор нигде не говорил. G>>Это я говорю. В серверной разработке абсолютно нет смысла заниматься оптимизацией алгоритмов, которые работают быстрее нескольких часов. I>Представляю — рендеринг картинки вместо пол-секунды займет пол-часа. Похоже это про тебя: "у нас всё в базу упирается"
Ты её можешь заранее отрендерить, а потом показывать? Может не всю, а по слоям. Сама идея слоев пришла из ГИСов, где рендерить все на лету нереально. Поэтому картинка режется на слои и рендеринг каздого оптимизируется с целью делать как можно меньше работы. Заметь — не делать как можно быстрее, а делать как можно меньше.
I>>>Чисто как пример — рендеринг используется очень часто во всяких тулах которые чтото визуализируют. Тут всегда вагон оптимизаций. САПР, моделирование, визуализация, сложные вычисления — перечислять можно до понедельника. G>>Чувак, 90% компаний этим не занимается. I>Ага, вне шарепоинта жизни нет.
Есть, и вообще SharePoint — малнькая среда. На всю Россию сотня крупных проектов. Во всем мире порядка на два больше.
Но даже это больше, чем САПРов.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, gandjustas, Вы писали:
G>>Задача не алгоритмическая.
НС>А задача разворота списка что, алгоритмическая? Т.е. переворот списка по принципу ханойской башни это алгоритм, который надо придумать? Жесть.
Да, потому что есть ровно один алгоритм разворота списка на месте. И если ты его заранее не знаешь, то надо придумать.
I>>>Правильно,и с реверсом тоже самое — нет решения, не подходит. G>>Не правильно, разворот списка не имеет отношения к реальной программе.
НС>А строку ты часто в реальных программах разворачиваешь?
Нет, но задача не на знание алгоритма, а на знание платформы.
Некоторые пытаются разворачивать строку на месте, не зная что строки immutable
Некоторые клеят строи в цикле, не зная про string builder.
Некоторые не могут цикл нормально написать
А идеальный вариант:
var a = str.ToCharArray();
Array.Reverse(a);
return new string(a);
Но такой пишет каждый десятый.
Операций со строками в реальных программах много происходит.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, gandjustas, Вы писали:
НС>>>В данном случае — понимание что такое ссылка и умение удерживать несложные ссылочные конструкции в голове. G>>Зачем? НС>Затем что это напрямую влияет на качество и эффективность программиста.
На качество и эффективность самое большое влияние оказывают умение читать код, а не писать.
На втором месте — знание среды, в которой работает. Тройку замыкает усидчивость и внимательность.
Умение жонглировать ссылками оказывает настолько маленькое влияние в enterprise разработке, что даже упоминать смешно.
G>>Пуст лучше компьютер удерживает, у него памяти много и она не дырявая, как в програиистов. НС>Компьютер еще дизайн софта самостоятельно делать не научился. Так что пока только головой.
Но можно писать так, чтобы минимум удерживать в голове.
Поэтому самый лучший разворот списка:
list.Reverse()
Если программист такое не может сделать, то он бесполезен для реальной работы.
НС>>>В месте программирования. Не все ж какой нибудь 1С подпиливают, некторые и посложнее задачки решают. G>>Ну вот, ты уже сам пришел к выводу, что это не всем надо.
НС>Конечно не всем. Это надо программистам. Ну так мы и собеседуем не вообще, а для конкретных вакансий.
Угу, и немалая часть конкретных вакансий это enterprise разработка, где жонглирование ссылками бесполезно.
НС>>>Не нахожу. Человек, не способный решить эту задачку, нормальный код писать неспособен. G>>Практика показывает обратное. НС>Практика именно это и показывает.
У нс разная практика.
Здравствуйте, gandjustas, Вы писали:
I>>Ты хочешь что бы я выложил 10мб спецификаций ? G>Нет, ты просто по русски напиши.
Ты лучше научись вопросы задавать, а делать вид что один ты здесь умный.
I>>>>Предложи решение которое даст O(n) без дополнительной памяти. G>>>Зачем? I>>Для того, что бы сошлись концы с концами. G>А почему так не сходятся? Память нинче дешевая. 4гб стоят дешевле моего дня работы. Причем сильно дешевле.
Память и адресное пространство нужно другим задачам.
I>>Представляю — рендеринг картинки вместо пол-секунды займет пол-часа. Похоже это про тебя: "у нас всё в базу упирается" G>Ты её можешь заранее отрендерить, а потом показывать? Может не всю, а по слоям. Сама идея слоев пришла из ГИСов, где рендерить все на лету нереально. Поэтому картинка режется на слои и рендеринг каздого оптимизируется с целью делать как можно меньше работы. Заметь — не делать как можно быстрее, а делать как можно меньше.
Ну ты же сказал, что алгоритм не надо оптимизировать если менее нескольких часов работает. Зачем тогда слои и тд ?
I>>>>Чисто как пример — рендеринг используется очень часто во всяких тулах которые чтото визуализируют. Тут всегда вагон оптимизаций. САПР, моделирование, визуализация, сложные вычисления — перечислять можно до понедельника. G>>>Чувак, 90% компаний этим не занимается. I>>Ага, вне шарепоинта жизни нет. G>Есть, и вообще SharePoint — малнькая среда. На всю Россию сотня крупных проектов. Во всем мире порядка на два больше. G>Но даже это больше, чем САПРов.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
I>>>Ты хочешь что бы я выложил 10мб спецификаций ? G>>Нет, ты просто по русски напиши. I>Ты лучше научись вопросы задавать, а делать вид что один ты здесь умный.
А я тут причем? Это ты прячешься за 10мб спецификаций.
I>>>>>Предложи решение которое даст O(n) без дополнительной памяти. G>>>>Зачем? I>>>Для того, что бы сошлись концы с концами. G>>А почему так не сходятся? Память нинче дешевая. 4гб стоят дешевле моего дня работы. Причем сильно дешевле. I>Память и адресное пространство нужно другим задачам.
Каким? Памяти мало?
I>>>Представляю — рендеринг картинки вместо пол-секунды займет пол-часа. Похоже это про тебя: "у нас всё в базу упирается" G>>Ты её можешь заранее отрендерить, а потом показывать? Может не всю, а по слоям. Сама идея слоев пришла из ГИСов, где рендерить все на лету нереально. Поэтому картинка режется на слои и рендеринг каздого оптимизируется с целью делать как можно меньше работы. Заметь — не делать как можно быстрее, а делать как можно меньше. I>Ну ты же сказал, что алгоритм не надо оптимизировать если менее нескольких часов работает. Зачем тогда слои и тд ?
Тебе же полсекуды надо. А у меня только чтение с диска дольше идет.
Здравствуйте, gandjustas, Вы писали:
I>>Это и нужно проверять, как человек умеет писать такой уникальный код, который не сводится к типовым задачам. G>Не понял, зачем?
Затем, что такой код и дает больше всего ошибок.
I>>Умение писать такой код это умение обучаться, умение решать проблемы. G>Нет, умение обучаться не связано с умением писать код.
Ты постоянно передёргиваешь и как то я подустал от этого.
I>>>>Нужны способности писать этот уникальный код, а не пытаться всё свести к типовой задаче. G>>>Нужны способности писать этот уникальный код, а не пытаться всё свести к развороту списка. I>>И ты проверяешь способности писать уникальный код с помощью типовой задачи. Я правильно тебя понял ? G>Нет, я же говорю, что писать уникальный код приходится редко. Незачем проверять это умение на собеседовании.
I>>Мало видел. G>Много видел.
Мне не единожды задавали похожие вопросы
I>>Наверное это особенности Шарепоинта или тех людей которых ты нанял, раз в типовом коде плотность ошибок такая же как и в остальном коде G>Нет, эта статистика постоянная и устойчивая во времени, практически не зависит от языка и среды. Скорее всего предел человеческой внимательности.
Дай уже эту статистику.
Как то очень странно — качество решения задачи вдруг перестаёт зависеть от того, берется ли готовое решение или его надо еще родить
Парадокс какой то.
Но в принципе есть объяснение — твои разрабы, если ты не путаешь, не могут ни строчки написать без ошибок.
I>>Конечно по другому — давали типовые задачи для асп-нета. G>Нет, как раз давали головоломки.
Кто ж вам доктор теперь ?
I>>Если задача сводится к типовой, это просто типовая задача. G>Нет. Иногда можно условия поменять.
Покажи такое изменение условия.
I>>Это чушь. Типовые пишутся даже пьяным без ошибок. G>Статистика говорит обратное.
Покажи уже эту статистику.
I>>Разлагается на другие и типовая задача это две большие разницы. G>Почему же? На каком-то уровне декомпозиции будут кусочки, которые ты уже писал. Поэтому задача резко становится типовой.
Ну, поздравляю, ты доказал что вообще все задачи в программировании типовые.
G>Иногда бывает что не все кусочки ты уже писал, и если по внешней похожести твой мозг определил задачу как типовую, то ты даже не поймешь что не так сделал.
Ты уже сам себе начал противоречить. Выше ты доказал что все задачи типовые.
Но вообще ты прав — всегда есть вещи, которые ты пишешь крайне редко, но так получается, что все редкие случаи вместе взятые составляют значительный процент и создают наибольшее количество проблем.
G>Мозг тебя очень часто обманывает. Большую часть решений человек принимает неосознано, грубо говоря на уровне рефлексов.
Правильно. Вот и надо проверять, как часто обманывает мозг. У всех это по разному.
G>тобы рефлексы работали правильно — их надо тренировать. Можно натренировать человека решать нестандартные задачи. Но для него тогда большая часть задач будет нестандартными и получится велосипедостроитель. Причем у стремление
Велосипедостроитель получается не из умения решать нестандартные задачи, а из нежелания учиться или хотя бы смотреть изредка по сторонам или хотя бы задавать вопросы.
Плюс ко всему между людьми есть разница примерно такая — одни лучше решают типовые задачи(быстрее и эффективнее), другие лучше решают уникальные(быстрее и эффективнее).
Велосипедостроителей примерно одинаково и там и там, причины я описал.
Скажем в задаче с сортировкой, где ты удачно 'блеснул'
первые подойдут примерно так как ты сделал — возьмут дерево и париться не будут. В итого говновелосипед который создает проблемы.
Вторые изобретут новые структуры данных, возможно то же дерево, и снова в итоге говновелосипед который создает проблемы.
Что интересно, если люди умеют учиться, то ни там, ни там проблем не будет.
Первые могут не только решать типовые, но как минимум смогут выяснить, что задача не решается в лоб типовым подходом.
Вторые могут не только хорошо решать уникальные, но не брезгуют стандартными алгоритмами и структурами данных.
G>>>Конечно можно, потому что она делается бесконечно малое время, по сравнению с получением данных их внужного источника. I>>Ты прав с точностью до наоборот. G>Почему? У тебя данные из ничего появляются в памяти?
Данные всегда в памяти. Пудозреваю, ты думал что данные всегда где то в базе или в сети и хотел свести задачу к типовой ?
Похоже это про тебя :
"Велосипедостроитель получается не из умения решать нестандартные задачи, а из нежелания учиться или хотя бы смотреть изредка по сторонам или хотя бы задавать вопросы. "
I>>Есть мир вне Шарепоинта. G>А причем тут SharePoint? Ты считаешь что сбалансированное дерево только в SharePoint можно посторить?
Вещи про которые я говорил, встречаются много чаще чем тебе кажется.
Просто во многих аутсорсных конторах появилось новое поколение менеджеров из вчерашних джуниоров, которые не зная базы обещают всё подряд, а потом заставляют девелоперов расставлять костыли и писать водопроводный код.
Вот и ходят по собеседованиям эдакие "программисты-сантехники" — специалисты по костылям и водопроводному коду.
Здравствуйте, gandjustas, Вы писали:
I>>Ты лучше научись вопросы задавать, а делать вид что один ты здесь умный. G>А я тут причем? Это ты прячешься за 10мб спецификаций.
По моему это ты предлагаешь решения не интересуясь ни требованиями, ни ограничениями.
G>>>А почему так не сходятся? Память нинче дешевая. 4гб стоят дешевле моего дня работы. Причем сильно дешевле. I>>Память и адресное пространство нужно другим задачам. G>Каким? Памяти мало?
Мало. Другие задачи это частично задачи этого же приложения, всем нужна память, частично — задачи ОС.
I>>Ну ты же сказал, что алгоритм не надо оптимизировать если менее нескольких часов работает. Зачем тогда слои и тд ? G>Тебе же полсекуды надо. А у меня только чтение с диска дольше идет.
То есть, ты предлгагаешь оптимизировать мой случай на основании каких то своих ограничений ?
Похоже ты натягиваешь типовое решение на уникальный случай, рожая велосипед
Здравствуйте, gandjustas, Вы писали:
НС>>А задача разворота списка что, алгоритмическая? Т.е. переворот списка по принципу ханойской башни это алгоритм, который надо придумать? Жесть. G>Да, потому что есть ровно один алгоритм разворота списка на месте. И если ты его заранее не знаешь, то надо придумать.
А алгоритм цикла ты каждый раз не придумываешь?
НС>>А строку ты часто в реальных программах разворачиваешь? G>Нет
Вот видишь.
G>но задача не на знание алгоритма, а на знание платформы.
1) ЭТО НЕ ЗАДАЧА НА ЗНАНИЕ АЛГОРИТМА!!!
2) Какие знания платформы ты проверяешь разворотом строки? Наличие индексера у класса string?
G>Некоторые пытаются разворачивать строку на месте, не зная что строки immutable
А зачем знать что строки immutable, если у string индексер только get акцессор содержит?
G>Некоторые не могут цикл нормально написать
Это знание платформы?
G>Операций со строками в реальных программах много происходит.
Здравствуйте, Undying, Вы писали:
U>Старый алгоритм так и работал, т.е. первоначально накладывал фильтр на сигнал. В результате терялась(загрублялась) информация о точности данных
Значит фильтр неправильный. Простейший ВЧ фильтр — не единственный вариант.
Здравствуйте, gandjustas, Вы писали:
НС>>Затем что это напрямую влияет на качество и эффективность программиста. G>На качество и эффективность самое большое влияние оказывают умение читать код, а не писать. G>На втором месте — знание среды, в которой работает. Тройку замыкает усидчивость и внимательность.
G>Умение жонглировать ссылками оказывает настолько маленькое влияние в enterprise разработке, что даже упоминать смешно.
В энтерпрайзе по моему мнению такой код, что нужно на раз знать все возможные последствия и сайд-эффекты у каждой строчки.
НС>>Конечно не всем. Это надо программистам. Ну так мы и собеседуем не вообще, а для конкретных вакансий. G>Угу, и немалая часть конкретных вакансий это enterprise разработка, где жонглирование ссылками бесполезно.
Наоборот, именно там и важно понимать все эти ссылки и многое другое.
НС>>>>Не нахожу. Человек, не способный решить эту задачку, нормальный код писать неспособен. G>>>Практика показывает обратное. НС>>Практика именно это и показывает. G>У нс разная практика.
Судя по тому, как ты не задав ни одного вопроса предложил наихудшее решение да еще начал доказывать, что оно будет работать на раз, сильно сомневаюсь, что у тебя адекватная практика.
Здравствуйте, gandjustas, Вы писали:
G>На качество и эффективность самое большое влияние оказывают умение читать код, а не писать.
Это связанные умения.
G>На втором месте — знание среды, в которой работает. Тройку замыкает усидчивость и внимательность.
Это не объясняет, почему у разных программистов с одинаковым опытом производительность может отличаться на порядок.
G>Умение жонглировать ссылками оказывает настолько маленькое влияние в enterprise разработке, что даже упоминать смешно.
Нет, смешно это когда человек, претендующий на работу программиста, не в состоянии справится с примитивной ссылочной конструкцией. И энтерпрайз, он очень разный, не обобщай шерпоинт на все остальное.
НС>>Компьютер еще дизайн софта самостоятельно делать не научился. Так что пока только головой. G>Но можно писать так, чтобы минимум удерживать в голове.
Иногда нельзя. В DSL, к примеру, без понимания таких конструкций просто делать нечего, там косвенность в 3-4 уровня — норма. И никакие алгоритмы тебя не спасут, только полномасштабные средства, которые сделают за тебя вообще все.
G>Поэтому самый лучший разворот списка:
Чем он лучший? Тем что кода в два раза больше надо писать?
НС>>Практика именно это и показывает. G>У нс разная практика.
Это я уже понял. Кто то под шерпоинт пишет, а кто то и сам шерпоинт.
Здравствуйте, Undying, Вы писали:
U>Программистскую спесь поубавь.
Ты чего то перепутал. Спесь это у тебя, а у меня набитые шишки.
U> В любой производственной деятельности работники делятся на конструкторов (люди, которые видят задачу целиком и умеют разбить ее на более простые части), технологов (люди, которые видят типовые задачи и умеют сделать их решение тривиальным) и рабочих (тех кто собственно воплощает продукт в реальность).
Нет, не в любой, это очевидно.
U>Хотя на самом деле программирование это такая же производственная деятельность
Нет никакой такой производственной деятельности вообще, есть конкретные задачи. И нет, они не абсолютно одинаковы, везде своя специфика.
U> и работа программистов точно также разделяется на конструкторскую, инженерную и рабочую.
Как минимум рабочие в программировании не нужны, потому что в материальном производстве рабочии занимаются созданием копий изделий, а в программировании копирование бесплатно. Ну и конструктор это разновидность инженера, совершенно непонятно почему ты их противопоставляешь. Инженер-конструктор в программировании это как раз программист и есть, а инженер-технолог это тот человек, который занимается обеспечением VCS, CI, релиз-менеджментом и т.п.
U> Разница только в том, что т.к. программисты отказываются это признавать, то в их проектах зачастую процветает кустарщина и бардак.
Батхерт в тебе я чую.
НС>>Мне кажется с самого начала было понятно, что речь не идет об найме обезьянок для шаблонного кода. U>Гордыня на мозг не жмет?
Нет. А тебе? А то от тебя столько пафоса льется, что деревьев не видно.
Здравствуйте, gandjustas, Вы писали:
I>>Это и нужно проверять, как человек умеет писать такой уникальный код, который не сводится к типовым задачам. G>Не понял, зачем?
В рамочку и на стенку.
G>Нет, я же говорю, что писать уникальный код приходится редко.
Надо говорить "мне приходится редко"
G> Незачем проверять это умение на собеседовании.
Мы уже поняли, что тебе программисты не нужны. О чем тогда ты споришь?
Здравствуйте, Ikemefula, Вы писали:
I>В энтерпрайзе по моему мнению такой код, что нужно на раз знать все возможные последствия и сайд-эффекты у каждой строчки.
Зависит.
НС>>>Конечно не всем. Это надо программистам. Ну так мы и собеседуем не вообще, а для конкретных вакансий. G>>Угу, и немалая часть конкретных вакансий это enterprise разработка, где жонглирование ссылками бесполезно.
I>Наоборот, именно там и важно понимать все эти ссылки и многое другое.
Нет, ссылки не нужны. Более того, часто бывает что
Object.ReferenceEquals(x.A,x.A) == false
В такой ситуации жонглирование ссылками — рассадник багов.
НС>>>>>Не нахожу. Человек, не способный решить эту задачку, нормальный код писать неспособен. G>>>>Практика показывает обратное. НС>>>Практика именно это и показывает. G>>У нс разная практика.
I>Судя по тому, как ты не задав ни одного вопроса предложил наихудшее решение да еще начал доказывать, что оно будет работать на раз, сильно сомневаюсь, что у тебя адекватная практика.
Обоснуй что худшее. Начни с твоих "особенностей".
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
G>>А идеальный вариант: G>>
G>>var a = str.ToCharArray();
G>>Array.Reverse(a);
G>>return new string(a);
G>>
G>>Но такой пишет каждый десятый.
I>Если у вас такое пишет каждый десятый, то вполне понятны твои вопли про реверс списка I>У нас такое пишет каждый первый
На собеседовании? Я тебе просто не верю.
Здравствуйте, gandjustas, Вы писали:
I>>Если у вас такое пишет каждый десятый, то вполне понятны твои вопли про реверс списка I>>У нас такое пишет каждый первый G>На собеседовании? Я тебе просто не верю.
Разумеется. Но мы же здесь не твою веру обсждаем, правильно ?
Здравствуйте, gandjustas, Вы писали:
I>>Наоборот, именно там и важно понимать все эти ссылки и многое другое. G>Нет, ссылки не нужны. Более того, часто бывает что G>Object.ReferenceEquals(x.A,x.A) == false
Это как раз и требует понимания, что такое ссылки. Скажем ссылка требует уверенного понимания идентити и хотя бы представляения о том, что есть референс тайпы и валюе тайпы.
G>В такой ситуации жонглирование ссылками — рассадник багов.
После "каждый десятый пишет" твои аргументы даже слушать смешно.
I>>Судя по тому, как ты не задав ни одного вопроса предложил наихудшее решение да еще начал доказывать, что оно будет работать на раз, сильно сомневаюсь, что у тебя адекватная практика. G>Обоснуй что худшее. Начни с твоих "особенностей".
Хороший инженер обязан узнавать особенности до того, как начнет решения выдвигать. В противном случае это не инженер а изобретатель велосипедов.
Все нужные объяснения уже были дадены — читай внимательно.
Здравствуйте, Ночной Смотрящий, Вы писали:
U>>Старый алгоритм так и работал, т.е. первоначально накладывал фильтр на сигнал. В результате терялась(загрублялась) информация о точности данных НС>Значит фильтр неправильный. Простейший ВЧ фильтр — не единственный вариант.
В очередной раз убеждаюсь, что больше умных слов употребляет в речи человек, тем меньше он способен думать. Я привел конкретные проблемы применения фильтров. В ответ ты ничего по существу сказать не смог. Т.к. зазубрить умные методы тебя в вузе заставили, а вот их пониманию, в частности пониманию когда их применение правильно и оптимально, а когда нет, не научили.
Здравствуйте, Ikemefula, Вы писали:
I>Все правильно, только время надо как то учитывать. Если ты хочешь решать сложные задачи скажем в области цифровой обработки сигналов так же быстро и качественно, как и человек, который там варится 10 лет, то теб надо будет потратить сравнимое время.
Если будет не у кого учиться, то возможно, да. А если на проекте уже будут специалисты в этой области, то учиться человек со способностями будет быстро, а пользу начнет приносить практически сразу.
I>Способности большей частью трансформируются в прочные знания. По другому не бывает. Умение решать задачи показывает именно способности.
Невозможно знать всего — областей деятельности очень много и никакой жизни не хватит для того, чтобы охватить их все. Человек знает только то, с чем реально сталкивался на практике. Из того с чем не сталкивался любой человек знает ничтожнейшую часть.
Возможности программиста определяются способностями, общим пониманием, конкретными знаниями. При этом развить способности очень сложно, общему пониманию при наличии способностей научить можно, но обычно требуется довольно много времени, конкретным знаниям человек учится очень быстро. При этом почему-то на собеседовании, как правило, спрашивают конкретные знания, т.е. то чему можно обучить очень быстро, а способности и общее понимание, т.е. то что неисправимо, даже не пытаются выяснить.
I>А я где то сказал, что любые задачи решаются за секунды ? Если тебе на каждый чих гуглить надо, то я боюсь сложные задачи потребуют годы на решение.
Зачем на каждый чих гуглить? Гуглить надо либо для общего знакомства с ранее незнакомой темой, либо для получения шаманских знаний, т.е. того что невозможно понять и надо просто запомнить. С незнакомыми темами сталкиваешься далеко не каждый день, использование методов требующих шаманских знаний желательно сводить к минимуму. Соответственно на практике я гуглю очень редко.
Здравствуйте, Vzhyk, Вы писали:
U>>В очередной раз убеждаюсь, что больше умных слов употребляет в речи человек, тем меньше он способен думать. Я привел конкретные проблемы применения фильтров. В ответ ты ничего по существу сказать не смог. Т.к. зазубрить умные методы тебя в вузе заставили, а вот их пониманию, в частности пониманию когда их применение правильно и оптимально, а когда нет, не научили. V>Ты ничего конкретного не привел, кроме того, что кто-то что-то прилепил и оно не работало.
Тебя сказанное тоже касается. Но на всякий случай повторю:
Старый алгоритм так и работал, т.е. первоначально накладывал фильтр на сигнал. В результате терялась(загрублялась) информация о точности данных — уровень топлива фильтр возвращает, а дисперсию уже нет, о времени начала/конца события — реальная точка начала заправки/слива замусорена последующим поднятием/снижением уровня топлива, о уровне топлива на начало/конец события — по той же причине.
Так какой фильтр нужно наложить на сигнал, чтобы вся эта информация сохранялась?
Здравствуйте, Undying, Вы писали:
I>>Все правильно, только время надо как то учитывать. Если ты хочешь решать сложные задачи скажем в области цифровой обработки сигналов так же быстро и качественно, как и человек, который там варится 10 лет, то теб надо будет потратить сравнимое время.
U>Если будет не у кого учиться, то возможно, да. А если на проекте уже будут специалисты в этой области, то учиться человек со способностями будет быстро, а пользу начнет приносить практически сразу.
Хорошая теория, попробуй её на шахматах.
U>Невозможно знать всего — областей деятельности очень много и никакой жизни не хватит для того, чтобы охватить их все. Человек знает только то, с чем реально сталкивался на практике. Из того с чем не сталкивался любой человек знает ничтожнейшую часть.
А я где то говорил что надо всё знать ? Вот скажем если ты понимаешь, что такое производная,то не надо запоминать все производные всех функций, можно взять и вывести все что тебе надо.
U>Возможности программиста определяются способностями, общим пониманием, конкретными знаниями. При этом развить способности очень сложно, общему пониманию при наличии способностей научить можно, но обычно требуется довольно много времени, конкретным знаниям человек учится очень быстро. При этом почему-то на собеседовании, как правило, спрашивают конкретные знания, т.е. то чему можно обучить очень быстро, а способности и общее понимание, т.е. то что неисправимо, даже не пытаются выяснить.
Ты это ганджустасу скажи, это он про знания спрашивать любит.
U>Зачем на каждый чих гуглить? Гуглить надо либо для общего знакомства с ранее незнакомой темой, либо для получения шаманских знаний, т.е. того что невозможно понять и надо просто запомнить. С незнакомыми темами сталкиваешься далеко не каждый день, использование методов требующих шаманских знаний желательно сводить к минимуму. Соответственно на практике я гуглю очень редко.
Общее знакомство тебе мало что даст. Если скажем ты пришел к выводу что имеющаяся структура данных не годится, то хотя бы задетектить эту проблему, а потом выбрать подъходящую, надо уметь анализировать структуры данных вообще, а не просто знать свойства одно двух вариантов деревьев.
В этом случае такая задача решается за минуты в уме. А если ты будешь гуглить, то есть шанс что используешь чейто велосипед который непригоден абсолютно.
Скажем, у меня не получается хорошо анализировать структуры данных и алгоритмы, тут надо свободно математикой владеть, а её, этой математики, уменя совсем мало. Более-менее простые случае получаются, а что посложнее, то студенты факультета прикладной математики заруливают в минуса.
Соответсвено я нигде не позиционирую себя как специалиста по алгоритмам и структурм данных. Но это, вобщем, не значит, что с алгоритмами у меня все плохо
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Как минимум рабочие в программировании не нужны, потому что в материальном производстве рабочии занимаются созданием копий изделий, а в программировании копирование бесплатно.
Токарь в опытном цехе может каждый день точить разные детали, от этого он не перестает быть рабочим.
Отличие конструктора и технолога от рабочего в том, что рабочий выпускает конечный продукт (т.е. изделие в металле или коде). Т.е. рабочие производят трактор, конструктора — чертежи трактора, технологи — описание техпроцессов по изготовлению деталей трактора.
Простенький пример работы технолога в программировании. Ты приводил задачу с переворотом списка. Допустим на проекте эта задача встречается регулярно. Конечно, можно каждый раз решать ее заново. Но в решении имеется довольно сложное состояние, при работе с которым можно ошибиться из-за описки, невнимательности или усталости. Работа технолога состоит в том, чтобы упростить решение этой задачи для других программистов. Например, это можно сделать вынеся код переворота в такую функцию:
static T Reverse(T first, Getter<T, T> nextGetter, Executter<T, T> nextSetter);
Использование этой функции намного проще, чем сам код переворота списка, соответственно программисты теперь на переворот списка будут тратить меньше времени и допускать меньше ошибок. Т.е. программист-технолог облегчил их работу.
Другой пример работы технолога в программировании. Это знаток некоего фрамеворка, который может разъяснить другим программистам, решающим прикладные задачи с использованием этого фрамеворка, тонкости, подводные камни и сложные места использования этого фрамеворка.
U>>Гордыня на мозг не жмет? НС>Нет. А тебе? А то от тебя столько пафоса льется, что деревьев не видно.
Своих коллег по профессии я обезъянками не считаю. Так что до эталонов гордыни мне еще очень далеко.
Здравствуйте, Ikemefula, Вы писали:
U>>Если будет не у кого учиться, то возможно, да. А если на проекте уже будут специалисты в этой области, то учиться человек со способностями будет быстро, а пользу начнет приносить практически сразу. I>Хорошая теория, попробуй её на шахматах.
Давно опробована. Вон у нас Панкратов в секции был, ныне гросс который, так он в 8 лет играл в силу кандидата в мастера. А подавляющее большинство остальных занимающихся и в 16 лет играли намного хуже.
U>>Невозможно знать всего — областей деятельности очень много и никакой жизни не хватит для того, чтобы охватить их все. Человек знает только то, с чем реально сталкивался на практике. Из того с чем не сталкивался любой человек знает ничтожнейшую часть.
I>А я где то говорил что надо всё знать ? Вот скажем если ты понимаешь, что такое производная,то не надо запоминать все производные всех функций, можно взять и вывести все что тебе надо.
И какую часть нужного на практике составляют производные? Большинство инженеров за свою жизнь ни разу не сталкивается с применением производных на практике.
Это я ни к тому, что математику в школе изучать не надо, т.к. для становления мышления она полезна. Но надо понимать, что математика и инженерная деятельность это совершенно разные вещи, хоть изредка и пересекающиеся.
I>Ты это ганджустасу скажи, это он про знания спрашивать любит.
У него может специфика такая. Возможно Sharepoint действительно сплошное шаманство, которое нельзя понять, а можно только запомнить. Тогда там реально специфические люди нужны, обычные — сбегут.
I>Общее знакомство тебе мало что даст. Если скажем ты пришел к выводу что имеющаяся структура данных не годится, то хотя бы задетектить эту проблему, а потом выбрать подъходящую, надо уметь анализировать структуры данных вообще, а не просто знать свойства одно двух вариантов деревьев.
Чтобы задетектить достаточно очень общих знаний, вроде того, что нормальное время сортировки это n*log(n), поиска по ключу — О, поиска в сортированном списке log(n). И чтобы подобные общие знания передать требуется немного времени при наличии о обучаемого способностей.
I>В этом случае такая задача решается за минуты в уме. А если ты будешь гуглить, то есть шанс что используешь чейто велосипед который непригоден абсолютно.
По такой логике написание программных продуктов вообще невозможно. Т.к. на любом реальном проекте регулярно встречаются принципиально новые задачи. И если на каждую такую задачу искать спеца, который имеет знания и опыт решения таких задач, то проект никогда не будет закончен.
I>Скажем, у меня не получается хорошо анализировать структуры данных и алгоритмы, тут надо свободно математикой владеть, а её, этой математики, уменя совсем мало. Более-менее простые случае получаются, а что посложнее, то студенты факультета прикладной математики заруливают в минуса.
Если вам постоянно нужна математика на проекте, то, значит, да, желательно иметь адекватного выпускника прикладной математики, который и будет консультировать остальных по сложным вопросам и наиболее математически сложные места сам кодить. Всем-то программистам зачем мегаматематиками быть?
Здравствуйте, gandjustas, Вы писали:
I>>>>Это и нужно проверять, как человек умеет писать такой уникальный код, который не сводится к типовым задачам. G>>>Не понял, зачем? НС>>В рамочку и на стенку. G>То есть доводов у тебя нет?
Да какие уж тут еще нужны доводы? Ты просто шедевры изрекаешь, мне просто поддерживать разговор надо.
НС>>Надо говорить "мне приходится редко" G>Тебе надо? Ну говори.
Мне то зачем? Это ты вселенской общности утверждения делаешь.
G>Тебя просят дать оценку.
Кто и какую оценку просит меня дать?
G> Ты называешь цифру или диапазон, на основании чего? Обычно мозг пытается сопоставить задачу с теми, которые ты уже решал. Когда ты пишешь код, мозг работает также. Ты неосознано генерируешь код, который ты уже писал. А иногда очень осознанно делаешь копипасту.
Я что то не припомню, что ты за моим плечом когда либо стоял.
НС>>Мы уже поняли, что тебе программисты не нужны. О чем тогда ты споришь? G>Это ты споришь о сущности умения разворачивать списки, пытаясь доказать что это практически Умение писать код.
Ничего подобного я доказать не пытаюсь. Я говорю лишь о том, что способность решить эту задачу — необходимое условие. Но отнюдь не достаточное.
G> Но у тебя нет ни доводов, ни фактов, ничего...
Здравствуйте, Undying, Вы писали:
U>В очередной раз убеждаюсь, что больше умных слов употребляет в речи человек, тем меньше он способен думать.
В очередной раз убеждаюсь, что чем меньше фактов у человека, тем больше он хамит. Пока что тут ты демонстрируешь просто фантастическую безграмостность как в основах программирования, так и в основах DSP.
U> Я привел конкретные проблемы применения фильтров.
Ничего ты по сути не привел. Все что можно из предоставленного тобой понять, это то что кто то там неверно подобрал функцию обработки, а ты, видимо из-за нулевого математического бекграунда, изобрел странный велосипед. В принципе, я тоже так делал, когда в университете учился, из-за недостатка опыта. И оно даже работало. Вот только мне потом повезло с существенно более сложными задачами, так что я быстро осознал наличие пробелов.
U>Т.к. зазубрить умные методы тебя в вузе заставили
Неа, в мою специальность в вузе вообще DSP не входила. "Зазубрить" меня заставила работа, плотно связанная с DSP, причем от паяльника до алгоритмов, близких к ИИ. Не все задачки можно решить колхозными методами, увы.
Здравствуйте, Undying, Вы писали:
U>Так какой фильтр нужно наложить на сигнал, чтобы вся эта информация сохранялась?
Если у тебя проблема с латентностью, то, обычно, в параллель ставят диффильтр, потом какой нибудь фильтр, удаляющий мусор, потом фильтр распознавания (их там несколько классов есть, подбирается в зависимости от потребностей) — на выходе у тебя будут нужные тебе сигналы с задержкой от 1-2 до десятка отсчетов, в зависимости от длины и сложности фиксируемого паттерна. Но это так, из пальца. Конкретные направления можно будет понять только после ознакомления с полной задачей и реальными семплами.
Здравствуйте, gandjustas, Вы писали:
НС>>Это связанные умения. G>Практика показывает что не связанные.
Твоя. А моя — что связанные.
G>Очень мнгого программистов видел, которые генерируют тонны кода.
И что?
G> Обрабатывают сотни кейсов, которые никогда не встретятся из-за особенностей api, закладывают гибкость, там где она не нужна итп. почти весь код бесполезен.
И что? Это называется умение писать код?
G>Писать код они точно умеют.
Ну так и читать, видимо, тоже не умеют. Ты к чему все это написал?
НС>>Это не объясняет, почему у разных программистов с одинаковым опытом производительность может отличаться на порядок. G>Именно объясняет.
Нет, не объясняет.
G>Моя практика показывает
Наконец то ты использовал правильное местоимение.
НС>>Нет, смешно это когда человек, претендующий на работу программиста, не в состоянии справится с примитивной ссылочной конструкцией. И энтерпрайз, он очень разный, не обобщай шерпоинт на все остальное. G>Да не нужно это умение.
Опять местоимение забыл.
G> Как бы ты не пытался доказать обратное.
Обратное? Да я давно уже понял, что в твоих задачах вообще программисты особо не нужны. И я, в отличие от тебя, не пытаюсь доказать, что это не так.
G> У тебя нет ни фактов, ни адекватных доводов. Везде только твое неподкрепленное ничем мнение.
Надо понимать, у тебя есть факты и адекватные доводы?
G>О да, каждый день программисты пишут dsl_и ??
Не каждый, но у нас такие задачки не редкость. Не нравятся DSL — задачки реализации транзакционного ресурса, к примеру, в плане косвенности не сильно проще, там такие хитрые ситуации вылазят, что мама не горюй.
НС>>Чем он лучший? Тем что кода в два раза больше надо писать? G>Тем что не надо ничего держать в голове.
Почему это? Надо, причем больше — сущностей то в коде больше.
G> Нету циклов со сложными инвариантами
Ты вообще о каком коде говоришь? Тот что я привел — там цикл есть.
G>, и с точки зрения платформы это оптимальный способ.
Нет, не оптимальный, ни по памяти, ни по процессору. Можешь взять и померять, если не веришь.
НС>>Это я уже понял. Кто то под шерпоинт пишет, а кто то и сам шерпоинт. G>Сам шарепонт написан индусами. Под капотом такой страшный код, что иногда удивительно как он работает.
Ну так нафига его тогда использовать?
G> Статический анализ на сборках sp выдает миллионы замечаний.
FXCop тоже написан индусами
G>И это не только sp такой. каждая корпоративная платформа такая. Где-то чуть лучше, где-то хуже. Это не потому что разработчики плохие. Это экономика разработки enterprise софта такая.
Ага, тут главное — верить, что не только ты говнокод пишешь — все такие.
Здравствуйте, Undying, Вы писали:
U>Токарь в опытном цехе может каждый день точить разные детали, от этого он не перестает быть рабочим.
Ну то есть ты решил перейти на доказательства по аналогии. Зря, на меня этот прием демагогии не действует.
U>Простенький пример работы технолога в программировании.
Настала пора обратится к энциклопедии, чтобы ты понял смысл термина:
Инженер-технолог — инженер, занимающийся разработкой, организацией того или иного производственного процесса.
U> Ты приводил задачу с переворотом списка. Допустим на проекте эта задача встречается регулярно.
Нет, эта задача в реальном проекте не встречается, я уже 10 раз это здесь писал. Ты толи не читаешь мои сообщения полностью, толи полностью игнорируешь все, что противоречит теории в твоей голове.
А про упрощение да, все правильно. И именно поэтому "программисты", умеющие писать только шаблонный код, не нужны.
НС>>Нет. А тебе? А то от тебя столько пафоса льется, что деревьев не видно. U>Своих коллег по профессии я обезъянками не считаю.
Я тоже не считаю. Я прямо писал, опять же неоднократно — программист из человека, который не в состоянии развернуть односвязный список, как из говна пуля. И это не потому что у меня какая то гордыня, это абсолютно практический опыт. Ты когда/если повоюешь за качество кода (ага, это уже работа инженера-технолога) подольше, в итоге к тому же и придешь. Разводить сопли с людьми, у которых моск не приспособлен для программирования — бесполезная трата времени и денег, а так же гавно в проекте, которое потом еще и вычищать придется.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Настала пора обратится к энциклопедии, чтобы ты понял смысл термина: НС>
НС>Инженер-технолог — инженер, занимающийся разработкой, организацией того или иного производственного процесса.
Т.е. по-твоему программирование это не производственный процесс и организовывать там нечего?
Собственно в непрограммировании несколько веков было тоже самое, тогда в производственных процессах не было ни конструкторов, ни технологов, ни рабочих, были только ремесленники. Сейчас в программировании все тоже самое. Т.к. на чужом опыте программисты учиться не желают, и будут учиться только на своих ошибках.
U>> Простенький пример работы технолога в программировании. Ты приводил задачу с переворотом списка. Допустим на проекте эта задача встречается регулярно. НС>Нет, эта задача в реальном проекте не встречается, я уже 10 раз это здесь писал. Ты толи не читаешь мои сообщения полностью, толи полностью игнорируешь все, что противоречит теории в твоей голове.
Ты что такое пример и допущение понимаешь?
НС>Я тоже не считаю. Я прямо писал, опять же неоднократно — программист из человека, который не в состоянии развернуть односвязный список,
Ты за рамки собственного примера выйти можешь? Речь уже давно не о том нужно ли спрашивать разворот списка на собеседовании, а о куда более общих вещах.
Здравствуйте, Undying, Вы писали:
U>Т.е. по-твоему программирование это не производственный процесс и организовывать там нечего?
Ты опять полностью игнорируешь мною написанное. Я прямо написал, что инженеры-технологи в процессе разработки ПО нужны. Только это совсем другие навыки.
U>Собственно в непрограммировании несколько веков было тоже самое
Ясно, опять пошли доказательства по аналогии.
U>Сейчас в программировании все тоже самое.
Нет.
НС>>Нет, эта задача в реальном проекте не встречается, я уже 10 раз это здесь писал. Ты толи не читаешь мои сообщения полностью, толи полностью игнорируешь все, что противоречит теории в твоей голове. U>Ты что такое пример и допущение понимаешь?
Делать допущения, которые прямо противоречат словам человека, и на основании этого доказывать что он не прав, с которым ты споришь — это, мягко говоря, не совсем корректный прием спора.
НС>>Я тоже не считаю. Я прямо писал, опять же неоднократно — программист из человека, который не в состоянии развернуть односвязный список, U>Ты за рамки собственного примера выйти можешь?
Могу. А зачем? Обсуждать другие отрасли я не собираюсь по очевидным причинам.
U> Речь уже давно не о том нужно ли спрашивать разворот списка на собеседовании, а о куда более общих вещах.
Ну то есть со списком ты ничего доказать не смог и решил сменить тему? Создай отдельный топик, изложи свои тезисы, обсудим.
Здравствуйте, Ночной Смотрящий, Вы писали:
U>>Т.е. по-твоему программирование это не производственный процесс и организовывать там нечего? НС>Ты опять полностью игнорируешь мною написанное. Я прямо написал, что инженеры-технологи в процессе разработки ПО нужны. Только это совсем другие навыки.
Это ты игнорируешь. Я написал "программирование", т.е. написание кода, а не "разработка ПО", которая может в себя включать тестирование, настройку стендов и т.п.
Я правильно понял, что ты утверждаешь, что написание кода это не производственный процесс, поэтому организовывать там нечего и технологи там не нужны?
U>>Собственно в непрограммировании несколько веков было тоже самое НС>Ясно, опять пошли доказательства по аналогии.
Т.е. ты умеешь учиться только на своих ошибках. Чужой опыт это почти всегда аналогия, полное совпадение бывает крайне редко.
НС>Делать допущения, которые прямо противоречат словам человека, и на основании этого доказывать что он не прав, с которым ты споришь — это, мягко говоря, не совсем корректный прием спора.
Ты о чем вообще? Где я в посте с примером говорил о том, что задача переворота списка плохо?
НС>Ну то есть со списком ты ничего доказать не смог и решил сменить тему?
Ты меня вообще читаешь? Я уж давно признал, что если использовать на собеседовании задачи как первичный фильтр, то задача переворота списка может быть неплохим, хоть и дорогим вариантом. Дорогим потому, что отсеет многих середняков, которые могли бы хорошо работать при должной организации процесса программирования.
НС>Создай отдельный топик, изложи свои тезисы, обсудим.
Здравствуйте, Undying, Вы писали:
U>Это ты игнорируешь. Я написал "программирование", т.е. написание кода, а не "разработка ПО", которая может в себя включать тестирование, настройку стендов и т.п.
Ну, если в команде нет выделенного специалиста — могут. Только эти навыки к программированию все равно отношения не имеют.
U>Я правильно понял, что ты утверждаешь, что написание кода это не производственный процесс, поэтому организовывать там нечего и технологи там не нужны?
Нет, ничего подобного я не утверждал даже близко.
U>>>Собственно в непрограммировании несколько веков было тоже самое НС>>Ясно, опять пошли доказательства по аналогии. U>Т.е. ты умеешь учиться только на своих ошибках
Нет, я просто знаю что доказательства по аналогии логически некорректны.
НС>>Делать допущения, которые прямо противоречат словам человека, и на основании этого доказывать что он не прав, с которым ты споришь — это, мягко говоря, не совсем корректный прием спора. U>Ты о чем вообще?
О том что ты вывернул мои слова на прямо противоположные.
U> Где я в посте с примером говорил о том, что задача переворота списка плохо?
Тогда с чем ты споришь?
НС>>Ну то есть со списком ты ничего доказать не смог и решил сменить тему? U>Ты меня вообще читаешь? Я уж давно признал, что если использовать на собеседовании задачи как первичный фильтр, то задача переворота списка может быть неплохим, хоть и дорогим вариантом.
Ты несколько другое писал.
U> Дорогим потому, что отсеет многих середняков, которые могли бы хорошо работать при должной организации процесса программирования.
Я не верю в то, что человек, не способный справится с такой простенькой задачей это середняк. По факту это даже не начинающий, а, либо, полный ноль, либо человек с неподходящим для программирования складом ума.
Здравствуйте, Ночной Смотрящий, Вы писали:
U>>Я правильно понял, что ты утверждаешь, что написание кода это не производственный процесс, поэтому организовывать там нечего и технологи там не нужны? НС>Нет, ничего подобного я не утверждал даже близко.
Т.е. технологи при написании кода все-таки нужны?
НС>Нет, я просто знаю что доказательства по аналогии логически некорректны.
Так как тогда учиться на чужих ошибках?
НС>О том что ты вывернул мои слова на прямо противоположные.
То чего ты занудный. Я не выворачивал твои слова наизнанку, т.к. никогда не утверждал, что на твоей работе переворот списков это обычное дело.
НС>Тогда с чем ты споришь?
Последние посты о полезности разделения труда в программировании.
U>>Ты меня вообще читаешь? Я уж давно признал, что если использовать на собеседовании задачи как первичный фильтр, то задача переворота списка может быть неплохим, хоть и дорогим вариантом.
НС>Ты несколько другое писал.
Признаю твою правоту. Я думал вы так специалистов-кодеров отбираете, а учитывая, что они вам не нужны, то это хорошая задача для первичного отбора.
Здравствуйте, Undying, Вы писали:
НС>>Нет, ничего подобного я не утверждал даже близко. U>Т.е. технологи при написании кода все-таки нужны?
Я где то утверждал обратное?
НС>>Нет, я просто знаю что доказательства по аналогии логически некорректны. U>Так как тогда учиться на чужих ошибках?
Не вижу связи между высказываниями.
НС>>О том что ты вывернул мои слова на прямо противоположные. U>То чего ты занудный.
Ага, на демагогию не поддаюсь.
U> Я не выворачивал твои слова наизнанку
Именно это ты и сделал.
U>>>Ты меня вообще читаешь? Я уж давно признал, что если использовать на собеседовании задачи как первичный фильтр, то задача переворота списка может быть неплохим, хоть и дорогим вариантом. НС>>Ты несколько другое писал. U>
U>Признаю твою правоту. Я думал вы так специалистов-кодеров отбираете, а учитывая, что они вам не нужны, то это хорошая задача для первичного отбора.
Здравствуйте, Tanker, Вы писали:
T>Кажись тебе хочется выдать за доказательство суждение по методу аналогии.
Нет, не хочется. Поскольку тут спор и обоснование изложенной теории, а не мозговой штурм и попытка теорию придумать, то индукция сразу отпадает. Остается единственное корректное применение аналогии — в качестве иллюстрации. Но при этом обязательно рядом должны быть доказательства утверждения, чего мы не наблюдаем. Так что имеет место быть классический случай доказательства по аналогии.
T>То есть, не надо бояться аналогий.
Это не значит что аналогии можно применять для доказательства.
Здравствуйте, Ночной Смотрящий, Вы писали:
T>>Кажись тебе хочется выдать за доказательство суждение по методу аналогии.
НС>Нет, не хочется. Поскольку тут спор и обоснование изложенной теории, а не мозговой штурм и попытка теорию придумать, то индукция сразу отпадает. Остается единственное корректное применение аналогии — в качестве иллюстрации. Но при этом обязательно рядом должны быть доказательства утверждения, чего мы не наблюдаем. Так что имеет место быть классический случай доказательства по аналогии.
Для иллюстрации достаточно пояснений и они приведены. Как только появятся доказательства, то аналогия в тот же момент станет вполне рабочей теорией.
Здравствуйте, Tanker, Вы писали:
T>Для иллюстрации достаточно пояснений и они приведены. Как только появятся доказательства, то аналогия в тот же момент станет вполне рабочей теорией.
Вот только это все уже заявлено как рабочая теория, а не как попытка индукции.
Здравствуйте, Undying, Вы писали:
U>Давно опробована. Вон у нас Панкратов в секции был, ныне гросс который, так он в 8 лет играл в силу кандидата в мастера. А подавляющее большинство остальных занимающихся и в 16 лет играли намного хуже.
8 лет вполне нормально для КМС, здесь нет ничего необычного. Вот если бы он до уровня гроссов дошел в этом возрасте — вот что странно. Собтсвенно уровень гроссов менее чем за 10 лет достигают уникумы.
I>>А я где то говорил что надо всё знать ? Вот скажем если ты понимаешь, что такое производная,то не надо запоминать все производные всех функций, можно взять и вывести все что тебе надо.
U>И какую часть нужного на практике составляют производные? Большинство инженеров за свою жизнь ни разу не сталкивается с применением производных на практике.
Я объясняю простую вещь — понимая основы нет необходимости запоминать.
U>Это я ни к тому, что математику в школе изучать не надо, т.к. для становления мышления она полезна. Но надо понимать, что математика и инженерная деятельность это совершенно разные вещи, хоть изредка и пересекающиеся.
Тем не менее в инженерном деле есть такая же база, как и в математике, то есть, не надо зазубривать.
U>Чтобы задетектить достаточно очень общих знаний, вроде того, что нормальное время сортировки это n*log(n), поиска по ключу — О, поиска в сортированном списке log(n). И чтобы подобные общие знания передать требуется немного времени при наличии о обучаемого способностей.
U>По такой логике написание программных продуктов вообще невозможно. Т.к. на любом реальном проекте регулярно встречаются принципиально новые задачи. И если на каждую такую задачу искать спеца, который имеет знания и опыт решения таких задач, то проект никогда не будет закончен.
Ты похоже не слышишь, что я говорю. Нет необходимости в таких спецах, если у тебя есть некотрая база. Если хорошо понимаешь, что такое "разделяй и властвуй", то легкой поймешь любой алгоритм и сможешь проанализировать его. Еще раз — любой.
U>Если вам постоянно нужна математика на проекте, то, значит, да, желательно иметь адекватного выпускника прикладной математики, который и будет консультировать остальных по сложным вопросам и наиболее математически сложные места сам кодить. Всем-то программистам зачем мегаматематиками быть?
Так и есть. Математики решают довольно сложные задачи, из за мелких проблем, типа лаги и креши, незачем отвлекать их от своей работы.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Его не надо совать в топливо, это теория. На основании этого преобразования считается матрица ВЧ фильтра или любой другой потребной функции, которую нужно наложить на сигнал.
В чем смысл частотного фильтра? В том, что он позволяет подавить в сигнале одни частоты, сохранив другие. Соответственно когда носителем информации в сигнале является частота, частотный фильтр является полезным и вероятно незаменимым методом первичной фильтрации. В рассматриваемой задаче носителем информации является уровень сигнала, частота никакой информации не несет. Так зачем здесь частотный фильтр? Какие частоты ты собрался в сигнале сохранять?
НС>Неа, в мою специальность в вузе вообще DSP не входила. "Зазубрить" меня заставила работа, плотно связанная с DSP, причем от паяльника до алгоритмов, близких к ИИ. Не все задачки можно решить колхозными методами, увы.
Заучить методы ты сумел, а вот понять их смысл и границы применимости так и не смог.
Здравствуйте, Sharowarsheg, Вы писали:
S>А чего, тут вон был какой-то дядька, всё рассказывал про "монитор" в многопоточности. Пришлось в википедию смотреть, хотя я вроде многопоточно пишу уже лет десять. Не был бы на форуме, не знал бы, что такое монитор.
Односвязный список все таки общепринятый термин. Или ты тоже не знаешь что это такое?
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>А чего, тут вон был какой-то дядька, всё рассказывал про "монитор" в многопоточности. Пришлось в википедию смотреть, хотя я вроде многопоточно пишу уже лет десять. Не был бы на форуме, не знал бы, что такое монитор.
НС>Односвязный список все таки общепринятый термин. Или ты тоже не знаешь что это такое?
Я-то знаю, но вот в общепринятость чего угодно не верю уже давно. Кстати, дядька тот (Морозов, чтоли?) тоже настаивал на общепринятости слова "монитор".
НС>>Односвязный список все таки общепринятый термин. Или ты тоже не знаешь что это такое?
S>Я-то знаю, но вот в общепринятость чего угодно не верю уже давно. Кстати, дядька тот (Морозов, чтоли?) тоже настаивал на общепринятости слова "монитор".
односвязный список -- это крайне неудачный термин (в русском языке). Потому что квалификатор "односвязный" уже давно прочно занят под совершенно другое понятие "simply connected".
А тут это слово используется в совершенно другом смысле "singly linked".
Здравствуйте, Ночной Смотрящий, Вы писали:
T>>Для иллюстрации достаточно пояснений и они приведены. Как только появятся доказательства, то аналогия в тот же момент станет вполне рабочей теорией. НС>Вот только это все уже заявлено как рабочая теория, а не как попытка индукции.
В данной ветке проблема не в аналогиях, а в том что Undying выдумывает терминологию для уже имеющихся вещей.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, gandjustas, Вы писали:
G>>Очень мнгого программистов видел, которые генерируют тонны кода. НС>И что?
G>> Обрабатывают сотни кейсов, которые никогда не встретятся из-за особенностей api, закладывают гибкость, там где она не нужна итп. почти весь код бесполезен. НС>И что? Это называется умение писать код?
G>>Писать код они точно умеют. НС>Ну так и читать, видимо, тоже не умеют. Ты к чему все это написал?
К тому что писать они умеют. Код, который они нагенерировали, прошел бы любой review и соотвествует всем практикам. Но бесполезен, ибо сами релизовали то, что уже есть в платформе, а их код как раз с платформой интегрируется плохо.
G>> Как бы ты не пытался доказать обратное. НС>Обратное? Да я давно уже понял, что в твоих задачах вообще программисты особо не нужны. И я, в отличие от тебя, не пытаюсь доказать, что это не так.
Ты о чем? Думашь без программирования много сделаешь на sharepoint? Увы это не так.
Вот только программирование крайне далеко от разворотов списка. Это факт.
А что ты пытаешься доказать? Что человек, умеющий разворачивать списки фиганет любое решение на sharepoint\crm\1c?
Не сможет. Тоже факт.
G>> У тебя нет ни фактов, ни адекватных доводов. Везде только твое неподкрепленное ничем мнение. НС>Надо понимать, у тебя есть факты и адекватные доводы?
Я же говорю — практика и статистика.
Ты, видимо, работаешь в области, где разворачивать списки нужно и тебе кажется, что это важное умение.
Я поработал в разных областях и вижу, что оно далеко не везде нужно.
НС>>>Чем он лучший? Тем что кода в два раза больше надо писать? G>>Тем что не надо ничего держать в голове. НС>Почему это? Надо, причем больше — сущностей то в коде больше.
Не вижу связи. То что сущностей в коде больше не означает, что надо больше держать в голове.
В этом и суть разработки — декомпозируем задачу, чтобы минимизировать количество информации, которые надо держать в голове при написании и чтении. Потом собираем из маленьких кусочков большое решение.
G>> Нету циклов со сложными инвариантами НС>Ты вообще о каком коде говоришь? Тот что я привел — там цикл есть.
О том, который я привел. Там нет циклов.
G>>, и с точки зрения платформы это оптимальный способ. НС>Нет, не оптимальный, ни по памяти, ни по процессору. Можешь взять и померять, если не веришь.
static void Main(string[] args)
{
var count = 100000;
var s = "abracedabra";
Reverse1(s);
Reverse2(s);
var sw1 = Stopwatch.StartNew();
for (int i = 0; i < count; i++)
{
Reverse1(s);
}
sw1.Stop();
Console.WriteLine(sw1.ElapsedMilliseconds); //34мсvar sw2 = Stopwatch.StartNew();
for (int i = 0; i < count; i++)
{
Reverse2(s);
}
sw2.Stop();
Console.WriteLine(sw2.ElapsedMilliseconds); //11мс
}
static string Reverse1(string s)
{
var result = new StringBuilder(s.Length);
for(int i = s.Length-1; i>=0; i--)
{
result.Append(s[i]);
}
return result.ToString();
}
static string Reverse2(string s)
{
var chars = s.ToCharArray();
Array.Reverse(chars);
return new string(chars);
}
Можешь у себя запустить.
НС>>>Это я уже понял. Кто то под шерпоинт пишет, а кто то и сам шерпоинт. G>>Сам шарепонт написан индусами. Под капотом такой страшный код, что иногда удивительно как он работает. НС>Ну так нафига его тогда использовать?
Он много чего умеет. Столько, что неэффективно подобную систему с нуля разрабатывать.
Глючит иногда, но если знать как делать, то глючить не будет.
G>> Статический анализ на сборках sp выдает миллионы замечаний. НС>FXCop тоже написан индусами
Дык то не fxcop.
G>>И это не только sp такой. каждая корпоративная платформа такая. Где-то чуть лучше, где-то хуже. Это не потому что разработчики плохие. Это экономика разработки enterprise софта такая. НС>Ага, тут главное — верить, что не только ты говнокод пишешь — все такие.
Да ты можешь верить, а вот заказчик не поверит.
Важно не то, какой ты код пишешь, а важно как он решает проблемы.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
I>>>Если у вас такое пишет каждый десятый, то вполне понятны твои вопли про реверс списка I>>>У нас такое пишет каждый первый G>>На собеседовании? Я тебе просто не верю.
I>Разумеется. Но мы же здесь не твою веру обсждаем, правильно ?
Здравствуйте, Sharowarsheg, Вы писали:
S>А чего, тут вон был какой-то дядька, всё рассказывал про "монитор" в многопоточности. Пришлось в википедию смотреть, хотя я вроде многопоточно пишу уже лет десять. Не был бы на форуме, не знал бы, что такое монитор.
Здравствуйте, Ikemefula, Вы писали:
I>8 лет вполне нормально для КМС, здесь нет ничего необычного. Вот если бы он до уровня гроссов дошел в этом возрасте — вот что странно.
Ты о чем вообще? Речь о том, что люди с хорошими способностями за год достигают уровня, который люди со средними способностями не достигнут никогда. Шахматы это прекрасно подтверждают.
I>Собтсвенно уровень гроссов менее чем за 10 лет достигают уникумы.
Ты на собеседованиях собрался только гроссов, т.е. людей с очень хорошими способностями всю жизнь посвятившими одной специализации, набирать? Во-первых, через собеседования таких людей найти не реально. Во-вторых, только гроссы на проекте малоэффективны. И даже не столько потому, что набрать только гроссов очень дорого и трудноосуществимо, сколько из-за того, что рояль за гроссами все равно носить кто-то должен.
I>>>А я где то говорил что надо всё знать ? Вот скажем если ты понимаешь, что такое производная,то не надо запоминать все производные всех функций, можно взять и вывести все что тебе надо.
А почему надо понимать именно производную? А не допустим критерий Вилкоксона? В подавляющем большинстве инженерных специальностей само по себе понимание и первого, и второго одинаково малополезно, из-за отсутствия задач где это было бы можно применить. Поэтому важно обладать способностями, которые позволят понять и первое, и второе, если это понадобится на практике. Т.к. сколько бы ты не тратил время на обучение, ты все равно будешь понимать ничтожную долю из общего количества инженерных задач.
I>Ты похоже не слышишь, что я говорю. Нет необходимости в таких спецах, если у тебя есть некотрая база. Если хорошо понимаешь, что такое "разделяй и властвуй", то легкой поймешь любой алгоритм и сможешь проанализировать его. Еще раз — любой.
Если у человека есть способности, то он сможет понять принцип "разделять и властвуй", даже если ранее его не знал и соответственно не понимал.
Т.е. проблемой проверки конкретного понимания на собеседовании является то, что невозможно понять почему человек не понимает какой-то принцип: 1) из-за того, что у него способностей 2) из-за того, что у вас просто разная терминология 3) из-за того, что человек с такими задачами не сталкивался
Также очень сложно отличить знание от понимания. А человек много знающий, но не имеющий способностей для того, чтобы понять как эти знания применять это худший выбор. Т.к. для таких людей характерна завышенная самооценка. А такие люди не только приносят мало пользы, но еще могут принести и массу вреда.
T>>Чтото в этом есть. Современный веб это все меньше и меньше программирования, а в кое где это уже сегодня на 100% конфигурирование. В такие компании программисты не нужны. G>Между конфигурированием и программированием тонкая грань. Написание кода для 1С это программирование или конфигурирование? G>С одной стороны конфигурирование, так как сама платформа не меняется. С другой стороны — программирование, ибо язык полн по тьюрингу и написать можно что угодно.
Если язык полон по тьюрингу, то в программистов надо записать и тестировщиков, и тех кто с xml-xslt работает, и поголовно всех админов и целую тучу людей которые к разработке не имеют отношения.
Здравствуйте, gandjustas, Вы писали:
I>>Это как раз и требует понимания, что такое ссылки. Скажем ссылка требует уверенного понимания идентити и хотя бы представляения о том, что есть референс тайпы и валюе тайпы. G>Ну ок. Человек понимает что такое value и ref типы. ИМХО без этого нельзя писать на .NET. G>Что ему ее нужно? Разворачивать список на месте на бумажке? Я так и не понял зачем это умение.
На задаче проверяются умения применить знания циклов, списков, ссылок-указателей. Вот эти умения нужны. А задача уникальная, что бы заготовками не пользовался.
G>Понимание identity? Что это вообще такое? Как выражается?
Похоже, с тобой все ясно.
G>Ты ведь так и не сказал зачем нужен разворот списка. Вроде свелось к пониманию value и ref, но это не головоломка (см определение выше).
Уже раз пять, и один раз выше прямо по тексту.
I>>Хороший инженер обязан узнавать особенности до того, как начнет решения выдвигать. В противном случае это не инженер а изобретатель велосипедов. G>Пффф... Ты откуда такую глупость придумал?
Я сильно устаю, когда очередной мега убер веб-девелопер с пеной у рта, навроде тебя, начинает тащить серверный подход один к одному в десктоп(мобайл)-приложение, абсолютно не интересуясь ни тем, сколько доступно памяти под задачу, ни тем, какие вообще есть требования и ограничения.
G>Есть исследование, которое показывает что инженеры обычно генерируют кучи решений и отсекают неподходящие. Причем критерий "подходящести" обычно меняется при рассмотрении новых вариантов. G>Увы ссылку не найду быстро, можешь погуглить если интересно. G>Вообще читай Design of Design Брукса.
Здравствуйте, Tanker, Вы писали:
T>Здравствуйте, gandjustas, Вы писали:
T>>>Чтото в этом есть. Современный веб это все меньше и меньше программирования, а в кое где это уже сегодня на 100% конфигурирование. В такие компании программисты не нужны. G>>Между конфигурированием и программированием тонкая грань. Написание кода для 1С это программирование или конфигурирование? G>>С одной стороны конфигурирование, так как сама платформа не меняется. С другой стороны — программирование, ибо язык полн по тьюрингу и написать можно что угодно.
T>Если язык полон по тьюрингу, то в программистов надо записать и тестировщиков, и тех кто с xml-xslt работает
По сути оно так и есть.
T>и поголовно всех админов и целую тучу людей которые к разработке не имеют отношения.
Админы, которые пишут одноразовые скрипты, программистами не являются, ибо не владеют всеми средствами комбинирования.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
I>>>Разумеется. Но мы же здесь не твою веру обсждаем, правильно ?
G>>Ссылку на вакансию кинь? Проверим.
I>Ты собеседование что ли хочеш пройти или как ? Ты его не пройдешь, ибо предлагаешь решения нисколько не интересуясь контекстом.
Нет, мы у себя впишем требования и посмотрим кто придет
Здравствуйте, Ikemefula, Вы писали:
I> "а теперь оказывается, что статистики у тебя нет"
А ты всетаки МакКонелла прочитай.
И гугли по defects per loc. Я ссылки не сохраняю, гуглить за тебя мне тоже влом.
I>>>Данные всегда в памяти. G>> G>>Откуда они берутся? Они зашиты в исполняемый модуль?
I>Ты лучше спроси что за приложение, тогда дурацкие вопросы отпадут сами собой.
Зачем?
I>Данные берутся I>1. с диска I>2. из сети I>3. от пользователя I>4. создаются самой программой
В каждом из этих случаев их нельзя вставлять в сбалансированное дерево?
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
T>>>Поэтому навыки программировани уже неактуальны, необходимо и достаточно выяснить знание основного набора инструментов — копипаст, справочник, гугл и умение разобраться в том, что нужно сделать и в том что уже сделано. G>>Это смотря что считать "навыкам программирования". Программирование уже давно не реализация с нуля приложений, это именно комбинирование существующих функций для достижения результата.
I>Оно и заметно — такие комбинаторы и выдают вместо реверса списка реверс строки через стрингбилдер.
Ты быть хоть контекст почитал. Смешно выглядишь.
I>Считай это навыками программирования, а я буду считать таких людей бездарями, которые нахватались баззвордов.
Да считай. Чем тебе это поможет?
Здравствуйте, gandjustas, Вы писали:
I>> "а теперь оказывается, что статистики у тебя нет" G>А ты всетаки МакКонелла прочитай. G>И гугли по defects per loc. Я ссылки не сохраняю, гуглить за тебя мне тоже влом.
Время разработки учитывать не надо ?
I>>Ты лучше спроси что за приложение, тогда дурацкие вопросы отпадут сами собой. G>Зачем?
Ну раз тебе нравится задавать дурацкие вопросы, так развлекайся.
I>>Данные берутся I>>1. с диска I>>2. из сети I>>3. от пользователя I>>4. создаются самой программой G>В каждом из этих случаев их нельзя вставлять в сбалансированное дерево?
Здравствуйте, Ikemefula, Вы писали:
I>Ну раз тебе нравится задавать дурацкие вопросы, так развлекайся.
I>>>Данные берутся I>>>1. с диска I>>>2. из сети I>>>3. от пользователя I>>>4. создаются самой программой G>>В каждом из этих случаев их нельзя вставлять в сбалансированное дерево?
I>Ни в одном.
То есть во всех можно. ЧТД.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
I>>>Ты собеседование что ли хочеш пройти или как ? Ты его не пройдешь, ибо предлагаешь решения нисколько не интересуясь контекстом.
G>>Нет, мы у себя впишем требования и посмотрим кто придет
I>Тогда надо и бренд сменить на наш, и зп поднять и тд и тд и тд.
Да ЗП и так нормальные, бренд тоже ниче так.
Ты не юли, дай ссылку на вакансию или просто текст, если сейчас нигде не опубликована.
Здравствуйте, Tanker, Вы писали:
T>Здравствуйте, gandjustas, Вы писали:
T>>>Если язык полон по тьюрингу, то в программистов надо записать и тестировщиков, и тех кто с xml-xslt работает G>>По сути оно так и есть. T>Значит в таком признаке как полнота по Тьюрингу смысла нт никакого, а разделять надо по задачам.
Полнота по тьюрингу является необходимым условием. Без него возможности программирования получаются довольно скудные.
T>>>и поголовно всех админов и целую тучу людей которые к разработке не имеют отношения. G>>Админы, которые пишут одноразовые скрипты, программистами не являются, ибо не владеют всеми средствами комбинирования. T>Это какие то не те админы еще есть безопасники, билд-инженеры....
Хороший админ очень быстро обучается функциональным языкам, ибо большинство shell-скриптовых языков обладают похожими свойствами. А потом можно и JS заняться, для него вообще надо месяц чтобы изучить и начать писать.
Безопасники, которые занимаются технической безпоасностью обычно очень хорошие программисты. А те которые занимаются бумажной безпопасностью — не программисты вообще.
Здравствуйте, gandjustas, Вы писали:
I>>>>Данные берутся I>>>>1. с диска I>>>>2. из сети I>>>>3. от пользователя I>>>>4. создаются самой программой G>>>В каждом из этих случаев их нельзя вставлять в сбалансированное дерево?
I>>Ни в одном. G>То есть во всех можно. ЧТД.
Если буквально — то можно. Любые типы данных можно класть в дерево, даже само дерево можно. Никто не запрещает.
Самое главое — не важно, что происходит между загрузкой и конечной обработкой и какие требования кастомера, главное — засунуть в дерево.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
I>>>>>Данные берутся I>>>>>1. с диска I>>>>>2. из сети I>>>>>3. от пользователя I>>>>>4. создаются самой программой G>>>>В каждом из этих случаев их нельзя вставлять в сбалансированное дерево?
I>>>Ни в одном. G>>То есть во всех можно. ЧТД.
I>Если буквально — то можно. Любые типы данных можно класть в дерево, даже само дерево можно. Никто не запрещает. I>Самое главое — не важно, что происходит между загрузкой и конечной обработкой и какие требования кастомера, главное — засунуть в дерево.
Ты же хотел сортировку за О(N), я тебе говорю — вставляй в дерево в момент появления данных. Доставать в нужном порядке будешь без дополнительных затрат.
Ты озвучил частную задачу, я тебе озвучил частное решение. Ты не сказал почему оно не подходит, начал вилять.
Скажи конкретно, почему не подходит в твоем случае. Не надо про "особенности".
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
G>>>>Нет, мы у себя впишем требования и посмотрим кто придет
I>>>Тогда надо и бренд сменить на наш, и зп поднять и тд и тд и тд.
G>>Да ЗП и так нормальные, бренд тоже ниче так. G>>Ты не юли, дай ссылку на вакансию или просто текст, если сейчас нигде не опубликована.
I>Все стандартно — ищется разработчик, опыт такой то, профиль такой то, на проект такой то, специфика такая то, соцпакет, зп, желательные требования — перечень баззвордов.
Здравствуйте, Ikemefula, Вы писали:
I>Все стандартно — ищется разработчик, опыт такой то, профиль такой то, на проект такой то, специфика такая то, соцпакет, зп, желательные требования — перечень баззвордов.
Есть конторы в Минске в которые соваться себе дороже, может ваша одна из таких?
Здравствуйте, gandjustas, Вы писали:
G>А что ты пытаешься доказать? Что человек, умеющий разворачивать списки фиганет любое решение на sharepoint\crm\1c?
Полное ощущение разговора с глухим.
G>>> У тебя нет ни фактов, ни адекватных доводов. Везде только твое неподкрепленное ничем мнение. НС>>Надо понимать, у тебя есть факты и адекватные доводы? G>Я же говорю — практика и статистика.
Чья практика? Твоя? Почему твоя практика это аргумент, а моя нет?
G>Ты, видимо, работаешь в области, где разворачивать списки нужно и тебе кажется, что это важное умение. G>Я поработал в разных областях и вижу, что оно далеко не везде нужно.
Даже не пытайся, у меня все равно длиннее.
НС>>Почему это? Надо, причем больше — сущностей то в коде больше. G>Не вижу связи. То что сущностей в коде больше не означает, что надо больше держать в голове.
G>>>, и с точки зрения платформы это оптимальный способ. НС>>Нет, не оптимальный, ни по памяти, ни по процессору. Можешь взять и померять, если не веришь.
G>[c#] G>static void Main(string[] args)
Речь, вообще то, шла про разворот списка.
G>>> Статический анализ на сборках sp выдает миллионы замечаний. НС>>FXCop тоже написан индусами G>Дык то не fxcop.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, gandjustas, Вы писали:
G>>Понимание identity? Что это вообще такое? Как выражается?
НС>Почему то я совсем не удивлен.
Ну может ты скажешь формальный критерий "понимания identity"?
Например в том же буче формального определения identity нет. Оно кстати есть в спецификации .NET.
Но вот что означает "понимание" в этом случае?
G>>Вообще читай Design of Design Брукса.
НС>А я бы порекомендовал тебе начать с Гради Буча.
Я его лет 10 назад прочитал, увы не самая достойная книга.
Здравствуйте, Vzhyk, Вы писали:
I>>Все стандартно — ищется разработчик, опыт такой то, профиль такой то, на проект такой то, специфика такая то, соцпакет, зп, желательные требования — перечень баззвордов. V>Есть конторы в Минске в которые соваться себе дороже, может ваша одна из таких?
До недавних пор именно такая и была. Может быть сейчас он и сменил место работы. Поэтому и говорю про недавнее прошлое.
Здравствуйте, Vzhyk, Вы писали:
I>>Все стандартно — ищется разработчик, опыт такой то, профиль такой то, на проект такой то, специфика такая то, соцпакет, зп, желательные требования — перечень баззвордов. V>Есть конторы в Минске в которые соваться себе дороже, может ваша одна из таких?
"соваться себе дороже" это у каждого свои предпочтения. Кому то важна социалка, кому то ЗП, кому то проекты, кому то командировки, кому то проекты, а кому то что бы нихрена не делать.
Тебе однозначно наша контора не подходит, т.к. звуком мы не занимаемся, по крайней мере всерьез
Здравствуйте, Undying, Вы писали:
I>>Я говорю о том, что если хочешь полностью заменить человека, т.е. решать все его задачи так же хорошо как и он, тебе придется потратить столко же времени. По другому не бывает.
U>Т.е. ты утверждаешь, что все люди обучаются с одинаковой скоростью?
В лучшем случае ты затратишь приблизительно такое же время. В худшем — потратишь больше времени или качество работы будет ниже.
U>Что-то повезло мне в топике с собеседниками. Для Ночного смотрящего оказалось новостью, что аналогии между явлениями можно проводить. Ты тоже отжог не хуже.
У тебя что ни сообщение, так смеяться можно до понедельника.
I>>Хочешь опровергнуть — покажи как можно стать уровня гроссов менее чем за 10 лет. Не надо носить рояль, покажи эту серебряную пульку. Ну хотя бы е гроссов, но по ЭЛО что бы было близко.
U>Если тебе так милы гроссмейстеры, то Карякин стал гроссом в 12 лет.
Я знаю еще около трех десятков аналогичных случаев, самый экстремальный — 9 лет, правда игра другая. Все это аномальные результаты. Обычному смертному такое не под силу.
Многие шахматисты до гроссов и за всю жизнь не добираются. Вот так.
U>Тезис о том, что для решения большинства реальных задач найти гроссов не удастся, да и не нужны они в большинстве случаев, ты естественно поскипал.
Гроссы это только пример. Не нрявится гроссы — возьми первый взрослый разряд. Многие и до него не могут добраться за срок более 10 лет.
I>>Знаешь ты критерий Вилкоксона — значит тебе не надо запоминать случаи его применения. U>Проблема в том, что на практике оказывается не нужны ни понимание производной, ни понимание критерия Вилкоксона. Зато нужно понимание других вещей, которым нигде не учат.
"прочитал одну книгу — прочитаешь и другую" — судя по твоим возражениям, с этим высказыванием ты резко не согласен.
I>>Ага, само собой появится в голове знание такое. Пока что нет способа замерить способности, потому проверяют знания и умения. О способностях можно предполагать, если есть хороший период для наблюдения. U>Т.е. ищут не там где потеряли, а там где светло. Замечательный подход.
Да вроде ничего не теряли, наоборот, только и находим
I>>Во, чую, скоро ты выдаешь еще одну новую хронологию терминологию
U>Т.е. ты считаешь, что твоя терминология заведомо правильная? И если собеседумый пользуется другой, то он заведомо не подходит?
Нет никакой моей терминологии, а твоя — в каждом посте.
U>Согласен, что по сравнению со проверкой знаний, задача гораздо лучший метод отбора. Но задача должна быть понятной, несложной, иметь много вариантов решения, оптимальное решение не должно являться обязательным.
Все как раз про реверс и аналогичные задачи. Это понятно, несложно, много вариантов решения, оптимальное необязательно, но наличие такого решения это гигантский плюс, даже два.
U>В том числе и поэтому проверять знания на собеседовании бессмысленно.
Спасибо, капитан.
U>Т.е. ты даешь задачу, основанную на опыте кандидата? Если заявил, что знаток Рихтера, то задачу по Рихтеру? Если так, то это очень правильный подход. Уважаю.
Да, я именно так и даю. Если приходит человек, у которого написано T-SQL в каждом проекте, то я обязательно попрошу это продемонстрировать. И опять же, задача не будет решаться навроде "select * from customers"
Если пришол сиплюсник в прошлом, с большим опытом, то ему придется раскрыть глубину понимания С++ У человека, который позиционирует себя как спец по jQuery я прошу накидать что нибудь простое по jQuery.
Cвою задачу я все равно дам отдельно Собтсвенно я прощаю все мелкие ошибки, неинициализироваными переменными и прочей фигней. Если в проходе по списку потеряется один инкремент, это не страшно, большей частью, если ошибку находит сам кандидат, то это равносильно описке.
Здравствуйте, ambel-vlad, Вы писали:
I>>>Все стандартно — ищется разработчик, опыт такой то, профиль такой то, на проект такой то, специфика такая то, соцпакет, зп, желательные требования — перечень баззвордов. V>>Есть конторы в Минске в которые соваться себе дороже, может ваша одна из таких?
AV>До недавних пор именно такая и была. Может быть сейчас он и сменил место работы. Поэтому и говорю про недавнее прошлое.
Гонишь, как обычно, порожняк.
Контора "именно такая и была" не имела никогда проблем с набором, ЗП и многими другими. Проекты у ней достаточно интересные были, с учетом того что сейчас в Минске 90% проектов это тупо CRUD.
Здравствуйте, gandjustas, Вы писали:
I>>Если буквально — то можно. Любые типы данных можно класть в дерево, даже само дерево можно. Никто не запрещает. I>>Самое главое — не важно, что происходит между загрузкой и конечной обработкой и какие требования кастомера, главное — засунуть в дерево.
G>Ты же хотел сортировку за О(N), я тебе говорю — вставляй в дерево в момент появления данных. Доставать в нужном порядке будешь без дополнительных затрат.
Пудозреваю, баттхерт у тебя случился из за "все данные в памяти" а ты как истинный веб-разработчик точно знаешь что в веб-приложении такого быть не может.
Успойкойся, про веб никто и не говорил, ты сам это додумал.
Итого — твое дерево и обход за O(N) это уже дополнительные затраты, ибо нет никакого дерева, сортировка за линейное время, данные отдаются не за O(N) а за O(1).
Данные в памяти ибо этого требует рендеринг и N других фич, гриды, деревья и прочие вещи, которые используют те же данные, только дают другое представление.
Скажем, типичный сценарий, клик пользователя дает в результате запрос который аффектает 100 тыс основных объектов и юзер получает почти мгновенный отклик во всех вьюшках.
100 тыс и более основных это от 1 млн объектов для рендеринга, они перестраиваются, обновляются и тд, т.к. у многих гарантировано изменится Z-order. Вот из за этого Z-order и нужны оптимизации, что бы рисовать быстрее.
Фокус такой, что объекты не прямоугольные, локальность изменений, как в MsPaint, невозможно обеспечить, отсечения соответсвенно трудоемкие.
Собственно для чего все нужно — пол-секунды на клик можно потратить куда более эффективно, нежели на qsort или твои деревья. Я например нашел оптимизацию, которая сэкономила 200мс на каждый фрейм — радости было как у ребенка, сам себе до сих пор завидую
Здравствуйте, Vzhyk, Вы писали:
I>>Контора "именно такая и была" не имела никогда проблем с набором V>Ты уж определись имела или нет.
Ты AV больше слушай, я, в отличие от него, там работал и трижды возвращался, ибо было зачем и о времени на той конторе не жалею нисколько, ибо было практически все что меня интересовало(и интересует) —
1. проф развитие
2. Интересный проект
3. Толковый менеджмент, QA.
4. ЗП
5. офис, расположение, куча кафешек-столовых в округе
6. свободный график
7. комфортный темп работы, без судорожных хватаний "всё пропало !!!!111расрас"
Скажем у нас всегда было время сделать внятную реализацию, а не лепить непойми что из костылей на скорую руку. Процессы были довольно четко поставлены, особых телодвижений, сверх common sense, не требовалось.
Основной недостаток это сокращения, которые были не раз и не два и контору покинуло очень много толковых людей. Причины в странной продуктовой политике головного руководства, перкос на оптику даже в то время, когда пошел бум на беспроводные технологии.
Были и другие недостатки — проекты узкоспециализированые, много доменной специфики, эту часть опыта очень сложно реюзать в нашей стране.
Ну и если кто не хотел работать, он мог и не работать. Обычно от таких избавлялись, но не всегда вовремя.
Собтсвенно что осталось от конторы — та часть где САПР, физика, математика, лазеры и тд. Консервативное и стабильное направление. Проектирование оптических сетей умерло, т.к. оптика пока что не сильно востребована, а беспроводные сети плохо поддерживаются имеющимися продуктами. Тупо специалисты по оптике это специалисты по оптике, а не по беспроводным технологиям.
Здравствуйте, Ikemefula, Вы писали:
I>Это как раз и требует понимания, что такое ссылки. Скажем ссылка требует уверенного понимания идентити и хотя бы представляения о том, что есть референс тайпы и валюе тайпы.
Чушь.Понимание ссылок не требует ни первого , ни второго. Я со ссылками работал (работал — т.е. понимал, что делал) сильно раньше до того, как начитался про identity и ref/val types.
Здравствуйте, Wolverrum, Вы писали:
I>>Это как раз и требует понимания, что такое ссылки. Скажем ссылка требует уверенного понимания идентити и хотя бы представляения о том, что есть референс тайпы и валюе тайпы.
W>Чушь.Понимание ссылок не требует ни первого , ни второго. Я со ссылками работал (работал — т.е. понимал, что делал) сильно раньше до того, как начитался про identity и ref/val types.
Есть сильные сомнения в этом. Читать про идентити не нужно, нужно показать в коде все свое понимание.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
I>>>Если буквально — то можно. Любые типы данных можно класть в дерево, даже само дерево можно. Никто не запрещает. I>>>Самое главое — не важно, что происходит между загрузкой и конечной обработкой и какие требования кастомера, главное — засунуть в дерево.
G>>Ты же хотел сортировку за О(N), я тебе говорю — вставляй в дерево в момент появления данных. Доставать в нужном порядке будешь без дополнительных затрат.
I>Пудозреваю, баттхерт у тебя случился из за "все данные в памяти" а ты как истинный веб-разработчик точно знаешь что в веб-приложении такого быть не может. I>Успойкойся, про веб никто и не говорил, ты сам это додумал.
С чего ты взял?
I>Итого — твое дерево и обход за O(N) это уже дополнительные затраты, ибо нет никакого дерева, сортировка за линейное время, данные отдаются не за O(N) а за O(1). I>Данные в памяти ибо этого требует рендеринг и N других фич, гриды, деревья и прочие вещи, которые используют те же данные, только дают другое представление.
Отдать N элементов быстрее O(N) никак не выйдет. Или ты о чем-то другом?
Кто мешает иметь и дерево и список одновременно?
I>Скажем, типичный сценарий, клик пользователя дает в результате запрос который аффектает 100 тыс основных объектов и юзер получает почти мгновенный отклик во всех вьюшках. I>100 тыс и более основных это от 1 млн объектов для рендеринга, они перестраиваются, обновляются и тд, т.к. у многих гарантировано изменится Z-order. Вот из за этого Z-order и нужны оптимизации, что бы рисовать быстрее. I>Фокус такой, что объекты не прямоугольные, локальность изменений, как в MsPaint, невозможно обеспечить, отсечения соответсвенно трудоемкие.
Разрешение экрана примерно 2М пикселей, при 1М объектов это 2 пикселя на объект. Видимо не все объекты попадают в область рисования, то есть ты их отсекаешь по каким-либо признакам еще до растериризации.
Самый эффективный способ отсечения — построение дерева по этому признаку, по крайней мере лет 7 назад был, когда я графику изучал.
Вторая оптимизация — создание слоев из несвязанных типов элементов с разной частотой изменений. Это используется повсеместно в ГИСах.
До сих пор ты так и не объяснил почему в твоем случае это не подойдет.
I>Собственно для чего все нужно — пол-секунды на клик можно потратить куда более эффективно, нежели на qsort или твои деревья. Я например нашел оптимизацию, которая сэкономила 200мс на каждый фрейм — радости было как у ребенка, сам себе до сих пор завидую
Ну так расскажи секрет, что за магические оптимизации?
Здравствуйте, gandjustas, Вы писали:
I>>Пудозреваю, баттхерт у тебя случился из за "все данные в памяти" а ты как истинный веб-разработчик точно знаешь что в веб-приложении такого быть не может. I>>Успойкойся, про веб никто и не говорил, ты сам это додумал. G>С чего ты взял?
Интуиция. Веб-разработчики очень предсказуемые, все как один, одно и то же предлагают .
I>>Итого — твое дерево и обход за O(N) это уже дополнительные затраты, ибо нет никакого дерева, сортировка за линейное время, данные отдаются не за O(N) а за O(1). I>>Данные в памяти ибо этого требует рендеринг и N других фич, гриды, деревья и прочие вещи, которые используют те же данные, только дают другое представление. G>Отдать N элементов быстрее O(N) никак не выйдет. Или ты о чем-то другом?
Считай сам — взяли готовые данные и отсортировали коллекцию на месте. Сколько времени займет вернуть эту отсортированую коллекцию ? Я даже не знаю, как надо постараться что бы "return x" стало хуже чем O(1)
G>Кто мешает иметь и дерево и список одновременно?
Время и память. Визуализация и так жрет слишком много памяти и процессора, что бы пихать туда и список и дерево да еще и результат отдавать за O(N) когда само работает за O(1)
I>>Фокус такой, что объекты не прямоугольные, локальность изменений, как в MsPaint, невозможно обеспечить, отсечения соответсвенно трудоемкие. G>Разрешение экрана примерно 2М пикселей, при 1М объектов это 2 пикселя на объект. Видимо не все объекты попадают в область рисования, то есть ты их отсекаешь по каким-либо признакам еще до растериризации.
Разумеется. Сортировка, в частности, так же нужна для всевозможных оптимизаций.
G>Самый эффективный способ отсечения — построение дерева по этому признаку, по крайней мере лет 7 назад был, когда я графику изучал.
Это хорошо работает, когда границы изменений легко локализовать. В противном случае построение дерева превращается в АДъ.
"локальность изменений, как в MsPaint, невозможно обеспечить, отсечения соответсвенно трудоемкие"
G>Вторая оптимизация — создание слоев из несвязанных типов элементов с разной частотой изменений. Это используется повсеместно в ГИСах.
"локальность изменений, как в MsPaint, невозможно обеспечить, отсечения соответсвенно трудоемкие"
Скажем, типичный случай — все объекты связанные и слишком много изменяющихся объектов, т.к. изменения одного распространяются на соседние. В ГИС это мягко говоря нетипичный случай.
G>До сих пор ты так и не объяснил почему в твоем случае это не подойдет.
"локальность изменений, как в MsPaint, невозможно обеспечить, отсечения соответсвенно трудоемкие"
I>>Собственно для чего все нужно — пол-секунды на клик можно потратить куда более эффективно, нежели на qsort или твои деревья. Я например нашел оптимизацию, которая сэкономила 200мс на каждый фрейм — радости было как у ребенка, сам себе до сих пор завидую G>Ну так расскажи секрет, что за магические оптимизации?
Это долго объяснять и к твоему дереву это не имеет отношения.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
I>>>Пудозреваю, баттхерт у тебя случился из за "все данные в памяти" а ты как истинный веб-разработчик точно знаешь что в веб-приложении такого быть не может. I>>>Успойкойся, про веб никто и не говорил, ты сам это додумал. G>>С чего ты взял?
I>Интуиция. Веб-разработчики очень предсказуемые, все как один, одно и то же предлагают .
I>>>Итого — твое дерево и обход за O(N) это уже дополнительные затраты, ибо нет никакого дерева, сортировка за линейное время, данные отдаются не за O(N) а за O(1). I>>>Данные в памяти ибо этого требует рендеринг и N других фич, гриды, деревья и прочие вещи, которые используют те же данные, только дают другое представление. G>>Отдать N элементов быстрее O(N) никак не выйдет. Или ты о чем-то другом?
I>Считай сам — взяли готовые данные и отсортировали коллекцию на месте. Сколько времени займет вернуть эту отсортированую коллекцию ? Я даже не знаю, как надо постараться что бы "return x" стало хуже чем O(1)
Что значит "вернуть коллекцию" ? Если ты её дальше не обрабатываешь, что можно любую возвращать, а если обрабатываешь, то зависит от того как ты это делаешь. А ты опять этот момент пропустил.
G>>Кто мешает иметь и дерево и список одновременно? I>Время и память. Визуализация и так жрет слишком много памяти и процессора, что бы пихать туда и список и дерево да еще и результат отдавать за O(N) когда само работает за O(1)
Памяти мало?
А время на что? У тебя на момент отдачи результата никаких дополнительных действий не происходит.
I>Это хорошо работает, когда границы изменений легко локализовать. В противном случае построение дерева превращается в АДъ. I>"локальность изменений, как в MsPaint, невозможно обеспечить, отсечения соответсвенно трудоемкие"
А тогда как ты выполняешь отсечение? Ты же сортируешь по ключу, вот по этому ключу и построй дерево.
Ты опять что-то не договариваешь.
I>>>Собственно для чего все нужно — пол-секунды на клик можно потратить куда более эффективно, нежели на qsort или твои деревья. Я например нашел оптимизацию, которая сэкономила 200мс на каждый фрейм — радости было как у ребенка, сам себе до сих пор завидую G>>Ну так расскажи секрет, что за магические оптимизации? I>Это долго объяснять и к твоему дереву это не имеет отношения.
Ну не сливайся, хоть раз расскажи что ты делаешь на самом деле то.
Здравствуйте, gandjustas, Вы писали:
I>>Считай сам — взяли готовые данные и отсортировали коллекцию на месте. Сколько времени займет вернуть эту отсортированую коллекцию ? Я даже не знаю, как надо постараться что бы "return x" стало хуже чем O(1)
G>Что значит "вернуть коллекцию" ? Если ты её дальше не обрабатываешь, что можно любую возвращать, а если обрабатываешь, то зависит от того как ты это делаешь. А ты опять этот момент пропустил.
Не пропустил, а указал ограничения. Не важно, что дальше, важно какие ограничения на входе-выходе.
G>>>Кто мешает иметь и дерево и список одновременно? I>>Время и память. Визуализация и так жрет слишком много памяти и процессора, что бы пихать туда и список и дерево да еще и результат отдавать за O(N) когда само работает за O(1) G>Памяти мало?
И это очевидно, более того, я тебе постоянно про это говорю.
G>А время на что? У тебя на момент отдачи результата никаких дополнительных действий не происходит.
Время на все — от подготовки данных до рендеринга примитивов.
I>>Это хорошо работает, когда границы изменений легко локализовать. В противном случае построение дерева превращается в АДъ. I>>"локальность изменений, как в MsPaint, невозможно обеспечить, отсечения соответсвенно трудоемкие" G>А тогда как ты выполняешь отсечение? Ты же сортируешь по ключу, вот по этому ключу и построй дерево.
Ты лучше расскажи на примере, как ты собираешься это дерево использовать. Пудозреваю, ты имеешь в виду какой то книжный алгоритм, заточеный под трассировку лучей для случая, когда области можно легко изолировать.
G>>>Ну так расскажи секрет, что за магические оптимизации? I>>Это долго объяснять и к твоему дереву это не имеет отношения. G>Ну не сливайся, хоть раз расскажи что ты делаешь на самом деле то.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
I>>>Считай сам — взяли готовые данные и отсортировали коллекцию на месте. Сколько времени займет вернуть эту отсортированую коллекцию ? Я даже не знаю, как надо постараться что бы "return x" стало хуже чем O(1)
G>>Что значит "вернуть коллекцию" ? Если ты её дальше не обрабатываешь, что можно любую возвращать, а если обрабатываешь, то зависит от того как ты это делаешь. А ты опять этот момент пропустил.
I>Не пропустил, а указал ограничения. Не важно, что дальше, важно какие ограничения на входе-выходе.
Это ты уже вилять начинаешь. Если тебя интересует быстродействие, то нельзя заниматься локальной оптимизацией.
Как все таки массив обрабатываться будет?
G>>>>Кто мешает иметь и дерево и список одновременно? I>>>Время и память. Визуализация и так жрет слишком много памяти и процессора, что бы пихать туда и список и дерево да еще и результат отдавать за O(N) когда само работает за O(1) G>>Памяти мало? I>И это очевидно, более того, я тебе постоянно про это говорю.
Но как-бы тебе никто не верит. На современном компе сложно забить память. Представим даже что у тебя 1М элементов, каждый по 100 байт. Это всего 100мб.
Даже если ты построишь индексы, типа древовидные, то это еще 50 мб даст.
G>>А время на что? У тебя на момент отдачи результата никаких дополнительных действий не происходит. I>Время на все — от подготовки данных до рендеринга примитивов.
Готовь данные заранее, вставляй в отсортированное дерево.
I>>>Это хорошо работает, когда границы изменений легко локализовать. В противном случае построение дерева превращается в АДъ. I>>>"локальность изменений, как в MsPaint, невозможно обеспечить, отсечения соответсвенно трудоемкие" G>>А тогда как ты выполняешь отсечение? Ты же сортируешь по ключу, вот по этому ключу и построй дерево. I>Ты лучше расскажи на примере, как ты собираешься это дерево использовать. Пудозреваю, ты имеешь в виду какой то книжный алгоритм, заточеный под трассировку лучей для случая, когда области можно легко изолировать.
Сначала ты скажи как твой отсортированный массив обрабатывается, скорее всего за o(N). Потом я тебе покажу как это положить на дерево за o(log n).
G>>>>Ну так расскажи секрет, что за магические оптимизации? I>>>Это долго объяснять и к твоему дереву это не имеет отношения. G>>Ну не сливайся, хоть раз расскажи что ты делаешь на самом деле то. I>Уже все что надо было сказано.
Ну конечно, потому что сказать еще немного и все твои позиции рассыпятся
Здравствуйте, gandjustas, Вы писали:
I>>Не пропустил, а указал ограничения. Не важно, что дальше, важно какие ограничения на входе-выходе. G>Это ты уже вилять начинаешь. Если тебя интересует быстродействие, то нельзя заниматься локальной оптимизацией.
Спасибо капитан.
G>Как все таки массив обрабатываться будет?
Не важно.
I>>И это очевидно, более того, я тебе постоянно про это говорю. G>Но как-бы тебе никто не верит. На современном компе сложно забить память. Представим даже что у тебя 1М элементов, каждый по 100 байт. Это всего 100мб.
Ты похоже читаешь как то по особенному. Я говорю, что памяти мало и не хватает, а ты придумал себе непойми что.
G>Даже если ты построишь индексы, типа древовидные, то это еще 50 мб даст.
А если бы ты спросил про количество объектов, то узнал бы, что всего в памяти 3..30 млн объектов. Это, в частности, означает, что 8-байтный хедер который есть у всех объектов, займет 24..240мб.
G>>>А время на что? У тебя на момент отдачи результата никаких дополнительных действий не происходит. I>>Время на все — от подготовки данных до рендеринга примитивов. G>Готовь данные заранее, вставляй в отсортированное дерево.
Они и так заранее готовятся. Не ясно, какой профит от дерева.
I>>Ты лучше расскажи на примере, как ты собираешься это дерево использовать. Пудозреваю, ты имеешь в виду какой то книжный алгоритм, заточеный под трассировку лучей для случая, когда области можно легко изолировать. G>Сначала ты скажи как твой отсортированный массив обрабатывается, скорее всего за o(N). Потом я тебе покажу как это положить на дерево за o(log n).
Примерно так — самые большие операции это генерация примитивов и отсечение самих примитивов. Где ты тут хочешь log n всунуть, мне, честно говоря, совершенно непонятно.
I>>Уже все что надо было сказано. G>Ну конечно, потому что сказать еще немного и все твои позиции рассыпятся
Это вряд ли — первый раз вижу такого кадра, который не интересуется ни объемом данных, ни ограничениями, ни показниями профайлера, но уверен, что знает лучше.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
G>>Как все таки массив обрабатываться будет? I>Не важно.
Вообще-то важно, если мы об оптимзации.
I>>>И это очевидно, более того, я тебе постоянно про это говорю. G>>Но как-бы тебе никто не верит. На современном компе сложно забить память. Представим даже что у тебя 1М элементов, каждый по 100 байт. Это всего 100мб. I>Ты похоже читаешь как то по особенному. Я говорю, что памяти мало и не хватает, а ты придумал себе непойми что.
Ну то что ты говоришь еще не значит что правда. Скорее наоборот.
Приведи факты: такая-то структура, столько то экземпляров, на таких-то устройствах работает.
А так ты рассказываешь про сферическую сортировку в вакууме.
G>>Даже если ты построишь индексы, типа древовидные, то это еще 50 мб даст. I>А если бы ты спросил про количество объектов, то узнал бы, что всего в памяти 3..30 млн объектов. Это, в частности, означает, что 8-байтный хедер который есть у всех объектов, займет 24..240мб.
О как... А зачем столько объектов в памяти? Если попытаться отрисовать все, то выйдет меньше пикселя на объект. Получается что большая часть из них будет очень редко попадать в отрисовку, а следовательно нет смысла держать в памяти все миллионы.
G>>>>А время на что? У тебя на момент отдачи результата никаких дополнительных действий не происходит. I>>>Время на все — от подготовки данных до рендеринга примитивов. G>>Готовь данные заранее, вставляй в отсортированное дерево. I>Они и так заранее готовятся. Не ясно, какой профит от дерева.
Ну так ты расскажи что дальше с массивом происходит и сразу станет ясно
I>>>Ты лучше расскажи на примере, как ты собираешься это дерево использовать. Пудозреваю, ты имеешь в виду какой то книжный алгоритм, заточеный под трассировку лучей для случая, когда области можно легко изолировать. G>>Сначала ты скажи как твой отсортированный массив обрабатывается, скорее всего за o(N). Потом я тебе покажу как это положить на дерево за o(log n). I>Примерно так — самые большие операции это генерация примитивов и отсечение самих примитивов. Где ты тут хочешь log n всунуть, мне, честно говоря, совершенно непонятно.
Ну если отсекать по упорядоченному дереву, то будет logn, вместо n.
I>>>Уже все что надо было сказано. G>>Ну конечно, потому что сказать еще немного и все твои позиции рассыпятся I>Это вряд ли — первый раз вижу такого кадра, который не интересуется ни объемом данных, ни ограничениями, ни показниями профайлера, но уверен, что знает лучше.
Ты от зеркала отвернись и прочитай сообщения. Я тебя прямо спрашивал про данные и алгоритм обработки. Ты только сверическую сортировку в вакууме привел.
Здравствуйте, gandjustas, Вы писали:
I>>Не важно. G>Вообще-то важно, если мы об оптимзации.
Я уже сказал — генерация примитивов и отсечение.
I>>Ты похоже читаешь как то по особенному. Я говорю, что памяти мало и не хватает, а ты придумал себе непойми что. G>Ну то что ты говоришь еще не значит что правда. Скорее наоборот.
Не пойму только, чего ты никак не угомонишься, если склоняешься к тому, что я тебе неправду всяку излагаю. Фетиш у тебя такой что ли ?
Извини, дальше буду отвечать только те, на которые мне будет интересно, ибо смысла нет раз уж "не значит что правда. Скорее наоборот"
G>О как... А зачем столько объектов в памяти? Если попытаться отрисовать все, то выйдет меньше пикселя на объект. Получается что большая часть из них будет очень редко попадать в отрисовку, а следовательно нет смысла держать в памяти все миллионы.
Спасибо, капитан. Ты похоже забыл, что визуализация не единственное, чем занято приложение. Объектов для визуализации где то около 500тыс, в основном потому, что они имеют сложную структуру, каждый объект состоит из 4-5 мелких. Все возможные упаковки, включая штук 30 битовых флагов, уже сделаны. Все что можно было, сделано структурами для экономии 8байт хедера.
Что это в кратце означает — памятью кидаться нельзя и расход памяти должен быть обоснован. 2е GC работает в наиболе неудобном режиме, все объекты в Gen2. 3е — фрагментация никуда не делась, а следовательно менее жрущий алоритм выгоднее более жрущего.
Дерево которое ты предлагаешь, вынудит GC выделить целый хип под него. Сравнивая с нулевым расходом памяти при моей сортировке хочет ОЧЕНЬ большого профита от дерева.
G>>>Сначала ты скажи как твой отсортированный массив обрабатывается, скорее всего за o(N). Потом я тебе покажу как это положить на дерево за o(log n). I>>Примерно так — самые большие операции это генерация примитивов и отсечение самих примитивов. Где ты тут хочешь log n всунуть, мне, честно говоря, совершенно непонятно. G>Ну если отсекать по упорядоченному дереву, то будет logn, вместо n.
Отсекается не по приоритету, а в основном по координатам. Для чего нужа сортировка я уже говорил, вообще говоря.
Итого — где профит от дерева, не ясно.
I>>>>Уже все что надо было сказано. G>>>Ну конечно, потому что сказать еще немного и все твои позиции рассыпятся I>>Это вряд ли — первый раз вижу такого кадра, который не интересуется ни объемом данных, ни ограничениями, ни показниями профайлера, но уверен, что знает лучше. G>Ты от зеркала отвернись и прочитай сообщения. Я тебя прямо спрашивал про данные и алгоритм обработки. Ты только сверическую сортировку в вакууме привел.
Да, на второй неделе тёрок ты, наконец, начал задавать кое какие вопросы, признаю.
НС>Ну попробуй тогда обосновать свое решение. Сколько проходов, какая сложность, есть ли ограничения на длину цепочки.
Для начала он вообще не решил твою задачу. Вместо переворота списка на месте, он показал, как на константном списке выдать имена узлов в обратном порядке...
Кстати, а решение с разворачивающейся в цикл хвостовой рекурсией примешь?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
НС>var head = ...;
НС>var current = head;
НС>var list = new List<Item>();
НС>while (current != null)
НС>{
НС> list.Add(current);
НС> current = current.Next;
НС>}
НС>list.Reverse();
НС>for (int i = 0; i < list.Count - 1; i++)
НС> list[i].Next = list[i + 1];
НС>list[list.Count - 1].Next = null;
НС>
НС>Этим гугль не поможет, они и рабочий код будут писать по принципу "фигли тут думать, трясти надо".
С другой стороны, во многих случаях, этот код и есть правильный.
Он надёжный, безопасный, по времени всего в два раза хуже правильного, по памяти, да, тратит пропорционально длине списка, конечно, но если это не гигабайты, то и пофигу часто, зато просто, прямо, на неизменяемых данных каждый шаг из двух делаем...
Поддержка опять же прямее...
Так то это, в современных критериях, -- хороший код!
А разворот списка на месте -- неготовая к исключениям и непотокобезопасная преждевременная оптимизация таки... Так что тут надо тщательнее смотреть что кто как и почему программирует-то...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Undying, Вы писали:
U>Есть подозрение, что вероятность этого худшего случая на большой коллекции данных пренебрежимо мала.
Во-первых, у тебя может так оказаться, что твои данные не случайные...
Во-вторых, если у одного из 1000 клиентов твоя программа будет таки уходить в тормоза на пару часиков, то слава "негодного глюкала" твоему продукту обеспечена
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Ikemefula, Вы писали:
I>Ты похоже не слышишь, что я говорю. Нет необходимости в таких спецах, если у тебя есть некотрая база. Если хорошо понимаешь, что такое "разделяй и властвуй", то легкой поймешь любой алгоритм и сможешь проанализировать его. Еще раз — любой.
Что, правда что ли? Расскажи нам на базе "разделяй и властвуй", почему работает генетическая диф. эволюция например?..
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Undying, Вы писали:
U>Т.е. проблемой проверки конкретного понимания на собеседовании является то, что невозможно понять почему человек не понимает какой-то принцип: 1) из-за того, что у него способностей 2) из-за того, что у вас просто разная терминология 3) из-за того, что человек с такими задачами не сталкивался
Дык можно же ему подсказывать. Типа видим, что задача для него нова, и пробуем ему её помочь решить в диалоге. Пусть он покажет вам, как он сможет учиться у вас...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Ikemefula, Вы писали:
I>Ты сначала говорил про какую то статистику, а теперь оказывается, что статистики у тебя нет
Вроде что-то в код комлите такое упоминалось...
Впрочем ты можешь взять базу багов за последний год, например, или там ещё какой период, выбрать багов 500 и быстренько поклассифицировать в типовом коде они были или нет, потом сопоставить скока того и другого у вас есть и прикинуть правда это или нет ДЛЯ ВАШИХ УСЛОВИЙ...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Вроде что-то в код комлите такое упоминалось...
E>Впрочем ты можешь взять базу багов за последний год, например, или там ещё какой период, выбрать багов 500 и быстренько поклассифицировать в типовом коде они были или нет, потом сопоставить скока того и другого у вас есть и прикинуть правда это или нет ДЛЯ ВАШИХ УСЛОВИЙ...
При равном выходном качестве нужно сравнить время на разработку, которое, вобщем, сильно зависит от количества багов. Покажи базу багов которая даст такую инфу.
Здравствуйте, Erop, Вы писали:
E>С другой стороны, во многих случаях, этот код и есть правильный.
Смотря с какой стороны правильность мерять. С тз. "вот код, только отъ..сь", то это почти абсолютно правильный, почти идеальный код.
E>Он надёжный, безопасный, по времени всего в два раза хуже правильного, по памяти, да, тратит пропорционально длине списка, конечно, но если это не гигабайты, то и пофигу часто, зато просто, прямо, на неизменяемых данных каждый шаг из двух делаем...
Этот код страшен, как пивной бодун Он длинный и сложнее более короткого варианта, с перестановкой на месте.
Проще == лучше, особенно, если ты в команде а не сам по себе.
E>Поддержка опять же прямее...
Где именно прямее ? Два цикла вместо одного и ровно те же приседания с индексами и ссылками ?
E>Так то это, в современных критериях, -- хороший код! E>А разворот списка на месте -- неготовая к исключениям и непотокобезопасная преждевременная оптимизация таки... Так что тут надо тщательнее смотреть что кто как и почему программирует-то...
Код который тебе понравился такой же неготовый к исключением и непотокобезопасный, только длиннее, сложнее и ест память.
Здравствуйте, Ikemefula, Вы писали:
I>При равном выходном качестве нужно сравнить время на разработку, которое, вобщем, сильно зависит от количества багов. Покажи базу багов которая даст такую инфу.
Я думаю, что твой оппонент имел в виду число багов в уже разработанном и закомиченном коде, а не во время разработки. Понятно, что если разрабатывают что-то нестандартное, то будет куча всего, в том числе и "планово неработоспособные эксперименты", например, но число багов в коде, про который разработчик сказал : "оно готово" определяется иными причинами...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, Ikemefula, Вы писали:
I>>При равном выходном качестве нужно сравнить время на разработку, которое, вобщем, сильно зависит от количества багов. Покажи базу багов которая даст такую инфу.
E>Я думаю, что твой оппонент имел в виду число багов в уже разработанном и закомиченном коде, а не во время разработки.
И это неправильно, т.к. время расходуется в основном пропорционально количеству ошибок.
>Понятно, что если разрабатывают что-то нестандартное, то будет куча всего, в том числе и "планово неработоспособные эксперименты", например, но число багов в коде, про который разработчик сказал : "оно готово" определяется иными причинами...
Не причины другие, а причин больше. Новую задачу не всегда очевидно, как покрыть тестами, а для типового кода все ясно. Ограничения для новой задачи не всегда очевидно или формализованы. Внезапно — работы тупо стало больше, хотя итоговое решение может быть и короче чем в типовой задаче и это не факт, что ошибок будет хотя бы столько же или меньше.
Здравствуйте, Ikemefula, Вы писали:
I>Не причины другие, а причин больше. Новую задачу не всегда очевидно, как покрыть тестами, а для типового кода все ясно. Ограничения для новой задачи не всегда очевидно или формализованы. Внезапно — работы тупо стало больше, хотя итоговое решение может быть и короче чем в типовой задаче и это не факт, что ошибок будет хотя бы столько же или меньше.
Он говорит о другом. Что если код долго живёт, то цена поддержки очень большая, и она мало зависит от того, нужны ли были исследования при разработке этого конкретного куска кода или он был "типовым", если, конечно, всё делать одинаково качественно...
Впрочем лучше спросить у него.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Ikemefula, Вы писали:
I>Код который тебе понравился такой же неготовый к исключением и непотокобезопасный, только длиннее, сложнее и ест память.
1) Если есть такое требование, его проще сделать безопасным.
2) Мутабельные данные вообще по природе своей ограничивают потоко-безопасность и готовность к исключениям. Так что сама поставновка задачи не того.
Мы же подход человека хотим протестить? И подход "в каждом месте пилим максимально эффективный хитрый/неочевидный код" против "пытаемся писать максимально стандартно, а мудрим там, где скажет профайлер" не факт что самый общепринятый...
Я бы, как минимум, если бы просил людей разворачивать списки, явно указал бы, что надо без памяти и быстро Или хотя бы что по возможности так.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
I>>Код который тебе понравился такой же неготовый к исключением и непотокобезопасный, только длиннее, сложнее и ест память.
E>1) Если есть такое требование, его проще сделать безопасным.
Если ты начал реализовывать такие требования не прояснив актуальность то тебе в дверь для джуниоров.
E>2) Мутабельные данные вообще по природе своей ограничивают потоко-безопасность и готовность к исключениям. Так что сама поставновка задачи не того.
А задать вопрос на собеседовании религия мешает ? Или же тебя религия заставляет писать только максимально потокобезопасный код устойчивй к любым сбоям, даже если это не требуется ?
E>Мы же подход человека хотим протестить? И подход "в каждом месте пилим максимально эффективный хитрый/неочевидный код" против "пытаемся писать максимально стандартно, а мудрим там, где скажет профайлер" не факт что самый общепринятый...
Нет, мы сравниваем "пилим любой, который пришел в голову, код, не пытаясь думать" против "минимально необходимый, простой и понятный код"
E>Я бы, как минимум, если бы просил людей разворачивать списки, явно указал бы, что надо без памяти и быстро Или хотя бы что по возможности так.
И тем самым ты понизишь уровень задачи ниже плинтуса.
Здравствуйте, Ikemefula, Вы писали:
I>А задать вопрос на собеседовании религия мешает ? Или же тебя религия заставляет писать только максимально потокобезопасный код устойчивй к любым сбоям, даже если это не требуется ?
Ну вы же с НС ждёте от чего-то максимально эффективного? Откуда известно, что именно его?..
Я бы, кстати, по умолчании, дал бы тот ответ, который ждал НС, но его логика, что дубовое решение плохое, а хитрое нет мне не ясна. Если считать, что это головоломка то понятно, что вряд ли тупое решение просят, если это реальный код, то всё от целей зависит...
I>Нет, мы сравниваем "пилим любой, который пришел в голову, код, не пытаясь думать" против "минимально необходимый, простой и понятный код"
Второе значительно дороже в разработке, а часто ещё и в поддержке...
Кстати обе обсуждаемые версии простые и понятные, так, которая вам не нравится, даже понятнее, IMHO...
Мало того, она легко обощается на любую перестановку элементов, скажем отсортировать так тоже можно так же трудно будет...
I>И тем самым ты понизишь уровень задачи ниже плинтуса.
Ну иначе это тест на телепалку, а не на навыки программирования.
И тот и другой код хорош, просто для разных целей. Ваши цели известны тока вам, пока вы их не озвучили...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Vzhyk, Вы писали:
V>Слушайте, не надоело еще? V>Все определяется только одним, предложением программистов и спросом на них. Сейчас спрос меньше предложения, по крайней мере в Минске. Отсюда работодатель может как угодно развлекаться, когда набирает народ. V>Было бы наоборот, не до развлечения с соискателями было бы, брали бы тех, кто хоть что-то умеет и доучивали бы.
Так и делаем — берем и доучиваем. Но отфильтровать людей которые не хотят включать голову, не мешает. Если люди не включают голову на простых вещах, то странно ждать, что она включится на сложных.
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, Ikemefula, Вы писали:
I>>А задать вопрос на собеседовании религия мешает ? Или же тебя религия заставляет писать только максимально потокобезопасный код устойчивй к любым сбоям, даже если это не требуется ?
E>Ну вы же с НС ждёте от чего-то максимально эффективного?
Кто тебе такое сказал ? Я так понимаю, если товарищ напишет тебе сортировку за O(N^3) или O(N!), ты этот код одобриши на том основании, что не было никаких требований про производительность ?
I>>Нет, мы сравниваем "пилим любой, который пришел в голову, код, не пытаясь думать" против "минимально необходимый, простой и понятный код"
E>Второе значительно дороже в разработке, а часто ещё и в поддержке...
Ну да, простыни легче и дешевле майнтейнить, ога
I>>И тем самым ты понизишь уровень задачи ниже плинтуса.
E>Ну иначе это тест на телепалку, а не на навыки программирования. E>И тот и другой код хорош, просто для разных целей. Ваши цели известны тока вам, пока вы их не озвучили...
Если девелопер не умеет задавать вопросов, он или джуниор, или никому не нужен.
Здравствуйте, Ikemefula, Вы писали:
I>Так и делаем — берем и доучиваем. Но отфильтровать людей которые не хотят включать голову, не мешает. Если люди не включают голову на простых вещах, то странно ждать, что она включится на сложных.
О боже. Не программисты — это странный народ. Вот один из них уже научился определять, что человек включает или выключает голову. Ты фильмов в зомби не пересмотрел?
З.Ы. А вообще от такого бреда про включение/выключение головы уже не смеяться, а плакать хочется. Все что вы делаете — это придумываете себе деятельность, которая по сути является киданием монетки, но с учетом, что тебе нравятся случаи, когда монетка падает вверх решкой.
Здравствуйте, Vzhyk, Вы писали:
V>З.Ы. А вообще от такого бреда про включение/выключение головы уже не смеяться, а плакать хочется. Все что вы делаете — это придумываете себе деятельность, которая по сути является киданием монетки, но с учетом, что тебе нравятся случаи, когда монетка падает вверх решкой.
Предложи хороший способ проверить умения, кроме как задачей. Про монетки не надо рассказывать, выдай уже эту серебряную пульку.
Здравствуйте, Ikemefula, Вы писали:
E>>Ну вы же с НС ждёте от чего-то максимально эффективного?
I>Кто тебе такое сказал ?
Ну то решение, которое не нравится НС, если его сделать более или менее по уму, оно всего в два раза медленнее + одна-две аллокации под буфер массива, что на GC полная фигня, как бы...
E>>Я так понимаю, если товарищ напишет тебе сортировку за O(N^3) или O(N!), ты этот код одобриши на том основании, что не было никаких требований про производительность ?
Нет. Не одобрю. Это очень плохой показатель, а у обсуждаемого "неправильного" кода, показатели-то не такие уж и плохие же. Просто тратит память, но не факт, что это проблема.
Да, и сортировку пузырьком, если не просил чего-то иного я приму, но спрошу, как селать быстрее.
I>Ну да, простыни легче и дешевле майнтейнить, ога
Почему простыни? Там всего два простых цикла.
Скопировали туда, а потом обратно.
Мало того, представь, что завтра надо буде не обращать порядок, а, например положить сначала все чётные, а потом все нечётные, как будешь править тот и как иной вариант?..
I>Если девелопер не умеет задавать вопросов, он или джуниор, или никому не нужен.
не никому, а вам...
Я, же, собственно, про это уже писал, что давая такие мутные задания, ты предоставляешь грамотному соискателю показать тебе тот или иной подход ПО ЕГО ВЫБОРУ, что легко может привести к тому, что ты пропустишь способного человека, а их реально мало, в отличии от придурков, которые могут обратить список хот так, хоть сяк
Ну то есть ты оптимизируешь тест так, что типа умный его скорее пройдёт, а глупый скорее нет, а лучше, ну во всяком случаее с моей т. з., оптимизировать так, что бы умных не терять. Дураков можно отфильтровать многиме способами же, не на этом сфейлится, так на ином. Если твоя цель найти тех, кто в принципе не умеет решать такие задачи, то сразу так и говори, что хочу без доп. памяти, а если тех, кто не знает что вам надо и гадает, то ты всё правильно делаешь Только это всё те же самые головоломки, тока в профиль, неэффективности которых для набора программистов и посвящено стартовое сообщенеи темы
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
I>Предложи хороший способ проверить умения, кроме как задачей. Про монетки не надо рассказывать, выдай уже эту серебряную пульку.
Да нет ее, этой серебряной пульки, нет, вообще нет, не существует и существовать не может.
Но ты уж определись, что ты проверяешь умения или включение/выключение головы (так и хочется добавить — молотком).
НС>Ни в каком случае этот код не есть правильный.
Это очень сложный вопрос. От целей и задач зависит.
Вот, например, давай я задам тебе похожую, но другую задачу? Она ещё и зания алгоритмов будет тестить за одно?
Есть твой список и надо его на месте отсортировать...
Я бы вот принял и правильное решение в духе, делаем массив ссылок, сортируем, потом делаем из него список, и в духе сортируем на месте сляиниями, например. А ты?..
//----------
E>>А разворот списка на месте -- неготовая к исключениям и непотокобезопасная преждевременная оптимизация таки...
НС>Это не оптимизация, а при чем тут потокобезопасность вообще непонятно.
Ну, как бы вот представь, что на предыдущем собеседовании нормального кандидата завернули на том, что он пишет непотокобезопасно, например...
В целом это был пример варианта обоснованой негативной оценки твоего решения и твоего задания.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>1) Если есть такое требование, его проще сделать безопасным.
Безопасным относительно чего? Сам по себе метод вполне безопасен, так как не использует внешнее состояние совсем.
E>2) Мутабельные данные вообще по природе своей ограничивают потоко-безопасность и готовность к исключениям. Так что сама поставновка задачи не того.
Какой такой задачи? О чем ты?
E>Мы же подход человека хотим протестить? И подход "в каждом месте пилим максимально эффективный хитрый/неочевидный код" против "пытаемся писать максимально стандартно, а мудрим там, где скажет профайлер" не факт что самый общепринятый...
Правильный ответ, он не только сильно лучше по процессору и памяти, он еще и самый простой.
Здравствуйте, Erop, Вы писали:
E>Ну вы же с НС ждёте от чего-то максимально эффективного?
Ничего подобного я не жду. Я жду другого — умения работать со ссылками, я это уже миллион раз в топике написал. На эффективность мне, вобщем то, плевать. Единственная причина, почему пишут тот код, что я привел выше, это то что человек не может или не умеет с этими ссылками работать.
E>Я бы, кстати, по умолчании, дал бы тот ответ, который ждал НС
И любой вменяемый программист тоже.
I>>Нет, мы сравниваем "пилим любой, который пришел в голову, код, не пытаясь думать" против "минимально необходимый, простой и понятный код" E>Второе значительно дороже в разработке, а часто ещё и в поддержке...
Обоснуй.
E>Кстати обе обсуждаемые версии простые и понятные, так, которая вам не нравится, даже понятнее, IMHO...
НС>Безопасным относительно чего? Сам по себе метод вполне безопасен, так как не использует внешнее состояние совсем.
относительно многопоточного окружения. Пока ты там крутишь свой разобранный список из другого потока его могут попробовать почитать...
НС>Какой такой задачи? О чем ты?
Твоей, про "перевернуть на месте"..
НС>Правильный ответ, он не только сильно лучше по процессору и памяти, он еще и самый простой.
По процессору он лучше раза в два примерно по памяти да, но не понятно дорого ли это.
Про "самый простой" не согласен.
Проведи два теста.
1) Посмотри насколько низкий уровень требуется что бы породить/понять "правильный" и "неправильный"
2) Давай нам надо мнемного модифицировать задание? Пусть перевернуть порядок следования надо не у всех элементов, а только у каждого второго, или не более, чем у первых 10... Какой из вариантов кода легче модифицировать?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Ничего подобного я не жду. Я жду другого — умения работать со ссылками, я это уже миллион раз в топике написал. На эффективность мне, вобщем то, плевать. Единственная причина, почему пишут тот код, что я привел выше, это то что человек не может или не умеет с этими ссылками работать.
Как ты проверял это утверждение?
I>>>Нет, мы сравниваем "пилим любой, который пришел в голову, код, не пытаясь думать" против "минимально необходимый, простой и понятный код" E>>Второе значительно дороже в разработке, а часто ещё и в поддержке...
НС>Обоснуй.
Ну "думать" вообщедорого. Мало того, потом тому, кто поддерживает тоже каждый раз надо не только подумать, но ещё и не забыть это сделать, кстати. Это всё непосредственно дороже в баксах в час, и в часах, часто, тоже.
Я уже предложил рассмотреть варианты модификации того и другог кода в будующем, ну если вдруг понадобится немного поменять поведение
E>>Кстати обе обсуждаемые версии простые и понятные, так, которая вам не нравится, даже понятнее, IMHO...
НС>Обоснуй.
Ну так ты сам считаешь, что уровень программиста для понимания нужен ниже, значит код проще...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Ночной Смотрящий, Вы писали:
E>>Вот, например, давай я задам тебе похожую, но другую задачу? НС>Зачем?
Ну про ту ты уже как бы подумал, всё решил и тебе психологически трудно пересмотреть свои оценки. на другой хадаче ты сможешь рассуждать с чистого листа и тебе легче будет быть объективным...
E>>Есть твой список и надо его на месте отсортировать... НС>Это существенно сложнее. С таким на собеседовании уже 99% не справятся.
Ну вот ты справишься, например? Хотя бы неприятным тебе способом?..
если да, то таки тот способ проще и технологичнее и масштабируется, в отличии от твоего "правильного"...
E>>Я бы вот принял и правильное решение в духе, делаем массив ссылок, сортируем, потом делаем из него список, и в духе сортируем на месте сляиниями, например. А ты?..
НС>А я не люблю доказательства по аналогии.
При чём тут аналогии? Я утверждаю простой факт, что если нам надо что-то соорудить с односвязанным списком, то решение "копируем всё в массив, там переставляем как просят и копируем обратно" намного более регулярное простое и масштабируемое, чем "придумываем алгоритм по месту". При этом оно ещё и не дорогое, к тому же по скорости, и не безумно дорогое по памяти.
Для каких-то задачек на перестановку списка простой алгоритм по месту напишется, для каких-то нет, это надо проверять, думать, потом каждую модификацию правил перестановки надо опять изучать и думать. Вопрос, чем это отличается от всяких других сценариев преждевременной оптимизации?
Я в целом не люблю вопросы-ловушки, так как они делают ситуацию собеселования конфликтой. Если бы ты сразу просил типа без доп. памяти, и каждую ссылку менять можно тока один раз, то это было бы прямее... Это был бы честный тест понимает соискатель концепию ссылок или нет, а так какая-то мерзкая угадайка выходит и вкусовщина.
НС>Зачем мне это представлять? Ты пытаешься довести до абсурда, но цель этого непонятна.
Я указал на два, на мой взгялд, неверных у тебя предположения.
1) Что код с промежуточным массивом однозначно хуже.
2) Что задавая соискателю вопросы надо скрывать от него чего мы от него ждём.
и пытаюсь их тебе обосновать.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
I>>Кто тебе такое сказал ? E>Ну то решение, которое не нравится НС, если его сделать более или менее по уму, оно всего в два раза медленнее + одна-две аллокации под буфер массива, что на GC полная фигня, как бы...
Здравствуйте, Erop, Вы писали:
E>на другой хадаче ты сможешь рассуждать с чистого листа и тебе легче будет быть объективным...
Ты, кажется, не понял — такая задача подобрана специально, на другой задаче все по другому.
E>>>Есть твой список и надо его на месте отсортировать... НС>>Это существенно сложнее. С таким на собеседовании уже 99% не справятся. E>Ну вот ты справишься, например?
Справлюсь. Дальше то что?
E> Хотя бы неприятным тебе способом?..
У меня нет неприятных способов.
E>если да, то таки тот способ проще и технологичнее и масштабируется, в отличии от твоего "правильного"...
Какой тот?
НС>>А я не люблю доказательства по аналогии. E>При чём тут аналогии?
При том что другая задача это другая задача, и что бы ты по другой задаче не доказал, к обсуждаемой это никакого отношения не имеет.
E>Я в целом не люблю вопросы-ловушки
Обсуждаемая задача это не вопрос-ловушка. Ловушки это ваши гномики и лампочки, которых на собеседовании спрашивают даже у людей, которые устраиваются на позиции архитектов или менеджеров. А здесь прямая демонстрация того как человек мыслит.
E>Если бы ты сразу просил типа без доп. памяти
А с чего ты взял, что не просят? Я где то такое писал?
E>, и каждую ссылку менять можно тока один раз
Этого требования вообще нет.
E>1) Что код с промежуточным массивом однозначно хуже.
Да, он однозначно хуже. И другая задача в этом плане ничего не доказывает.
E>2) Что задавая соискателю вопросы надо скрывать от него чего мы от него ждём.
Опять ты со своими фантазиями споришь. Никто ничего не скрывает.
Здравствуйте, Erop, Вы писали:
E>Как ты проверял это утверждение?
По коду это хорошо видно.
E>>>Второе значительно дороже в разработке, а часто ещё и в поддержке... НС>>Обоснуй. E>Ну "думать" вообщедорого.
За это программистам, собственно, и платят. Код, который написали не думая, почти всегда приходится переписывать почти полностью. Но особенно смешно это выглядит на собеседовании, где явно проверяют как раз умение думать.
>Это всё непосредственно дороже в баксах в час, и в часах, часто, тоже.
Дороже, это когда куча наколбашенного кода плодит стадо багов, а отрефакторить все это гавно крайне тяжело.
E>Я уже предложил рассмотреть варианты модификации того и другог кода в будующем, ну если вдруг понадобится немного поменять поведение
Это совсем совсем другой скилл, и его надо совсем другими задачками и вопросами проверять.
E>>>Кстати обе обсуждаемые версии простые и понятные, так, которая вам не нравится, даже понятнее, IMHO... НС>>Обоснуй. E>Ну так ты сам считаешь, что уровень программиста для понимания нужен ниже, значит код проще...
Нет, не значит. Иммутабельный код, к примеру, обычно проще и надежнее кода с инвариантами, но неумелые программисты, если у них нет нужного бекграунда, пишут именно инварианты. Еще один пример — парсеры правильно пишут только те, кто хотя бы немного знаком с темой, а остальные 99% без профильного образования пишут страшных каракатиц, мутных и падучих, при том что с другими задачками они худо-бедно справляются.
С обсуждаемой задачкой все тоже самое, только на более примитивном уровне. Если человек рисует в резюме какие то весьма непростые проекты, а на практике пишет код что я привел, это означает что у человека нет даже базового бекграунда.
Здравствуйте, Erop, Вы писали:
НС>>Безопасным относительно чего? Сам по себе метод вполне безопасен, так как не использует внешнее состояние совсем. E>относительно многопоточного окружения. Пока ты там крутишь свой разобранный список из другого потока его могут попробовать почитать...
Это совсем другое, и оба способа его не решают. Тут надо либо придумывать параллельный список, либо лочить, либо список сделать иммутабельным и копировать. Но это совсем другие скилы и другие задачи.
НС>>Правильный ответ, он не только сильно лучше по процессору и памяти, он еще и самый простой. E>По процессору он лучше раза в два примерно по памяти да, но не понятно дорого ли это. E> Про "самый простой" не согласен.
Ну приведи метрику, по которой он окажется сложнее.
E>1) Посмотри насколько низкий уровень требуется что бы породить/понять "правильный" и "неправильный"
А с какого это перепугу мы стали простоту кода мерять возможностью его написания безграмотным "программистом"? Нормальный LL парсер у тебя тоже сложнее, чем ручной разбор без какой либо методики, потому что первый человек с первого раза скорее всего написать не догадается? А код, который из сиквела выбирает лишние данные, потому что человек джойнами не умеет пользоваться, он тоже проще? А ручная десериализация XML, потому что человек никогда не слышал про XmlSerializer или Linq2Xml? А рукопашный контроль структуры XML, потому что моска не хватило со схемами разобраться? Или вон, как Шеридан, ниасил xslt и наворотил шаблонов на базе string.Format. С твоей логикой очень далеко можно зайти.
E>2) Давай нам надо мнемного модифицировать задание?
Нет, не давай. Доказательства по аналогии идут в сад, потому что таким способом можно доказать что угодно.
Здравствуйте, Vzhyk, Вы писали:
I>>Предложи хороший способ проверить умения, кроме как задачей. Про монетки не надо рассказывать, выдай уже эту серебряную пульку. V>Да нет ее, этой серебряной пульки, нет, вообще нет, не существует и существовать не может. V>Но ты уж определись, что ты проверяешь умения или включение/выключение головы (так и хочется добавить — молотком).
Предложи тогда более толковый способ, нежели задачи.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Ты, кажется, не понял — такая задача подобрана специально, на другой задаче все по другому.
Это ты не понял, что кроме оценки кода, много там лишнего или мало, есть и другие метрики, например его технологичность и стандартность...
И "технологичность" как раз, в том числе, означает, что на многих задачах код будет примерно одинаковый.
E>> Хотя бы неприятным тебе способом?.. НС>У меня нет неприятных способов.
В смысле?
"приятным" я назвал сортировать тупо на месте, "неприятным" сортировать в массиве ссылок, а потом писать обратно в ноды.
НС>Обсуждаемая задача это не вопрос-ловушка. Ловушки это ваши гномики и лампочки, которых на собеседовании спрашивают даже у людей, которые устраиваются на позиции архитектов или менеджеров. А здесь прямая демонстрация того как человек мыслит.
А я про гномиков тоже не люблю. А демонстрация нифига не прямая, если ты прямо не просишь без лишней памяти...
НС>А с чего ты взял, что не просят? Я где то такое писал?
Если так и просят, то нормальная задача. А ты писал просто НЕПОНЯТНО, про то, что ни в коем случае нельзя упомянул кто-то другой.
А если просите без доп. памяти, то зачем народ сдаёт решение с массивом? От безисходности что ли?
НС>Да, он однозначно хуже. И другая задача в этом плане ничего не доказывает.
Ну вот такой простой параметр, как лёгкость модификации, как оценишь, без рассматривания что изменится в коде, если поменются немного условия?
НС>Опять ты со своими фантазиями споришь. Никто ничего не скрывает.
Если не скрываешь, то нормально.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
НС>>Ты, кажется, не понял — такая задача подобрана специально, на другой задаче все по другому. E>Это ты не понял, что кроме оценки кода, много там лишнего или мало, есть и другие метрики, например его технологичность и стандартность...
А еще есть дядька в Киеве. Еще раз, следи за губами — эта задачка предназначена для тестирования строго определенного скила, и это не технологичность и не стандартность. Ты же, подменяешь задачу (потому что исходная специально так подобрана, чтобы по минимуму затрагивать другие скилы), а потом на основании этой подмены пытаешься доказать, что неверный ответ к исходной задаче на самом деле верный. Это, мой друг, демагогия.
E>>> Хотя бы неприятным тебе способом?.. НС>>У меня нет неприятных способов. E>В смысле?
Что тебе непонятно в простом предложении?
E>"приятным" я назвал сортировать тупо на месте, "неприятным" сортировать в массиве ссылок, а потом писать обратно в ноды.
Ты написал "неприятным тебе" способом, а что ты там у себя называешь мне лично все равно.
E>А демонстрация нифига не прямая
Придумай прямее.
E>, если ты прямо не просишь без лишней памяти...
То есть продолжаешь спорить со своими фантазиями?
E>А ты писал просто НЕПОНЯТНО
Ну да, и вместо того чтобы прямо спросить о том что ты не понял ты начал что то фантазировать и на основании этих фантазий спорить.
E>А если просите без доп. памяти, то зачем народ сдаёт решение с массивом? От безисходности что ли?
Да потому что не может по другому. Мы ж даже, после неверного решения, намеки делаем, что надо бы вот так переписать, чтобы под весь список несколько раз память не выделять или там всего один проход делать, но результат почти всегда остается прежним.
НС>>Да, он однозначно хуже. И другая задача в этом плане ничего не доказывает. E>Ну вот такой простой параметр, как лёгкость модификации, как оценишь
Никак. Это задача не на легкость модификации, она, как минимум, слишком маленькая для оценки этого. Ты же, надеюсь, еще помнишь, что здесь обсуждается именно конкретная задача, а не что то еще?
Здравствуйте, Erop, Вы писали:
E>Это у тебя невроз такой, да? Аллергия на аналогии?
Нет. Просто единственный конструктивный способ продолжения разговора после применения подобных приемов. А ты ожидал, что я будут с твоими аналогиями спорить? Фик тебе.
E>Ты просил метрику простоты кода? Ну так вот, простой код просто модифицировать.
ДОКАЖИ.
E> Так что смотрим насколько просто модифицировать тот и другой код
А если надо не сортировку добавить, а просто изменить способ получения ссылки Next? В каком из вариантов больше изменений будет, а?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Я вот, честно, уже не знаю как с тобой разговаривать.
Не знаешь, ка кразговаривать? -- Не разговаривай
НС>Никаких проблем он не плодит, он вообще имеет довольно опосредованное отношение к коду реальному.
Ты сам там вот на пару сообщений выше написал, что типа код с массивами плохой, потому, что программировать так, типа шаблонно вообще плохо, так как потом это породит кучу проблем и тружно будет отрефакторить.
Я же ничего ен перепутал?
ну вот мне и инетерсно понять, какие проблемы может по твоему породить этот код и почему его трудно отрефакторить?
НС>Потому что он не предназначен для проверки вообще всех возможных навыков написания кода, это всего лишь простенькая задачка-фильтр, позволяющая понять кто сидит перед нами — программист или человек, который пытается его имитировать.
Ты, как бы, взял два куска кода и сказал, что один конфетка, а другой какашка. Я тебе говорю, что это не так, они хороши с разных точек зрения просто. Это вообще никак не свящано с тем, что ты как-то издеваешься или там ещё что делаешь с соискателями, вопрос о том, почему ты считаешь, что один код хорош, а другой плох
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Нет. Просто единственный конструктивный способ продолжения разговора после применения подобных приемов. А ты ожидал, что я будут с твоими аналогиями спорить? Фик тебе.
При чём тут спорить? Речь о том, что один код устроен шаблонно, шаблон хорошо масштабируется и применяется в куче аналогичных задач, а другой годится только для одного единственного преобразования списка, и если преобразование немного поменяется, всё рассыплется, надо будет писать новый, совсем другой код...
НС>А если надо не сортировку добавить, а просто изменить способ получения ссылки Next? В каком из вариантов больше изменений будет, а?
Одинаково, вообще-то...
Зачем второй раз итерировать список, если есть верно упорядоченный массив?..
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
НС>>Никаких проблем он не плодит, он вообще имеет довольно опосредованное отношение к коду реальному. E>Ты сам там вот на пару сообщений выше написал, что типа код с массивами плохой, потому, что программировать так, типа шаблонно вообще плохо
Попробуй найти в моих сообщениях хотя бы одно использование слова "шаблонный". Может хватит уже придумывать за меня мои слова?
E>, так как потом это породит кучу проблем и тружно будет отрефакторить. E>Я же ничего ен перепутал?
Да ничего, кроме того что я ничего подобного не писал.
НС>>Потому что он не предназначен для проверки вообще всех возможных навыков написания кода, это всего лишь простенькая задачка-фильтр, позволяющая понять кто сидит перед нами — программист или человек, который пытается его имитировать. E>Ты, как бы, взял два куска кода и сказал, что один конфетка, а другой какашка. Я тебе говорю, что это не так
Это так.
E>, они хороши с разных точек зрения просто.
Второй кусок плох с любой точки зрения. В контексте данной конкретной задачи.
E> Это вообще никак не свящано с тем, что ты как-то издеваешься или там ещё что делаешь с соискателями
То есть я обсуждаю конкретную задачу конкретно в контексте собеседования, но тут, в середине топика, не разобравшись с контекстом, влазишь ты и начинаешь что то доказывать вне этого контекста и для другой задачи. Извини, но с логикой у тебя не все хорошо.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>То есть я обсуждаю конкретную задачу конкретно в контексте собеседования, но тут, в середине топика, не разобравшись с контекстом, влазишь ты и начинаешь что то доказывать вне этого контекста и для другой задачи. Извини, но с логикой у тебя не все хорошо.
Это у тебя нехорошо. Так как ты, оказывается, обсуждаешь как решение то, что решением вообще не является
При этом апеллируешь, не к простому утверждению, что это не соответствует требованию без доп. памяти, а к тому, что якобы этот код сложнее, написан без применения головы и т. п...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>При чём тут спорить?
А что ты тут делаешь? Лекции читаешь?
E> Речь о том, что один код устроен шаблонно
Докажи.
E>шаблон хорошо масштабируется
Докажи.
E> и применяется в куче аналогичных задач
Докажи.
Ты если реально хочешь именно шаблонный код увидеть, то он будет, например, таким:
IEnumerable<Item> AllElements(this Item head)
{
while (head != null)
{
yield return head;
head = head.Next;
}
}
Item ToSingleLinkedList(this IEnumerable<Item> src)
{
var head = new Item();
var cur = head;
foreach (var item in src)
{
cur.Next = new Item();
cur = cur.Next;
}
return head;
}
...
var reversed = head.AllElements().Reverse().ToSingleLinkedList();
А то что я привел, это не шаблонный код, это безмозглый код человека, который дальше книжки "C# за 21 день" не прошел. Более менее вменяемые C# программисты такой код не пишут.
На закуску — для добавления сортировки в этом коде нужно немного изменить одну строчку:
var reversed = head.AllElements().OrderByDescending(i => i.Name).ToSingleLinkedList();
Вот тут действительно модифицируемость кода выше.
НС>>А если надо не сортировку добавить, а просто изменить способ получения ссылки Next? В каком из вариантов больше изменений будет, а?
E>Одинаково, вообще-то...
Здравствуйте, Erop, Вы писали:
E>Демогогия -- это то, что ты тут пишешь. E>Если в твоей задаче есть В УСЛОВИИ требование не использовать доп. память, то ответ с массивом НЕ ВЕРНЫЙ по ФОРМАЛЬНЫМ причинам.
НС>>Ну да, и вместо того чтобы прямо спросить о том что ты не понял ты начал что то фантазировать и на основании этих фантазий спорить.
E>Я вообще никак не оценивал твои собеседования. Я оспариваю то, что код с массивом -- плохой. Он просто написан исходя из другой системы ценностей. Он не является решением твоей задачи и мне странно, что ты не упомянул это, когда приводил его...
Этот тред уже вырос до безумного размера... Но всё ж напишу. Тем более это не последняя такая тема. Сколько их уже было.
ИМХО, бОльшая часть этих аргументов мимо кассы. Даже те, что формально правильные.
В смысле люди держат в голове одно, а доводы придумывают по случаю.
А всё просто: есть плохо осознанная установка, что правильный программист — это примерно выпускник тех. вуза,
которому давали некоторые "базовые" знания. В число которых, естественно, входит разворот списка на месте.
Это я иронизирую, если что. Т.е. есть вроде как прогер должен понимать структуры данных. Но структуры данных
начинаются с односвязного списка (табличка "сарказм"). Т.е. если не знает про односвязный список, то скорее всего
человек случайный, пришел с улицы в надежде на халяву.
Самое смешное, что это долгое время было примерно правдой. Для средней конторы было нормальным
писать "высшее тех. образование" в требованиях. Как фильтр это работало, а потерями от такого фильтра можно
было пренебречь. Отсюда и традиция первым делом спрашивать разворот списка на месте. И даже подразумевать,
что кандидат сам поймёт, что разворот списка это именно на месте. И что это список, а не какой-то там List<T>.
Этому же всех учили!
Ну а сейчас ситуация поменялась. Просто те, кто проводят собеседования действуют по старинке,
потому что тут так принято, и потому что их в своё время мучали этим.
Многие к тому же не осознают или просто не знают, что ситуация таки поменялась.
Откуда же его [независимый суд] взять, если в нем такие же как мы? (c) VladD2
Здравствуйте, Erop, Вы писали:
НС>>Меня формальные причины не особо интересуют. E>Ну тебя может и не интересуют, но соискатели-то отвечают на тот вопрос, который ты им задал, а не на то, что тебя интересует.
И?
E>То есть, если ты просишь их "сделайте без доп. памяти", а они тулят массив, то они НЕ РЕШИЛИ ЗАДАЧУ.
Верно. Но причины нерешения могут быть разные. Может человек просто от волнения недочитал условие или не так понял. Мы ж не программу тестируем, а человека. А человеки, они такие, неформальные.
E>Ну, давай так, пусть у нас целый класс операций над списком, типа мы контейнер пишем. И если все операции переупорядочения сделаны похоже, то это лучше, правда это может быть слишком дорого, а может и не быть...
Все равно неправильный код. В этом случае лучше перевести базис не в список, а в IEnumerable, он легковеснее и гибче, и на ряде операций позволит таки обойтись без лишнего перевыделения памяти (реверс не из их числа, впрочем).
E>Мне не понятно, что за имбицилы к вам идут
Ну вот такой вот в своей массе соискатель. К вам они тоже идут в том же количестве, просто ХРы и первые собеседователи их отфильтровывают и до тебя оно не доходит, видимо.
E>IMHO, ты чего-то тут не договариваешь...
Скорее у тебя иллюзии по поводу среднего уровня. Да ты почитай целиком этот топик то — тут и про односвязный список люди впервые отсюда узнали, и программисты, которым концепция ссылок не нужна.
НС>>В контексте этой задачи он таки хуже. E>В контексте этой задачи он не то что бы хуже там или лучше, а один является решением, а другой нет
Здравствуйте, Erop, Вы писали:
E>Это у тебя нехорошо. Так как ты, оказывается, обсуждаешь как решение то, что решением вообще не является
Решением оно является, просто неправильным. И о том что оно неправильное я сказал с самого начала. Если ты это не прочел или прочел по иагонали(что тут нередко бывает) — тут я не виноват.
E>При этом апеллируешь, не к простому утверждению, что это не соответствует требованию без доп. памяти, а к тому, что якобы этот код сложнее, написан без применения головы и т. п...
Ну так это потому что мы не юнит-тест обсуждаем, а проверку знаний реальных человеков. У нас, в принципе, формально неработающие решения вполне принимались, если ход мысли правильный.
На что смотреть? На то, как ты не умеешь программировать?
Тебе надо ОДИН раз прочитать каждый Next при заполнени массива, и ОДИН раз прописать, при записи переупорядочения обратно в узлы...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Ну и чем это отличается от функции сливающей в массив
Тем что перечисление легковеснее, гибче и универсальнее.
E>На что смотреть? На то, как ты не умеешь программировать?
Перешел на личности — слил (С)
E>Тебе надо ОДИН раз прочитать каждый Next при заполнени массива, и ОДИН раз прописать, при записи переупорядочения обратно в узлы...
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Верно. Но причины нерешения могут быть разные. Может человек просто от волнения недочитал условие или не так понял. Мы ж не программу тестируем, а человека. А человеки, они такие, неформальные.
Вот про это я и писал тебе "ил он не понял вопроса", а ты что мне на это ответил?
На самом деле я твой вопрос про разворт списка на месте, при явном требовании O(1) по памяти считаю нормальным, но слегка наивным. Хотя если оно работает, то и хорошо. Тут у меня с тобой разногласий нет, хотя мне так кажется, что ты как-то очень пристрастно к теме относишься, нервно. Это же довольно простой и наивный вопрос и всё.
НС>Все равно неправильный код. В этом случае лучше перевести базис не в список, а в IEnumerable, он легковеснее и гибче, и на ряде операций позволит таки обойтись без лишнего перевыделения памяти (реверс не из их числа, впрочем).
Ну так тоже можно. Я согласен, что для шарпа это, наверное лучше, хотя накосячить с ним проще. Ты, вот, например, вроде как накосячил
Опять же IEnumerable, вроде как назад плохо мотается, так что меньше будет возможностей, но может и хватит.
Но это уже обсуждаемо вполне, и так можно смотреть и сяк. Вам, шарписатм, виднее, как в шарпе адекватнее.
Но, мне таки кажется, что ты понял наконец, что я имел в виду, когда говорил, что тот и другой вариант обращения списка просто написаны для разных целей. Для своих целей каждый хорош.
НС>Ну вот такой вот в своей массе соискатель. К вам они тоже идут в том же количестве, просто ХРы и первые собеседователи их отфильтровывают и до тебя оно не доходит, видимо.
Ну да, но их как-то проще отфильтровывают, без списков. Насколько я слышал есть большой процент, кто сыплется на задачке вроде посчитать устно/на пальцах сумму чисел от 1 до 1000 %)
НС>Именно.
Ну вот, то есть и тут у нас полное согласие. Просто мне странно называть "хуже" решение, которое вообще решением не явлеется, а тебе я не понял странно или привычно
Именно потому, что ты стал говорить про "хуже" и возникло впечатление, что в задачке не просят явно обойтись без доп. памяти
А так, в целом, не ясно о чём спор-то, я скорее разделяю твою позицию, чем оспариваю, просто немного уточняю в сторону своей ИМХИ
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Ну так это потому что мы не юнит-тест обсуждаем, а проверку знаний реальных человеков. У нас, в принципе, формально неработающие решения вполне принимались, если ход мысли правильный.
Ну, видимо, я как-то иначе, чем ты мыслю. IMHO, если в задаче сказали "без доп. памяти", то ход мыслей в сторону доп. массивов точно не в туда просто принципиально
Это вообще решение совсем другой задачи, что, кстати, не есть хорошая особенность программиста. Типа ты ему даёшь ТЗ, а он делает что-то совсем другое
Такие, кстати, не так уж и редки...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Тем что перечисление легковеснее, гибче и универсальнее.
но и ошибиться легче, увы. Но в целом да, мне тоже больше нравится, я же тебе сразу написал, что так логичнее, но немного сложнее. Но, по идее, шарпист должен таки уметь с ними работать достаточно легко.
E>>Тебе надо ОДИН раз прочитать каждый Next при заполнени массива, и ОДИН раз прописать, при записи переупорядочения обратно в узлы...
НС>А там последнюю строчку не приметил?
Если честно, я уже не помню, что конкретно ты там написал, что там в последней строчке такого было великого?
Казалось бы, пишем ссылки на узлы в массив, потом его переворачиваем, или не переворачиваем, тут по вкусу, а потом первому узлу в массиве говорим, что его Next -- второй, второму, что третий и т. д...
Последнему говорим, что 0
Зачем нам при этом дважды читать next какого-то узла?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>хотя мне так кажется, что ты как-то очень пристрастно к теме относишься, нервно
Оценивать эмоции по тексту — крайне неблагодарное занятие, легко промахнуться.
E>. Это же довольно простой и наивный вопрос и всё.
Ну вот некоторые считают, что могут быть такие программисты, которые на него не ответят даже после уточняющих вопросов.
НС>>Все равно неправильный код. В этом случае лучше перевести базис не в список, а в IEnumerable, он легковеснее и гибче, и на ряде операций позволит таки обойтись без лишнего перевыделения памяти (реверс не из их числа, впрочем). E>Ну так тоже можно. Я согласен, что для шарпа это, наверное лучше, хотя накосячить с ним проще. Ты, вот, например, вроде как накосячил
Я писал пост в форум, а не на собеседование ответ. Тут и опечаток в тексте целая пачка, это ж не означает что я по руски писать без ошибок не могу.
E>Но, мне таки кажется, что ты понял наконец, что я имел в виду
Я давно это понял, а вот ты меня понять никак не можешь.
E>Ну да, но их как-то проще отфильтровывают, без списков.
Например?
E> Насколько я слышал есть большой процент, кто сыплется на задачке вроде посчитать устно/на пальцах сумму чисел от 1 до 1000 %)
И какое это отношение имеет к программированию? Это математика про ряды, и она точно не обязательна для любых программистов (хотя это первый семестр любого негуманитарного ВУЗа, да). Вот формула:
Конечно, если немножко моск напрячь, можно ее и вывести. Только это будет опять разновидность задачи про гномиков.
Здравствуйте, Erop, Вы писали:
E>Ну, видимо, я как-то иначе, чем ты мыслю. IMHO, если в задаче сказали "без доп. памяти", то ход мыслей в сторону доп. массивов точно не в туда просто принципиально
Верно. Но если задать вопрос — а можно ли как то поменьше памяти расходовать, то тут уже зависит от ответа на него.
E>Это вообще решение совсем другой задачи, что, кстати, не есть хорошая особенность программиста.
Надо делать скидку на стресс во время собеседования или невнимательность. Скажем, если ошибка будет типа той, что я допустил в последнем примере, то это точно не будет основанием для отказа, особенно если человек ее найдет и исправит.
E> Типа ты ему даёшь ТЗ, а он делает что-то совсем другое
Ну, не все так однозначно. В вопросе сформулировано что то вроде "реализовать с минимальным расходом памяти", не уточняя каким конкретно. Так что кандидат может и не знать что его решение неправильное, если не знает правильного.
Здравствуйте, Erop, Вы писали:
НС>>А там последнюю строчку не приметил? E>Если честно, я уже не помню, что конкретно ты там написал, что там в последней строчке такого было великого?
Ничего великого, просто еще одно обращение к Next. Но это, вобщем то, неважно. Суть тут не в конкретном коде, а в том что, если заранее задать правильный вариант, то часто можно подобрать такое требование, чтобы именно это решение было лучше. И именно поэтому доказательство правильности варианта путем замены исходной задачи логически некорректно.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Ну вот некоторые считают, что могут быть такие программисты, которые на него не ответят даже после уточняющих вопросов.
Ну я тоже так читаю. Например 1С-пограммисты или там бэйсикисты, или как их надо называть? просто понятие "программист" широкое довольно. Но я вполне верю, что вам такие могут быть и не нужны.
НС>Я писал пост в форум, а не на собеседование ответ. Тут и опечаток в тексте целая пачка, это ж не означает что я по руски писать без ошибок не могу.
Я не хотел сказать что-то плохое про тебя, просто дал иллюстрацию, что с перечислением накосячить проще. даже тебе. С массивом же ты не накосячил? Или накосячил? Я уже не помню, если честно.
НС>Я давно это понял, а вот ты меня понять никак не можешь.
Почему? После того, как ты пояснил, что в твоём идиалекте неправильное решение, это тоже решение, только оно хуже правильного, я тебя прекрасно понял. но я вообще не обсуждал твою задачу и собеседования, на самом деле
НС>И какое это отношение имеет к программированию? Это математика про ряды, и она точно не обязательна для любых программистов (хотя это первый семестр любого негуманитарного ВУЗа, да). Вот формула: НС> НС>Конечно, если немножко моск напрячь, можно ее и вывести. Только это будет опять разновидность задачи про гномиков.
Думаешь?..
Я вот формулу не знаю, я знаешь как считаю такие суммы? Мне вот очевидно, что если добавить эти же числа, но в обратном порядке и через один, то есть 1 + 1000 + 2 + 999 + 3 + 998 + ... + 1000 + 1, и расставить там скобок (1 + 1000) + (2 + 999) + ... + (1000 + 1), то получится 1001000, и это будет искомая сумма взятая дважды, так что искомая будет 500500... Проверь по формуле, если тебе это не очевидно.
только я не считаю, что для этого упражнения надо "напрягать мозг"
Но в целом я просто рассказал тебе тайну, как отсеивают совсем глупых. Кажется эту задачку дают даже соискателям на позицию серетаря, кстати.
Ну и в целом, IMHO, это примерно всё равно как отсеивать настолько несклонных к аналитическому мышлению людей.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Ночной Смотрящий, Вы писали:
IO>>Этому же всех учили! НС>Нет, не поэтому, а потому что мозг нормального программиста должен щелкать подобные задачки за секунду.
Тут объяснили, что для многих областей этого не требуется. Не вижу оснований не верить.
Я тоже раньше думал, что нормальный тест на базовые умения. Задача вроде простая и ответ можно
увидеть чисто визуально, даже если раньше к односвязным спискам не прикасался.
Но на практике ненормальные программисты работают вместе с "нормальными" и по большей части над тем же.
IO>>Ну а сейчас ситуация поменялась. НС>У нас ситуация не менялась как минимум с 2003 года.
Поменялась. Народ стал менее однородный и с разным бекграундом.
Учить в ВУЗах стали хуже и меньше требовать.
Культура программизма внутри РФ стала менее специфична и замкнута.
И т.д.
А у вас — это точно РФ?
НС>ИМХО, не стоит по себе о других судить.
Не стоит. Я этого и не делаю. Кстати телепатией заниматься тоже не стоит.
Откуда же его [независимый суд] взять, если в нем такие же как мы? (c) VladD2
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Ну, не все так однозначно. В вопросе сформулировано что то вроде "реализовать с минимальным расходом памяти", не уточняя каким конкретно. Так что кандидат может и не знать что его решение неправильное, если не знает правильного.
Ага! Таки вопрос с хитрецой, и потом с уточняющим таки. Тогда понятнее всё становится и почему то таки решение, и почему его предлагают...
А почему бы прямо не написать в вопросе "с расходом памяти O(1)"? Ну тупо итерацию одну сэкономишь как бы...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Ничего великого, просто еще одно обращение к Next.
А зачем оно там?
НС>Но это, вобщем то, неважно. Суть тут не в конкретном коде, а в том что, если заранее задать правильный вариант, то часто можно подобрать такое требование, чтобы именно это решение было лучше. И именно поэтому доказательство правильности варианта путем замены исходной задачи логически некорректно.
Ну так мы не про задачу же, а про модель реального кода, как бы.
Впрочем, я уверен, что ты уже меня понял полностью, так что предмета для спора нет.
Про дополнительное образение к Next заитриговал. Завтра может найду сообщение с твоим кодом и посмотрю. Что-то никак не могу придумать на кой оно надо. IMHO, в любой верной реализаци надо ОДИН раз у каждого узла взять Next и ОДИН раз каждому прописать, хоть "на месте" оборачивай, хоть "через массив"
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Ну я тоже так читаю. Например 1С-пограммисты
Про них речь здесь не шла.
E> или там бэйсикисты
Бейсик нынче уже совсем не тот, это C# с другим синтаксисом.
E>, или как их надо называть? просто понятие "программист" широкое довольно. E>Но я вполне верю, что вам такие могут быть и не нужны.
Ну вот gandjustas утверждает, что под шерпоинт надо писать полноценный код, не сильно ограниченный в плане сложности и доступных фич. Врет?
А Undying утверждает, что для DSP не нужно не только понимание концепции ссылок, но даже и базовая для DSP математика.
НС>>Я писал пост в форум, а не на собеседование ответ. Тут и опечаток в тексте целая пачка, это ж не означает что я по руски писать без ошибок не могу. E>Я не хотел сказать что-то плохое про тебя, просто дал иллюстрацию, что с перечислением накосячить проще. даже тебе.
Я точно так же тем же самым способом мог накосячить и в варианте со списком — там же тоже последний элемент вне цикла обрабатывается.
E>Думаешь?.. E>Я вот формулу не знаю, я знаешь как считаю такие суммы? Мне вот очевидно, что если добавить эти же числа, но в обратном порядке и через один, то есть 1 + 1000 + 2 + 999 + 3 + 998 + ... + 1000 + 1, и расставить там скобок (1 + 1000) + (2 + 999) + ... + (1000 + 1), то получится 1001000, и это будет искомая сумма взятая дважды, так что искомая будет 500500...
Это и есть вывод формулы. Но графически ее вывести даже проще, формулу площади параллелепипеда и прямоугольного треугольника даже ты должен помнить.
А оценочно я вообще прикидываю как An/2*n — это интуитивно понятная формула, и для рядов типа твоего дает маленькую погрешность.
E>Но в целом я просто рассказал тебе тайну, как отсеивают совсем глупых.
Для совсем глупых у нас был тест на основы C# — 20 простейших вопросиков с вариантами ответов. Этот тест писался в кабинете у ХР.
Здравствуйте, ins-omnia, Вы писали:
IO>Тут объяснили, что для многих областей этого не требуется.
Программирование на языке C# в эти области не входит.
IO>А у вас — это точно РФ?
Точно. Я даже больше скажу — Москва.
НС>>ИМХО, не стоит по себе о других судить. IO>Не стоит. Я этого и не делаю.
А на основании чего тогда ты решил, что другие действуют по старинке, и только ты зришь в корень? Сложность и объемность задач с 2003 года только выросла, программирование на C# 5.0 и FW 4.5 это сильно больше и хитрее, чем на C#/FW 1.1, и я не понимаю с какого фига требования нужно снижать, и человек, ниасиливший как следует ссылки, на C# 1.1 программировать не мог, а на 5.0 вдруг запрограммирует как из пушки.
Здравствуйте, Erop, Вы писали:
E>Ага! Таки вопрос с хитрецой, и потом с уточняющим таки. Тогда понятнее всё становится и почему то таки решение, и почему его предлагают...
Проблема то остается — даже после наводящих вопросов подавляющее большинство справиться с задачей не может.
E>А почему бы прямо не написать в вопросе "с расходом памяти O(1)"? Ну тупо итерацию одну сэкономишь как бы...
Здравствуйте, Erop, Вы писали:
НС>>Но это, вобщем то, неважно. Суть тут не в конкретном коде, а в том что, если заранее задать правильный вариант, то часто можно подобрать такое требование, чтобы именно это решение было лучше. И именно поэтому доказательство правильности варианта путем замены исходной задачи логически некорректно.
E>Ну так мы не про задачу же, а про модель реального кода, как бы.
Вот поэтому ты меня и не понимаешь. Я то как раз про задачу, а не про модель реального кода.
E>Про дополнительное образение к Next заитриговал. Завтра может найду сообщение с твоим кодом и посмотрю. Что-то никак не могу придумать на кой оно надо.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>А на основании чего тогда ты решил, что другие действуют по старинке, и только ты зришь в корень? Сложность и объемность задач с 2003 года только выросла, программирование на C# 5.0 и FW 4.5 это сильно больше и хитрее, чем на C#/FW 1.1, и я не понимаю с какого фига требования нужно снижать, и человек, ниасиливший как следует ссылки, на C# 1.1 программировать не мог, а на 5.0 вдруг запрограммирует как из пушки.
Так это разная сложность. Ты же не утверждаешь, что в 5.0 появились какие-то новые фундаментальные концепции?
Тем более такие, которые требуют для понимания классического базы алгоритмов/структур данных.
Многие нововведения как раз направлены на то, чтобы было легче писать бойлерплейт не заморачиваясь низкоуровневыми деталями.
Да, а почему ты объединяешь сложность задач и сложность платформы? Вроде чем сложнее и специфичнее задача, тем меньше пользы от фишек платформы.
Задача конечно может быть сложной, но не специфичной. Типичный "кроваый энтерпрайз" например. Но это же как раз область, где рулят совсем другие
скилы, к алгоритмам имеющие отдаленное отношение.
Откуда же его [независимый суд] взять, если в нем такие же как мы? (c) VladD2
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, ins-omnia, Вы писали:
IO>Так это разная сложность.
А неважно. Важно что ссылки никуда не делись.
IO> Ты же не утверждаешь, что в 5.0 появились какие-то новые фундаментальные концепции?
Утверждаю. Как минимум поддержка короутинов двух видов и некоторых конструкций ФП.
IO>Многие нововведения как раз направлены на то, чтобы было легче писать бойлерплейт не заморачиваясь низкоуровневыми деталями.
Легче, но только человекам с хорошим бекграундом.
IO>Но это же как раз область, где рулят совсем другие IO>скилы, к алгоритмам имеющие отдаленное отношение.
Эта область настолько обширна, что там рулят почти любые программистские скилзы.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>А неважно. Важно что ссылки никуда не делись.
Ты считаешь, что человек, который не осилил задачу на односвязный список, не понимает что такое ссылки?
При условии, что он раньше этих списков не видел.
IO>> Ты же не утверждаешь, что в 5.0 появились какие-то новые фундаментальные концепции? НС>Утверждаю. Как минимум поддержка короутинов двух видов и некоторых конструкций ФП.
Если уж на то пошло, чем дальше в функциональные дебри, тем дальше от концепции ссылок. Но это уже оффтопик.
IO>>Многие нововведения как раз направлены на то, чтобы было легче писать бойлерплейт не заморачиваясь низкоуровневыми деталями. НС>Легче, но только человекам с хорошим бекграундом.
Что такое хороший бекграунд? Дискретная математика и Кнут? Это конечно хороший бекграунд, но здесь он не особо нужен.
Или ты думаешь, что человек, которого магическая сила не потянула изучать Кнута, не сможет ослить Линк и асинки?
Не такие это сложные концепции. Ничего принципиально более сложного, чем процедурное программирование там нет.
Люди, которые не знают вообще ничего, кроме жабаскрипта усваивают подобные концепции без труда и применяют их
в своём коде.
Я бы тут заменил "хороший бекграунд" на "общую вменяемость". Думаю, что даже задача на списки может служить для её проверки.
Но естественно при условии вменяемости собеседующего. Т.е. не "переверни мне список на бумажке, ааа ты даже не понял, что
я имел в виду односвязный список, пшел нафиг петеушник". Можно сначала спросить чела, слышал ли он о такой струкруте,
если нет показать ему, спросить как бы он перевентул такой список. Если нарисовать это на бумажке, чел должен догадаться и
объяснить в двух словах. Ну и после написать код. Главное не пытаться читать мысли и не заставлять чела читать мысли.
Но если кандидат говорит, что знает об этой структуре, но не может показать, значит скорее всего тупой или профессиональный зубрила.
Как-то так.
Откуда же его [независимый суд] взять, если в нем такие же как мы? (c) VladD2
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Это чего вообще такое? Особо извращенный способ заполнить массив интов нулями?
исправленному псевдокоду верить E>>
E>> v[i].next = prev;
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Ну то есть в итоге ты воспроизвел правильное решение практически 1 в 1, но при этом зачем то заменил обход списка индексированным доступом.
Ну я же говорю тебе, что между ними таки моно общего
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Ну вот устраняем из твоего решения ненужную сущность — промежуточный массив или список — и получаем самое простое решение
Опять за рыбу деньги
Я и правда могу написать сразу то решение, которое ты называешь "правильное".
Мало того, мне так кажется, что даже если писать то, которое ты называешь "хуже", естественно его писать похоже на то, которое "правильное"
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, -n1l-, Вы писали:
N>Пффф, пока вы тут писали эту простыню, я взял листочек и ручку набросал схему ссылок и решил задачу двумя разными способами.
вдогонку: "пфф ололо схема ссылок на листочке".
N>Это вообще детские задачи. Вот я на работе решал задачку.
а мы все только формы клепаем, ага.
"
Операцией добавления N Элементов в дерево можно значит пренебречь ? у тебя уже на ровном месте O(n log(n)) + дополнительная память O(n) + отдавать данные вместо O(1) почему то O(n) 
Или хотя бы что по возможности так.
* thriving in a production environment *
Тогда какой смысл во всех этих хитродуманных задачах? Отсеять ламеров? Так это вы должны уметь уже по CV и первым трём предложениям.
Мы уже победили, просто это еще не так заметно...
