VB6: Best way to find all permutations of a given string in a file - Contest

I am putting in a verification routine but it will still need the string output to verify against. But since I haven't created the verification process yet...

The reason I have to create the verification is solely because the submitters did not verify their codes output themselves.

E-mail now featuring improved code. And that by a big margin as I finally optimized a bit more than little. (And included my own verification/validation in it for a sample.)

OK, you don't need to return the permutation string, the offsets will do just fine. I will check the string at the offset for you in the Verification procedure.

I will post another skeleton soon...

BTW: I can't easily test your module if it does not have the same calling parameters as in the skeleton... I can't go thru 100 different calling and testing techniques. That is the purpose of the skeleton to create one user interface between all the submitted modules.

Example of a module using the Contestant Class. Start with mFindUsing the append your Method then underscore and your VBForums name. Please use the definitions in the class for the parameters that your subroutine needs. Modify lngOffset with your offset where you find the permutations.

Code:

---

Public Sub mFindUsingBruteForceInstr_randem(Contestant As Object, lngOffset() As Long)

    With Contestant
...
        ' If nothing found
        ReDim lngOffset(0) 
        lngOffset(0) = -1&
        .Count = 0

    End With

End Sub

---

The contestant class is as follows:

Code:

---

Option Explicit

Public Name As String
Public FunctName As String
Public Time As Long
Public OutputFile As String
Public Key As String
Public index As Long
Public Position As Long
Public SourceFile As String
Public FindStr As String
Public Chunksize As Long
Public CaseSensitive As Boolean
Public ReturnOffset As Boolean
Public Count As Long
Public OmitOutput As Boolean

---

The only item in the class your subroutine may modify is the Count variable All the rest are input for your module.

In clsContestantFunctions you add the call to your subroutine such as in:

Code:

---

Public Sub FindUsingBruteForceInstr_randem(Contestant As clsContestant, lngOffset() As Long)
    mFindUsingBruteForceInstr_randem Contestant, lngOffset  ' This is the call to your module
End Sub

---

In frmFuncBench add an enum to the ContestantEntries for your module and your VBForums name to EntrantNames along with your function name in FunctionNames (This name is the call to the sub in clsContestantFunctions).

After testing your module with the skeleton all you need to submit is the module.

Thanks.

Attachment removed see later posts for updated version.

Your project uses a reference called "RS General Routines" which is not included in the project. It also seems to have replacement procedures to basic functions such as String and Format.

Quote:

---

Originally Posted by randem

BTW: I can't easily test your module if it does not have the same calling parameters as in the skeleton... I can't go thru 100 different calling and testing techniques.

---

Why is that? You are using an extra wrapper there. My earlier submitted functions work with it like this:

Code:

---

Public Sub FindUsingInStr_Merri(Contestant As clsContestant, lngOffset() As Long)
    With Contestant
        lngOffset = mFindUsingInStr_Merri(.SourceFile, .FindStr)
    End With
End Sub

---

Also, this makes the functions much more general purpose, because when you force to pass a certain class in order to make things work, you effectively prevent the functions from working as standalone functions. Ie. you can't easily paste them to anywhere except into your skeleton program.

That's why I did my functions the way I did.

That very well may be. I will look into that.

Quote:

---

Originally Posted by Merri

Your project uses a reference called "RS General Routines" which is not included in the project. It also seems to have replacement procedures to basic functions such as String and Format.

---

Yes, I forgot about that dll. The whole thing was just meant for reference. I can post that dll so that everyone can test with it.

What replacements for String and Format are you referring too?

It seems the DLL includes those, because I got errors on those until I removed the DLL. I don't see any need for the DLL in the project.

Although there seems to be problems with the project, none of the functions I added to the constant strings in the form didn't show up, always seeing only four items in the combobox.

Show me what you added...

It does work..

I will change the calls to the way you suggested.

OK, here is the new skeleton with the changes...
clsContestantFunctions contains:

Code:

---

Option Explicit


Public Sub FindUsingBruteForceInstr_randem(Contestant As clsContestant, lngOffset() As Long)
    With Contestant
        lngOffset = mFindUsingBruteForceInstr_randem(.Sourcefile, .FindStr, .ChunkSize, False)
    End With
End Sub

Public Sub FindUsingBruteForceInstrRev_randem(Contestant As clsContestant, lngOffset() As Long)
    With Contestant
        lngOffset = mFindUsingBruteForceInstr_randem(.Sourcefile, .FindStr, .ChunkSize, True)
    End With
End Sub

Public Sub FindUsingBruteForceReplace_randem(Contestant As clsContestant, lngOffset() As Long)
    With Contestant
        lngOffset = mFindUsingBruteForceReplace_randem(.Sourcefile, .FindStr, .ChunkSize)
    End With
End Sub

---

So the submitted module never has to be changed.

In frmFuncBench change:

Code:

---

Public Enum ContestantEntries
    All
    RandemInstr
    RandemInstrRev
    RandemReplace
    EndOfEntries  ' Do not add after this entry insert before
End Enum

' These constants must match ContestantEntries coorespondingly

Private Const EntrantNames = "All,randem,randem,randem"  ' Add your name here for the number of cooresponding routines
Private Const FunctionNames = "All,FindUsingBruteForceInstr_randem,FindUsingBruteForceInstrRev_randem," & _
                                "FindUsingBruteForceReplace_randem"  ' add your routine names here

---

Attachment removed see later posts for updated version.

I added my module to the skeleton, and didn't have any problems running the first test. There are some bugs here, though.

First off, in cmdBenchmark_Click event, you need a Case -1 to avoid an error if no item is selected.

Next up, in the SetupContestants subroutine, you need to clear cmbContestant. Otherwise, you get duplicate items and run into trouble if you try to run All.

Finally, txtPerm doesn't function dynamically. I was scratching my head for a bit before I figured out that you have set the perm string before selecting a new file.

Another curiosity, when I tested on a file with embedded permutations of "aabc", I got these results, along with a lot of annoying 'permutations missing' message boxes.

Code:

---

Verified - FindUsingBruteForceInstr_randem finished in # ms, found 40569 permutations
Verified - FindUsingByteRange_Logophobic finished in # ms, found 40577 permutations

---

Do you remember the settings for creating the aabc file you used?

Ok, modifications made for those errors.

It also create a log file in the app folder named LogFile.txt from the contents of the main listbox (lstLog).

@Merri: It was a 5MB file with 500 permutations per buffer. I must have changed the seed, though, so I ran the test on a new file with the default 9756 seed.

Code:

---

Verified - FindUsingBruteForceInstr_randem finished in # ms, found 40581 permutations
Verified - FindUsingByteRange_Logophobic finished in # ms, found 40593 permutations

---

My InStr and MatchCount functions both return 40593.
My Replace function gives the same 40581 permutations as randem's InStr.

Yes, The replace functions cannot take into account overlapping permutations. Once you replace the data it's gone and the overlapping item is lost.

BTW, I've given up...this project's had too many changes to be enjoyable to me any more (which is the main reason why I took part originally)...Feel free to salvage my code and do as you wish with it

Results pending?

Yes, I will post the result and code modules for proper viewing and inspection and possible raves...;)

Quote:

---

Originally Posted by randem

Aloha,

File must be read and processed in 64kb chunks to allow any size file to be scanned.[/B]

Permutation Variations:

Variable length.
Fixed length.
No repeating characters.
Repeating characters.

---

This makes no sense. Are you saying that "a" and "ss" are permissible permutations? And why 64K? That is a nonsensical requirement in today's computers. VB6 will 2^31 char in a string. Even if you want the coder to prove they can handle buffers, 64K is a bit silly.

It makes plenty sense. The requirement are the requirement. Because you may not understand the requirement doesn't mean they don't make sense (the world is larger than just you).

The fact that you ask about "a" and "ss" being permutations is speculatory. Since all the other posts seem to get it. Does that click the light on? Please re-read the posts starting at the beginning. It's all there, even examples...

Ok, Here it is. I have been a little busy lately.

Here are the results that you can see for yourselves. Included in the zip file (PermFuncBench.zip) is the following:

1 - File that will create a permutation file to run against the benchmark program.
2 - The benchmark program.

The code for each WORKING entry is in the zip file named BenchMark.zip


Sorry, for the delay...

.

Very impressive. A few minor issues running it, but nothing I couldn't figure out in a few seconds. (Except I seem to be missing clsContestant.cls)

One note is that the benchmark program seems to leave a bunch of zero-byte text files laying around. Not a big deal, obviously, but you may want to check that if you use a similar technique in other projects.

File updated. Sorry about that. Yeah, those files were actually logs but they were not turned off completely.