остаток конечно может убежать за пределы, а может и не может

Ты же понимаешь что все приложения надо переписать на асинх.модель

Причем на competition based модель

Говорят, что если y = kx + r, 0 <= r < x, то y сравнима с x по модулю r. У сравнения по модулю есть различные свойства, но, так или иначе, если эти свойства не позволяют вспомнить делитель или он заранее неизвестен, то нет способа восстановить делимое. Тут ещё важный момент, если хочется свойства сравнений по модулю использовать, то нужно учитывать, что / и % не работают, как в математике.

примерно понял но там вроде другая тема. если делитель целый то остаток получается целый, и остаток просто складыывается с "начальным"  числом

ну, вообще делитель известен всегда. но он может меняться

и по идее остаток в аккумуляторе будет валиден и для нового. вобщем это все тяжко

наверное пока втупую буду абсолютное число делить

оно само себе аккумулятор

@enomad Ты это... всё таки нарисуй кружок.

Картинки помогают больше, чем типчики.

А что ты скажешь насчёт того что иногда можно делать уб а   иногда нельзя/)

Не тролль меня, пожалуйста

Уб никогда нельзя делать

Ну ты так предложил вчера)

Я не предлагал делать уб

Да, просто говорил что ничего страшного не случится)

я не понимаю как тут заюзать кружок. у меня условно говоря тут не кружок ) у меня правило - каждые 1000 счетов сделать 1 счет в другом месте. т.е. ратио например 1000:1 и этот счет интовый(хотя можно сделать не интовый и аккумулировать тоже, наверное).

проблема в том что когда мы хотим брать не абсолютное значение от самого начала т.е. 1000 от нуля - а дельту от того сколько было в прошлом фрейме - мы не можем ее разделить на 1000 чтобы получить 1, поэтому приходится писать что мы ничего не взяли чтобы следущий фрейм начать с того же числа

хотя наверное аккумулировать "воздействие" будет наверное чище...

т.е. просто складываем дроби по 1/1000