Как вывести кратчайший путь в графе?

Вам надо еще в самом начале в searched помещать начальную вершину.

А потом надо начать с конца и делать v = path[v], пока не придете в начало.

Сколькими способами можно расставить на шахматной доске 8 ладей таким образом, чтобы они не били друг друга?

asault_ceko,

А доказательство одного решения не является отрицанием другого возможного решения.

в этой задаче один ответ - число. И если вы доказали, что оно равно чему-то, то любое "решение", дающее другой ответ - автоматически неправильное. Ну или у вас ошибка в доказательстве первого решения, но тут не этот случай.

Сколькими способами можно расставить на шахматной доске 8 ладей таким образом, чтобы они не били друг друга?

asault_ceko, Ну вот уже на вашей картинке, где у вас 2 ладьи стоят - вы эту ситуацию можете получить двумя способами: когда на первом шаге взяли правую-верхнюю ладью, а на втором - левую-нижнюю; и когда наоборот. Это одна и та же расстановка ладьей, а подсчитана уже дважды.

Более быстрый способ нахождения всех делителей числа?

PythonDemon, делитель 2 обработать битовыми операциями. А дальше начинать с 3 и делать +=2. Не считать i*i каждый раз, а один раз подсчитать sqrt(n). Вместо if-else использовать вложенный while. Возможно это будет быстрее из-за более короткого и развернутого цикла.

Но вообще, эти все оптимизации - это не про питон. Перепишите алгоритм на C++ какой-нибудь, там можно микрооптимизировать. А питон так далек от CPU, что вряд ли что-то тут поможет. Первый совет будет - переписать на язык с оптимизирующим компилятором.

Где Decimal в C++?

Ланской Кирилл, Ну, FPU уже лет 25, как часть процессора. Когда-то давно это был со-процессор. Но сейчас работа с float ничем не отличается от работы с int с точки зрения процессора.

Еще раз, если у вас числа маленькие (скажем, суммарно до 17 значащих цифр), то ваши Decimal ничем принципиально не отличаются от int64_t. И ничего в процессоре менять для них специально не надо. Не забывайте только при умножении/делении на 10^N делить/домножать, но это процессор уже умеет.

Если же они у вас длинные (до 1000 знаков, например, как в питоне), то сделать схему, которая работает с такой длинной входных данных - практически невозможно. Она будет жрать слишком много транзисторов и будет не эффективна для маленьких чисел. Поэтому вся "длинная арифметика" - выполняется кучей инструкций над кусочками длинных чисел.

Ну и почти в любом случае эти ваши Decimal можно заменить на float. Ибо часто не надо больше 18 значащих знаков. Поэтому за все время существования процессоров, никто так и не удосужился впендюрить в них специальные блоки для работы с такими числами.

Где Decimal в C++?

Ланской Кирилл,
Числа с плавающей запятой применяются чаще потому что:

1) Они сильно быстрее чисел с фиксированной точкой. Потому что короткие числа с фиксированной запятой вы можете сами запросто реализовать в целых числах (например, считайте деньги в копейках, при выводе делите на 100). Или расстояние меряйте в целых миллиметрах, а не в float метрах. Время - в милисекундах. Тут вам никакой специальный тип не нужен.
А длинные decimal, как в питоне - это очень медленно. В процессоре есть операции для работы с float/double. А с числами произвольной длины процессор работать напрямую не может. Это надо руками циклы реализовывать. То же деление - и то в столбик надо делать! А целые и float за одну операцию обрабатываются, в процессоре есть специальные цепи именно для этого.
И использовать такой медленный тип и зависимый от реализации тип - это не философия языков с/с++. Кому надо, напишут/подключат свою библиотеку, которая заточена под их нужды.

2) Числа с плавающей запятой имеют более обширное применение. Ведь редко когда вам достаточно фиксированной абсолютной точности. Как в суммах рублей, где точности до копейки хватит. Обычно вы не знаете заранее, сколько вам знаков понадобится. Очень маленькие числа нужны точнее, очень большие - не так важно. Вот и появляется идея плавающей запятой.

Как транспонировать биты числа максимально быстро?

SergeySerge11, вы правы, я не в том порядке маски для строк выписал.

Почему нельзя использовать private метод в качестве аргумента для алгоритмов в другом private методе?

Давайте пример кода и всю ошибку. Вполне можно использовать приватные методы в алгоритмах.

Может, у вас проблема с тем, что вы пытаетесь не статические методы использовать? вот с этим действительно проблема может быть. Надо метод в bind оборачивать, потому что не статические методы на самом деле имеют +1 аргуент, они еще и this принимают под капотом.

Ошибка в алгоритм получения интерполяции с помощью Лагранжа?

BlinCT, Ну вот вы рассчитали точки, когда полотно было 25x300. Когда его размер 100x600 вам надо все координаты домножить на 100/25 по x и 600/300 по y.

Ошибка в алгоритм получения интерполяции с помощью Лагранжа?

BlinCT, Ну тут у вас все точки растягиваются вместе с графиком. По идее просто все числа домножаются на коээфициент растяжения по оси OX и по оси OY. Если вы график увеличили c 25 x 300 до 100 x 600, то вы все x координаты умножаете на 4, а y - на 2.

Ошибка в алгоритм получения интерполяции с помощью Лагранжа?

BlinCT, Я не понимаю, что у вас за размер. У вас есть ключевые точки, кривая через них пройдет и никак иначе.

Ошибка в алгоритм получения интерполяции с помощью Лагранжа?

BlinCT, Вот, например, статья. Там с кодом. https://habr.com/ru/articles/749288/

Вам точно также придется 2 раза прогнать для данных {i, xi} и {i, yi}, потому что этот метод все еще не работает с вертикально расположенными точками.

И вообще, гуглите: интерполяция кубический сплайн на плоскости.

Ошибка в алгоритм получения интерполяции с помощью Лагранжа?

Стоп. Вам надо, чтобы линия проходила через вот эти вот все точки, так? Тогда никакого пересчета делать нельзя.

Возможно, кривая будет очень сильно уходить далеко, а потом возвращаться к этим точкам. В этом случае, вам стоит подумать о другом методе интерполяции.

Вы сейчас все точки итерполируете одним полиномом очнь большой степени. А вам нужны, допустим, кубические сплайны - вы там каждый кусок между двумя точками будете интерполировать полиномом маленькой степени. Тогда кривая не будет так далеко убегать между точками.

Ошибка в алгоритм получения интерполяции с помощью Лагранжа?

BlinCT, Да, первый лист выглядит так. Второй:
0;24
1;21
2;18
3;16
4;11
5;8

Результаты нельзя просто объединить. Вам над взять y от первого листа и потом y от второго. Это и будет список x,y координат точек. При этом они могут идти вертикально, справа-налево или вообще закручиватья в спираль. Что совсем не полином, но по крайней мере, эта гладкая кривая пройдет через все ваши изначальные точки.

Ошибка в алгоритм получения интерполяции с помощью Лагранжа?

Что именно? вы хотите вариант с параметрической функцией для x и y?

Просто весь ваш код оборачиваете в функцию. Передаете ей list 2 раза, только первый раз m_X равен номеру точки, m_Y равен m_X точки. Второй раз m_X тот же номер, а m_Y равен m_Y точки.

Ошибка в алгоритм получения интерполяции с помощью Лагранжа?

Кстати, по коду, его можно сильно упростить, не надо вам bFirst вообще. Вы просто инициализируйте Hi = 1.0 и в цикле всегда домножайте на calc. Тогда и calc можно выкинуть вообще и просто сразу домножать. Или вообще сразу инициализируйте как list.m_List[j].m_Y.

По какому принципу работает алгоритм с массивом очереди?

Alexandroppolus, Только там жаваскриптовые массивы и там вставляется пустое место прям внутрь. Я не берусь давать никаких гарантий про то, какая там на самом деле структура данных на самом деле используется.

По какому принципу работает алгоритм с массивом очереди?

MishaXXL, Выделяется новый массив размера 2000 элементов. Эти 1000 туда копируются. Потом спокойно дописываются 5 новых в конец.

По какому принципу работает алгоритм с массивом очереди?

MishaXXL, Массив будет размера столько, сколько максимально было заявок в какой-то момент времени (ну, в 2 раза больше на самом деле). Он не будет расти бесконечно.

Кольцевой буфер - он так называется, потому что он замкнут в кольцо. После конца идет начало. Ваши заявки в этом буфере, как змейка в компьютерной игре, дивгаются по этому буферу. С одного конца они добавляются. с другого удаляются. Вся змейка ползет по массиву вправо и оборачивается.

После того, как вы какой-то элемент "удалили", заменив на undefined, он будет снова переиспользован, когда "змейка" пройдет полный круг и вернется на эту позицию.

Если змейка догоняет свой хвост, то массив увеличивается в 2 раза, и змейка помещается туда. Массив не будет длиннее, чем длина змейки*2 в какой-то момент времени. Но массив не растет просто так при добавлении заявок. Если у вас максимум 100 активных заявок есть в каждый момент времени, он никогда не будет длиннее 200. Ибо змейка длины 100 сама себя не догонит в таком массиве никогда и нового увеличения не произойдет.

По какому принципу работает алгоритм с массивом очереди?

MishaXXL, Массив не выделяют сразу фиксированного размера, чтобы вообще все влезло. Выделяют, допустим, 10 элементов. Если циклический буфер заполнился, то перевыделяют память на 20 элементов, все их туда копируют. Когда заполнится этот, выделяют 40 элементов и т.д. В результате любая операция добавления будет O(1) в среднем, ибо эти перевыделения будут происходить все реже и реже за счет увеличения длины в 2 раза. Так работает тот же std::vector.

Если же вы используете связный список, то там памят выделяется отдельно под каждый элемент по мере надобности.