Пишу не ответ на вопрос а просто некое частное мнение. ИМХО.
1. Устанавливал среднее сжатие данных, так как диск был SSD всего на 128 гигабайт, а процессор I7? было довольно не плохо)
Будь осторожен со сжатием. Оно эффективно только на определенном роде информации и на юзкейсе. Как только юз-кейс этой информации меняется (например решил обновлять на регулярной основе много документов) то может появится неконтролируемая нагрузка. И самое плохое что когда это случится - ты скорее всего забудешь о сжатии и не будешь понимать что происходит. Почему все стало медленно.
У меня стоит диск под бигдату. 3G. Учебные наборы данных. И он отформатирован под XFS. Если мне нужно сжать какой-то крупный dataset - то я его сжимаю bzip-ом. Взамен получаю splittable архив по которому биг-датавские фреймворки умеют бегать и работать с его частями независимо. Это опция только bzip2. Другие архивы эту опцию не поддерживают поэтому я их не использую. Данные не меняются в силу природы датасетов. Все работает хорошо.
Если-бы я сжимал на уровне ФС все подряд каким-то жлобским GZip или Snappy, то я-бы не получил этой возможности. Более того я мог-бы получить неконтролируемую просадку в производительности например на операциях многократного сохранения датасета в файл. А я люблю по много раз пересоздавать датасет-файл добиваясь толи индексирования толи еще чего.
По поводу Btrfs - это хорошая и умная система. Но ее возможности шире чем ты используешь. Она сильна снапшотами и программными рейдами. Но это все - фичи которые "дома" тебе практически никогда не потребуются. Более того. Если какая-то ситуация случается (что-то отмонтировалось) у тебя обычно нет времени и желания с этим разбираться глубоко. Если ты создавал снапшот для задач разработки а потом "забыл" его - то получишь невидимый технически долг на диске. В чем этот долг проявится - чорт его знает но обязательно он проявится. Вобщем мораль такова что если ты хочешь быть дежурным админом или девопсом - то ставь сложные файловые системы. Если просто надо работать - то ставь ext4 или xfs.
Pudjak, почему забил? И почему решил искать корень n-й степени?
Мне тут неясно только начальное приближение. И непонятна констата А.
Все остальное - очень простой итеративный алгоритм. Без рекурсий.
Его можно дебажить. Выводить значение x и n на каждом шаге.
Да, скорее всего он из-за чего-то заходит бесконечно в рекурсию.
Я скажу честно что я не компилировал и не анализировал твой код.
Все что я пишу - это набор механических советов или трансформаций
кода нацеленных на выявление причины сегфолта.
Я тебя попросил в первом посту измерять глубину рекурсии. Сделай пожалуйста это. Это очень легко.
Залоггируй. Иначе мы топчемся на месте.
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 Не понимаю - говорит. Массивы-указатели. Соглашения и традиции по тому как передавать и использовать аргументы. Это не метод тыка как Питоне. Это... наука. До седых висков надо кодить чтоб появилось видение как вообще правильно делать.
Будь осторожен со сжатием. Оно эффективно только на определенном роде информации и на юзкейсе. Как только юз-кейс этой информации меняется (например решил обновлять на регулярной основе много документов) то может появится неконтролируемая нагрузка. И самое плохое что когда это случится - ты скорее всего забудешь о сжатии и не будешь понимать что происходит. Почему все стало медленно.
У меня стоит диск под бигдату. 3G. Учебные наборы данных. И он отформатирован под XFS. Если мне нужно сжать какой-то крупный dataset - то я его сжимаю bzip-ом. Взамен получаю splittable архив по которому биг-датавские фреймворки умеют бегать и работать с его частями независимо. Это опция только bzip2. Другие архивы эту опцию не поддерживают поэтому я их не использую. Данные не меняются в силу природы датасетов. Все работает хорошо.
Если-бы я сжимал на уровне ФС все подряд каким-то жлобским GZip или Snappy, то я-бы не получил этой возможности. Более того я мог-бы получить неконтролируемую просадку в производительности например на операциях многократного сохранения датасета в файл. А я люблю по много раз пересоздавать датасет-файл добиваясь толи индексирования толи еще чего.
По поводу Btrfs - это хорошая и умная система. Но ее возможности шире чем ты используешь. Она сильна снапшотами и программными рейдами. Но это все - фичи которые "дома" тебе практически никогда не потребуются. Более того. Если какая-то ситуация случается (что-то отмонтировалось) у тебя обычно нет времени и желания с этим разбираться глубоко. Если ты создавал снапшот для задач разработки а потом "забыл" его - то получишь невидимый технически долг на диске. В чем этот долг проявится - чорт его знает но обязательно он проявится. Вобщем мораль такова что если ты хочешь быть дежурным админом или девопсом - то ставь сложные файловые системы. Если просто надо работать - то ставь ext4 или xfs.