Надо-бы исследовать как это произошло. Балансы хранит не кошелек а блокчейн. А в бумажнике по идее должны лежать приватные ключи для подписей. Как случилось что автор увидел старый баланс - непонятно. Либо глюк кошелька. Либо кошелек дал команду на вывод средств куда-то что согласитесь выглядит вообще как треш-трешовый. В любом случае главное правило - надо понимать чей софт мы берем. Доверяем-ли мы производителю софта. Или посреднику как в веб-версиях кошельков.
У тебя контракт функции какой? Тебе нужно вернуть true/false как признак повторения? Или тебе нужно распечатать первый попавшийся повтор? Или тебе надо найти все-все повторы?
Вот любишь ты писать в олимпиадном стиле. Все одной простыней. И разбивать на мини-функции тоже не любишь.
И что expected и что actual тоже не указываешь. И любишь заставлять бедных С++ ников дико напрягать мозг чтоб
скомпилировать это в уме.
Wan-Derer, что-то я не понимаю твою проблему. Есть задача. Автоматизируй все что можешь. Сгенери Java код на основе таблиц. Для генератора будет безразлично 300 таблиц или 1000.
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 на каждом шаге.
Да, скорее всего он из-за чего-то заходит бесконечно в рекурсию.
Я скажу честно что я не компилировал и не анализировал твой код.
Все что я пишу - это набор механических советов или трансформаций
кода нацеленных на выявление причины сегфолта.
Я тебя попросил в первом посту измерять глубину рекурсии. Сделай пожалуйста это. Это очень легко.
Залоггируй. Иначе мы топчемся на месте.
