Workarounds for broken modulus?

Epic8009

Modulus is broken in this way:

-1 % 192. Should be 191, right? In processing 3, the answer is -1. I need a workaround or something, as I cannot continue doing what I am doing with this bug,

GoToLoop

• If we divide -1 by 192, the non-fractional answer is 0.
• So the rest of that division is indeed -1.
• And that's the behavior not only for Java (which Processing is merely a library), but for other languages too.
• Hit F12 key in your browser and type in -1 % 192.
• You're gonna get -1 in JavaScript as well. :>

Epic8009

https://www.google.co.uk/search?q=-1+%+192&oq=-1+%+192&aqs=chrome..69i57.6294j0j7&sourceid=chrome&ie=UTF-8

I would like to mimic this behavior. Any way?

koogs

(i + n) % n

(Assuming i never gets below -n...)

Epic8009

so is this mimicing i % n? or am i mistaken?

koogs

((i % n) + n) % n

If I does go below -n

Epic8009

lol refresh XD

Epic8009

oh its i % n... thanks! this helps greatly

GoToLoop

Oh, you were asking for a backwards modulo calc. #-o

// forum.Processing.org/two/discussion/20128/
// workarounds-for-broken-modulus#Item_8

// GoToLoop (2017-Jan-07)

static final String[] WORDS = splitTokens(
  "Lorem ipsum dolor sit amet consectetur adipiscing elit");

int idx, dir = 1;

void setup() {
  frameRate(1);
}

void draw() {
  println(idx, dir, WORDS[idx]);
  idx = (idx + WORDS.length + dir) % WORDS.length;
}

void mousePressed() {
  dir *= -1;
}

void keyPressed() {
  mousePressed();
}

Epic8009

already solved.. but thanks for the help anyway!