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

BFE>>>Однако! Бывает же... Что, настоящий обход дерева с запоминанием посещённых узлов?
EP>>Да, с маркировкой посещённых.
BFE>А с какой целью был обход графа? Что нужно было найти?

Компоненты связности.

BFE>>>Иначе это уже не список.
EP>>Почему? Например кольцевой список
BFE>Например потому, что std::find к нему применить прямо не получится.

Это не "не список", а "не диапазон по определению STL". Но речи о том что это будет диапазоном STL — не было.

EP>>>>Ты же, как я понимаю, пытаешься подвести к тому что графы в явном виде редки, и поэтому не нужны. Вот тут с ассоциативностью аналогия 100%.
BFE>>>Ассоциативность в С++ встречается в каждом выражении, где есть через аргумент идущие одинаковые знаки a+b+c. Порядок сложения не определён.
EP>>1. Порядок сложения определён. Более того, для плавающей точки изменение порядка даст разный результат, так как такие операции как раз не ассоциативны.
BFE>Насколько я помню стандарт, порядок не определён до тех пор, пока он не влияет на результат. Точно, см в стандарте 1.9/9

Это только для встроенных ассоциативных типов

http://eel.is/c++draft/intro.execution#footnote-7
Overloaded operators are never assumed to be associative or commutative.

EP>>2. Я про другую ассоциативность — про свойство бинарной операции, а не про порядок вычисления в отсутствии скобок.
BFE>

BFE>Note: Operators can be regrouped according to the usual mathematical rules only where the operators
BFE>really are associative or commutative.
BFE>

BFE>

Я выше сноску процитировал. В любом случае, перегруппировка скажем сложения unsigned'ов на результат не влияет.

И повторюсь, я не про ту ассоциативность которая левая или правая, а про ту которая позволяет скобки переставлять без изменения результата. И вот она в явном виде в коде практически не выражается, при этом используется неявно (без выражения непосредственно в коде) например при параллельной редукции. Собственно это пример к моему исходному поинту о том, что даже если что-то в коде не выражается явно, это не означает что эти знания не полезны и не нужны.

EP>>То что где-то например граф зашит в алгоритме неявно, совсем не означает что до этого алгоритма додумались без теории графов.
BFE>Но и об обратном это так же не говорит.

Да, и об обратном тоже не говорит. Поэтому не пойму почему ты делаешь акцент на неявности.

EP>>

F>>>>Допустим прихожу я устраиваться на с++ разработчика, какой должен быть минимальный уровень знания математики? каких разделов и где та линия после которой меня примут?
LVV>>>Зависит от решаемых задач.
LVV>>>Но полезно знать алгебру, вероятности, графы — это по-любому.

BFE>"графы — это по-любому" как понимать?
BFE>Я понял — в обязательном порядке. Хотя, конечно, 'никак не знать' — это тоже "по-любому"...

Я это распарсил как "полезно знать (x,y,z) — это по-любому". Но это уже вопрос толкования, и не суть важно.

Мои основные тезисы:
— обозначенные знания не являются жёстким требованием ко всем программистам. Да, без них получится создавать реальный код, решающий некоторые реальные задачи, и получать за это реальное вознаграждение.
— для тех кто хочет стать хорошим программистом — эти знания обязательны.
— даже если допустить что эти знания являются балластом и на практике не нужны — они всё равно проверяются на некоторых реальных собеседованиях, что немаловажно.
— программирование по большей части это математическая активность — так как происходит оперирование абстрактными объектами, идеями и структурами. Более того — это строгая (rigour) математическая активность, так как нет возможности пропустить "очевидные" этапы и шаги — нужно закодировать всё — от самых низших уровней до высших. ЕМНИП, подобный тезис был у Александра Степанова. С этой позиции заявления вида "программистам математика не нужна" нелепы.