Mrrl

Я обычно делаю так. Предположим, что желаемая форма графика известна - прямая, парабола, синусоида, поверхность второго порядка... Ищу коэффициенты наилучшего приближения по методу наименьших квадратов. Смотрю для каждой точки величину остаточной ошибки, считаю средний квадрат ошибок (сигму). Отбрасываю все точки, для которых ошибка больше 2.5*сигма, для остальных ищу график снова. И так, пока процесс не стабилизируется.
А вообще надо подробнее написать, что за данные, откуда они взялись, в каком диапазоне, что нужно от графика - например, должен ли он строго проходить через точки, или должен проходить в области наибольшего сгущения, известно ли что-нибудь про зависимость заранее... А так задача слишком общая.

Например, так:

double FindMinimum(Func<double,double,double>F,out double x1,out double x2){
     x1=x2=0;
     return F(x1,x2);
}

Тогда вызов поиска минимума будет double zmin=FindMinimum(f1,out x,out y);

Как-то так:

int S0[37],S1[37],S2[37],S3[37],S4[37];

void Expand(int *a,int *b,int n){
	int s0=0;
	for(int i=0;i<n+10;i++){
		if(i<n) s0+=a[i];
		if(i>=10) s0-=a[i-10];
		b[i]=s0;
	}
}

int Conv(int *S,int balance,int m){
	int res=0;
	while(--m>=0) res+=S[m]*S4[balance+m];
	return res;
}

// number of tickets in 0..u-1
int NHappy(int u){
	int res=0;
	int balance=0;
	int digit;

	digit=u/10000000; u%=10000000;
	for(int i=0;i<digit;i++) res+=Conv(S3,balance++,28);
	digit=u/1000000; u%=1000000;
	for(int i=0;i<digit;i++) res+=Conv(S2,balance++,19);
	digit=u/100000; u%=100000;
	for(int i=0;i<digit;i++) res+=Conv(S1,balance++,10);
	digit=u/10000; u%=10000;
	for(int i=0;i<digit;i++) res+=S4[balance++];
	digit=u/1000; u%=1000;
	for(int i=0;i<digit && balance>=0;i++) res+=S3[balance--];
	digit=u/100; u%=100;
	for(int i=0;i<digit && balance>=0;i++) res+=S2[balance--];
	digit=u/10; u%=10;
	for(int i=0;i<digit && balance>=0;i++) res+=S1[balance--];
	if(balance>=0 && balance<u) res++;
	return res;
}

void __cdecl main(){
	S0[0]=1;
	Expand(S0,S1,10);
	Expand(S1,S2,19);
	Expand(S2,S3,28);
	Expand(S3,S4,37);

	int m,n;
	for(;;){
		printf("m,n: ");
		scanf("%d%d",&m,&n);
		printf("Result: %d\n",NHappy(99999999)+1-NHappy(m)-NHappy(99999999-n));
	}
}

Проверок входных данных не делается. На простых тестах результаты были правильными. Работает, по моим оценкам, быстрее, чем за 2000 операций. Если нужно проверять много диапазонов, то можно предварительно вычислить частичные суммы Conv() в циклах, и тогда любой диапазон сосчитается за два десятка операций (и при этом не будет требовать гигабайта памяти).

UPD: Вот оптимизированный вариант:

int S[8][38];

void InitS(){
	for(int i=1;i<38;i++) S[0][i]=1;
	for(int a=1;a<9;a++){
		int s0=0;
		for(int i=1;i<=37;i++){
			s0+=S[a-1][i];
			if(i>10) s0-=S[a-1][i-10];
			S[a][i]=s0;
		}
	}
}

// number of tickets in 0..u-1
int NHappy(int u){
	int res=0;
	int balance=36;
	for(int a=7,b=10000000;a>=0;a--,b/=10){
		int digit=u/b;
		u%=b;
		int b1;
		if(a>3){
			balance-=9;
			res+=S[a][b1=balance+digit]-S[a][balance];
		} else{
			b1=balance-digit; if(b1<0) b1=-1;
			res+=S[a][balance+1]-S[a][b1+1];
		}
		balance=b1;
	}
	return res;
}

void __cdecl main(){
	InitS();
	int m,n;
	for(;;){
		printf("m,n: ");
		scanf("%d%d",&m,&n);
		printf("Result: %d\n",NHappy(99999999)+1-NHappy(m)-NHappy(99999999-n));
	}
}

Не спрашивайте, почему :)

Зависит от длины константы. Что короче - загрузить её в регистр непосредственно в команде, или взять из памяти (указав в команде адрес)? Сильно зависит от процессора.
В целом, одинаковые константы в алгоритме это не страшно. Хуже, когда одно и то же условие приходится проверять много раз. Или, что ещё страшнее, условия, следующие одно из другого (проверили, что a < b, а потом проверяем, что a+c < b+c). Такое часто встречается в геометрии. И в этом случае над алгоритмом стоит поработать.

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

Если вы хотите экономить память, то проблема будет не в переменных, а в больших структурах (списки, массивы, словари...). Мне чаще всего встречаются такие ситуации:
- память в обмен на время. Запоминать результаты или вычислять заново? Иногда здесь удаётся обменять экспоненциальное время на полиномиальное, или уменьшить степень полинома на 1 или на 2. Но чаще выигрыш идёт только в константу раз (хотя в узком месте это может быть немаловажно). Впрочем, иногда вычислить функцию оказывается быстрее, чем найти её значение в таблице - так что надо такие оптимизации проверять.
- замена обработки большого массива в памяти на послойную обработку (когда очередной фрагмент/строка/двумерный слой трёхмерного массива... вычисляется, обрабатывается, а уже ненужный слой забывается). Здесь память экономится за счёт серьёзного усложнения кода - приходится писать всякие конвейеры. Зато появляется шанс сэкономить ещё и время с помощью параллельной обработки.
- хранение данных, которые должны быть в памяти, в упакованном виде. Трудно читать, очень трудно писать, код усложняется, время теряется. Но появляется шанс уложиться в 3 ГБ и остаться в 32-битном режиме (если это важно).
- хранение в памяти против чтения из файла. Либо будет теряться время, либо усложняться код (если сумеете воспользоваться асинхронным чтением/записью).
- в тяжелых случаях - экономия байтов кода (это если пишете на ассемблере). Может пригодиться, если действительно пишете сервер для кофеварки. Но возможно, здесь лучше попытаться поставить процессор помощнее.

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

Лишние пробелы - это те, которых больше одного подряд?

List *delSpaces(List *p) {
    for(List **a=&p;*a;){
        if((*a)->c==' ' && (*a)->next && (*a)->next->c==' ') *a=(*a)->next;
        else a=&((*a)->next);
    }
    return p;
}

Не проверялось.

Если расстояние равно d, то вторая точка имеет координаты x=10+d*cos(t), y=10+d*sin(t), где t - какое-то число. Если на вторую точку есть дополнительные условия, то координаты иногда можно найти точнее.

Решить задачу легко - заводите массив A[N,N], в каждой клетке [K,M] которого будет записано число лесенок из K кубиков, нижний слой которых состоит из M кубиков. Число будет ненулевым, когда M <= K <= M*(M+1)/2.
Массив заполняется начиная со строчки K=1 по формуле A[K,M]=sum(A[K-M,r],r=1..M-1). Сумма элементов в строчке K=N будет искомым числом.

В решении, ссылку на которое вы дали, последовательно вычисляется число лестниц из j кубиков, нижний ряд которых не длиннее, чем i кубиков. Чтобы найти это число, надо к уже найденным лестницам, нижний ряд которых не длиннее, чем i-1 кубик (их мы оставляем без изменения), прибавить лестницы из j-i кубиков с нижним рядом не длиннее, чем i-1 кубик (к ним мы добавим ряд из i кубиков). Что и делается во внутреннем цикле.

Надеюсь, что остаток берётся всё-таки от деления на 390, а не на 389 - иначе смысла в коде вообще не видно.
Итак, у нас есть 77 простых чисел, меньших 390. Четыре из них - 2,3,5,13 - не более, чем мусор, дающий лишние срабатывания алгоритма. В самом деле, если x%390==3, то x делится на 3, а значит, оно составное. Остальные 73 числа годятся.
Получается такая картина. Для простого x величина x%390 - некоторое число, взаимно простое с 390. Причём распределены эти остатки более-менее равномерно (на картинке они выглядят как красные столбики). Всего этих остатков 96.
Если x - простое число, то с вероятностью 73/96 остаток будет простым числом, и алгоритм честно скажет "скорее, простое". С вероятностью 23/96 - те самые 25% - остаток окажется составным, и алгоритм ошибётся.
Если x - составное, то вероятность того, что число объявят "скорее, простым" будет равна 77/390-1/ln(x) (первое слагаемое - вероятность того, что остаток оказался простым, а второе - доля простых чисел в окрестности x).
Можно легко избавиться от ошибки первого вида: для этого надо в массив charr положить не простые числа, а числа, взаимно простые с 390. Тогда если алгоритм скажет "составное", то так и есть.
Можно было вместо 390 взять N=30030=2*3*5*7*11*13. Если массив будет заполнен числами, взаимно простыми с N, то отсеиваться, как составные, будет 4 числа из 5, а ложных отсеиваний простых чисел не будет вообще.

Есть простое решение за (число сообществ)*(число связей "пользователь-сообщество").

Для каждого сообщества Y:
- заводим массив R[C], где C - число сообществ
- для каждого пользователя X из сообщества Y:
- - для каждого сообщества M, в которое входит пользователь X: R[M]=R[M]+1
- для каждого сообщества M: если M!=Y и R[M] > 1, то пара (Y,M) - ядро.

Быстрее пока не получается.