Почему в лекциях не даётся вся информация для решения задач.

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

удобно наверное из контекста вырывать фразу и потом на основе этого уходить в отвлеченные рассуждения и придумывать примеры. я писал о конкретном случае. задача возвести число в куб, в условии нет запрета на использование Math.pow, если уж использовать четкую терминологию, то это некорректно сформулированное ТЗ. P.S. а и еще, искренне не понимаю призывов все решать своим умом, осознать то, что мол в реале все будет в разы жестче чем при обучении, что код пишется не для себя и т.д.... А что есть кхм "особо одаренные", которые этого не понимают? Ну то есть это настолько прописные истины, что даже странно, что кто-то тратит время на их написание, для чего, зачем.

в условии нет запрета на использование Math.pow,

Я не знаю о какой задаче речь, если о pro.task06.task0608, то в ней согласно условиям, метод math.pow нельзя использовать, поскольку задача поставлена так, что тебе нужно реализовать конкретный метод, а не использовать готовый. На стадии обучения это абсолютно нормально, если какие-то вещи неочевидны, для этого есть раздел Помощь. Если прям стесняешься, то просто действуй по алгоритму, решил одним способом, не прошло, решай другим способом. Потом картинка сложится, почему это условие нужно читать так, чтение условий это навык который постоянно развивается, и чем более высокая экспертиза у программиста, тем меньше технических моментов, а это технический момент, ему нужно обуславливать, бизнес-моменты - да, но не технические. По техническим в рамках выбранного стека он сам будет знать миллион нюансов, почему здесь так, а здесь иначе, хороший пример, тестовое задание на работу, которое звучит как краткий перечень основных технологий и простая бизнес-логика. И по результату выполнения задания, очень хорошо определяется технический уровень кандидата, поскольку одно и то же условие, 100 кандидатов поймут по разному. Чем больше опыта и экспертизы, тем больше моментов кандидат может предусмотреть, тем больше "можно использовать"/"нужно использовать"/ "нельзя использовать" он видит в условиях, поскольку это просто очевидные вещи, как в случае с тем же кубом, когда говорят написать свой метод, а ты тащишь готовое решение написанное другим программистом. Это просто стадия, на текущей стадии ок этого не видеть, но если ты считаешь, что в условиях должно быть явно прописано все...так не бывает. Проще самому все сделать, чем перечислить все 10000 технических моментов, которые программист и так должен знать и понимать. Бизнес нюансы да, должны быть раскрыты полно. А технические моменты нужно знать и понимать, если непонятно - спрашивать.

а к задачам ещё обсуждение есть? o_O

Да я сама в шоке)