Assertj-core: Consider adding isEven/isOdd to AbstractByteAssert, AbstractShortAssert, AbstractIntegerAssert and AbstractLongAssert

[fbiville]

Summary

It is currently not possible to directly assert whether integers are odd or even.

Example

assertThat(someInteger).isEven();
assertThat(someInteger).isOdd();

[scordio]

Wouldn't the isEven()/isOdd() pair be enough?

[joel-costigliola]

yes, if it's not even then it's odd 😄

[fbiville]

Wouldn't the isEven()/isOdd() pair be enough?

It could, but I imagine in some contexts, you want to express the negation. Maybe not worth keeping though. No strong opinions :)

[scordio]

It could, but I imagine in some contexts, you want to express the negation.

That would be odd! (sorry, I couldn't resist 😄)

[joel-costigliola]

Let's keep it simple, no negative assertion.

[fbiville]

I assume we also want this for Byte, Short, Long and maybe even Character?

[joel-costigliola]

yes but I'm not sure we need it for character (how likely is somebody going to use that?), I'd rather wait for a user to ask for it

[scordio]

I assume we also want this for Byte, Short, Long and maybe even Character?

I think we should add these to NumberAssert, which would trigger some children classes so it's probably not going to be a small change.

I guess these new assertions should appear wherever isZero is available:

[fbiville]

The problem is that FloatingPointNumberAssert extends NumberAssert and you would end up with odd/even assertions for numbers other than integers.

[scordio]

Fair point, that would be wrong. Should we introduce an IntegerNumberAssert interface similarly to FloatingPointNumberAssert?

Probably BigInteger should also be part of the group, what do you think?

[joel-costigliola]

Probably BigInteger should also be part of the group, what do you think?

yes but if that is too much work, happy to create another issue for that.

Should we introduce an IntegerNumberAssert interface similarly to FloatingPointNumberAssert?

no strong opinion on that

[scordio]

We could go with the four in the title, later with BigInteger and then decide if the common interface is needed. For example, LongAdderAssert in #1812 could also belong to the family being a java.lang.Number.

[piefel]

Fair point, that would be wrong. […]

Well, floating point number _can_ be integral (and even exactly so), so they can be odd or even. Only that many number are neither.

[scordio]

Well, floating point number _can_ be integral (and even exactly so), so they can be odd or even. Only that many number are neither.

I'm far from being a mathematician, but the topic seems a bit more complicated when we move to rational numbers (i.e., floating point numbers), e.g. from Math StackExchange

The notion of parity can be extended to many rings - but certainly not all rings, since if 2 has an inverse 𝑢 then 2𝑢=1 ⇒2∣1∣𝑥 so everything is "even". So we can't extend it to all rationals, but if we restrict to the subring of rationals with odd denominator then integer parity has a unique extension: the parity of 𝑚/(2𝑛+1) is the parity of 𝑚, by mod2: (2𝑛+1)−1≡1−1≡1.

Also, from Wikipedia:

A fraction is even if the numerator is, therefore all rational numbers have parity.

IMHO I would keep floating point types out for now and we can always change it if the community sees the benefit of those assertions also there.