Re: Actual Lottery Stuff. WOW eh?

"John Griffin" <thathillbilly@xxxxxxxxxxx> wrote in message
news:Xns9811CD141FFAAthathillbillyyahooco@xxxxxxxxxxxxxx
"Abraxas" <dontbother@xxxxxxxxxx> wrote:

"John Griffin" <thathillbilly@xxxxxxxxxxx> wrote
"Abraxas" <dontbother@xxxxxxxxxx> wrote:

"John Griffin" <thathillbilly@xxxxxxxxxxx> wrote
"Abraxas" <dontbother@xxxxxxxxxx> wrote:
"Michael Harrington" <mikharr@xxxxxxxxxxx> wrote
"Abraxas" <dontbother@xxxxxxxxxx> wrote
"Michael Harrington" <mikharr@xxxxxxxxxxx> wrote



I thought that all sounded like lots of fun, so I wrote
a program which does the same thing using a different
method. It generates all the combinations serially and
decides whether to use each one by comparing a random
number to the proportion needed to fulfill the sample size
in the remaining ones. My machine is slower (2.7Ghz, I
think), my program is generalized to do any single-barrel
game, and I run it in the environment instead of making an
executable, so maybe that's why it takes longer to do
9,841,209 random lines with a guarantee of no duplicates--
it takes 187 sec ....oops...you said minutes... never mind
that.


Right...everything has to be a competition for you...and you
always have to come out on top. Do you ever do anything
without having to boast about it?

I'm an ***, in case you forgot.


I can see my way clear to agree with that.

This newsgroup would be a far better deal if everyone would agree
with me.


Such a newsgroup wouldn't exist if we did.

Why not compile the thing? I did. The .exe is only 28K and
runs a helluva lot faster. (Clue #1)

I never bother to compile any project because I almost always
have VB open and I never consider any program complete.

For the record, the compiled version completes the 9.8
million lines in 113 sec. on my machine. That's a very
impressive 87,090/sec. I like it!

Oddly enough, it takes 17 sec. to crank out just 1 million @
58,823/sec. Seems to pick up speed when it has more to do.

That's because of the fixed time it takes to generate all
possible combinations. It takes 22 seconds for a sample of
size zero on this machine (not compiled, as always here).


Oh. Takes 5 here.

I have a suggestion. I believe a lot of time is wasted by
using the text file statements. (Not to mention those ugly
for..next things.) Creating a record with CR/LF and using
the put statement with a binary file gives the same result.

Here's the whole form file in case you care <yuk yuk>...
Ignore the thing that selects combinations by
generating a normally distributed variable, because it
isn't likely to work for a sample bigger than half the
total. Calls to function nextselection and the test of
its return value are commented out.


Why include things that should be ignored? (Clue #2)

That function was the original record selection method, and I
want to go back and see how it works for smaller samples. It
might be a dumb idea. The main reason it should be ignored is
that it calls itself under a certain condition, and I didn't
provide a way to be 100.00% certain it won't keep doing so
until a stack overflow occurs.


I see.

BTW, your code doesn't reset the variables when it finishes,
so if the user tries to run it more than once, it crashes
with a "subscript out of range" error. I'd like to see how
you would fix that.

That's weird! I knew I shouldn't have used those static
variables after I figured out that I couldn't make that
function recursive. I put a comment into it that tells how to
fix it, if those are what you're talking about. All other
variables are local (on the stack), so they're automatically
destroyed upon exit from the procedure.


Apparently "debugging" isn't part of your programming regimen.

Nothin' rigorous, that's for sure! However, since I always run
everything in the VB environment and I write programs just for
fun, I don't care. Anyway, I do enough debugging for my purposes
before I ever start typing the code. That's a habit I developed
when a test run consisted of writing a program on paper, sending
it off to keypunch, correcting keypunch errors, sending the deck
of cards to the computer room, waiting, waiting, waiting... That
process makes you want things to work without a horde of test
runs.

Again...I'd like to see how you would propose to fix that.
I've already done so.

Lazy way: call getnextcomb once more after loop in the command
button subroutine. (kludge!)


Kludge maybe, but it's a simple fix that works. Good enough in this case.

Better way: change loop limiter to "while dblTried>0" and put the
rest of the loop within "if dbltried>0"...end if" (I've done that
in every other program where I've used that function, which is
why I had to pay you to find programming spazzes like this.)

Another better way: In function getnextcomb, after
"getnextcomb=combs," add
if combs=calc(take,outof) then started=false


That works, but slows it down dramatically.

Another way: As I described in the comments, put "started" at
module level (I'd give it a meaningful name) and reset it in a
setup procedure that does nothing more than "started=false." This
would be the logical way if it's always called just before the
loop. Anyway, all the functions ought to be in a .bas file.
(They are on my computer. I just placed copies of them on that
form to make it self-sufficient.) Purists would barf at the idea
of making those statics global or module level, but that would
work.

Best way?: Make "started" an argument instead of a local, module
or global variable. This way, you could restart without running
through all the combinations.


Fuckin' "A". Very good. I'm convinced that you are familiar with the code.
I'm not really interested in fooling around with it much more. It performs a
dirty little job very quickly and accurately.

BTW...there are a few undeclared variables that I have corrected. The
biggest difference is here:

For j = 1 To lngChoose
Mid$(strComb, 3 * j - 2, 2) = Right$(Str$(100 + combo(j)),
2)
Next j

By adding "Dim j as long"...it shaves the run of 9.8 million lines from 113
sec. to just 99 sec. That's about 12,000 lines/sec. better than previous.
Big difference!

Also changed several of your declared variables from double to long or
integer to long. The long type is favored by VB for some reason...unless of
course you're dealing with very large numbers that require single or double
types.

I don't know why it says VERSION 5.00. I'm using VB6
in Visual Studio.


Heh-heh. (Clue #3)

I don't get it. Version 5.00 of what?

I just checked this out...every form file on this computer,
187 of them including the one I just now created to check
this, has that same first line, and they were all created
with VB6.


VB5 was a major upgrade from all previous versions in that it
compiles 32-bit windows apps instead of 16-bit. VB6 really
isn't much more than a cosmetic upgrade of VB5 that also
includes a lot of bug-fixes and a few new features...basically
what VB5 should have been in the first place. They do that
with their "Service Packs"...currently up to SP6. My guess is
that the developers at MS are simply too lazy to change the
file header.

In the Visual Studio version, those bastards shitcanned the print
method in picture boxes, thereby screwing up some old programs I
had written in VB4. Grrrrrrrrr


That's Microsloth for ya.

See what happens when we can play nice? Your cooperation has been
appreciated...not that we're exactly ready to swap spit. Hell hasn't frozen
over just yet.





--
Posted via a free Usenet account from http://www.teranews.com

.