mayton2019

Человек тарабанил по клавишам. Развлекался. Никакого нарушения нет. И угрозы пока нет.

Вряд-ли ваше мероприятие зачем-то понадобилось Анонимосу. Вобщем не переживайте по этому поводу.

Непонятно что в вопросе автора является исходными данными?

Заголовок генерацию? Но по сути вопрос - про обработку.

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

Да. Перевод из десятичной системы в дробную 60 ричную (минуты и секунды) это вобщем правильный путь.

Кроме этого. Как трактовать такие цифры GPS="36643005440;30046005270". Вот в моём GPS навигаторе в настройках есть несколько стандартов на координаты и коррекцию формы земли. Вобщем если вы просто получили сферические координаты из неизвестной системы - то надо поднять максимум инфы в каком стандарте она работает.

Чистой математики на шаре вам будет недостаточно.

Наверное коробочное решение - это запускать все в конейнерах Docker/Kubernetes.

+На стековерлоу было такое обсуждение https://stackoverflow.com/questions/41105733/limit...

Серая область? Тут наверное 2 цикла надо.

Либо обходить левый прямоугольник элементов и уже 2 линиями ограничить. Одна линия
y = x и вторая - перевернутая y = -x и сдвинутая на вниз на SIZE. Тоесть y = -x + SIZE

Между ОЗУ и БД есть еще промежуточный вариант. Это различные key-value библиотеки для работы с хранением и поиском больших объемов данных. Из таковых я помню

• BerkeleyDb
  
• LevelDb https://github.com/google/leveldb/blob/main/doc/in...
  
• RocksDb
  

На самом деле их гораздо больше. Но автору и этих хватит. LevelDb создавался гуглом и под него есть разные API (C++, Java, C#). Почти все эти key-value библиотеки поддерживают 2 базовые структуры данных на диске (это HashTable, B+Tree).

Для твоей задачи прекрасно подходит дисковая хеш-таблица.

А если разумно партицировать твой объем - то можно и просто в CSV файлы разложить с гарантийным временем доступа.

Вместо 4 сторон света лучше брать единичный вектор на плоскости (x,y). Тогда формулы удара о борт получаются тривиальные. Просто где то меняется знак с плюса на минус.

Никакой это не JSON.

А по задаче. Может лучше не массив а vector?

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

Наш мир состоит из постоянно менающихся объектов. Файлы. Сетевые соединения. Объекты в БД. Это грязный мир. И натянуть на него ФП парадигму довольно сложно. В хаскель довольно жёстко порешали с этим. Сказали что есть монада IO. И если функция ее возвращает - то она работает с таким грязным миром. Всё остальное - чистое. Тоесть провели границу.

Как тебе конфигурить твой роутер в ФП - я честно говоря не знаю. Мы должны сначала договориться об абстракциях. И понять где проходят границы чистого и грязного миров. Что делает get users from DB. Изменяет ли он мир? Или может вернуть внезамно другой результат при тех-же аргументах. Это все - сложные вопросы которые просто выходят за рамки твоего.

Поэтому лучше не парь себе мозги именно таким вопросом. Кстати функциональщики тоже не могут сойтись на мнении например считать ли Sheme функциональным или мультипарадигменным языком. Вообще строгого деления на такие классы не существует. Можно просто сказать что когда мы программируем - то мы тяготеем к чему-то больше или меньше. Например форма Бекуса-Науэра (БНФ) - это чистое функциональное описание грамматики. А язык XPath - чистый функциональный. При этом и одно и второе могут быть инкапсулированы в проект на языке Java например который вобщем грязно-императивный. Тоесть в каких-то частях проекта мы сами исповедуем ФП.

Ты переусложняешь. Сделай просто массив строк.

{
    "data": ["string"]
}

Это покрывает все твои кейсы с 1 строкой и с null. И маппинг упрощается.

В игровых конторах С++ вроде как нужен. Но я думаю что половину собеседования надо будет рассказывать как ты хорошо знаешь Unreal Engine.

Автор посмотри системные переменные. System.getProperties() там полно всякой информации по текущему процессу. В том числе текущий директорий, и много другой полезной информации. Это поможет ответить на вопрос где лежит твой бинарник. А именно полный физический путь к файлу.

Как скачать это - целая цепочка вопросов и ответов например КУДА качать и ОТКУДА. Ведь по вопросу непонятно где ты сам находишся в этом стеке технологий. Поэтому когда задаешь вопрос - дай хотя-бы обзор твоей технологии. Графическое приложение AWT/Swing/SWT/JavaFx. Веб-приложение. Stand-alone процесс. Апплет ( :)).

Похоже автор занимается расчетом простых чисел.

Значить так. Четные числа - всегда - составные. Поэтому их можно даже не проверять и сразу прыгать по нечетным 3,5,7....

Внутренний цикл не надо делать от 2 до i. Делитель 2 мы уже исключили выше. Поэтому начинаем с тройки и гоним не до n а до квадратного корня из n. Или наоборот возводим в квадрат. Тут надо понять что для Python быстрее будет. Я на С++ делал там по другому.

Для более глубокой оптимизации все найденные простые - пишутся в array и участвуют во внутреннем цикле как делители. Это еще быстрее.

Этож не Хаскель. Значит можно.

Python вроде только tuples запрещает мутировать. Мне кажется что тут более важный вопрос о конвенции. И о том как на это смотрит команда разработки. Если команда договорится что не мутировать сущности а создавать копии - то делайте так.

Если из 8 планок забрать 2 то получается ... примерно 192. Это близко к той цифре которую meminfo.

Может кто-то втихаря память спер? И деньги пропил.