Антон, лет 5 назад я создавал акк. Там есть пробный период типа 30 дней. За этот период можно понять нужен ли вам конфлуенс или нет. А дальше надо что-то платить.
Тебе размер этой вставке не сообщали? Значит может быть любая. Напиши на паскале эту формулу как есть. И приаттачь сюда. И дальше уже на ассемблере мы придумаем что приклеить сбоку.
Cipo, я себе это так вижу. Есть цена дома и цена с учотом налогов. Это - одно и то-же. Корреляция будет равна примерно единичке. Зачем нам брать во внимание эти две абсолютно связные характеристики. Никакой новой информации в модель эта цена с налогами не превносит. И ее можно выкинуть.
GaalSpear, странная методика тестирования. Мне кажется - достаточно дорогая в реализации. Можно было как-то больше гипотез вызвинуть об искомом шаблоне. Иначе получим транс-вычислительную задачу.
Вобщем по поиску строк из теории я помню КМП и Боуер-Мур. Ввиду того что у нас нет никаких шаблонов - практически невозможно построить эффективный индекс.
Как можно оптимизировать по скорости? Я думаю в вашем случае - только экстенсивно. Наращивая количество узлов в вашем кластере. Сколько у вас? 12 executors. Вот разделите ваш датасет по хешу на 12 partitions. И пускай каждый исполнитель работает над своим объемом. Не забывайте про fork-join. Освободившиеся исполнители обязаны взять часть работы у других которые еще работают. Потом в конце их результаты надо свести в общий итог.
Что можно поисследовать. Можно построить гистограмму "тригамм". И если какие-то триграммы будут иметь больше количество попаданий - то надо идти за ними в строку и делать соотв. поиск вправо и влево добиваясь макимасльного соотвествия. Учитывая длины строк (по 150Г) возможно я не прав и триграмм будет мало. Берите "квадро-граммы", "квинто-граммы" и так далее до достижения более яркого проявления подстрок-дублей.
Математика может понадобиться чтобы объяснить заказчику почему на данном датасете какая-то гипотеза не сработала.
Также нужно уметь видеть какие-то признаки (выбросы) которые говорят о том что данные - грязные и не годятся для обучения. Строгих критериев тут мало и надо разбираться глубоко в мат-статистике чтобы озвучивать например такие заключения.
Не знаю как реализован в шарпе string.Replace(...) но скорее всего это алгоритм из двух частей.
Первое - это собственно поиск строки. И второе - это генерация новой строки на основе замен старой.
Из алгоритмов поиска я помню 2 штуки. Кнута-Морриса-Пратта и Боуера-Мура. Вот можно в эту сторону
смотреть.
Я думаю что string.Replace(...) реализует вполне себе хороший алгоритм. И если автор хочет делать замены
в гигабайтных строках то стоит наверное глубже изучить предметную область. На что делаем упор? На очень
длинные строки? Будет ли вследствие замен строка сильно увеличена в размере? Какой аллоцировать объем
для билдера? (приблизительо). Будет-ли string.replace работать на регулярной основе.
Может имеет смысл строку индексировать? Но опять-же это можно обсуждать только зная данные.
Вывести Hello World на ассемблере - не очень сложно. Но все эти дополнения по поводу bios - могут усложнить
задачу на 1000%.
Тебе-же это не надо? Зачем жизнь усложнять?