My1Name, он отработает корректно но бесполезно. Мы не сможем восстановить исходное изображение
и даже не сможем понять что оно из себя представляет. Это как анекдот про двух людей которые смотрят
на цилиндр и видят толи квадрат толи круг в зависимости от угла.
Ради интереса - почитай про преобразование Радона. Может это твое исследование найдет
какое-то новое направление.
Здесь есть дилемма попадания мячика на уголок биты.
И ее надо решить на уровне самой игровой постановки.
Пока ее не решим - бесполезно обсуждать "бока" биты.
Иначе решение будет недостоверным и противоречащим физике столкновений.
В несколько этапов. На языке программирования типа python/php собрать сведенья из системного словаря. Тут надо знать тип БД потому что названия системных таблиц разные везде. Потом динамическим запросом выбрать 3 колонки.
Максим Федоров, сомнительно что стек подходит под задачу. Я смотрел примеры приложений с Fx. Это - насыщенность инфографикой в первую очередь. Много всего анимированного. Это - основной юзкейс javafx. Если в приложении с арендой этот юзкейс не будет раскрыт - то считайте что инструмент был применен не по назначению. Тоесть зря потрачено время.
Пишу не ответ на вопрос а просто некое частное мнение. ИМХО.
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 - лучше сразу понять систему типов и это приводит дисциплину программирования на новый уровень.
А дисциплина - нужна. Куда-ж без нее в наше время.
и даже не сможем понять что оно из себя представляет. Это как анекдот про двух людей которые смотрят
на цилиндр и видят толи квадрат толи круг в зависимости от угла.
Ради интереса - почитай про преобразование Радона. Может это твое исследование найдет
какое-то новое направление.