FRDB Archives

Freethought & Rationalism Archive

The archives are read only.


Go Back   FRDB Archives > Archives > IIDB ARCHIVE: 200X-2003, PD 2007 > IIDB Philosophical Forums (PRIOR TO JUN-2003)
Welcome, Peter Kirby.
You last visited: Today at 05:55 AM

 
 
Thread Tools Search this Thread
Old 07-09-2003, 10:10 AM   #11
Veteran Member
 
Join Date: Jan 2001
Location: USA
Posts: 1,072
Default

Quote:
Principia: In that thread, I demonstrated convincingly that DNAunion is a novice programmer [nope], before the moderators shut down the thread for DNAunion's tantrums [the pot calling the kettle black]. It seems like, 4 months later, DNAunion still has a grudge, and wants to relive that thread.
DNAunion: Hey Principia, where'd you learn math?

The last post in that thread was dated 04/04/2003. Today's date is 07/09/2003. Uhm, isn't it a lot closer to 3 months than 4?
DNAunion is offline  
Old 07-09-2003, 10:29 AM   #12
Veteran Member
 
Join Date: Jan 2001
Location: USA
Posts: 1,072
Default

Quote:
Principia: So what exactly is DNAunion trying to excuse himself, from? Well, could it be this little gem that he wrote?

**************************

long GetRandomNumber(int nMin, int nMax)
{
long lRandomNumber;

lRandomNumber = rand();
while (lRandomNumber < nMin || lRandomNumber > nMax)
{
lRandomNumber = rand();
}
return lRandomNumber;
}
********************************

Notice that to a trained eye, what DNAunion is trying to do here is generate a uniform random number between nMin and nMax, by discarding all the numbers randomly generated between 0 and MAXRANDOM (or whatever the largest integer rand() returns is)
DNAunion: Already been dealt with…remember? Here, let me refresh your memory.

Quote:
DNAunion: Too bad you can't read Visual FoxPro code. If you could, you would see that in the original program - not the quickly thrown together C++ translation I made while also posting at two discussion forums on the web - I performed this task more efficiently.


Code:
FUNCTION GetRandoumNumber(lnMin, lnMax)
	LOCAL lnRandomNumber
	* The pseudo-random number generator was already seeded with the system
	* clock – all calls after that initialization should not pass any value
	DO WHILE .T.
		lnRandomNumber = (FLOOR(RAND() * 1000) % lnMax) + 1
		IF (lnRandomNumber >= lnMin AND lnRandomNumber <= lnMax)
			EXIT
		ENDIF
	ENDDO
	RETURN lnRandomNumber
ENDFUNC

The modulus operation guarantees a result between 0 and 1 less than the lnMax. 1 is then added to it to obtain a number that lies between 1 and lnMax, inclusive. This should work on the very first iteration – the DO WHILE…ENDDO loop construct is used only to ensure that if I overlooked anything that an invalid result would not be returned.

When making the quick translation to C++ (as I said above, during which time I continued to post on the web at two discussion forums) I opted for the quickest method of getting the program up and running. Note also what I said:

***********************************

DNAunion: In addition, once the code is setup and debugged,…
***************************************


DNAunion: As this suggests, the C++ program is not completed. It performs the function it was designed for, but it is not ready for handing over to others (for example, instead of defining the parameters as constant variables it should allow the user to pass values into the program from a command prompt).




Finally , I would point out that your comments about my writing a program to do the calculations related directly to the Visual FoxPro program…not the later C++ translation of it.

PS: You might want to learn how to spell accommodate.
DNAunion: By the way, do you know what a "stub" is Principia? Learn that first. Then learn what can come after a stub and before the final function code: code that works, even if it is not optimized.

Quote:
"For all but the most performance-intensive situations, apply the following "rule of thumb". First, make your code simple and correct; then make it fast and small, but only if necessary." (C# A Programmer's Introduction, Deitel & Deitel, Prentice Hall, 2003, p133)
DNAunion is offline  
Old 07-09-2003, 10:36 AM   #13
Veteran Member
 
Join Date: Jan 2001
Location: USA
Posts: 1,072
Default

Quote:
Principia: As I noted then, DNAunion has no clue how to generate uniform random numbers in general (botching up the modulus algorithm):

***********************
Principia: The problem is even worse, since when you take the modulus of FLOOR(RAND()*1000) by lnMax, which is typically not a factor of 1000 (or 1000 and RANDmax), then once again your distribution is biased. There are some numbers that are underepresented. Let me give an example: say I take 0 to 100 modulo 7. There are 15 0's 15 1's and 15 2's whereas all the rest have 14 numbers to them. This is a clear bias.
************************
DNAunion: Also already dismissed. Here, let me remind you.

Quote:
***************************
Principia: The problem is even worse, since when you take the modulus of FLOOR(RAND()*1000) by lnMax, which is typically not a factor of 1000 (or 1000 and RANDmax), then once again your distribution is biased.
***************************


DNAunion: Well of course it is typically not a factor of 1000. If it were typically a factor of 1000, then the % operation would typically return 0, which is not what is needed.

******************************
Principia: There are some numbers that are underepresented. Let me give an example: say I take 0 to 100 modulo 7. There are 15 0's 15 1's and 15 2's whereas all the rest have 14 numbers to them. This is a clear bias.
***********************************

DNAunion: Why are you substituting your own set of values for mine? The numbers I used were 0 through 999, modulo 9; they are quite easy to look at.

What we get is as follows:

0 = 112 occurrences; P(0) = 0.112
1 = 111 occurrences; P(1) = 0.111
2 = 111 occurrences; P(2) = 0.111
3 = 111 occurrences; P(3) = 0.111
4 = 111 occurrences; P(4) = 0.111
5 = 111 occurrences; P(5) = 0.111
6 = 111 occurrences; P(6) = 0.111
7 = 111 occurrences; P(7) = 0.111
8 = 111 occurrences; P(8) = 0.111

Hardly the kind of bias you would have us believe (though you are correct that it does exist, and technically I should eliminate it). Even with that function being called 4,000,000 times (4 calls / iteration * 1,000,000 iterations) that amount of bias won’t amount to anything really meaningful: if things fell perfectly in line with the above probabilities I’d get 4,000 too many 0’s (448,000 instead of 444,000), which out of 4,000,000 calls is only one-tenth of one percent error.

Hey, that's a lot better than Rode's being off by at least 11 orders of magnitude!
DNAunion is offline  
Old 07-09-2003, 10:47 AM   #14
Banned
 
Join Date: Jul 2002
Location: U.S.
Posts: 4,171
Default

Good programming practices seems a simple and easy subject to me. I don't know why there are volumes written on it when it is such an easy thing to grasp.

This is especially true in the age of very fast computers where, more often than not, super efficient code is not necessary.

Once a friend and I calculated time differences when doing things the "right" way as opposed to the "wrong" way under various circumstances. We added extra lines of code to make things clearer yet less efficient. In our samples, which I admit were not that extensive, it was difficult to find examples that came up to any noticeable time differences.

DC
Rusting Car Bumper is offline  
Old 07-09-2003, 10:47 AM   #15
Veteran Member
 
Join Date: Jan 2001
Location: USA
Posts: 1,072
Default

Quote:
Principia: Or perhaps it is this other gem [that DNAunion is trying to cover up for]:

Code:
 
for (nTrial = 1; nTrial <= nTrialsPerIteration; nTrial++)
{
	// Pull a single tile out of the urn
	nFoundOne = 0;
	while (nFoundOne == 0)
	{
		nIndex = (int) GetRandomNumber(0, nLetteredTiles - 1);
		if (nDiscardTilesOnceChosen == 0)
		{
			// Doesn't matter if the tile has been 
			// chosen previously because selected
			// tiles are placed back into the urn.
			nFoundOne = 1;
		}
		else if (cUrn[nIndex][2] == 'T')
		{
			// This tile has already been chosen and
			// discarded: it can't be selected again.
			nFoundOne = 0;
		}
		else if (cUrn[nIndex][2] == 'F')
		{
			// This tile has not been chosen previously.
			nFoundOne = 1;
		}
	}
	// A tile has been chosen: flag it as such
	cUrn[nIndex][2] = 'T';

	// Does the chosen tile match one of the targets?
	if (cUrn[nIndex][3] == 'T')
	{
		nMatches += 1;
	}

	// No need to continue pulling tiles for this iteration
	// if we've obtained enough matches for success
	if (nMatches >= nMatchesNeededForSuccess)
	{
		nTrial = nTrialsPerIteration + 1;
	}
}
DNAunion: That you find the above code confusing only exposes your complete inability to understand, or even recognize, structured programming.

Let’s see how Principia continues…it’s a hoot!

Quote:
Principia: Once again to the trained eye, compare this code to the examples of undisciplined use of if statements, I listed in the post above (with modifications to better match the comparison):

Once again to the trained eye, compare this code to the examples of undisciplined use of if statements, I listed in the post above (with modifications to better match the comparison):

Code:

if (x == 1)
{
  if (y == 1 && x > 0)
  {
     if (x > 2 || y < 2)
     {
        x=0;
        y=0;
        printf("Hello world.\n");
     }
     else if (y < 3)
        printf("Goodbye world.\n");
  } else {
     if (y < 3)
        if (x == 0)
          printf("Where am I?\n");
       else
       {
          x = 2;
          break;
       }
  }
}
else if (z == 2)
{
   printf("Now I'm really confused.\n");
   if (x == 1)
   {
      printf("But didn't we just test for this above?\n");
      if (x < 0)
        printf("Whaa...??\n");   
   }
}
DNAunion: All that shows us is that YOU can write “spaghetti code”. It has nothing to do with MY code. Try comparing apples to apples sometime…it’s the HONEST thing to do Principia.

Here we see another example of a common underhanded tactic Principia employs. He creates a substitute example -- one that in reality is grossly inaccurate -- and trashes it, all the while pretending that doing so trashes the original. Is anyone here really gullible enough to buy his dishonest "substitutions" tactic?
DNAunion is offline  
Old 07-09-2003, 10:54 AM   #16
Senior Member
 
Join Date: Feb 2003
Location: San Diego, California
Posts: 719
Default

Quote:
Originally posted by DNAunion
This should work on the very first iteration – the DO WHILE…ENDDO loop construct is used only to ensure that if I overlooked anything that an invalid result would not be returned.
Hmm, that's a rather confusing safety-check. No person reading your code would have any clue as to why that loop was there. Unnecessary redundancy mainly just serves to obfuscate your intentions and leaves your code potentially riddled with hidden errors. You would really be much better off if you made that an assertion, not some redundant loop that cleans up after errors you might not know about (have some faith in your code). If there's an error in your logic, get it out in the open--print something and halt the program, for example--so that you can actually understand your problems and fix them.
Lobstrosity is offline  
Old 07-09-2003, 11:15 AM   #17
Veteran Member
 
Join Date: Jan 2001
Location: Median strip of DC beltway
Posts: 1,888
Default

That's a horrid way to generate the random number. A better way would be:

random_val=min+floor(double(rand()/(RAND_MAX+1.0))*double(max-min))

It's simpler, practically no distribution bias (assuming no bias in rand()), and a hell of a lot faster.

According to man rand:
Quote:
In Numerical Recipes in C: The Art of Scientific Computing (William H. Press, Brian P. Flannery, Saul A. Teukolsky, William T. Vetterling; New York: Cambridge University Press, 1992 (2nd ed., p. 277)), the following comments are made:
"If you want to generate a random integer between 1 and 10, you should always do it by using high-order bits, as in

j=1+(int) (10.0*rand()/(RAND_MAX+1.0));

and never by anything resembling

j=1+(rand() % 10);

(which uses lower-order bits)."
Of course, that's mostly because many older random number generators are less random in the low order bits than the high order bits.
NialScorva is offline  
Old 07-09-2003, 11:40 AM   #18
Senior Member
 
Join Date: Feb 2003
Location: San Diego, California
Posts: 719
Default

Quote:
Originally posted by NialScorva
Of course, that's mostly because many older random number generators are less random in the low order bits than the high order bits.
Is this still a problem or has this now been addressed?
Lobstrosity is offline  
Old 07-09-2003, 12:11 PM   #19
Moderator - Science Discussions
 
Join Date: Feb 2001
Location: Providence, RI, USA
Posts: 9,908
Default

DNAunion:
Here we see another example of a common underhanded tactic Principia employs. He creates a substitute example -- one that in reality is grossly inaccurate -- and trashes it, all the while pretending that doing so trashes the original. Is anyone here really gullible enough to buy his dishonest "substitutions" tactic?

As I said to Principia, comments about the motives/honesty of other posters are not appropriate here. Please either stick to attacking arguments (for example, the above quote could be made acceptable by saying Principia is attacking a strawman), or refrain from posting any more on this thread.
Jesse is offline  
Old 07-09-2003, 12:48 PM   #20
Contributor
 
Join Date: Jul 2001
Location: Deep in the heart of mother-lovin' Texas
Posts: 29,689
Default

This is especially true in the age of very fast computers where, more often than not, super efficient code is not necessary.

That depends, generally, on the target platform and the application/purpose/function of the code.

In addition, many compilers optimize "inefficient" code for you (though I've had some optimizing compilers introduce some strange behavior into my code).

However, there's ususally no reason that code must be made more complex just for understandability. IMO, it's usually the case that simplifying and streamlining the code makes it more understandable (comments are more important than code structure, generally).

- Mageth, who used to follow the maxim "REAL programmers never document their code; if it was hard to write, it should be hard to understand."
Mageth is offline  
 

Thread Tools Search this Thread
Search this Thread:

Advanced Search

Forum Jump


All times are GMT -8. The time now is 03:13 PM.

Top

This custom BB emulates vBulletin® Version 3.8.2
Copyright ©2000 - 2015, Jelsoft Enterprises Ltd.