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.
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.
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.
And the idea of a "UST" is even more nonsensical. We've got four time zones in the continental US, plus at least two for Alaska and Hawaii. I'm too lazy to look up other places like Guam to see how they would change the total, or to argue about whether they should be considered. And inconsistencies in the adoption of Daylight Saving Time (evil blight on humanity that it is) make the issue even more complicated. If you want to see a 5-hour difference between the "US" and Britain, then you must mean the East Coast of the US. If you use TimeZone.getTimeZone("America/New_York"), that should work.
Really? If someone likes Weekly World News, is that really a serial? Personally I would never use the word this way. But I don't know what "serial" is taken to mean in India. [ June 10, 2008: Message edited by: Jim Yingst ]
[vijay]: hey John, 'Damini' I was talking about is a good serial in our country, not 'that' kind of serial. Please dont get misunderstood my friend.
If you want to avoid misunderstanding, it might help to actually explain what you mean by "serial". Notice that no one without an Indian name seems to have any idea what you mean here. Or well, some of us may have have a very vague idea, but I think you're using many unstated assumptions. Do the written works of Charles Dickens count? The TV show Dallas? The ongoing comic book The Amazing Spider-Man? Maybe Grand Theft Auto IV? (Hint: if the only examples you can name have titles only in Hindi, then this might not be a very good question for an international English-language site.) I suggest that some clarification might be in order. [ June 10, 2008: Message edited by: Jim Yingst ]
[Cameron]: Have you seen my book "Pickering is Springfield?" Perhaps I should send you a complimentary copy. It'll give you a much greater appreciation for the importance I place on subtle references and symbolism.
No, I confess I overlooked that one at my local bookstore. I suspect it may be unjustly under-promoted outside of, well, Pickering. So... you've got a lot of saguaro cactus around Pickering, do you? Still, I am intrigued, and I'm interested in checking this out.
Cameron- actually I agree that Lucas had this idea (and others) floating around among many others in his mind well before the first movie came out. His plans changed numerous times along the way, and his statements now about what his intent was back then really can't be trusted. But I was just disagreeing with your statement that "there was no reason or context to have that in other than foreshadowing". I'm saying there was a fairly straightforward reason to have it in, that had nothing to do with Vader being Luke's father. Whether or not that was actually Lucas' reason at the time, we may never really know.
Still wondering about your diplomatic craft comment though. I don't have my DVDs around currently to verify what the model looks like. I was thinking it looked like a small model of the vehicle sitting in the garage, evidently under repair. This is generally thought to be the T-16 that Luke says he used to "bullseye womp rats" back home. It's appeared more explicitly in later "extended universe" stuff, e.g. here. This craft also looks similar to the Imperial shuttle later used by the Emperor, Vader, and the rebels - is that what you meant by a "diplomatic craft"? But that vehicle didn't appear until Empire, the second film. It's hardly meaningful foreshadowing in the first film when the Imperial shuttle didn't even exist yet.
Luke's Aunt: "He's just like his father." Uncle Owen: "That's what I'm afraid of."
That was a pretty big hint, right from episode 1. There was no reason or context to have that in there other than foreshadowing.
I disagree - if we assume Lucas had no plan for Vader to be the father, then it's pretty easy to read that scene as Beru and Owen worrying that Luke was like his father in the sense that he was apt to go off and have adventures that would get him killed.
[CWMK]: Also, when you see Luke locked in his room with the droids, playing with 'airplaned', the plane he is playing with it Darth Vaders diplomatic craft, another big hint, right in the first (4th) episode.
Um, Henry seems to be assuming that an exception is thrown. If that's the case, then absolutely, report its error message and stack trace. However the methods delete() and renameTo() were written by perverse programmers who didn't feel the need to throw any exception in case of failure - they just return false. I consider it an embarrassment that Java has not provided better methods than these, in all this time.
Damodar, there are several possible reasons why these might fail:
Another stream or program may still be open for that file - be sure that streams are closed in a finally block before you try to delete.
One of the paths may be incorrect
You may not have permission to delete or rename that file.
The file may have already been deleted or renamed.
Unfortunately there's not really a good way to know which is the problem, other than checking each possibility carefully.
Corroboration: "Aren't you a little short for a storm trooper?"
While that may be considered evidence, it's hardly definitive. It's entirely possible this just means that troopers are generally adults, and a gawky punk kid like Luke was still a bit short of the average height for an adult trooper. In practice, Mark Hamill was about 26 during the filming of Star Wars. But he was supposed to be a teenager. I really think that's all Lucas meant by the line at the time.
Quoth Wikipedia:
"In order to reconcile this, George Lucas himself, as cited in a question and answer article of Star Wars Insider in 2005, stated that not all Stormtroopers are clones as a result of volunteers and conscription. He also said the clones themselves are not all clones of Jango whether out of necessity or political "rewards" for finding favor with the Emperor. So it is possible that there would be a mix of Jango clones, citizens within the Empire, and various clones of political appointees."
As for the original question here: generally, when I catch an exception, I would not log it and re-throw it. That just leads to the same exception being logged multiple times in the log files. I prefer to either log the exception, or re-throw it. Logging the exception is the responsibility of the last handler, whichever one does not re-throw the exception. Of course, that assumes that the final handler will indeed log the exception. If that last handler is written incorrectly (such that the exception is not logged at all), you may need to implement catch-and-rethrow in other handlers to help in your debugging. Then once you track down the author of the final handler that failed to log the exception, shoot them. [ June 07, 2008: Message edited by: Jim Yingst ]
[Peter Chase]: Also, you probably shouldn't be using Throwable here, because that implies you might be catching Errors somewhere. That's almost always wrong, as Errors indicate serious unrecoverable JVM-wide problems, for which the only solution is usually exiting the whole process (perhaps after attempting some minimal clean-up).
Eh, I don't really buy that. Yes, I agree that usually, catching an Error is a bad idea - but not always. The case against And if you create a new Exception that can't wrap a Throwable, but only an Exception, you're preventing people from ever using it to catch and re-wrap an error. I think that's a mistake.
Well, actually you don't completely prevent it, since they can always use the initCause() method inherited from Throwable. That's a bit more cumbersome though, and often overlooked.
The issue of catching Errors has been discussed numerous times here. These are some of my past diatribes on the subject:
[Bill Shirley]: Another reason (not that you should need one) to avoid the Date + 10 * 24 * 60 * 60 * 1000 solution is that the entire class has been deprecated.
No, the Date class has certainly not been deprecated. Many of its methods (and constructors) have been deprecated. But the class as a whole is definitely not deprecated, and it remains the preferred way to refer to dates and times in most Java programming contexts.
[Bill Shirley]: Calendar is what to use going forward, you might as well get used to using it now.
Calendar is what to use when you absolutely have to, because you can't find what you need in Date or DateFormat. Generally that means you need it for anything that might depend on knowing how many days are in a given month, or when daylight savings takes effect, or when leap years occur. Unfortunately Calendar has a very poorly-designed API, so I recommend avoiding it except when you really need it. The current problem of subtracting ten days probably qualifies - depending on what we mean by a "day". Is it 24 hours, or is it a calendar day? Usually people mean the latter, in which case you need Calendar. Or you could use Joda-Time, which is much nicer.
[Darth Spritzler]: If the first death star waited till it was 100% compeleted, why didn't they wait that long for the second death star. And wouldn't they have made it more difficult to destroy than the first one? I mean now instead of just a 2 meter whole, an entire Millenium Falcon can now fly through it to a big whomping target to shoot and destroy it. You would think they learned their lesson from the 1st death star.
The second Death Star was designed with a ruse/trap in mind - the idea was that it would be "fully functional" (at least, able to raise its shields and fire its big planet-destroying main gun) well before it looked complete. At least, that was the impression I always had from the Emperor's big "fully operational battle station" reveal. The Emperor wanted to lure the Rebels into an attack, at a time and place of his choosing. And the Rebels fell for it.
Yes, but if the Emperor had the ability to dissolve them at any time, one has to wonder how much they were able to really scrutinize the budget before approving it. I tend to think there was probably a big chunk of the budget that was marked "Imperial Security - Top Secret". Or perhaps its purpose was obfuscated and hidden under a myriad of more benign-sounding names. The latter seems more probable to me, but who knows? Either way, there's ample opportunity for the Empire to fund a major secret weapons program.
[Mark Spritzler]: ... Along those lines, what was the actual first piece, and how did it sit on its own out there in space...
Well, Marc already addressed this implicitly. But to spell it out: the station is in outer space. It doesn't have to be attached to anything. As long as the station's creators put it on an orbit that doesn't intersect a planet or star (or other celestial body), it doesn't have to do anything - it can just sit there in orbit, not bothering anyone. Doesn't need to be attached to anything. Why should it?
[satish]: The example given in the article is not a immutable class. It is a mutable class. If you want to write a immutable class, all object attributes must be final and private. Public setter methods should not be provided. Check the comments given in the article's page.
[amitabh]: Satish, the writer has also clarified your point.
No, the writer made a slightly different point, because the writer used a slightly different (weaker) definition of "immutable". The writer gave an example of a class that was "immutable" but its fields are not final. Such a class is not truly immutable - not according to what Satish wrote. Or according to me. A truly immutable class is one whose fields are all final, whose fields are either primitive or also immutable types, and the class is being run using JDK 5 or later. (I could also say that it has no setters or other mutator methods, but that's not necessary - it follows from making the fields final.)
[Nick]: final, or immutable ( which is what the word final does, not an actual keyword ) does not make anything Thread Safe
A truly immutable class is thread-safe in all respects, no matter how you use it. (Um, well, aside from some nasty things you might do with reflection maybe...) The keyword final is necessary but not sufficient to make this happen. You are not doing anyone any favors by blurring the distinction between final and immutable.
My experience is that a byte[] array typically uses one full byte for every boolean. Thus, it's eight times as big as it needs to be. This is not specified anywhere that I'm aware of, and it's possible that on some platforms, a boolean[] array uses only one bit per boolean. It's also possible that some platforms use more than one byte per boolean. Anyway though, if you want to use space a little more effectively, a java.util.BitSet may be a good idea. This generally uses one bit per boolean, if you get the size right in the first place and don't need it to resize. It's probably a little slower than a byte[] array - perhaps a lot slower, if you aren't doing anything else in your program. Usually that doesn't matter much though.
(But as usual with performance problems, you should probably verify that you actually have a noticeable problem, before you spend much time optimizing it.)
I'm not a JBoss person at all. But as for why you're not able to catch the error, I would check (a) what is the full package name of the error and (b) what classloader does it have? If either of those are different, that might explain why catch NoClassDefFoundError is not catching the NoClassDefFoundError.
[Scott]: I don't like the looks of "if (obj == this) return true;" inside of equals() method, it seems like a bad idea.
Really? Why? Seems to me that it's generally not necessary, but it can be a useful performance enhancement. You can see the same thing in the source code for java.lang.String, for example.
But that's not broken, in the sense that it is still behaving exactly as you should expect, based on the API.
Regardless, I say there is no good reason to use a StringBuffer or StringBuilder as a key in a Map, ever. I can imagine cases where you could do it, but there's always another way which is no worse, and almost always better. Which usually means: USE A STRING INSTEAD.
Note where it says "Usage: Asia". A term can be in the dictionary without being in general usage. And what is "correct" will ultimately depend on who you're trying to communicate with. Prepone, splitted and doubt (as used here) are still not well known outside India (and sites with a lot of Indians).
To clarify my previous post here (see why we don't like these discussions spread across multiple threads? Blech!):
If you use a StringBuffer as a key, with the equals as defined, and you change the value inside the StringBuffer, then the map won't break, but quite possibly it won't behave as you expect. In fact that was the point of this thread - with the current equals() and hasnCode() implementation, HashMap doesn't work as many would expect. I can imagine little use for a HashMap using StringBuffers as keys. It's not broken, just not very useful.
However if Sun had provided an equals() and hashCode() that reflect "expected" behavior (based on the content of the StringBuffer), then if you changed the content of a StringBuffer used as a key, that would break the contract of the HashMap, and it wouldn't work. That's really true for any mutable object that has an equals() and hashCode() based on its content. If you change the object after it's been put in a map as a key, the map won't work.
[imaya]: do you mean we should use only immutable object in Hashmap or Hashset? lot of time we 'll use our custom class (Eg: Student.class) objects as key in hashmap which is mutable which can be modified even after put in collection. developer has to take care of this.
Well, for most classes, we don't have a mutable version and an immutable version. We often just have a mutable version, and when we put instances in a map, we simply don't change them afterwards. Usually that works, though sometimes people make mistakes. Often that seems easier than creating new immutable classes just for use as keys. Fine.
However with String and StringBuffer (and StringBuilder), we have both mutable and immutable versions. So if you need a string-like object to use as a key - USE A STRING. I don't think there is any good reason to use a mutable object as a key when an immutable alternative is readily available. The only reason to use the mutable version is if you still expect to change it - and if that's the case, you should not be using it as a key. [ May 29, 2008: Message edited by: Jim Yingst ]
Well, a Map or Set assumes that the keys (for Map) or values (for Set) will not change. And the entire purpose of a StringBuffer is to change its content. Which makes them extremely poor choices to use in a Map or Set - if you change the content of a StringBuffer after you use it as a key in a Map, the map won't work correctly. There are two basic options:
1. If you're dong changing the content of the StringBuffer, use toString() to convert it to an immutable String, and use the String as the key in your Map.
2. If you're not done changing the content of the StringBuffer, don't even try to use it as a key in a Map. It will only cause you pain.
I think the main problem is that when you call useDelimiter(), the scanner will look for the itemsbetween the delimiters. E.g. if you have a line
1,2,3,4
and you use a delimiter of ",", then Scanner's next() will give you all the numbers, not the commas. If you want to see the commas, you can't use them as delimiters. Instead try using findWithinHorizon().
If you want to find one complete properties group tag, for example, try
However as I look at your problem, it may well be easier to forget about regexes, and instead just read one line at a time. You can look at the first letter of each line to tell what's going on:
'[' - starting a new property group. ' ' or blank line - ending a property group any other letter - listing a new property within the current group [ May 29, 2008: Message edited by: Jim Yingst ]
![[Logo]](/templates/default/images/moosefly.gif)
So... you've got a lot of saguaro cactus around Pickering, do you? 
Still, I am intrigued, and I'm interested in checking this out.