 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / November 2007Story about assertions
I was just writing a small and simple program to calculate a random number from the set {0,1}: final int r = secureRandom.nextInt(); final int result =( r / 69313 )% 2; Just for the heck of it, I added: assert result >= 0 && result < 2; As I wrote this, I thought: This assertion is completely unnecessary, because it is obvious that the result of »% 2« is always in the set {0,1}. So what am I doing here? Just stating the obvious to needlessly enlarge the source code? The next thing happening then, of course, was: Exception in thread "main" java.lang.AssertionError > I was just writing a small and simple program to calculate > a random number from the set {0,1}: [quoted text clipped - 14 lines] > > Exception in thread "main" java.lang.AssertionError Presumably an effect of thinking of "%" in Java as a modulo operator, rather than integer division remainder? The moral, perhaps, is that the more deeply you are assuming something, the more valuable it is to assert it. Patricia Stefan Ram wrote: >> I was just writing a small and simple program to calculate >> a random number from the set {0,1}: [quoted text clipped - 12 lines] >> >> Exception in thread "main" java.lang.AssertionError > Presumably an effect of thinking of "%" in Java as a modulo operator, > rather than integer division remainder? > > The moral, perhaps, is that the more deeply you are assuming something, > the more valuable it is to assert it. Throw a Math.abs() in there to enforce the postcondition. For those not used to the 'assert' keyword yet, the key concept is "invariants". The presumed invariant wanted in Stefan's example was "that the result ... is always in the set {0,1}"; it just happened that of »% 2« was not enough to ensure it. Math.abs() would have helped ensure it. As Patricia says, this is an excellent example of how assertions help make a program bug free.  SignatureLew >>final int result =( r / 69313 )% 2; >Presumably an effect of thinking of "%" in Java as a modulo >operator, rather than integer division remainder? Yes. I hitherto had used it nearly always for positive numbers only. >The moral, perhaps, is that the more deeply you are assuming >something, the more valuable it is to assert it. The point of the program was to test another such assumption: When you start to throw a coin, which sequence appears first (on the average): »Head-Tail-Head« or »Head-Tail-Tail«? For example, in »Head Head Head Tail Head« there are five throws, and »Head Tail Head« is at the end; so in this attempt, five throws were needed to arrive at »Head-Tail-Head«. After this, a new attempt is started (a new sequence of throws) and the number needed to arrive at either end (»Head-Tail-Head« or »Head-Tail-Tail«) is recorded again. One output line from the simulation I wrote is: 359934651 382966118 371453626 371447146 The first number is the sum of the number of throws of the coin until »Head-Tail-Head« is found, the second number is the same for »Head-Tail-Tail«. (The next to numbers are the total sum of Tail and Head results, respectively. They show that the random generator delivers quite an even distribution of these two events.) The output suggest that one arrives at »Head-Tail-Head« faster. I leave it to the reader to speculate on why this might be so or to implement his own version of the simulation. > One output line from the simulation I wrote is: > [quoted text clipped - 3 lines] > the coin until »Head-Tail-Head« is found, the second number > is the same for »Head-Tail-Tail«. What are the mean and variance of the results? SignatureLew > The point of the program was to test another such assumption: > > When you start to throw a coin, which sequence appears first > (on the average): »Head-Tail-Head« or »Head-Tail-Tail«? [...] > One output line from the simulation I wrote is: > 359934651 382966118 371453626 371447146 [quoted text clipped - 7 lines] > I leave it to the reader to speculate on why this might > be so or to implement his own version of the simulation. No need to speculate, it stands to reason. Michael >No need to speculate, it stands to reason. If you are a native speaker of German, you might think of »speculate« as the German verb »spekulieren« only, but it also might mean »nachdenken«. See: http://dict.leo.org/ende?search=speculate > The point of the program was to test another such assumption: > When you start to throw a coin, which sequence appears first > (on the average): »Head-Tail-Head« or »Head-Tail-Tail«? Are you sure you meant »Head-Tail-Tail« not »Tail-Tail-Head«? Michael >Are you sure you meant »Head-Tail-Tail« not »Tail-Tail-Head«? The two sequences actually investigated are written in my source code as: static final int i101 =( 1 << 2 )|( 0 << 1 )|( 1 << 0 ); static final int i100 =( 1 << 2 )|( 0 << 1 )|( 0 << 0 ); If you choose »1« to mean »head«, this would be »Head-Tail-Head« versus »Head-Tail-Tail«. >>Are you sure you meant »Head-Tail-Tail« not »Tail-Tail-Head«? > [quoted text clipped - 5 lines] > If you choose »1« to mean »head«, this would be »Head-Tail-Head« > versus »Head-Tail-Tail«. Well, that depends on the order they are interpreted in. It would be typical to use the least significant bit first, so the sequences would be HTH and TTH. The expected chance of finding HTH before HTT is 50% (equally likely) The expected chance of finding HTH before TTH is 37.5%. Much more interesting. /L SignatureLasse Reichstein Nielsen - lrn@hotpop.com DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html> 'Faith without judgement merely degrades the spirit divine.' >The moral, perhaps, is that the more deeply you are assuming something, >the more valuable it is to assert it. I just read a web page, where Robert Fischer suggests to write the following unit test: »assertTrue(true);« http://enfranchisedmind.com/blog/2007/11/26/my-great-secret-to-writing-unit-tests/ >> The moral, perhaps, is that the more deeply you are assuming something, >> the more valuable it is to assert it. [quoted text clipped - 5 lines] > > http://enfranchisedmind.com/blog/2007/11/26/my-great-secret-to-writing-unit-tests/ I've never gone quite that far, but I do often start by testing null, and other out-of-range, arguments. That is particularly helpful from the point of view of tests as a documentation driver. Trying to write a null argument test reminds me to write the Javadoc comment saying what *should* happen for null, so that I know what the test should expect. Patricia > >The moral, perhaps, is that the more deeply you are assuming something, > >the more valuable it is to assert it. [quoted text clipped - 5 lines] > > http://enfranchisedmind.com/blog/2007/11/26/my-great-secret-to-writin... I wonder what he would do if that test failed... >>> The moral, perhaps, is that the more deeply you are assuming >>> something, the more valuable it is to assert it. [quoted text clipped - 7 lines] > > I wonder what he would do if that test failed... Debug or replace his copy of JUnit. Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.