но можете оценить качество самого кода? Некоторые моменты сделаны обусловлены тем, что задача состояла в том, чтобы делать именно так (к примеру использовать кортеж, а не список).
https://dpaste.org/yiZx
Всем спасибо ✌️
сходу можешь идти читать PEP8
ох реально, обрати внимание на PEP8. Код очень тяжело читать. + добавляй комменты, если хочешь, чтобы кто-то проверял)
Это из-за отступов? Я знаю что иде ругался бы на одинарные отступы между. А mixedCase использовал чтобы не использовать стиль с нижним подчеркиванием как в курсе. Отступа в конце нет, насколько я понимаю. Но дело не только в этом?)
> А mixedCase использовал чтобы не использовать стиль с нижним подчеркиванием как в курсе так вот в питоне принят snake_case стиль.
во вторых тут лучше подойдет ООП. Ты в принципе похожий концепт и реализовал, но ООП лучше)
Хм, в целом можно вынести за пределы функции, в цикл. Или сразу формировать такой лист) Спасибо
Мне ООП в целом больше нравится. Но модуль посвящён функциям)
if i ==0 Т.е. просто можно было сделать до цикла фор Кстати чойто у тебя рамки фиксированные??
смотри, функция должна делать определенное действие. Если у тебя есть функция "вывести доску", то она должна только выводить доску.
вот эта функция. Насколько я помню в крестике нолики тебе надо ввести ячейку и крестик/нолик. У тебя функция прости ввести число от 1 до 9, что делает очень сложным понимание того, где находится ячейка
ну и вот хард инпут побед очень не нравится. Напиши просто скрипт, который чекает сумму по диагоналям/строкам/столбцам. И если сумма равна -3 или +3, то тогда выигрывает крестик или нолик
Не понял по поводу рамок) А насчёт до цикла, согласен...
Человек нолик по умолчанию. И всегда ходит вторым, это, кстати, условие задания)
окей, тогда почему крестик всегда по центру?))
Условие задания) Наверное, было бы логично, сразу и условие скинуть, чтобы лишние вопросы по логике отпали
в любом случае, лучше поменяй систему ввода с 1-9, на x/y иначе если масштабировать игру (например 5*5 или 10*10), будет неудобный ввод)) в целом, если всё работает - значит ок)
Согласен, но не мог на скорую руку придумать алгоритм ) Спасибо 👍
Мне кажется мой код не очень подходит для масштабирования, хотя частично старался не использовать фиксированные числа. Но тот же алгоритм вычисления побед абсолютно не динамичный В целом, я свои ошибки понял, спасибо) По поводу того что лишнее в функции пихаю, и почитать пеп 8 Остальное уже мелочи)
вот это заменяется на import numpy as np board = np.empty([3,3])
лучший совет, который мне давали - перед тем как что-то делать, погугли 5-7 ссылок, как это делают другие люди))
только ради этого numpy тащить?
у тебя есть много вещей, которые можно упростить)
Но для обучения, наверное, импортировать что-то не всегда хорошо. Когда можно лишний раз попрактиковаться
хмммм, я сторонник той мысли, что если ты можешь сделать что-то более продвинутым, но практичным методом, то лучше так и делать :)
Ну нееее зачем тут нумпай... тем более человек учится. Зачем ему сейчас это?
ну а прикинь игру масштабировать на доску 100 на 100. Нафига двойной цикл?) если 3 на 3, то ок)
эм... и что изменится?
Ну я больше к тому что нумпай для решения даже толком оптимизаций не даст (та же итерация и будет)
ну хз, на 10000*10000 разница очень заметна
import numpy as np import time now_1 = time.time() board_1 = np.zeros([10000,10000]) end_1 = time.time() now_2 = time.time() board_2 = [] for j in range(10000): board_2.append([]) for i in range(10000): board_2[j].append([]) end_2 = time.time() print(f"numpy: {end_1-now_1}") print(f"for loop: {end_2-now_2}") зацени
np.zeroes выполняется мгновенно, фор луп не выполняется у меня вообще
Но игровая логика то будет через итерацию, там не будет (по крайней мере я не вижу таких вариантов) операций с матрицами чтобы понять, кто выиграл, возможен ли ход
Да тут не спорю создать нумпай массив гораздо быстрее (но вряд ли это лимитирует)
то есть притащить лишнюю зависимость ради оптимизации того чего никто не просил оптимизировать, а именно времени инициализации.
ага, я такой. Сразу пытаюсь ускорить всё)
Обсуждают сегодня