Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, diez_p, Вы писали:
I>Если некто не справился с обходом списка, дерева, крайне странно думать, что он понимает итерации, рекурсию и тд.
Тут тоже есть тонкие моменты. Человек не знает например список — ОК. Пусть не знает. Пусть придумает, как можно сохранить множество объектов, чтобы например удаление/вставка занимали констатное время. Плюс там однонаправленный, двунаправленный список и т.д.
А потом элементарная оптимизация , нужен список фрагментированность которого ограничена, чтобы зная расположение в памяти можно было вычислить произвольный адрес элемента: и иначинаются чанки, кастомные аллокаторы, АВЛ деревья для переиндексации Какие-то списки удаленных элементов, либо работа с чанком как массивом, либо длинна масива может быть переменной.
А потом делаем дерево многопоточным и спрашиваем про протоколы синхронизации памяти.
Как по мне, так лучше вообще заменять алгоритмические задачи на задачи по применению SOLID (если на проекте практикуется чистый ООП-шный код) и GRASP.
Пусть это будет алгоритмически простая задача, но например с вариациями (тогда применяем полиморфизм из GRASP), или дан код, который дублируется в нескольких методах частично, и нужно избавиться от дублирования, применив Template Method (выделив повторяющийся код в абстрактные методы, а отличающиеся детали в методы подклассов). Или дан код, нарушающий принцип подстановки Лисков, и нужно самостоятельно понять что именно этот принцип нарушен и предложить решение.
Здравствуйте, diez_p, Вы писали:
I>>Если некто не справился с обходом списка, дерева, крайне странно думать, что он понимает итерации, рекурсию и тд. _>Тут тоже есть тонкие моменты. Человек не знает например список — ОК. Пусть не знает.
Это говорит об отсутствии элементарной грамотности, отсутствии минимального опыта с базовыми структурами данных, отсутствии адекватного образования и много чего еще.
>Пусть придумает, как можно сохранить множество объектов, чтобы например удаление/вставка занимали констатное время.
Каким чудом он натренировал вычислительную сложность без базовых структур данных ?
Такие люди лично мне встречались — жосткие самоучки, дерево знаю — список не знаю, сложное знаю — простое не знаю. И всегда такие пробелы показывали просто чудовищные провалы почти в каждой из областей.
Фактически, натретировались ровно на конкретные кейсы, не вникая.
> Плюс там однонаправленный, двунаправленный список и т.д.
Если ты не знаешь списков — то даже заподозрить не сможешь типичные решения типичных задач. Эта область для тебя отсутствует.
_>А потом элементарная оптимизация , нужен список фрагментированность которого ограничена, чтобы зная расположение в памяти можно было вычислить произвольный адрес элемента: и иначинаются чанки, кастомные аллокаторы, АВЛ деревья для переиндексации Какие-то списки удаленных элементов, либо работа с чанком как массивом, либо длинна масива может быть переменной.
Ага — списки не знает, но чанки умеет Чудо то какое.
_>А потом делаем дерево многопоточным и спрашиваем про протоколы синхронизации памяти.
Если нет списков, то никаких деревьев не будет и в помине.
_>P.S я не С++ программист и не алгоритмист
Это ничего не меняет. Список это одна из базовых вычислительных моделей, встречается по сотне раз на день.
Здравствуйте, Ikemefula, Вы писали:
I>Это ничего не меняет. Список это одна из базовых вычислительных моделей, встречается по сотне раз на день.
Вы шаблонно мыслите. Человек не знает списков, допустим. Как они решал задачи которые связаны с ними? Не решал, значит надо посмотреть, решал — ок, знаит не вдумывается как рабоотает, одной стороны хорошо: работает — не трогай, с другой: знаит в случае чего придется потратить время на копание ибо незнает.
Все IT это применение стандартных решений или свое велосипедо строение, под конкретно свою узкую задачу.
Если человек не может придумать свой велосипед, на уже решенную задачу — какой он тогда программист? Построение велосипедов может потребоваться значительно раньше, чем будет изобретено коробочное решение.
Лично я писал свой react еще в 2007 году, а DI контейнер до меня велосипедисты написали еще на .NET 1.1.
т.е. сам факт не знания списков еще ни о чем не говрит, надо копать глубже.
Здравствуйте, diez_p, Вы писали:
I>>Это ничего не меняет. Список это одна из базовых вычислительных моделей, встречается по сотне раз на день. _>Вы шаблонно мыслите. Человек не знает списков, допустим. Как они решал задачи которые связаны с ними? Не решал, значит надо посмотреть, решал — ок, знаит не вдумывается как рабоотает, одной стороны хорошо: работает — не трогай, с другой: знаит в случае чего придется потратить время на копание ибо незнает.
Не знает списков — значит не знает одну из самых часты вычислительных моделей. До свидания.
_>Все IT это применение стандартных решений или свое велосипедо строение, под конкретно свою узкую задачу. _>Если человек не может придумать свой велосипед, на уже решенную задачу — какой он тогда программист? Построение велосипедов может потребоваться значительно раньше, чем будет изобретено коробочное решение.
Если велосипедить простейшие вещи, как списки — далеко не уедешь. Студент 2го курса справится куда лучше такого кандидата.
_>Лично я писал свой react еще в 2007 году, а DI контейнер до меня велосипедисты написали еще на .NET 1.1.
Реакт это гораздо больше чем списки, а DI — тем более.
_>т.е. сам факт не знания списков еще ни о чем не говрит, надо копать глубже.
Наоборот — это отсутствие опыта. Списки это
1 простейшая ссылочная структура данных, все остальное гарантировано сложнее.
2 обработка данных порциями — дай следующую часть, дай следующую часть, и тд
То есть, кандидат как то ухитрился пройти мимо всего этого.
Если кандидат не умеет простые вещи на списках, это говорит о том, что его квалификация примерно 1...2 семестр первого курса профильной специальности. Списки обычно или на втором семестре 1го курса, или на 1 семестре 2го курса.
Здравствуйте, kaa.python, Вы писали:
KP>Ты в серьез утверждаешь, что переключение контекста в Windows настолько тяжелая операция? Я не спец в этих ваших вендах, но в нормальных ОС типа Linux речь идет о микросекундах
, нужен список фрагментированность которого ограничена, чтобы зная расположение в памяти можно было вычислить произвольный адрес элемента: и иначинаются чанки, кастомные аллокаторы, АВЛ деревья для переиндексации Какие-то списки удаленных элементов, либо работа с чанком как массивом, либо длинна масива может быть переменной.
Чудо то какое.
