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