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

, то ошибка уровня последнего знака (

или около того), превращается в большую по абсолютной величине.
Менее вероятные варианты - ошибка в вычислении факториалов, связанная с переполнением (при рекурсивном расчёте вряд ли) и эффекты UNDERFLOW (потери всех значащих цифр)
Варианты лечения - в любом случае убрать вычитание близких значений.
Вариант А. Преобразовать формулу, убрав численное вычитание, вычтя аналитически "четный" член рядя из "нечётного"(придётся ограничится случаем чётных m, n, k) и затем складывая.
Вариант Б. Не складывать слагаемые сразу, а писать в массив (лучше два - для положительных и отрицательных). Затем его отсортировать по возрастанию абсолютной величины и сложить отдельно положительные, отдельно отрицательные, и только на последнем этапе получить разность (сегрегация по знаку - чтобы убрать вычитание с риском "катастрофического округления", на финальном этапе величины должны быть не столь грандиозны; сортировка, чтобы, прибавляя малое к большому, не потерять малое, если начинать с малых, сумма будет расти постепенно)
Вариант В. Использовать арифметику повышенной точности. Помимо технических сложностей (непонимания компилятором и необходимости делать ассемблерные вставки) - проблема вновь проявится, пусть позже.
Вариант Г. Обрывать ряд достаточно рано.
Лично я попробовал бы "Б".