Здравствуйте, Ночной Смотрящий, Вы писали:
НС>По условиям задачи исходный список — однонаправленный. Предлагаешь загонять односвязный список в List, а потом после реверса выгружать?
Можно узнать для каких практических задач целесообразно использовать однонаправленный список? Я вот за десять лет практики не видел ни одной такой задачи. На практике в 99,9% случаев использование однонаправленного списка это и синтаксический и производительный оверхед. Так в чем смысл спрашивать на собеседовании задачу, не встречающуюся на практике?
Уж лучше обход дерева спросите, это хоть реально бывает нужно.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>По условиям задачи исходный список — однонаправленный. Предлагаешь загонять односвязный список в List, а потом после реверса выгружать?
Это не говоря уж о проблеме разного понимания терминологии на собеседовании. Т.к. в шарпе термин "список" всеми понимается как List, т.е. динамический массив. В классическом значении им никто не пользуется, т.к. на практике классические списки это никому не нужная экзотика.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Code review сильно помогает в такой ситуации. При наличии обратной связи человек либо быстро учится, либо уходит. Но это довольно дорогое удовольствие.
Code review помогает, когда архитектура проекта (с высоты птичьего полета) и используемые алгоритмы изначально правильные, но что-то реализовано не так, надо отрефакторить и т.д. А уж если изначально взят неверный подход, то CR может быть только один : выбросить и начать с начала.
Здравствуйте, Undying, Вы писали:
U>Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>По условиям задачи исходный список — однонаправленный. Предлагаешь загонять односвязный список в List, а потом после реверса выгружать?
U>Можно узнать для каких практических задач целесообразно использовать однонаправленный список? Я вот за десять лет практики не видел ни одной такой задачи. На практике в 99,9% случаев использование однонаправленного списка это и синтаксический и производительный оверхед. Так в чем смысл спрашивать на собеседовании задачу, не встречающуюся на практике?
Ну я использую односвязные списки для хранения полилиний, проводников на печатных платах, иногда для контуров полигонов.
На некоторых моих задачах односвязный список незаменим, а двусвязный — избыточен.
Стандартный std::list здесь непригоден, списки реализованы на основе массивов, вместо указателей используются индексы, поэтому оверхед по памяти минимальный.
Задача разворота односвязного списка в моем случае используется для объединения пары проводников в один.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Undying, Вы писали:
U>Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>По условиям задачи исходный список — однонаправленный. Предлагаешь загонять односвязный список в List, а потом после реверса выгружать?
U>Можно узнать для каких практических задач целесообразно использовать однонаправленный список? Я вот за десять лет практики не видел ни одной такой задачи.
Связанный список используется в других структурах данных, в том же дереве косвенно и в хештаблице напрямую.
Нынче это больше задача для обучения основам программирования нежели что-то практическое. Но то, что эта структура данных используется на практике(хоть и скрыто от глаз) — факт.
Просто напрямую уже не используется.
Вот как умножение в двоичной системе счисления считается через цикл и сдвиг и напрямую уже не используется, но необходимо знать принцип, что бы в практической задаче типа нахождения среднего арифметического избежать переполнения.
Возможно, что задача для собеседования не из лучших, но непонимание таких основ уменьшает производительность работника в разы.
Здравствуйте, gandjustas, Вы писали:
G>99% смогут написать разворот списка имея компьютер и час времени. Обход дерева — 4 часа, ни раз не писав обходы до этого.
Я, конечно, извиняюсь, но о каком дереве речь идет ? Если об обычном двоичном дереве, то 4 часа — гм... Примерно по строчке в час получается.
Здравствуйте, 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>Ты, видимо, ничего не понял, либо я плохо объяснил. То, что элементы лежат в массиве не значит, что их порядок совпадает с порядком следования в массиве. Это полноценный список со всеми его плюсами и минусами.
А в чем тогда смысл использования? Как я понимаю, список может оказаться наилучшим решением, когда производительность вставок в середину важна, а скорость прохода по коллекции нет. Вроде и полилинии, и проводники, и контуры полигонов намного чаще обходятся, чем изменяются. Минусом же является и производительность и усложнение кода — рекурсию сложнее читать чем циклы. Соответственно непонятно в чем выгода от использования списков для решения этих задач.
Говорили же об обходе дерева.
