В роли коррекции может выступать длина окружности. По сути нам надо разбить круг на набор бубликов (количество и ширина задается как пользовательские параметры). Далее рассматривать эти бублики как независимые графы которые имеют точки соединения на границах бубликов.
Есть такой чувак Conor Hoekstra. Он увлекается сравнением какого-то алгоритма в разных ЯП. У него куча публикаций в youtube. И вот я смотрю что с С++11 исходники C++ в его публикациях приобретают такой себе изящный ФП-style. Им конечно еще далеко до Haskell но тем не менее. Выглядят компактно. Я думаю что checkRepeat можно переписать в 3-4 строки без потери смысла.
А данный императивный алгоритм - фуфу. Эти переменные типа flag. Эти индексы. Все от недостатка выразительности. И неужели со времен Visual Studio 6.0 мы так и не получили функциональной выразительности?
Не могу проголосовать ответом потому что в тексте не звучит ответ. Звучит просто набор рекомендаций. Я думаю что лучше все таки приаттачить сорцы и тогда можно и голосовать.
Надо-бы исследовать как это произошло. Балансы хранит не кошелек а блокчейн. А в бумажнике по идее должны лежать приватные ключи для подписей. Как случилось что автор увидел старый баланс - непонятно. Либо глюк кошелька. Либо кошелек дал команду на вывод средств куда-то что согласитесь выглядит вообще как треш-трешовый. В любом случае главное правило - надо понимать чей софт мы берем. Доверяем-ли мы производителю софта. Или посреднику как в веб-версиях кошельков.
У тебя контракт функции какой? Тебе нужно вернуть true/false как признак повторения? Или тебе нужно распечатать первый попавшийся повтор? Или тебе надо найти все-все повторы?
Вот любишь ты писать в олимпиадном стиле. Все одной простыней. И разбивать на мини-функции тоже не любишь.
И что expected и что actual тоже не указываешь. И любишь заставлять бедных С++ ников дико напрягать мозг чтоб
скомпилировать это в уме.
Wan-Derer, что-то я не понимаю твою проблему. Есть задача. Автоматизируй все что можешь. Сгенери Java код на основе таблиц. Для генератора будет безразлично 300 таблиц или 1000.
My1Name, он отработает корректно но бесполезно. Мы не сможем восстановить исходное изображение
и даже не сможем понять что оно из себя представляет. Это как анекдот про двух людей которые смотрят
на цилиндр и видят толи квадрат толи круг в зависимости от угла.
Ради интереса - почитай про преобразование Радона. Может это твое исследование найдет
какое-то новое направление.
Здесь есть дилемма попадания мячика на уголок биты.
И ее надо решить на уровне самой игровой постановки.
Пока ее не решим - бесполезно обсуждать "бока" биты.
Иначе решение будет недостоверным и противоречащим физике столкновений.
В несколько этапов. На языке программирования типа python/php собрать сведенья из системного словаря. Тут надо знать тип БД потому что названия системных таблиц разные везде. Потом динамическим запросом выбрать 3 колонки.
Максим Федоров, сомнительно что стек подходит под задачу. Я смотрел примеры приложений с Fx. Это - насыщенность инфографикой в первую очередь. Много всего анимированного. Это - основной юзкейс javafx. Если в приложении с арендой этот юзкейс не будет раскрыт - то считайте что инструмент был применен не по назначению. Тоесть зря потрачено время.
