freeExec, у меня плана нет. Но если играть камень-ножницы бумага, то я подсознательно буду чаще выбирать ножницы. И я думаю что все люди на планете земля не смогут сделать идеальное линейное и лишённое авто-корреляций распределение.
Нет смысла обсуждать ООП без языка разработки. Просто специфика языка, который ты выберешь будет такова, что под нее придется подгонять твою теорию. Увы увы.
NIKA_R, ты сюда пришел не для того чтобы спорить. Ты пришел с вопросом. Тебе первый экспертный совет. Уходи от RDD. Это тебе только мешает в решении данной задачи. Здесь нет никаких оснований для использования RDD.
Не надо реплицировать рекламную чепуху от спарка образца 2010 года. И спарку не нужен HDFS. Он может работать поверх S3, Azure Blob e.t.c.
Убери проект с яндекса. Залей нормально на github и мы посмотрим.
Как вариант ты взял Scala 3.1.x но это не поддерживается в спарке еще.
Базы данных обычно не оперируют порядком записей. Данные внутри таблицы лежат вразнобой. И иногда перетасовываются вакуумом и прочее. И поэтому твоя задача с первой "попавшейся записью" - скорее всего ошибочна. Тоесть сделать ее конечно можно. Добавив опцию LIMIT 1 например. Но это тебе не поможет. Нужно либо обновить все wifi точки либо вообще их не трогать.
shutil.copyfile(f'D:\\Txtfiles\\{x}', f'D:\\Txtfiles\\3.txt')
v = open('3.txt', 'w+t')
смотри. Это задание конечно можно трактовать по разному. Но в программировании в 99% случаев никто не модифицирует текстовые файлы построчно.
Обычно приложение читает одну-за-одной строки. Вносит в них изменения и пишет в новый файл. Потом происходит свап. Старый файл убивается а на его место ставистя новый. Типа переименование.
Вы можете хранить 100% хешей но при этом 1% реальных снимков эпохи. Учитывая строгую формулу движения вперед - при нахождении одинакового хеша вы всегда можете взять тот самый близкий 1% и сделать "перемотку" эпох вперед и таким образом быстро проверить коллизия это или реальное совпадение.
Я делал без излишеств. В текстовом режиме. Я пинговал хосты несколько раз в минуту и просто красным цветом в text-mode подсвечивал хост если он был не доступен. Или ходил на порт 1521 коннектом чтобы понять что оракл доступен. Скрипт был настолько прост что его даже публиковать стыдно.
Ты приводишь ссылку на netdata.cloud но я-бы сказал что это богатый по UI интерфейс. И сложный.
Что-же ты хочешь тогда?
Под windows щас кодить уже не модно. Уже нишевое. Мы живем в мире мобильных приложений. Поэтому веб все равно победит в части презентации информации.
vista1x, это же фигня полная. Ты согласен? Мы не загрузим машину.
Вообще мне интересна не теоретическая а практическая сторона этого вопроса. Людям свойственно например к стеночке кузова класть более высокие вещи а к центру или к выходу - более низкие. Это такая обще-человеческая эвристика. Можно это иметь в виду.
Вообще в науке и технкие эта задача решена. Она называется "оптимальный раскрой" материала. Ее обычно решают суб-оптимально. Тоесть дают алгоритму поработать пару минут и с читают что оптимум найден. И это хорошо. При произвольных размерах (не кратных ничему) - задачу можно считать транс-вычислительной и решать до скончания времен. Но мы не будем.