detect odd or even

hello i need help again. how do i detect odd or even integers on my code? my code is this.

int SetPin = 18;
int ChangePin = 19;
int SetButton = 0;
int ChangeButton = 0;
int Change = 0;
int Second = -1;
int Minute = 1;
int Start = false;

void setup(){
pinMode(SetPin , INPUT_PULLUP);
pinMode(ChangePin , INPUT_PULLUP);
}


void loop(){
Set();
ChangePoint();
ChangeButton == digitalRead(ChangePin);
SetButton = digitalRead(SetPin);
unsigned long currentMillis = millis();
  if (currentMillis - previousMillis >= interval) {
    previousMillis = currentMillis;
    if (Start == true && Second > 0) {
      Second = Second - 1;
    }
    if (Second == 0 && Start == true && Minute > 0){
      Second = 60;
      Minute = Minuter -1;
    }
    if (Minute == 0 && Second == 0){
      Start = false;
    }
  }
}

void ChangePoint(){
  if(ChangeButton == LOW){
      Change = Change + 1;
  }
}
void Set(){
  if (SetButton == LOW && Start == false ){
    if(Change % 2 == 0){
      Second = Second + 1;
    }
    if(Change & 2 == 1){
      Minute = Minute +1;
    }
  }
}

if i press the Change button i can set any integers on Seconds and i press Change button again i can set any integers on Minute .

my problem is it doesn't detect odd or even number. Second for even numbers and Minute for odd numbers.

int x = somevalue;

if (x % 2 == 0) ==> even // this is the most generic way

or

if (x & 0x01) ==> odd // bit magic

There are even more odd variations ;)

ChangeButton == digitalRead(ChangePin);

OOPS! ^

robtillaart: int x = somevalue;

if (x % 2 == 0) ==> even // this is the most generic way

or

if (x & 0x01) ==> odd // bit magic

There are even more odd variations ;)

Then you get the endless discussion of:

if (x % 2 == 0) ==> even // this is the most generic way

Then is zero odd or even?

Paul

Paul_KD7HB: Then is zero odd or even?

It can certainly be divided into two equal groups. That makes it divisible by two and by every definition of even that I know of that makes it even.

Paul_KD7HB: Then you get the endless discussion of:

if (x % 2 == 0) ==> even // this is the most generic way

Then is zero odd or even?

Paul

explained here - https://en.wikipedia.org/wiki/Parity_of_zero

Paul_KD7HB: Then you get the endless discussion of:

if (x % 2 == 0) ==> even // this is the most generic way

Then is zero odd or even?

Jesus, folks are arguing universal fundamentals of mathematics here now?

Just recalling the problem new programmers had with a signed/unsigned zero. The sign depended on how the "0" was created. By addition or by subtraction or by a fixed constant at compile time.

Paul

Paul_KD7HB: Just recalling the problem new programmers had with a signed/unsigned zero. The sign depended on how the "0" was created. By addition or by subtraction or by a fixed constant at compile time.

Paul

What kind of machine were they programming?

robtillaart: if (x & 0x01) ==> odd // bit magic

If I'm understanding how that works correctly, if the final bit in the number is a 1, the number has to be odd?

SteevyT: If I'm understanding how that works correctly, if the final bit in the number is a 1, the number has to be odd?

how about it?

look at 1 as an int8_t:

00000001

and how about negative 1?

11111111

Negative 1 is also odd.

Paul_KD7HB: Just recalling the problem new programmers had with a signed/unsigned zero. The sign depended on how the "0" was created. By addition or by subtraction or by a fixed constant at compile time.

Paul

of course both IEEE-754 zeros are even!

SteevyT:
If I’m understanding how that works correctly, if the final bit in the number is a 1, the number has to be odd?

yes, if an integer number is represented in binary format, then the least significant bit indicates the oddness.

We see something similar in the decimal representation: a number is odd if the last digit is odd.

At school we were once asked to write a program to generate as fast as possible the first 10000 “hyperodds”,
that were odd numbers that in binary format had an odd number of ones.

eg 13 is an hyperodd as it is written 000001101 (it has even an odd nr of zero’s),

hyperodds = { 1, 7, 11, 13, 19, 21, … }

robtillaart: (it has even an odd nr of zero's)

If we're talking about 8 bit (or any other even number of bits) systems then the fact that it has an odd number of 1's dictates that it MUST also have an odd number of 0's.

floating point numbers have no odd or even, just like fractions and Complex numbers

Wait, complex integers can they be odd / even / both?

e.g 3 + 4i is that odd and even at the same time? computor says no

Delta_G: If we're talking about 8 bit (or any other even number of bits) systems then the fact that it has an odd number of 1's dictates that it MUST also have an odd number of 0's.

true :)

dictates that it MUST also have an odd number of 0's.

I don't even think it's odd

odometer: What kind of machine were they programming?

The IBM 360/370 series. The sign of the number was not part of the number, but a separate bit we could test, but not actually see, I guess.

Paul

Integer arithmetic on the 360/370 was twos-complement and so had a "normal" sign bit. The packed decimal format had a separate sign indicator but I never used that format so I'm not conversant with its mysteries. Many years ago I worked on a machine that used ones-complement arithmetic. In that representation there are two zeros - negative zero and positive zero. To form a negative number in twos-complement arithmetic you invert all the bits of the number and then add one (complement and increment). Using a 16-bit integer, negating zero works like this: 0000000000000000 1111111111111111 complement 0000000000000000 and incrementing makes the carry disappear off the end.

But in ones-complement arithmetic you negate a number by just complementing it. So, 0000000000000000 1111111111111111 complement gives a negative zero. The arithmetic with ones-complement was weird too because it had what was called "end-around-carry". Adding one to zero should, of course, give one. Adding one to the plus zero is easy. Adding it to the negative zero involves the end-around-carry. 1111111111111111 minus zero 0000000000000001 plus one 0000000000000000 BUT the carry went off the end, so the end-around-carry (done automatically by the ALU) adds the one back on the right hand side and results in 0000000000000001

Pete