mayton2019

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

*!Tomsk2018*Oksana!  
*06Tomsk08*Oksana18!*

Можно предположить что есть два произвольных ASCII-NUM-CTRL символа. Потом Tomsk. Потом календарная дата от 2008 до 2018 года в двух форматах YYYY, YY. Потом женское имя. И потом опционально еще раз календарная дата и 2 ASCII-NUM-CTRL символа.

Давайте посчитаем количество. Пускай для простоты ASCII-NUM-CTRL = 128 символов.
Даты - 10 лет и еще 2 формата итого 20 штук.

Итого. 128 * 20 * 20 * 128. Но у нас еще есть пустая комбинация NULL (опция). Для простоты просто добавим +1 к каждому множителю и таким образом закроем эти опциоанльные строки. Получается

129 * 21 * 21 * 129 = 7338681

Семь мильонов. Словарь - детского размера. Вобщем подбор вполне осуществим.

P.S. Я надеюсь что мы не нарушаем правил qna обсуждая такие вещи. И я надеюсь что автор честен и спрашивает это только для личного пользования.

У Python 2.x, 3,x были разные формы представления числа типа int.

Поэтому я бы выбирал тот тип данных который даёт arbitrary precision.

Разумеется плавающая точка здесь не помощник.

Мне нужна функция которая возвращает координаты столкновения луча со сферой

Сразу замечание. Давайте перечислим ситуации которые могут быть.

1) Луч пересекает сферу в 1 точке (касательная). Или луч испускается изнутри сферы.
2) Луч пронизывает сферу в 2 точках (наиболе общий кейс)
3) Луч не попал в сферу.

Наша функция (какая-бы она не была) должна возвращать 3 типа этих результатов. Или просто список от 0 до 2х векторов в пространстве (x,y,z). Я-бы предпочел перечисление из 3х типов результатов. Мне кажется что это достаточно важно.

Нет никакого смысла страховать Кафку. Она совершенно самодостаточна. Есть настройка message delivery semantics. Почитай про нее. Вобщем идея такава что - каждый сам себе в зависимости от бизнес требований выставляет такие параноидальные настройки producer/consumer, чтобы было и быстро и надёжно одновременно.

Если речь идет о computer vision - то да. Скорее всего можно. Но мне жаль ваш талант. Если вы действительно создатите такого бота который обучается по картинке то вас можно нанимать на работу и платить столько денег что дешевая прокачка Эльфа в какой нибудь MMORGPG вам станет просто не нужна. Сможете купить все.

Есть много способов устроить нагрузочное тестирование. Как вариант - приложение JMeter https://jmeter.apache.org/

При чем здесь Wifi - непонятно. Обычно тестируют приложение а не частные куски сетей.

Трудно поверить конечно, что в логах у тебя ничего не написано. Как вариант - ты упираешся в какие-то прикладные ограничения который сам и создал.

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

Значит тебе надо дважды вызвать вот эту утилиту

$ jstack --help
Usage:
    jstack [-l][-e] <pid>
        (to connect to running process)

Options:
    -l  long listing. Prints additional information about locks
    -e  extended listing. Prints additional information about threads
    -? -h --help -help to print this help message

и сохранить в текстовый файл что она выдаст. Потом сравнить. Разница - будет подсказывать причину.

И еще понаблюдай глазами за памятью через JVisualVM. Может что-то раньше увидишь.

Это наверное к ИИ не имеет отношения. Просто статистика. Марковские сети. И наверное теория игр.
Все это было создано задолго до термина ИИ в современном его понимании.

А попробуй сделай так

create index name_idx on emails(name);

и повтори свой запрос еще разик.

Для расчета среднего нам нужна сумма элементов и количество. Количество - это константа.

Сумма конечно меняется. Но если у нас уже есть расчитанная сумма от 1 000 000 элементов то
следующее скользящее среднее будет не сильно отличаться. Нужно от сумма забрать первый элемент
и добавить элемент с индексом 1 000 001. Это и есть оптимизация.

Тоесть первая итерация расчитывается полностью. Следующая - на основании предыдущей. Как в численных
методах.

Скорее всего - никак. Информатика (и вычислительная техника) это все практические науки. Их надо изучать параллельно делая что-то руками. Все что вы перечислили. Теория игр. Криптография. Должно быть подкреплено реальным проектом где это используется.

В противном случае - эти знания бесполезны и забудуться. Это я по себе говорю. Такой мой опыт.

Очень много причин может быть. Основная - это ноутбук и смартфон используют разные драйверы для 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.

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