Pudjak, давай разделим две проблемы. Первая - segfault. Неправильный доступ к памяти.
Вторая - численный метод который очень долго работает. Скорее всего ты взял из справочника
метод с очень медленной сходимостью. Надо поискать именно тот который реализован в
функции pow и для начала просто его повторить.
Закомментарь все циклы while. Должно отработать норм без segfault. Но выдаст ненужный резульат.
Потом - откомментаривай потихоньку циклы. Где-то что-то стрельнет.
dmshar, я стартовал в Basic for ZX-Spectrum. И зря вобщем-то. Это даже не транслятор и не компиллятор. Чёрти-что. И после того как я увидел Borland Pascal (PC) - это как прояснение настало. Просто понял что зря терял время. Вобщем безотносительно Python или Scratch - лучше сразу понять систему типов и это приводит дисциплину программирования на новый уровень.
А дисциплина - нужна. Куда-ж без нее в наше время.
Little_Junior, вот и делай как я говорю. Без этих промежуточных выборок. Если тебе надо гарантировать что поле не пустое - то добавь еще один предикат IS NOT NULL.
Александр, приведи пример данных как-бы ты хотел на выходе.
У SQL баз данных для responce нет такого понятия как группа.
Есть просто результат который отдается и в нем есть поля. Вот можешь считать
одно выборочно поле признаком группы. Или кодом группы.
Dr. Bacon, в таком кейсе я думаю что 99% будет отдано на откуп оптимизатору. Например если одно из полей имеет индекс - тогда направление поиска будет перевернуто. Другое дело, понимает ли автор булеву логику настолько чтобы понять что вопрос не имеет резона.
Вот даже за примером не надо далеко ходить. В смежном топике один бедняга уже горит https://qna.habr.com/q/1226946 Не понимаю - говорит. Массивы-указатели. Соглашения и традиции по тому как передавать и использовать аргументы. Это не метод тыка как Питоне. Это... наука. До седых висков надо кодить чтоб появилось видение как вообще правильно делать.
Главный вопрос так и остался - выделять ли под монету сущность
Я тебе уже дал ответ. Вести лог. С датами. С монетами. С назначением платежа.
Размышления на тему заводить или не заводить сущность - это вопрос эстетики.
Можешь заводить если она тебе так сильно нужна. Можешь почиать про шаблон
проектирования Flyweight https://en.wikipedia.org/wiki/Flyweight_pattern это на тему
экономии ресурсов.
Но мне кажется что тут первичный вопрос какова стоимость поисковой операции монет
по пользователю а не вопрос ООП-эстетики.
Я-бы голосовал сразу против Python. Без типизации новичок очень долго не понимает зачем она будет нужна потом в других языках. Тоже самое что стартовать с изучения JavaScript. Для профессионалов которые уже знают десяток языков - этот факт не имеет значения. Но как точка старта - Python плох.
Вторая - численный метод который очень долго работает. Скорее всего ты взял из справочника
метод с очень медленной сходимостью. Надо поискать именно тот который реализован в
функции pow и для начала просто его повторить.
С чем мы сейчас боремся?