Mrrl

Посмотрите здесь: habrahabr.ru/post/253105
Может быть, получится то, что надо.

Скорость работы вероятностного алгоритма - примерно C*L^2*log(L), где L - длина проверяемого числа, C - количество тестов (вероятность false positive будет не больше 4^(-C)). Это если использовать сверхбыстрые алгоритмы умножения. Для миллиона знаков время получится несколько триллионов - и там всё зависит от константы. Будут это часы, или дни - сказать трудно.
Если тестируемое число равно произведению нескольких известных простых чисел + 1, то проверка может дать гарантированный результат, но в этом случае C равно количеству чисел, входящих в произведение.

Есть:
выводите число B, потом 1000 нулей, потом C. Конечно, нужно, чтобы было C < B.

В первом случае варианты не эквивалентны. При a=3, b=4 в первом варианте CallMe() вызовется дважды, а во втором - только один раз.
Первый вариант написан оптимально. Чтобы заставить его вести себя, как второй вариант (с одним вызовом CallMe()), достаточно вставить else:

if(a == 3)    CallMe();
else if(b == 4) {
    CallMe();
    Giveme();
}

Это будет оптимально по времени. Если же вместо CallMe() стоит более сложный вызов или длинный блок, и вас волнует длина кода (например, на микроконтроллере), то берите второй вариант. Если при этом и общее условие сложнее, чем b==4, то придётся его запомнить:

bool cond1=(sin(x)>=sin(y));
if(cond1 || cos(x)<cos(y)) Draw(tan(x),tan(y));
if(cond1) CloseLine();

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

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

45*y*(2*x^2+x-2)+90*(x^2+x+1)

Если a и b глобальные, то лучше сделать одну глобальную функцию, которая на них будет смотреть:

int CmpAB(int same,int diff){ return a==b ? same : diff; }

и положить её рядом с переменными. Потом туда же перетаскивать и другие обращения к ним. Глядишь, и соберётся класс с какими-нибудь осмысленными свойствами.
return - вещь хорошая, но если возвращать значение, то в нём должен быть смысл. Ради сокращения пары скобок придумывать тип возврата не стоит. Так что

if(a == b){
   print("test");
   return;
}
// код, если a != b

По большому счёту, однородные координаты нужны с единственной целью - чтобы при получении экранных координат точки не нужно было различать ортогональную и перспективную проекции. В остальных ситуациях их полная поддержка была бы только лишней тратой ресурсов.
Сразу надо сказать, что матрицей 3*3 вы не обойдётесь. Такие матрицы описывают только поворот, а в перемещениях объекта и камеры в 3D есть ещё сдвиги. Поэтому нужна матрица, по меньшей мере, 3*4 (в конвенции компьютерной графики, когда вектор это строка а не столбец).
В терминах линейной алгебры пользоваться такими матрицами неудобно, поэтому к ним добавляют столбец (0,0,0,1), а к координатам точки - четвёртую координату 1. Де-факто мы при этом получаем проективное пространство, представленное однородными координатами. Но при любых операциях над матрицами и точками у нас последний столбец всегда будет (0,0,0,1), а последняя координата точки - 1.
Если знать это, то можно хорошо сэкономить: для хранения матрицы хватит 12 чисел вместо 16, для перемножения двух матриц - 36 умножений вместо 64, а для умножения матрицы на точку - 9 умножений вместо 16. Надеюсь, что в реальных проектах так и делают.
Но есть одно место, где последний столбец не равен (0,0,0,1), и четвёртая координата точки может отличаться от 1 - это перспективная матрица для вывода на экран (ссылку вам уже дали). Для вывода точки (x,y,z) результат её применения может быть, условно, (x,y,z,1) - тогда имеет место ортогональная проекция, и выведется точка (x,y), а может - (x,y,-1,z) - тогда координаты точки окажутся (x/z,y/z), и проекция будет перспективной. Хватило бы одного бита - как интерпретировать точку, делить ли на z. Но разработчики компьютерной графики решили, что матрица 4*4 и однородные координаты - это более эффективно. Им виднее.

Надеюсь, что оптические появятся раньше. От них пользы больше будет.

Стараюсь запомнить хотя бы основные термины или формулировки. Если потом понадобятся - через Google с самого начала, а там ассоциативная память подскажет, куда идти. Никакого локального внешнего хранилища не держу.

Линейная алгебра (довольно глубоко - чтобы свободно ориентироваться в свойствах линейных операторов), функциональный анализ, ТФКП и УрЧП. Думаю, для начала должно хватить.

Не очень понятно, зачем здесь Z. Если 1000 структур помещается в памяти, и мы их можем отсортировать, то казалось бы - читаем из файла 10 раз по 1000 структур (по порядку, за один проход), каждый раз структуры сортируем и в отсортированном порядке помещаем в новый файл. Всего получается 10 файлов. Дальше - обычный merge. Кстати, слить можно сразу все 10 файлов, если их можно открыть одновременно. Если нет - сливаем два самых маленьких файла, пока не останется один (выгодно, чтобы сливаемые файлы были примерно одинакового размера - как группы символов в коде Хаффмана).
Возможно, Z придумали, чтобы файлы были не совсем одинаковыми, чтобы алгоритм не закладывался на одинаковость размера. Но тогда лучше было бы, например, "случайное число от 500 до 1000". В любом случае, если брать не максимум, то алгоритму только хуже.

Каждому классу присвоить id (целое число), и написать для этого класса функции записи в бинарный поток и чтения из него. Записывать непосредственно значения полей.
Если потребуется прямой доступ к объектам, то при создании файла отвести в начале место для ссылок на положение каждого элемента массива в файле, потом, по мере создания файла накапливать эти ссылки. В конце записать. Если прямого доступа не нужно - писать и потом читать все объекты подряд.
Если структура классов будет меняться, и иногда потребуется читать старые файлы, надо предусмотреть номер версии, чтобы десериализатор класса мог его учитывать. Читать новый файл старой программой при этом не получится.
Если есть информация о диапазонах значений полей, можно записывать меньше байтов, чем размер типа (например, для целых - два или три байта). Для массивов можно предусмотреть упаковки какими-нибудь разностными схемами.