aspose file tools*
The moose likes Beginning Java and the fly likes Find duplicate number in text file Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Find duplicate number in text file" Watch "Find duplicate number in text file" New topic
Author

Find duplicate number in text file

Andy Joness
Greenhorn

Joined: Sep 15, 2009
Posts: 24
What I'm trying to do is create a unique randomly generated number, and then search through a text file to ensure that number is not already entered. I've wrote the code and the program is working, but I have no way of knowing if this part of the program works (because the chance of the two same values occurring is quite low) so I was hoping someone could look over it for me and see if it is correct.



David Newton
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

You can test algorithmic correctness by decreasing the range of the random numbers being generated.
David Newton
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

It's also substantially easier to help if you post complete code instead of making us figure out "the rest", maintain consistent usage conventions ("uniqueNo" versus "this.uniqueNo", for example), and keep the code super, super clean, concise, and easy to understand. You're much more likely to get help this way.
David Newton
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

It also seems like there are instance variables that don't need to be instance variables (randomNo, uniqueNo, and the backwards-named notDuplicate).
David Newton
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

Here's my take on what you're doing--if this is correct, we can move on from there:

1) Add numbers 10-99 to a list of numbers.
2) Shuffles the collection and creates a string from the (now-shuffled) numbers in positions 45-47 (three numbers).
3) Checks that number against all lines in the input file; if it's not found, writes it to the (end?) of the file.

Is that correct?
Andy Joness
Greenhorn

Joined: Sep 15, 2009
Posts: 24
David Newton wrote:Here's my take on what you're doing--if this is correct, we can move on from there:

1) Add numbers 10-99 to a list of numbers.
2) Shuffles the collection and creates a string from the (now-shuffled) numbers in positions 45-47 (three numbers).
3) Checks that number against all lines in the input file; if it's not found, writes it to the (end?) of the file.

Is that correct?


That's right. If the number is found in the text file then I want it to re-shuffle until a unique number is found and then write it.

Sorry I didn't include the rest of the class, I thought it would make sense to only include the part that is specific to my question. I'm sure my code isn't as clear and concise as it could be but it'll improve in time hopefully
David Newton
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

(Are you aware of java.util.Random, and Random.nextInt(int)? It might make generating 6-digit random numbers easier :)
David Newton
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

(And you should close the file whether or not you write to it.)
David Newton
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

(I think this is also unintentionally recursive, which is probably bad.)
Andy Joness
Greenhorn

Joined: Sep 15, 2009
Posts: 24
I initially used the Math.random method but I was getting 4-6 digit numbers, so I thought I'd stick with the current way as it guarantees 6 digits.

What I'm really curious about is:


If that returns true, will it then re-run the shuffleNumber method then restart the searchUniqueNo method with a new uniqueNo value?
David Newton
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

That doesn't return anything. The answer to your real question is "yes"--but I'm skeptical this is your real intent: you're turning what should be an iterative process into a recursive one. While it's unlikely to cause a problem for you, in theory you could blow the stack.

Getting a 6-digit random number from Random.nextInt(int) is a matter of some pretty simple math.
Andy Joness
Greenhorn

Joined: Sep 15, 2009
Posts: 24
I don't follow. Whats blowing a stack? How would I go about doing what I want it to?
David Newton
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

"Blowing the stack" happens in recursion when there's no terminating condition. Recursion means calling a method from within itself, or in this case, via other methods.

In this case, in the (probably unlikely, but without knowing more it's hard to say) event that you keep having to look for random numbers (like if the random number generator is broken, which yours is a little bit, since there's only 99*98*97 combinations, or as the random number file becomes larger and larger and it's more difficult to find a unique number) your method will keep calling itself. Technically it could do this indefinitely. Boom goes the dynamite. My initial suggestion to reduce the random number range would demonstrate this problem rather quickly, like if you were generating two or three digit numbers.

Basically, while this problem *can* be solved recursively, it strikes me more as an iterative process:Now, it's possible I've misinterpreted your original code--to be honest I find it a little hard to follow, but that it's recursive is certainly true. There doesn't *appear* to be an absolute terminal condition, which is where the stack explosion can come from.

Again, for short runs, with small comparison files, and six-digit numbers, it's unlikely you'd see it happen--but as soon as you crank up the number of unique numbers you want to generate and run it a few times the duplicate count skyrockets: for example, generating 20k unique six-digit numbers I get 228 dupes the first run, the second run I get 708, the third 1207. (I added some code to allow setting the number of unique numbers to generate.)

My iterative version doesn't currently have a terminating condition either--but since it's not recursive, it'll just run forever rather than crashing the JVM.)

Just for comparison, my refactored, non-recursive version weighs in at 83 lines, although some would take issue with some of my coding conventions. I'm not telling you that as a "I wrote that in less lines than you", because shorter != better--rather that once you've got an iterative version working it might be interesting to take a look at another way of doing it that some (not all :) people might find easier to understand with only a cursory reading. It also doesn't have a terminating condition--it could potentially run forever, but it won't crash the JVM.

Note also that successive runs will take longer and longer, since file IO is relatively slow--I'd probably do something different if performance was important.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Find duplicate number in text file