Александр Пожарский

Пакеты вы скачали, а зависимости для них нет.

Наиболее простым вариантом будет скачать нужные пакеты вместе с зависимостями через pip.

pip download python-docx -d ./packages --no-binary=:all:

в итоге в директории packages будут архивы с нужными вам зависимостями и самим пакетом.
подробнее тут https://pip.pypa.io/en/stable/reference/pip_download/

Ну как бы на C++ пишут кроссплатформерные приложения, просто API разных платформ отличается и зачастую приходится юзать платформозависимый код или обёртки вроде Qt, где этот платформозависимый код скрыт. Другие технологии, как например Java делают тоже самое, только ещё больше это скрывают от программиста.

Да, как бы, ничего не мешает писать один С++ код для множества платформ. Почти весь мой трудовой стаж связан именно с разработкой кроссплатформенных игр. Я работал с несколькими (самодельными и не очень) движками и имею свое собственное детище, прекрасно и однозначно собирающееся на 5 целевых платформ (Win, Mac, Linux, ios, Android), к которым без труда можно добавить и консоли, и новые платформы.

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

Кроссплатформенность подразумевает решение ряда вопросов, которые и выливаются в слой абстракции над операционной системой. Эти вопросы, зачастую, решать никто не хочет. Несколько раз встречал такое сам и еще мне рассказывали о том, как тот или иной движок сперва был только под конкретную ###, а потом решили портировать на @@@. Оказалось, что компилятор, которым всегда и собирали движок, нашпигован расширениями языка, которые конечно же все пользовали на 100%, и при смене компилятора ни один файл исходников не остался без доброй сотни ошибок. Т.е. переписывать надо было ВСЁ.

Mercury13 хорошо рассказал про Unicode пути к файлам. Drakonoved правильно подметил про разделители путей к файлам. Максим Гришин очень хорошо напомнил про порядок следования байт. Это все и есть часть этого ряда вопросов.
У каждой платформы есть свой API, которого не будет на другой платформе. Но на другой платформе будет свой API, со своими именами и схожей функциональностью. И работу с API надо абстрагировать от универсального кода.
Еще, на одной платформе у тебя может быть разомкнутый главный цикл обработки сообщений (Win), а на другой - замкнутый (Android). Надо подстраиваться. GUI везде разный, надо подстраиваться. Сама структура приложения на одной платформе может быть монолитной, а на другой - композиционной. Графические и звуковые API могут быть и кроссплатформенными, однако простоты использования это им не прибавляет. Инициализация все равно будет платформозависимой.
На самом деле даже в рамках работы на одной платформе надо соблюдать ряд правил, чтобы иметь возможность из одного кода получать и 32-битное приложение, и 64-битное тоже. Об этом неплохо написано на сайте разработчиков PVS-Studio.

И все это решается. От части - с помощью архитектурных приемов. Один из таких я уже показывал в другом своем ответе.
И еще эти вопросы можно не решать.
ДубльГИС, например, уже давно работает на базе Qt, что сильно упростило им кроссплатформенную жизнь. Qt решает ряд проблем кроссплатформенности.

Держать проект на локальной машине (в смысле иметь возможность запустить его на локалхосте) возможно только для маленьких проектов?

Откуда у Вас такие заключения?

Т.к. с ростом БД и сложности окружения redis + сервер очередей + логи и т.п. держать, запускать и обновлять это всё на локали становится сложно.

Есть например, VirtualBox + Linux + [что-то ещё] + [...] и так далее. Ставите на виртуалку нужный вам набор софта, запускаете, пользуетесь.

Сложности в установке/настройке программ... ну это очень риторический вопрос, кому-то сложно даже интерпретатор PHP из архива распаковать...

Вопрос с тем, что может требовать значительных ресурсов (например, базы данных) занимая большой объём дискового пространства или создавать большую нагрузку на вычислительные ресурсы машины - тут вариантов несколько:
1. Хранить базы данных не локально, а работать с ними удаленно
2. Набор данных необходимый для разработчика - обычно ощутимо меньше, чем тот, что используется в реальном проекте. Используйте версию базы "для разработки", а не "продакшен" вариант
3. Если позволяют ресурсы (например, объем жесткого диска) и есть необходимость - используйте полную версию БД. Нагрузку на БД создают не объёмы данных, а объёмы обращений к этим данных (условно конечно, но суть такова). Иными словами, если у Вас база занимает 500Гб и структура проекта построена адекватно - работать даже с такой БД может вполне "обычный" компьютер.

И ещё вопрос: при использовании DEV-сервера можно держать файлы проекта у себя на машине и в PHPStorm либо автоматически либо вручную заливать изменения на сервер. А можно в шторме прямо к серверу подключиться и работать сразу с файлами на сервере, т.е. не иметь копии проекта у себя на машине по сути. Какой из этих вариантов лучше и почему?

Не совсем понятно, что именно Вы подразумеваете под "DEV-сервером" и зачем он Вам нужен вообще? Я за более 10-и лет разработки с реальностью подобного рода серверов сталкивался в двух случаях:
1. Необходимость иметь некоторый эталонный сервер и/или сервер, с помощью которого можно демонстрировать работу конечному заказчику или разработчикам проверять свои правки и нововведения в условиях "эталонного" окружения (что в целом легко реализуется в большинстве случаев, при возможность запустить виртуальную машину на компьютере разработчика)
2. Мой рабочий ноутбук настолько слаб, что с трудом "тянет" даже phpStrom, не говоря уже о всяких VM и прочих "прелестях жизни", в этом случае меня неоднократно выручал удаленный вирт. сервер

Далее, "подключиться к серверу и работать с файлами сразу там" - Вы что имеете в виду? Пробросить SSH-туннель или иным подобным образом подключить файловую систему сервера как сетевой диск? По моему, без прямой необходимости в обратном, "лучше" - использовать средства автоматического "деплоя". А как "лучше" выгружать файлы на конкретный сервер, "руками" или "как-то ещё" - зависит от множества факторов, в т.ч. от того, как часто это нужно делать, кол-вом "выгружающих" и т.д.

>Стэмминг
Воспользуйтесь SnowballStemmer'ом из библиотеки nltk и выделите корень для каждого слова из вашего датасета, добавляя результат в set.
>замена одинаковых слов числами по словарику
Создайте словарь, где каждому слову из множества соответствует свое число, что-то вроде:

words = {w: i for i, w in enumerate(set_of_stemmed_words)}

Далее вам нужно представить каждое предложение из датасета в виде списка токенов, в данном случае - с помощью словаря words. После этого вы готовы обучать свою модель, ура!

Впрочем, я хочу отметить, что такое представление слов (гуглите word embeddings) является не самой лучшей идеей, потому что сеть может сделать "ошибочные выводы" о важности или близости слов, руководствуясь величиной их токена. Гораздо эффективнее использовать вектора, полученные с помощью word2vec'а или TF-IDF etc.

UPD.
На коленке сделал для вас тетрадку. Подтяните для начала теорию в области машинного обучения в общем, а потом уже беритесь за нейросети. Начать можно вот с этой замечательной статьи.

Вопрос читабельности.
Немного проще прикинуть что 0b100 + 0b10 = 0b110
Еще сильнее это заметно, когда надо наоборот, понять по какой-то сумме какие компоненты в нее входят.
Гораздо проще разложить в уме 101010 на 100000, 1000 и 10, чем 42 на 32, 8 и 2

Почитайте про то как работает градиентный спуск.

В процессе обучения вы минимизируете функцию потерь, ищете её дно:


«Скорость обучения» == «величина шага». Если слишком большие шаги, есть риск проскочить свою остановку. Если слишком маленькие – придёте, но пешком быстрее. : )

На иллюстрации приведена ещё более оптимальная стратегия, когда величина шага изменяется с каждой итерацией от большого к меньшему.

Учить или не учить зависит от того нравится тебе в целом программирование и математика или нет.

Большинство сайтов, которыми ты пользуешься написаны на html,css,javascript + backend. Эта сфера работы называется web-программирование.
Backend включает в себя базу данных и систему которая обрабатывает запросы от пользователей, ходит в базу(если нужно) и выдает ответ. Обычно такую систему для обработки запросов пишут на php, python и т.п. языках.
Веб программисты зарабатывают в Москве от 60к в среднем + возможность уехать за границу, т.к. профессия довольно востребованная.
Python также широко используется в сфере machine learning, data science и т.п. - это сфера работы где платят за обработку данных, сбор статистики, аналитики, предсказание показателей и т.п.

Из результатов поиска у клиентов через 30 дней(исправлено) уберут, но вернут как только вернетесь и начнете подавать заявки. Ничего не блокируют.
https://support.upwork.com/hc/en-us/articles/11500...

Так вы нигде в рекурсии не используете значение hist, которое возвращает функция queryString.

Да, можно. Скорее даже нужно, т.к. везде есть свои общепринятые стандарты.

Например:

• SQL Style Guide - www.sqlstyle.guide/ru
  
• C# Code Style - https://docs.microsoft.com/ru-ru/dotnet/csharp/pro...
  

book - это структура, методом которой является эта функция