Тебе размер этой вставке не сообщали? Значит может быть любая. Напиши на паскале эту формулу как есть. И приаттачь сюда. И дальше уже на ассемблере мы придумаем что приклеить сбоку.
Cipo, я себе это так вижу. Есть цена дома и цена с учотом налогов. Это - одно и то-же. Корреляция будет равна примерно единичке. Зачем нам брать во внимание эти две абсолютно связные характеристики. Никакой новой информации в модель эта цена с налогами не превносит. И ее можно выкинуть.
GaalSpear, странная методика тестирования. Мне кажется - достаточно дорогая в реализации. Можно было как-то больше гипотез вызвинуть об искомом шаблоне. Иначе получим транс-вычислительную задачу.
Вобщем по поиску строк из теории я помню КМП и Боуер-Мур. Ввиду того что у нас нет никаких шаблонов - практически невозможно построить эффективный индекс.
Как можно оптимизировать по скорости? Я думаю в вашем случае - только экстенсивно. Наращивая количество узлов в вашем кластере. Сколько у вас? 12 executors. Вот разделите ваш датасет по хешу на 12 partitions. И пускай каждый исполнитель работает над своим объемом. Не забывайте про fork-join. Освободившиеся исполнители обязаны взять часть работы у других которые еще работают. Потом в конце их результаты надо свести в общий итог.
Что можно поисследовать. Можно построить гистограмму "тригамм". И если какие-то триграммы будут иметь больше количество попаданий - то надо идти за ними в строку и делать соотв. поиск вправо и влево добиваясь макимасльного соотвествия. Учитывая длины строк (по 150Г) возможно я не прав и триграмм будет мало. Берите "квадро-граммы", "квинто-граммы" и так далее до достижения более яркого проявления подстрок-дублей.
Математика может понадобиться чтобы объяснить заказчику почему на данном датасете какая-то гипотеза не сработала.
Также нужно уметь видеть какие-то признаки (выбросы) которые говорят о том что данные - грязные и не годятся для обучения. Строгих критериев тут мало и надо разбираться глубоко в мат-статистике чтобы озвучивать например такие заключения.
Не знаю как реализован в шарпе string.Replace(...) но скорее всего это алгоритм из двух частей.
Первое - это собственно поиск строки. И второе - это генерация новой строки на основе замен старой.
Из алгоритмов поиска я помню 2 штуки. Кнута-Морриса-Пратта и Боуера-Мура. Вот можно в эту сторону
смотреть.
Я думаю что string.Replace(...) реализует вполне себе хороший алгоритм. И если автор хочет делать замены
в гигабайтных строках то стоит наверное глубже изучить предметную область. На что делаем упор? На очень
длинные строки? Будет ли вследствие замен строка сильно увеличена в размере? Какой аллоцировать объем
для билдера? (приблизительо). Будет-ли string.replace работать на регулярной основе.
Может имеет смысл строку индексировать? Но опять-же это можно обсуждать только зная данные.
ErrezMe, тебе скорее всего не нужно учить "OOP in general". Достаточно будет того среза ООП которое использует Python. Вот если Тони Геддис пишет про какие-то термины вроде наследования или композиции в Python - вот их бери и изучай.
Какой у тебя? Free-Pacsal? Gnu-Pascal?