Во-первых, позвольте мне начать с того, что я знаю, что нет способа избежать ошибок округления.Мой вопрос скорее заключается в том, как принять ошибки округления и исправить их.«Почему это важно?», Спросите вы.В моем Java-проекте я использовал теорему о разделении осей для реализации обнаружения / разрешения столкновений для движущихся объектов, и она работает потрясающе хорошо, но есть недостаток, с которым я продолжаю сталкиваться ...
Ошибки округления
Я сделал иллюстрацию, чтобы проиллюстрировать то, о чем я говорю: 
Выше описан порядок разрешения конфликтов в моем проекте Java.Позвольте мне показать, как ошибки округления могут быть проблематичными в этой ситуации.
SV = MV.scale(2f(distance)/3f(move length))
2f / 3f = 0.666666667 (примерно то, что будет отображаться, если вы напечатаете 2/3) 0.666666667 очень плохо, потому что это на самом деле вызывает масштаббыть слишком большим масштаб 0.000000001 слишком велик, что означает, что SV будет больше, чем ожидалось, что приведет к тому, что он едва обрезается в другую форму при разрешении столкновения.Да, он настолько мал, что не может быть обнаружен человеком, но он действительно вызывает отсечение, каким бы малым оно ни было, и поэтому я считаю это СБОЙОМ разрешением коллизий.
Мое рабочее решение до сих порбыло что-то вроде
MV.scale((int)(2f/3f)*10000f)/10000f)
Хотя это, вероятно, будет работать для всех приложений, для которых я бы использовал свой алгоритм, потеря точности и вероятное возможное нарушение при больших числах (из-за потери точности, возникшей в связи сприрода чисел с плавающей запятой) затрудняют принятие.У меня не было бы проблемы с выбором 0.666666665 (или чего-то близкого к нему) с помощью алгоритма, но я не могу найти алгоритм для нахождения следующего ближайшего числа с плавающей запятой к числу (и, если оно существует, я бы с осторожностьюпотери производительности).
Есть идеи или альтернативные стратегии?Я как бы в своем уме остроумие здесь.Заранее спасибо!