Здравствуйте, ferz1, Вы писали:
F>Допустим прихожу я устраиваться на с++ разработчика, какой должен быть минимальный уровень знания математики? каких разделов и где та линия после которой меня примут?
Если работа не связана с какими-то специальными математическими методами и моделями -- ноль.
Здравствуйте, rm822, Вы писали:
R>Я иногда спрашиваю во сколько раз сортировка 1млн элементов медленнее 100к элементов, и выгоняю тех кто не может посчитать двоичный логарифм от 10 или считает его по основанию e
А вот здесь я не понял. Исходя из оптимальной сложности сортировки O(n * log(n)), ответом будет 10 * log(1M) / log(100K). Мы вольны выбирать здесь любое удобное основание для логарифмирования, потому как отношение логарифмов не зависит от их основания и при любом основании будет одинаковым. И самым удобным в данном случае является не 2, и не e, а 10: 10 * 6 / 5 = 12. Поясни, пожалуйста, почему ты считаешь, что основание должно быть именно 2 и зачем вообще здесь нужно считать логарифм от десяти?
--
Справедливость выше закона. А человечность выше справедливости.
Здравствуйте, rg45, Вы писали:
R>>Я иногда спрашиваю во сколько раз сортировка 1млн элементов медленнее 100к элементов, и выгоняю тех кто не может посчитать двоичный логарифм от 10 или считает его по основанию e R>А вот здесь я не понял. Исходя из оптимальной сложности сортировки O(n * log(n)), ответом будет 10 * log(1M) / log(100K). Мы вольны выбирать здесь любое удобное основание для логарифмирования, потому как отношение логарифмов не зависит от их основания и при любом основании будет одинаковым. И самым удобным в данном случае является не 2, и не e, а 10: 10 * 6 / 5 = 12. Поясни, пожалуйста, почему ты считаешь, что основание должно быть именно 2 и зачем вообще здесь нужно считать логарифм от десяти?
Во-первых вычислительная сложность выражается не только асимптотическими оценками, но и например точным/абсолютным ограничением на количество операций. Например std::partition_point делает не более log2(N)+2 сравнений. Ограничения на std::stable_sort также выражены через двоичный логарифм в абсолютном виде.
(при этом количество каких-то из операций необязательно прямо пропорционально затраченному времени на реальном железе, поэтому строго говоря нужно делать соответствующие оговорки)
Во-вторых асимптотическая сложность Θ не даёт ответа на вопрос "во сколько раз медленнее N=100k vs N=1M" в прямом смысле, а лишь классификацию по классам эквивалентности.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Во-первых вычислительная сложность выражается не только асимптотическими оценками, но и например точным/абсолютным ограничением на количество операций. Например std::partition_point делает не более log2(N)+2 сравнений. Ограничения на std::stable_sort также выражены через двоичный логарифм в абсолютном виде. EP>(при этом количество каких-то из операций необязательно прямо пропорционально затраченному времени на реальном железе, поэтому строго говоря нужно делать соответствующие оговорки) EP>Во-вторых асимптотическая сложность Θ не даёт ответа на вопрос "во сколько раз медленнее N=100k vs N=1M" в прямом смысле, а лишь классификацию по классам эквивалентности.
Даже при этих уточнения остаются без ответов вопросы: зачем нужен логарифм десяти, и почему непременно по основанию два.
--
Справедливость выше закона. А человечность выше справедливости.
Здравствуйте, rg45, Вы писали:
R>Даже при этих уточнения остаются без ответов вопросы: зачем нужен логарифм десяти, и почему непременно по основанию два.
Да, согласен — не нужно ни то, ни другое. Подозреваю что логарифм десяти взялся из попытки разложить логарифм произведения, на сумму логарифмов.
Здравствуйте, rg45, Вы писали:
R>Здравствуйте, rm822, Вы писали:
R>>Я иногда спрашиваю во сколько раз сортировка 1млн элементов медленнее 100к элементов, и выгоняю тех кто не может посчитать двоичный логарифм от 10 или считает его по основанию e
R>А вот здесь я не понял. Исходя из оптимальной сложности сортировки O(n * log(n)), ответом будет 10 * log(1M) / log(100K). Мы вольны выбирать здесь любое удобное основание для логарифмирования, потому как отношение логарифмов не зависит от их основания и при любом основании будет одинаковым. И самым удобным в данном случае является не 2, и не e, а 10: 10 * 6 / 5 = 12. Поясни, пожалуйста, почему ты считаешь, что основание должно быть именно 2 и зачем вообще здесь нужно считать логарифм от десяти?
скорее всего он под 100K имел в виду 100 тысяч и из-за употребления "K" у него мысль немного мигрировала в сторону двоичной арифметики, смешав в кучу десятичный логарифм с двоичным (наверное, он хотел сказать "выгоняю тех кто не может посчитать десятичный логарифм от 10 или считает его [ логарифм в формуле максимального времени ] по основанию e")
Здравствуйте, LaptevVV, Вы писали:
BFE>>>>Единственное, что приходит на ум, это граф переходов конечного автомата. EP>>>А как же например вездесущие деревья? BFE>>Деревья — это частный случай, который намного проще. LVV>Не. Зависит от графа и дерева... LVV>В-деревья, АВЛ-деревья — покруче некоторых графов будут...
Не могу согласиться. Деревья принципиально проще графов. Достаточно посмотреть на количество открытых проблем с ними связанных, чтобы это подметить.
Здравствуйте, Erop, Вы писали:
BFE>>Давайте конкретно: какие математические свойства и какие из алгоритмов для графов вы используете в коде. E>Ну, A*, например, часто использую...
И что это означает?
BFE>>Когда я говорю про графы, я не говорю про деревья. E>Если пользоваться общепринятой терминологией, понимать коллег будет проще...
Если дерево называть графом, то проблемы в понимании будут.
EP>>>Это смотря как посмотреть. Список может иметь цикл, а дерево — нет BFE>>Что-то я не припомню, чтобы я когда-то использовал список с циклом внутри... Наличие цикла внутри списка свидетельствует об ошибке, так что в тестовых целях я поиск цикла в списке писал, но назвать это работой с графом... E>std::list когда-нибудь юзал?..
да.
BFE>>И вы хотите сказать, что где-то в коде, в явном виде хранится этот граф переходов? E>А что такое "в явном виде"?
Это когда хранятся и используются все переходы графа.
E>Ну и ты же алгоритмы просил?
да. E>Как найти длину цикла генератора?
Мне на практике такая задача никогда не встречалась, но я сомневаюсь, что для её решения надо строить граф переходов в памяти компьютера.
BFE>>Ну и где там граф? Там нельзя получить граф, как структуру. Нельзя запустить поиск по графу, если я правильно понимаю. E>Таки std::vector<std::vector<int> > g, где g[i] — массив индексов соседних с i-й вершин -- одно из популярных ЯВНЫХ представлений графов Я в курсе. Но если из всего внешнего массива доступен только один элемент, то это не граф.
Здравствуйте, B0FEE664, Вы писали:
E>>Ну, A*, например, часто использую... BFE>И что это означает?
Гуглофу на нуле что ли?
BFE>Если дерево называть графом, то проблемы в понимании будут.
А если лес, например? А если в дереве склеивать совпадающие подветки? Это будет дерево или ациклический направленный граф?
E>>std::list когда-нибудь юзал?.. BFE>да.
AFAIK, одна из популярных реализаций базируется на зацикленном списке нод...
BFE>Это когда хранятся и используются все переходы графа.
А что значит "хранятся"? Если есть функция, которая по id ноды может вернуть id следующей ноды, это в явном виде? Если таки да, то чем ГПСЧ не "явный граф"?
Чем списки соседей в соц. сети не явное представление графа?
BFE>Мне на практике такая задача никогда не встречалась, но я сомневаюсь, что для её решения надо строить граф переходов в памяти компьютера.
А для поиска цикла в списке, нужно?
BFE> Я в курсе. Но если из всего внешнего массива доступен только один элемент, то это не граф.
Это ты о чём?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>>>Ну, A*, например, часто использую... BFE>>И что это означает? E>Гуглофу на нуле что ли?
А область применения?
А то я однажды решал задачу прокладки пути от A к B с обходом препятствий и оказалось, что графы там не нужны.
BFE>>Если дерево называть графом, то проблемы в понимании будут. E>А если лес, например? А если в дереве склеивать совпадающие подветки? Это будет дерево или ациклический направленный граф?
Это будет два объекта: дерево и список.
E>>>std::list когда-нибудь юзал?.. BFE>>да. E>AFAIK, одна из популярных реализаций базируется на зацикленном списке нод...
Интересно. Где можно глянуть?
BFE>>Это когда хранятся и используются все переходы графа. E>А что значит "хранятся"? Если есть функция, которая по id ноды может вернуть id следующей ноды, это в явном виде? Если таки да, то чем ГПСЧ не "явный граф"?
Конечно это не граф.
Вы наверное и вот здесь:
int f(int n)
{
return (n + 1) % 5;
}
граф увидите.
E>Чем списки соседей в соц. сети не явное представление графа?
Вот когда список всех пользователей соц. сети лежит в базе данных, то можно сказать, что в базе данных лежит граф в явном виде. Но если в ничего с этим графом не делаете, то вам от этого ни жарко, ни холодно. Для того, чтобы его можно было рассматривать как граф, нужно чтобы к нему применялись спец алгоритмы применимые к графу. Evgeny.Panasyuk нашел один такой алгоритм, который, наверное, применяется в LinkedIn — поиск знакомого, через знакомого. Вы знаете ещё такие же задачи?
BFE>>Мне на практике такая задача никогда не встречалась, но я сомневаюсь, что для её решения надо строить граф переходов в памяти компьютера. E>А для поиска цикла в списке, нужно?
Нет, конечно.
BFE>> Я в курсе. Но если из всего внешнего массива доступен только один элемент, то это не граф. E>Это ты о чём?
Это я о списке друзей из соц сети.
объект std::vector<std::vector<int> > является графом только тогда, когда к нему применяются алгоритмы применимые к графу.
Здравствуйте, B0FEE664, Вы писали:
E>>Гуглофу на нуле что ли? BFE>А область применения?
Поиск путей в графе
BFE>А то я однажды решал задачу прокладки пути от A к B с обходом препятствий и оказалось, что графы там не нужны.
Бывает. Я, обычно, ищу пути в довольно абстрактных графах. Хотя, иногда, и в графах вполне графической природы. Например, в графе линейного деления...
E>>А если лес, например? А если в дереве склеивать совпадающие подветки? Это будет дерево или ациклический направленный граф? BFE>Это будет два объекта: дерево и список.
Что? Ациклический граф, полученный склеиванием одинаковых веток деревьев?
BFE>Интересно. Где можно глянуть?
Начни с реализации stl в твоём компиляторе
На самом деле, зачем хранить ДВЕ ноды — терминатора, когда можно хранить ОДНУ? То, что возвращает end -- поле list, элемент двусвязного циклического списка. Его next -- это begin списка. Сверху этого всего декоратор, для rbegin и т. д...
BFE>
Ну, да. Это можно интерпретировать, как граф. Например, если рассматривать любые целые n...
E>>Чем списки соседей в соц. сети не явное представление графа? BFE>Вот когда список всех пользователей соц. сети лежит в базе данных, то можно сказать, что в базе данных лежит граф в явном виде. Но если в ничего с этим графом не делаете, то вам от этого ни жарко, ни холодно. Для того, чтобы его можно было рассматривать как граф, нужно чтобы к нему применялись спец алгоритмы применимые к графу. Evgeny.Panasyuk нашел один такой алгоритм, который, наверное, применяется в LinkedIn — поиск знакомого, через знакомого. Вы знаете ещё такие же задачи?
Поиск людей, к которым ведёт много коротких путей, что бы предложить их добавить в своих друзей.
Анализ структуры графа, что бы выявлять накрутки и т. д...
E>>А для поиска цикла в списке, нужно? BFE>Нет, конечно.
Ну так список с циклом это же таки граф?
Почему поиск цикла в таком списке -- это алгоритм на графе, а поиск цикла в ГПСЧ -- нет? Алгоритм-то тот же?
BFE>объект std::vector<std::vector<int> > является графом только тогда, когда к нему применяются алгоритмы применимые к графу.
И?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Ни зачем, считай как хочешь лишь бы правильно было, задача на устный счет и адекватность, прнимаются ответы и "чуть больше десяти" и любой конкретный от 12 до 15
Почти все адекватные по привычке работают с 2-чным степенным рядом
Неадекватные
* не могут связать вопрос с n log n
* не знают что такое логарифм
* умерли на подсчетах взяв его по основанию е
Здравствуйте, Erop, Вы писали:
E>Поиск путей в графе
Это понятно, что поиск пути. А в какой задаче его искать-то потребовалось?
BFE>>А то я однажды решал задачу прокладки пути от A к B с обходом препятствий и оказалось, что графы там не нужны. E>Бывает. Я, обычно, ищу пути в довольно абстрактных графах. Хотя, иногда, и в графах вполне графической природы. Например, в графе линейного деления...
Ну а я как-то обхожусь без этого.
E>>>А если лес, например? А если в дереве склеивать совпадающие подветки? Это будет дерево или ациклический направленный граф? BFE>>Это будет два объекта: дерево и список. E>Что? Ациклический граф, полученный склеиванием одинаковых веток деревьев?
Значит я не понял, что значит склеивать.
BFE>>Интересно. Где можно глянуть? E>Начни с реализации stl в твоём компиляторе E>На самом деле, зачем хранить ДВЕ ноды — терминатора, когда можно хранить ОДНУ? То, что возвращает end -- поле list, элемент двусвязного циклического списка. Его next -- это begin списка. Сверху этого всего декоратор, для rbegin и т. д...
О звёзды! Это что? В списке всегда хранится один лишний элемент с аллоцированной памятью под пользовательские данные? Какой кошмар...
Похоже, что авторы, таки, реализовали эту абсурдную идею с графом из одной вершины.
Нет, ну я не могу отвечать за это извращение. Мало ли, что там под капот засунули...
BFE>>
BFE>>граф увидите. E>Ну, да. Это можно интерпретировать, как граф. Например, если рассматривать любые целые n...
А можно и не рассматривать...
E>Поиск людей, к которым ведёт много коротких путей, что бы предложить их добавить в своих друзей.
Ok. Принимается. E>Анализ структуры графа, что бы выявлять накрутки и т. д...
Не, анализ — это не то...
Анализ — это не для пользователей, а для аналитиков. Аналитики любят красивые картинки...
E>>>А для поиска цикла в списке, нужно? BFE>>Нет, конечно. E>Ну так список с циклом это же таки граф?
Да, список с циклом, это, таки, граф. А что?
E>Почему поиск цикла в таком списке -- это алгоритм на графе, а поиск цикла в ГПСЧ -- нет? Алгоритм-то тот же?
Потому, что список существует как структура и к ней применяется алгоритм. А при поиске цикла в ГПСЧ нам сама структура не нужна, насколько я понимаю.
BFE>>объект std::vector<std::vector<int> > является графом только тогда, когда к нему применяются алгоритмы применимые к графу. E>И?
И они крайне редко нужны на практике.
Здравствуйте, B0FEE664, Вы писали:
BFE>>>Интересно. Где можно глянуть? E>>Начни с реализации stl в твоём компиляторе E>>На самом деле, зачем хранить ДВЕ ноды — терминатора, когда можно хранить ОДНУ? То, что возвращает end -- поле list, элемент двусвязного циклического списка. Его next -- это begin списка. Сверху этого всего декоратор, для rbegin и т. д... BFE>О звёзды! Это что? В списке всегда хранится один лишний элемент с аллоцированной памятью под пользовательские данные? Какой кошмар...
Нет, необязательно. У end'а может быть другой тип (базовый), не включающий память под пользовательские данные.
E>>Почему поиск цикла в таком списке -- это алгоритм на графе, а поиск цикла в ГПСЧ -- нет? Алгоритм-то тот же? BFE>Потому, что список существует как структура и к ней применяется алгоритм. А при поиске цикла в ГПСЧ нам сама структура не нужна, насколько я понимаю.
Алгоритм тот же самый, который как раз обходит структуру. А тот же самый он потому, что структура (в общепринятом математическом смысле) в обоих случаях одинаковая.
А вот выражены ли связи в коде явно как указатели, или же задаются функцией перехода — на применимость алгоритма не влияют
Здравствуйте, Evgeny.Panasyuk, Вы писали:
E>>>На самом деле, зачем хранить ДВЕ ноды — терминатора, когда можно хранить ОДНУ? То, что возвращает end -- поле list, элемент двусвязного циклического списка. Его next -- это begin списка. Сверху этого всего декоратор, для rbegin и т. д... BFE>>О звёзды! Это что? В списке всегда хранится один лишний элемент с аллоцированной памятью под пользовательские данные? Какой кошмар... EP>Нет, необязательно. У end'а может быть другой тип (базовый), не включающий память под пользовательские данные.
Может, но в исходниках именно так. А почему вообще нельзя обойтись без этой ноды?
E>>>Почему поиск цикла в таком списке -- это алгоритм на графе, а поиск цикла в ГПСЧ -- нет? Алгоритм-то тот же? BFE>>Потому, что список существует как структура и к ней применяется алгоритм. А при поиске цикла в ГПСЧ нам сама структура не нужна, насколько я понимаю. EP>Алгоритм тот же самый, который как раз обходит структуру. А тот же самый он потому, что структура (в общепринятом математическом смысле) в обоих случаях одинаковая. EP>А вот выражены ли связи в коде явно как указатели, или же задаются функцией перехода — на применимость алгоритма не влияют
В теории — да, не влияют, а вот на практике зависит от задачи.
В тех же соц. сетях, например, граф друзей сейчас и через секунду — это два разных графа.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
BFE>>>>Иначе это уже не список. EP>>>Почему? Например кольцевой список BFE>>Например потому, что std::find к нему применить прямо не получится. EP>Это не "не список", а "не диапазон по определению STL". Но речи о том что это будет диапазоном STL — не было.
Хорошо, согласен. Кольцевой буфер я использовал на практике, кольцевой список — никогда.
EP>И повторюсь, я не про ту ассоциативность которая левая или правая, а про ту которая позволяет скобки переставлять без изменения результата. И вот она в явном виде в коде практически не выражается, при этом используется неявно (без выражения непосредственно в коде) например при параллельной редукции. Собственно это пример к моему исходному поинту о том, что даже если что-то в коде не выражается явно, это не означает что эти знания не полезны и не нужны.
Ассоциативность явно применяется во многих рекурсивных алгоритмах вида:
f(a,b,c...)
{
return a + f(b,c...);
}
EP>Мои основные тезисы: EP>- обозначенные знания не являются жёстким требованием ко всем программистам. Да, без них получится создавать реальный код, решающий некоторые реальные задачи, и получать за это реальное вознаграждение. EP>- для тех кто хочет стать хорошим программистом — эти знания обязательны. EP>- даже если допустить что эти знания являются балластом и на практике не нужны — они всё равно проверяются на некоторых реальных собеседованиях, что немаловажно.
Согласен. Но не понятно, почему выбраны именно эти знания.
EP>- программирование по большей части это математическая активность — так как происходит оперирование абстрактными объектами, идеями и структурами. Более того — это строгая (rigour) математическая активность, так как нет возможности пропустить "очевидные" этапы и шаги — нужно закодировать всё — от самых низших уровней до высших. ЕМНИП, подобный тезис был у Александра Степанова. С этой позиции заявления вида "программистам математика не нужна" нелепы.
Не соглашусь. В математике легко можно пропустить те или иные действия (по ошибке), в отличии от программирования.
Здравствуйте, B0FEE664, Вы писали:
E>>>>На самом деле, зачем хранить ДВЕ ноды — терминатора, когда можно хранить ОДНУ? То, что возвращает end -- поле list, элемент двусвязного циклического списка. Его next -- это begin списка. Сверху этого всего декоратор, для rbegin и т. д... BFE>>>О звёзды! Это что? В списке всегда хранится один лишний элемент с аллоцированной памятью под пользовательские данные? Какой кошмар... EP>>Нет, необязательно. У end'а может быть другой тип (базовый), не включающий память под пользовательские данные. BFE>Может, но в исходниках именно так.
Я посмотрел в исходниках libstdc++ — насколько я распарсил, там именно так — последний узел имеет только два указателя, без места под данные.
В других реализациях может быть по-другому.
BFE>А почему вообще нельзя обойтись без этой ноды?
Ты имеешь в виду использовать вместо неё nullptr? Не получится — список двусвязный, мы можем взять std::prev от .end(). Можно конечно попробовать без дополнительного узла, но будет сложнее, а главное медленнее.
Да и проблемы в дополнительной ноде нет никакой — она хранится по значению в std::list, и содержит только два указателя которые нужны в любом случае.
То есть схематически там следующая структура данных:
template<typename T, ...>
class list
{
struct base_node
{
base_node *prev, *next;
};
struct value_node : base_node
{
T value;
};
base_node end_node;
...
};
Из этого кстати вытекает что итератор .end() у такого списка инвалидируется при swap'е и т.п., что не запрещено стандартном:
no swap() function invalidates any references, pointers, or iterators referring to the elements of the containers being swapped. [ Note: The end() iterator does not refer to any element, so it may be invalidated. —end note ]
Здравствуйте, B0FEE664, Вы писали:
E>>>>Почему поиск цикла в таком списке -- это алгоритм на графе, а поиск цикла в ГПСЧ -- нет? Алгоритм-то тот же? BFE>>>Потому, что список существует как структура и к ней применяется алгоритм. А при поиске цикла в ГПСЧ нам сама структура не нужна, насколько я понимаю. EP>>Алгоритм тот же самый, который как раз обходит структуру. А тот же самый он потому, что структура (в общепринятом математическом смысле) в обоих случаях одинаковая. EP>>А вот выражены ли связи в коде явно как указатели, или же задаются функцией перехода — на применимость алгоритма не влияют BFE>В теории — да, не влияют, а вот на практике зависит от задачи. BFE>В тех же соц. сетях, например, граф друзей сейчас и через секунду — это два разных графа.
Не вдаваясь в конкретные детали сказанного, то о чём ты говоришь — это переход к другой математической структуре, в которой возможно не выполняются изначальные математические требования.
Например если у тебя есть нечто похожее на группу, но например не имеющее обратного элемента каждому, то применять алгоритмы для групп и использовать теоремы/свойства групп естественно некорректно.
Но из этого не следует ни бесполезность теории групп, ни математики в целом. У тебя в этом случае другая математическая структура, например моноид, и ты можешь использовать алгоритмы и математические свойства для моноидов. Либо например можешь выделить группу из этой структуры, по аналогии с GLn(R) — и уже работать с этой группой.
Также и с графами — если у тебя например не один граф, а целое множество графов соответствующее предыдущим состояниям во времени — то и используй соответствующий мат.аппарат
Здравствуйте, B0FEE664, Вы писали:
EP>>И повторюсь, я не про ту ассоциативность которая левая или правая, а про ту которая позволяет скобки переставлять без изменения результата. И вот она в явном виде в коде практически не выражается, при этом используется неявно (без выражения непосредственно в коде) например при параллельной редукции. Собственно это пример к моему исходному поинту о том, что даже если что-то в коде не выражается явно, это не означает что эти знания не полезны и не нужны. BFE>Ассоциативность явно применяется во многих рекурсивных алгоритмах вида: BFE>
BFE>f(a,b,c...)
BFE>{
BFE> return a + f(b,c...);
BFE>}
BFE>
BFE>
Это не применение ассоциативности, а как раз наоборот — использование жёсткого порядка, а конкретно правая свёртка а-ля foldr.
Применение ассоциативности это например быстрый алгоритм возведения в натуральную степень, который как раз работает за счёт "перестановки скобок" https://www.sgi.com/tech/stl/power.html
И даже там, ассоциативность непосредственно в коде явно никак не выражена, только в имени типа и в документации. Там нигде нету выражения (x*y)*z == x*(y*z), тем не менее это математическое свойство используются неявно.
EP>>Мои основные тезисы: EP>>- обозначенные знания не являются жёстким требованием ко всем программистам. Да, без них получится создавать реальный код, решающий некоторые реальные задачи, и получать за это реальное вознаграждение. EP>>- для тех кто хочет стать хорошим программистом — эти знания обязательны. EP>>- даже если допустить что эти знания являются балластом и на практике не нужны — они всё равно проверяются на некоторых реальных собеседованиях, что немаловажно. BFE>Согласен. Но не понятно, почему выбраны именно эти знания.
Видимо потому что это общие знания, которые широкоприменимы и широкоизвестны.
EP>>- программирование по большей части это математическая активность — так как происходит оперирование абстрактными объектами, идеями и структурами. Более того — это строгая (rigour) математическая активность, так как нет возможности пропустить "очевидные" этапы и шаги — нужно закодировать всё — от самых низших уровней до высших. ЕМНИП, подобный тезис был у Александра Степанова. С этой позиции заявления вида "программистам математика не нужна" нелепы. BFE>Не соглашусь. В математике легко можно пропустить те или иные действия (по ошибке), в отличии от программирования.
Так я же и говорю что программирование как математическая активность более строгая нежели другие распространённые варианты — именно потому что нельзя ничего пропустить и отдать на откуп интуиции, нужно всё закодировать начиная с самого низкого уровня.
