MH
There are only two hard things in computer science: cache invalidation, naming things, and offbyone errors
Saurabh Pillai wrote:(Did I take correct route?)
if you weigh 3 against three, and one side is lighter, you only need two weighings.
Both of the fake coins are in the lighter side.
kri shan wrote:If one fake coin is one side and another fake coin is another side during my first weighing
like (2 original coins + 1 fake coin one side and 2 original coins + 1 fake coin another side).
Then can we start from begining ?
MH
J2EE Architect/Developer
Henrique Ordine wrote:That's a lot more than 3 weighings.
J2EE Architect/Developer
Henrique Ordine wrote:Nice try.
I stopped counting after that.
Henrique Ordine wrote:Nice try.
1:A
2:B
3:C
4:D
I stopped counting after that.
J2EE Architect/Developer
J2EE Architect/Developer
Henrique Ordine wrote:I still have doubts about the last solution to the previous problem.
Are they assuming that if A<B then A is one of the lighter coins and B is not? If so, they said that the lighter coins don't necessarily need to have the same weight, so how do you know that they're not both the lighter coins. <br /> <br /> Also, are they assuming that if then they must be both original coins? If so, how do they know that they're not both lighter coins that coincidentally weigh the same weight?>
1: AB
2: CD
If we have identified two coins as lighter, we are done (e.g. A < B and C < D).
If we have identified one coin as lighter
3: EF to find the 'other" lighter coin.
Otherwise (all scales balanced to date):
3: AC
If balanced, then the two 'lighter' coins are E,F
If A<C, then the coins are A,B
otherwise the coins are C,D
please buy this thing and then I get a fat cut of the action:
Enterprisegrade Excel API for Java
https://products.aspose.com/cells/java
