Wataru

Нужно обратить все операции и делать их задом наперед.

Шифрование делает 34567890 итераций, вам надо сделать столько же. Внутри порядок операций надо развернуть, чтобы отмены выполнялись в обратном порядке. Если в строке 2 операции, например умножение и вычитание, то сначала надо выполнить обратное к вычитанию и только потом обратное к умножению.

Обратные к вычитанию и сложению - сложение и вычитание соответственно. Если шифрование прибавляет 12345, то вам надо 12345 вычитать в дешифраторе. Побитовое исключающее ИЛИ обратно само себе, ведь если его применить 2 раза, то получится исходное число.

С умножением все гораздо сложнее. Я предполагаю, что тип state - unsigned int. Если он знаковый, то умножение с переполнением - это undefined behavior вообще. В безнаковых целых умножение с переполнением есть просто умножение и взятие по модулую 2^32. Т.е вам нужно найти операцию, обратную умножению по модулю 2^32.

Это будет умножение на обратное по модулю.

Для его нахождения вам надо будет использовать расширенный алгоритм эвклида (в статье по ссылке выше оно расписано). Его можно или реализовать отдельно для нахождения обратных к 31663 (и другим множителям). Или можно его руками на бумажке прогнать.

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

Edit, только заметил в вопросе, что state - двубайтовый. Значит, все происходит по модулю 2^16.

Можно не рекурсивно.

Перебирите все битовые маски (числа) от 0 до 2^n -1 (mask = 0; mask < (1 << n); ++mask).

А внутри при подсчете суммы пройдитесь по всем позициям массива и, если i-ый бит установлен, прибавляйте текущее число. Проверить, что бит установлен можно сделав побитовое и (&) c 1 << i.

Если хотите рукурсивно, то пусть ваша функция принимает текущую позицию и сумму. Если позиция равна n - выводите сумму. Иначе запускайтесь рекурсивно от следующей позиции два раза - с текущей суммой без изменения, и с суммой увеличенной на текущее число.

Картинка не видна, но по коментариям понятно, что вам хочется получать только выпуклые многоугольники?

Проверить, что что-то не так можно через векторное произведение последовательных сторон.

Для всех 3 подряд идущих вершин a, b и c, то надо проверить, что (b-a)*(c-b) всегда дает одинаковый знак (или всегда <=0 или всегда >=0). Это векторное произведение.
Формула в вашем случае будет (xb-xa)*(yc-yb)-(xc-xb)*(yb-ya).

Еще можно построить выпуклую оболочку (convex hull).
Вот расписан алгоритм, как ее построить по заданным точкам: https://e-maxx.ru/algo/convex_hull_graham

Edit: Еще можно, вместо сортировки точек в выпуклую оболочку, игнорировать клики от пользователя, которые делают текущий многоугольник невыпуклым. Опять же, проверку невыпуколсти можно делать только для новых сторон: В последней, новой и первой точках.

У вас правильная идея, что двух чисел в ответе всегда достаточно. Всегда можно выдать, например, n, n-1 и эти две операции покроют все позиции с 1 по n.

Но вот случай, когда достаточно одного числа вы неправильно разобрали. Почему вы ищите самое большое простое число? Какой вообще смысл смотреть, что в позиции ans-1 стоит c?

А еще ваш код выводит 0 неверно иногда.

Вы, может, задачу неправильно поняли? Надо сделать так, что бы все позиции, в которых символы отличные от c, не делились бы на хотя бы одно число в вашем ответе.

Ваша рекурсия восстонавливает ответ в динамическом программировании в матрице.

Построение матрицы менять не надо, оно просто считает оптимальную длину LCS. Вам надо отдавать приоритет переходам вверх (или влево) пока это возможно при восстановлении ответа.

Но можно сделать простой хак - усеките ваш текст как можно короче, пока LCS все еще оптимального размера.

Вам надо найти самое первое максимальное число в последней строке (или столбце, в зависимости от того в какой из входных строчек вы хотите как можно левее найти вхождение. Я не в курсе, что у вас за aCompareFunc).

От этой позиции и запускайте ваш DoDiff вместо левой нижней ячейки матрицы.

Значения максимума даже не надо искать, он будет в левом нижнем углу матрицы. Вам остается только циклом найти самое левое число в строке (столбце) равное последнему.

Вам еще придется в конце зарепортить необходимое количество l3diffDeleted или l3diffAdded, чтобы восстановить усеченную часть.

Это и есть нормальное преобразование float в int - с округлением вниз.

Edit: Видимо, проблема в том, что 0.9 нельзя идеально точно представить в float. На самом деле там хранится что-то вроде 0.8999999.... При домножении на 10 и округлении вниз вы получите 8, а не 9.

Надо использовать округление к ближайшему - round.

Используйте std::vector. Он автоматически расширяется и при этом работает быстро.

Тут проблема не в том, что член класса char*, а в том, что запись идет в char*, и из-за strict aliasing правил - это может быть запись куда угодно, в том числе в &this. Кешировать пришлось бы любой член структуры, любого типа.

Эту же проблему можно воспроизвести в меньшем масштабе, если у вас в цикле есть запись в int* и чтение какой-то другой не меняющейся int переменной. Особенно, когда переменная в куче и указатель пришел в параметре функции. Вот компилятор офигеет и будет на каждой итерации ее загружать в регистр заново. Опять же, потому что ну не может он понять, что вот этот вот указатель не указывает на вот эту вот переменную.

Частично это можно решить кешированием, можно попробовать поменять типы кое где. Но делать это не стоит - это та самая преждевременная оптимизация, о которой писал Кнут. Лучше алгоритм хороший и структуры данных правильные в вашей программе выберите. А уже дальше, если профилирование покажет, что вот тут вот узкое место, то можно смотреть на ассемблерный код и думать, как убедить компилятор геренировать что-то более быстрое.

У вас решение за O(MN), когда как можно за O(M log N).

Вы говорите, что оно линейно, но вы выполняете линейное количество операций на каждый элемент массива b. Это медленно. Ваша проблема в том, что вы храните все индексы для каждого значения просто в списке и потом там наивно ищите первое вхождение больше данной границы. Можно список хранить в Set. Вот я не в курсе, умеет ли он, как C++-шный set искать первый элемент больше заданной границы. Если нет, то можно тупо хранить отсортированые списки индексов, тогда там можно будет делать бинпоиск.

Если это С++ и вы используете std::string, то можно строки тупо суммировать через +=.

Если по условию задания вам надо делать все руками, то нужно выделить память, чтобы все поместилось, а дальше можно воспользоваться strcat_s, memcpy или вообще посимвольно копировать.

Ну посмотрите в документацию же.

Там английским по белому написано:

The number of characters successfully read and stored by this function can be accessed by calling member gcount.

И даже пример внизу есть.