вообще тут верно говорят, что нужно читать код внимательнее, потому что суть в мелочах, но я вообще в целом отмечу одну вещь, которую не могу понять в твоем подходе - в ответах на комменты: спросили про ревью - "я не знаю что такое ревью" в решениях задач - "ой тут функции, мы еще не проходили" также в решениях задач: испугался import time - "ой тоже не проходили" ты не хочешь гуглить. курс не научит тебя гуглить - он даст краткую выжимку по питону, которую ты забудешь через месяц. суть не в этом, суть - в том, чтобы при таких проблемах ты бы разбирал что происходит и шел бы искать ответы, а не скипал со словами, что чего-то не проходил, только так учатся программисты. в конце говоришь - "ну, вот такое решение, вот такие задачи выполнили, мы молодцы". при этом единственную задачу, где предлагалось подумать ты просто скатал у чатгпт - есть ли смысл в твоем обучении? не уверен)
хах, впервые наткнулся на вас, так и думал, что проходите курс на stepik "поколение python". Сам его прошел, скоро буду приступать к следующему курсу) Удачи
Можешь изучить Pygame просто ради интереса. Он ничего не даст для трудоустройства, и реальные игры на нём не пишутся, но можешь для себя пописать на нём.
Задача о Гипотезе Эйлера. Основных оптимизаций в этой задаче две: Во-первых, можно отказаться от 5-го вложенного цикла для числа e. Как собственно и поступили ребята в решениях. a ** 5 + b ** 5 + c ** 5 + d ** 5 = e ** 5 эквивалентно записи e = (a ** 5 + b ** 5 + c ** 5 + d ** 5) ** (1/ 5). Так как нам нужно найти 5 натуральных чисел, то, если для какого-то набора a, b, c, d e-шка, найденная по формуле, записанной ранее, получилась натуральной, то, значит, что нашелся такой набор a, b, c, d, e, что a ** 5 + b ** 5 + c ** 5 + d ** 5 == e ** 5. Как же проверить тот факт, что текущее значение e натурально? В решении, которое ты скопировал под конец видео это делают так int(e) == round(e, 10). Функция int(x) приводит число x к целому виду, отбрасывая дробную часть. Функция round(x, 10) округляет число по мат. правилам до какого-то порядка дробного знака (здесь 10). Казалось бы, зачем нужно округлять? Почему нельзя просто проверить int(e) == e? На самом деле, если изучить работу функции корня (5-ой в данном, или любой другой степени), то функция раскладывается в ряд Тейлора и поэтому высчитывается не совсем точно (имеет некоторую погрешность) и таким образом, например 5 ** 5 = 3125. А 3125 ** (1 / 5) = 5.0000000001 (условно). И хоть по логике (5 ** 5) * (1 / 5) = 5, но 5 != 5.000000001. Ели Вы не хотите пользоваться функцией round, то можно использовать функцию модуля abs. И вместо int(e) == round(e, 10) проверять, что abs(int(e) - e) < EPS, где EPS наперед заданное малое число. Второй оптимизацией является тот факт, что в данном случае не важен порядок чисел. Согласитесь, что набор 1 ** 5 + 2 ** 5 равен 2 ** 5 + 1 ** 5. Так и тут эквивалентные наборы чисел a, b, c, d будут давать в сумме пятых степеней чисел одно и то же число. Как же не повторять наборы чисел? Пусть a проходит по всем числам от 1 до 150. Тогда b можно начинать с числа b = a до 150. Тогда уже не возникнет такой ситуации, например, что a = 1 b = 12, а потом a = 12 b = 1. Аналогично для всех последующих чисел. То есть for a in range(1, 151) : for b in range( a, 151) : for c in range( b, 151) : for d in range( c, 151) : Тогда программа совершит уже не 150 * 150 * 150 * 150 итераций, а меньше - (150 * 149 * 148 * 147) / 4!. Думаю, согласитесь, что это меньше по времени примерно в 4! раза. Также хочу отметить, что команда print() довольно сложна с точки зрения ресурсов компьютера. Поэтому ее вызов на каждой итерации вложенных циклов довольно замедляет работу. Спасибо за ролики! И успехов вам в учении!
к задаче с суммой пятых степеней - у GPT там было одно существенное отличие - он начинал циклы не с единицы, а с прошлого числа. Так, как порядок слагаемых не имеет сначения, GPT считал, что числа слева направо расположены по возрастанию, потому цикл для A начинался с 1, для B уже не с 1, а со значения A, для C со значения B и так далее. Отсюда и такой прирост скорости.
Желаю вам удачи. По моему опыту примерно на сотом дне +- будет резкое падение мотивации (по прогрессу это было начало изучения ООП), для меня самый сложный был этап за уже почти год учебы
а я тебе скажу почему на ооп трудно стало. В пайтоне оно просто довольно таки неочевидное и немного топорное(имхо разумеется). Сам изучал ооп по шарпам и это был отличный вкат в тему как мне кажется. После этого когда была какая-то муть в пайтоне я уже знал, дело не во мне XD
@@freedomtv2295 Мне иногда вообще хотется бросить изучение ибо бесит, когда очередная дыра в коде, которую не знаешь как решить, а потом она оказывается очень очевидной и еще сильнее психуешь :D
@@freedomtv2295 поэтому и посоветовал автору готовится и придумать какие-то конкретные меры на такой случай) Самое начало Питона до ООП как экскурсия, потом начинается жесть… Зато после освоения ООП уже по инерции двигаешься, самый большой затык сейчас лично у меня в асинхронке и структурах по типу двусвязных, односвязных списков
