mayton2019

Очень много причин может быть. Основная - это ноутбук и смартфон используют разные драйверы для FAT32.
У ноутбука этот драйвер - более толерантный к ошибкам. У смартфона нет. Дальнейшее расследование этого
пустяка уже потребует денег и специалистов.

Попробуй отформативроать в ExFat https://en.wikipedia.org/wiki/ExFAT
Возможно многие потенциальные баги там уже исправлены.

FAT12/FAT32 - это морально устаревшая система и сегодня нет оснований ее использовать. Она создавалась для магнитных дисков и дискет малого объема.

Я долго подбирал те слова которые ругательные, но которые цензура все таки пропускает. Вобщем выходило очень по старо-словянски. Вобщем лихо. Сиречь молвить совсем тяжко. Бесовщина... Все неправильно.

Во первых для чтения и обработки CSV файла тебе не нужен RDD. Это очень сырой тип данных который щас никто почти не использует. Его почти всегда заменяют на DataFrame/DataSet. Он остался только в легаси коде и в тех кейсах когда нужно обработать текст (natural language).

Во вторых желательно разделить просто Scala-функции и протестировать их отдельно.

В третьих. Тебе надо поработать со Schema и DataFrames. Тебе дано 9 comma-separated файлов. Получи из них сначала 9 датафреймов. При чтении используй следующий шаблон.

val atusact = spark.read.format("csv")
                .option("header","true")
                .option("inferSchema", "true")
                .option("delimiter", ",")
                .load("/data/atusact.csv")

После того как все датафреймы будут загружены - ты работаешь с данными которые имеют схему. (опция infer).
И из каждого датафрейма можешь получить колонки и типы как коллекции объектов.

Ошибки implicite conversions имеют отношение к языку Scala больше чем к Spark. Если перепишешь все на PySpark то ошибка сама собой уйдет. Я не хотел-бы на ней останавливаться. Отдельным топиком задай по Scala.

P.S. Я вообще игнорировал твоё задание. Мне безразлично что там надо сделать. Я просто смотрел по стилю.

P.P.S Не пиши флуд с картинками. Это не помогает в решении вопроса а только запутывает и раздражает читателя.

Отвечу на первую часть вопроса

Одно из условий остановки игры, если поле зацикливается.
Но как это реализовать? Знаю способ, с запуском "скрытой" игры, которая будет течь в 2 раза быстрее, и сравнивать поле этой игры с полем оригинальной каждый ход. Затем на каком то моменте поля совпадут и с этого момента запустить сравнение по ходам со стартовым первоначальным полем. Когда совпадут, получается зациклилось.
Но можно ли как-то попроще это реализовать?...

Я не программировал Convay-s Life т.к. было не особо интересно. Но я наблюдал работу приложения Golly. Там можно было проводить сутки напролет в экспериментах, задавая различные конфигурации клеток и вот к чему я пришел.

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

Короче клеточный автомат имеет свойства которые невыводимы из начальной конфигурации в общем случае.

В частных случаях например когда вы знаете что такое глайдер и куда он полетит - то пожалуй можно. Но таких случаев будет мало.

Нерешенные вопросы:
1) Поле бесконечное? Как быть с конечными ресурсами оперативной памяти?
2) Поле конечное? Уничтожаем клетки (глайдеры) которые вылетают за границу поля?
3) Поле завернутое в тор (бублик)? Будем ли считать линейные трансформации поля - эквивалентными к исходному?

Данные вопросы вобщем-то тоже влияют на проблему завершения жизни Конвея.

По поводу идеи автора с удвоением времени. Может не сработать если период повтора не будет кратен двойке.
По сути надо не сравнивать x и 2x эпоху. А записывать в базу данных все x - 1 эпох и проверять все-с-последней.
Но такая сверх-задача невыполнима например с растущим бесконечным полем.

Вторая часть вопроса не так интересна. Ее можно задать отдельным вопросом в habr.

Техно-стек Erlang/OTP считаеться эталлоном надежности. Акторы. Супервизоры.

Вот изучи новый язык. Хорошая мотивация уже есть :)

Посмотри вот в этой табличке https://ru.wikipedia.org/wiki/%D0%A1%D1%80%D0%B0%D...

По теме. Я думаю что тебе не стоит думать в таких категориях. Все равно хорошую игру в 2К ты не втолкаешь. Шахматы в 5К втолкнули ну и что? Это слабые шахматы. Если у тебя есть хорошая игра то лучше положить ее в хостинг и в QR код добавить просто ссылку.

Никак. Как же ее парсить, когда ее нигде нет?

Обычно ошибки - это некое детерминированное поведение когда например в С++ функция fopen возрващает файловый хендл. И если проверка этого указателя на NULL - положительна значит была ошибка. И программист сам вручную принимает решение что делать.

Исключения - это некоторое свойство блока кода в котором может произойти "нечто" и мы на своём уровне не желаем отрабатывать каждую ошибку каждой функции а определяем некий общий обработчик всех ошибок одного типа.

Если не обрабатываем - то считается что делегируем обработку исключения той функции которая нас вызвала. По сути передаем управление "наверх". Тоесть кто вызвал - тот и обязан разруливать ситуацию. Очень похожий подход принят в акторной технологии.

Обычно механика исключений хорошо приживается в языках с Garbage Collectors.

Поэтому, подытоживая - да. Ошибки не равны исключениям. Исключения - это более высокоуровневый мехнизм.

Вопрос такой что отвечая на него можно новую книгу написать. Тут даже С не причем. А причем - архитектура процессора x86. Кстати тут еще надо кеш-линии рассмотреть. Это фокус такой. Что если тебе надо 1 байт прочитать
из произвольного адреса, современная архитектура этого не умеет. Она читает (обычно) кусок памяти шириной в 64 байта. Это обзывается кеш-линия. И уже из нее будет прочитан нужный байт. Отвечающие верно сказали выше. Еще можно добавить такое (условное правило) что тип данных должен лежать в сегменте данных по адресу кратному самому размеру типа. Тоесть int должен лежат на адресах кратных 4, long - 8 байт и так далее. Вот насчет MMX/SSE не знаю.

Из сбивчивых жалоб и стенаний автора можно только то что нет опыта и есть признаки выгорания от учёбы. У меня тоже такое было. Я выгорал. И самое лучшее в этот момент - бросить самообучение и заняться другим делом за которое платят и которое вполне осязаемо. Самая большая беда новичка - это амбиции. Это желание сразу сходу делать своё где есть все фичи в мире и можно грабить корованы и прочее. Это ошибка. Ошибка которая как раз приводит к выгоранию. Лучше написать морской бой в браузере который работает чем писать 3д шутер 10 лет и потом выкинуть его на свалку просто потому что он морально устарел. Одиночки вообще никакой игры не могут написать. Игра сегодня - это как съемки сериала. Требует слишком много разных знаний из разных областей и 1 чел никогда все не охватит.

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

С практической точки зрения удобнее задать вид форматирования (например 4 знака после запятой) и любое значение float при выводе на печать форматировать.

Вот эту сигнатуру ты сам придумал.

def add_time(self, h=0, m=0, d=0, dw=0, mh=0, y=0):

и дальше уже пошли все остальные беды отсюда. А прикинь еще будет 20 методов которые делают сравнение времени, разность в днях или календарные расчеты и везде-везде у тебя будет это ужасное векторизованное представление времени. Хотя на самом деле время - это просто вещественная точка на оси истории. Одно число. Например для unix-time достаточно целого числа 32х бит чтобы хранить любую дату с 1970 года.

С проверками условий тут ничего не поделать. Все они будут как ты и написал в полном объеме. С проверкой типов можно извернуться и свалить их хотя-бы на type hints.

Посмотри как python3 рекомендует работать с временем https://docs.python.org/3/library/datetime.html

Если очень хочешь создавать свой класс Clock - создавай. Только опиши хотя-бы для себя какой у него SingleResponcibility. Что он делает. Что хранит. Может окажется что тебе его делать не надо. Есть альтернативы.

Можно поискать так называемые экстракторы ресурсов. В 2000е издавались целые диски этого софта.
По названиям утилит можно здесь посмотреть https://wiki.xentax.com/index.php/Extraction_tools
Будь осторожен. Многие эти тулзы были с "сюрпризом" внутри. Я-бы их ставил только на виртуалку и после одноразового исопльзования удалял.

Иногда можно просто догадаться что ресурсы игры - это по сути архив приаттаченый к экзешнику.
Например Quake3 просто использовал zip для упаковки своих ресурсов. А в игре Mortal Kombat я находил звуки просто просматривая байты как 8-битные амплитуды на wave-редакторе. Находил довольно быстро. Звук видно визуально. Так-же с текстурами.

Дело в том что нельзя решать проблемы TCP находясь выше уровня TCP.

Сами потери пакетов этот протокол решает повторной пересылкой (TCP Retransmission).
Тоесть технически это уже решено в самом протоколе. Разумеется не безплатно и ценой
потери времени. Когда у вас примерно 50% теряется - это ситуация "очень плохо".

Так работать нельзя и нужно решать эту проблему именно в том месте где она возникает. Если
это физический уровень то надо менять кабели (антены) или если это работа шейперов и firewalls
то решать это соотв там.

По поводу удвоения трафика и избыточности. Можно использовать различные коды Хемминга и РидаСоломона
но они требуют буфера. Причем если единица потери у вас это TCP-пакет то для удачного восстановления
надо хотя-бы передать 1000 пакетов оснащённых кодами восстановления (и при этом гарантировать
что ретрансмиссий не будет ибо они не нужны) и на выходе где-то (интересно где?) их всех собрать
в один массив и быстринько проверить что инфы для восстановления уже достаточно чтоб пролечить
потерянный пакет. Как это сделать - ума не приложу. Но это полюбому будет на уровне IP/UDP
и это совершенно новый протокол. Крайне ресурсоёмкий по памяти и с длинным лагом по TTFB.

Вобщем схема очень напоминает скачивание большого торрент-файла по UDP в условиях рандомного порядка
следования чанков этого самого файла. Кому такая схема нужна? Это нединамично и неотзывчиво. Никаких онлайн
игр и стриминга тут нельзя построить.

Вот например CPU вырос в два раза, а чем при этом занимается наше Java-приложение, какие запросы отрабатывает, непонятно.

Так не бывает. Если вы разрабатываете этот софт - то вы соотв. знаете какие changes заходили в последнем релизе.

Если вы прям вообще-вообще невкурсе где у вас нагрузка или bottleneck - то это плохо, друзья. Вы не знаете свой код. И почему случилось так что вы раньше этого не знали - непонятно. Вобщем главный совет - будьте familiar to your code. И вам не понадобиться бегать и в день релиза искать профилировщики.

+1 к тому что написал Владимир. Все верно.

Думаю что вся игровая логика описывается орграфом из трех вершин и 3 ребер.

from enum import Enum

class Game(Enum):
     STONE    = 1
     SCISSORS = 2
     PAPER    = 3

winners = { Game.STONE : Game.SCISSORS, 
            Game.SCISSORS : Game.PAPER, 
						Game.PAPER : Game.STONE }

Тут - непонятно.

using Stream stream = File.Open(filePath, FileMode.Open, FileAccess.Read, FileShare.ReadWrite);

читающий поток разрешает другим одновременно запись. Это к чему. Чтобы разрушить файл?

А в пишущем потоке какие-то непонятные лишние действия совершаются. Зачем файл дваждый открывать-создавать?