How can "a <= b && b <= a && a != b" be true? [duplicate]

Question

Here is the code i have to figure it out how is it possible. I have a clue but i do not know how to do it. I think it is about negative and positive numbers and maybe the variable modifiers as well. I am a beginner i looked the solution everywhere but i could not find anything usable.

the question is that: You need to declare and initialize the two variables. The if condition must be true.

the code:

if( a <= b && b <= a && a!=b){
       System.out.println("anything...");
}

I appreciate you taking the time.

Geibel

for int, I don't think the if ever evaluates to true – Bastardize

I would not be surprised if there is a combination of floating point numbers where this works. – Wedurn

I looked into -0F and 0F, but they won't do it. I think Henry's is the intended answer. – Sinister

I'm pretty sure this is a duplicate of a recent question, I can't find it at the moment, however. – Effeminacy

@JoachimSauer found a few. – Frederico

@johnchen902 the question you linked is already a duplicate. I prefer not to link question as duplicate of a duplicate question. BTW: this kind of questions shows no efford. This question ("how to make (a<=b&&a>=b&&a!=b) true?") should be downvoted, but instead we get this question every week in the "Hot questions" tab. – Frederico

@JohannesKuhn I think the answer in the latter linked question is better than that in the former one. – Lapointe

Here is the earliest version of this question I could find: how to declare i and j to make it be an infinite loop? I repeated my answer there so won't be lost if this version is deleted. – Sinister

Answer 1

This is not possible with primitive types. You can achieve it with boxed Integers:

Integer a = new Integer(1);
Integer b = new Integer(1);

The <= and >= comparisons will use the unboxed value 1, while the != will compare the references and will succeed since they are different objects.

Managing

These subtleties in the new features bolted on to Java 5 are just terrible... What a potential for bugs. – Wedurn

@Wedurn There is a reason they are called subtleties. I don't think there is anything wrong with the above subtlety. – Bastardize

@Wedurn agreed, auto-boxing and -unboxing is only convenient if you know exactly what you are doing. – Managing

That doesn't work because of the internal IntegerCache. Initalize to 128 and you'd be correct. – Opening

This answer is correct; he's not using auto-boxing. The new operator is, of course, guaranteed to create a new object (or fail to return normally). – Sinister

Those subtleties can easily be avoided: just don't use Integer anywhere where you care about the numeric value: use int. Only use Integer when you need an Object. – Effeminacy

The point is that != (and ==) compare the memory-position of the objects, whereas <, <=, >, >= compare the value of the object.<br>A serious design flaw right at the basis of the language: The simpler, more often used test requires the more far fetched, more complicated equal() method. – Wendling

This kind of counterintuitive behaviour makes me shy away from the Numeric Objects as much as possible. I'd love to have operator overloading in JAVA so that you can define the way your mathematical Objects deal with basic operators. It seems strange that the behaviour is defined for build in Numeric Objects, but you are unable to define the behaviour for you own Numberic Objects. – Huntlee

Answer 2

This works too:

Integer a = 128, b = 128;

This doesn't:

Integer a = 127, b = 127;

Auto-boxing an int is syntactic sugar for a call to Integer.valueOf(int). This function uses a cache for values less than 128. Thus, the assignment of 128 doesn't have a cache hit; it creates a new Integer instance with each auto-boxing operation, and a != b (reference comparison) is true.

The assignment of 127 has a cache hit, and the resulting Integer objects are really the same instance from the cache. So, the reference comparison a != b is false.

Sinister

It should be noted that the exact boundary of what is cached is not specified in the spec. – Effeminacy

@JoachimSauer The interval [-128, 127] must be cached, according to the spec, so 127, for example, will always fail. Values beyond that interval may be cached, which would cause a failure. – Sinister

Answer 3

Another rare case for class-variables may be that another thread could change the values of a and b while the comparison is executing.

Finkelstein