Jim Yingst

Yes, obviously "offset += length" should have been "offset += count". Thanks for the catch.

Vanja Sanjin wrote:file.length(); returns long. Here it's casted to an integer. What if the return value is bigger than a maximum integer?

Presumably Raymond inserted the cast to int because "new byte[length]" doesn't work for a long length. Ultimately if the file length is longer than Integer.MAX_VALUE, there's no way to read everything into a single byte array anyway; we should probably just error out instead.

Oh, and Matthew, thanks for showing the proof.

But Matthew, didn't you hear? Centroids have nothing to do with it. IT DID NOT WORK!

Based on Myke's obvious respect for the traditions of Plato and Pythagoras, I'm sure a detailed proof of this will be forthcoming. It was probably just overlooked in the rush.

I agree with Ryan of course. Also:

rutuja patil wrote:Jim, what if they don't know the exact weight... then will they need two weighings?

No, three. See the solution posted by Mike. Misha also claims there is another solution with three weighings - I expect that's true. There are probably multiple solutions with three weighings. But if you don't know the weight of a real coin or a counterfeit coin in advance, you can't get a better solution than three weighings - even if the weighings are done with a spring scale rather than a balance.

I always liked the growly icon best.

Some problems are probably easier to solve by banning.

Maybe it's a little late to return to this, but it occurred to me that, under Steve's assumptions, one weighing is sufficient to identify the counterfeits. Just weigh the seven genuine coins, and we see that the weight is exactly what we'd expect for seven genuine coins. Thus, the remaining seven coins must be counterfeit. So hey - why waste a second weighing when one is sufficient?

Hm, I find the 3-weighings-with-a-balance version of the problem much more rewarding.

W. Joe Smith wrote:I thought the assumption was you didn't know which ones were counterfeit, so you were weighing them to find out?

No, that was the original, mis-stated version of the problem. It's impossible in 3 weighings. Arjun posted the corrected version on November 25/26:

Arjun Shastry wrote:I also think whether it has any solution.This is the exact problem statement-(I made mistake by saying all lighter coins weigh same)
Fourten coins were represented in a court as evidence.The judge knows that exactly 7 of these are counterfeit and weigh less than genuine coins.A lawyer claims to know which coins are counterfeit and which are genuine and she is rquired to prove it.
How can she accomplish this using only three weighings?
Taken from this book- http://www.amazon.com/Mathematical-Circles-Russian-Experience-World/dp/0821804308

Yeah, I was considering scale-based solutions back when we had the original, misstated version of the problems. (It's still demonstrably impossible in three weighings, for that version of the problem.) However you've added the assumption that the weight of a real coin is known, without weighing. I'm not sure that's valid.

Steve Fahlbusch wrote:This of course assumes that all bad coins weigh the same. And that all good coins weigh the same.

Yea, I think all solutions will require this assumption. Otherwise it's extremely hard to prove anything unless you use a lot more than three weighings.

Joe Ess wrote:The literal pool cannot get "full". The compiler creates it by pulling the literals out of your code, so it is a set size when you start your program. It neither grows nor shrinks.

That's true only if you're talking about the constant pool, which is a region in a .class file. That's for all constants referenced in the class definition, not just strings, so I don't think that's what the rest of this thread has been about.

If you're talking about the String intern pool, that's shared with String's intern() method - which means it certainly can grow. It can also grow if you keep loading new classes into the JVM.

It's also possible for items in the intern pool to be garbage collected, but that's fairly unusual, at least for literals, since such object also have other references from the class definition. You can think of the intern pool as a WeakHashMap - by itself, the intern pool will not prevent GC of its contents. But if there are any other references to a String in the pool, those can prevent GC. And it turns out that such references are maintained by the class in memory, after being loaded by a ClassLoader. So the only way for a literal to get GC'd is for the class to get unloaded. Which in turn requires that the ClassLoader that loaded it is also eligible for GC. Which doesn't happen often in beginner code, but it's not unusual in something like an app server. Bottom line, items in the intern pool can be GC'd, but it's complex and unusual.

Apparently, this is continued from here. Damodar, in general it's better to continue a topic in the same thread you started in, if you're really just continuing the exact same discussion. That way people have access to all the earlier info and don't waste time saying things that have already been said before. Thanks.

Apparently, continued here.

Yes. Case statements can only take compile-time constants, or enums, and the definition of compile-time constant expressions can only be applied to primitives and Strings. That's just the way they wrote the rules. On the one hand, yes the compiler has access to enough information here that it could probably figure out how to use an int rather than an Integer here. On the other hand, there's really no reason this number needs to be an Integer in the first place, is there? It can easily be changed to an int, and everything will work fine.