Re: Actual Lottery Stuff. WOW eh?

"Abraxas" <dontbother@xxxxxxxxxx> wrote:

"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.

By god, I think you're right...okay, let's make the number of combinations
another argument to the function. Seems to me that it would always be
found for one reason or another in the calling procedure.

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!

Holy ***!

Fuckin' default variants...they waste lots of memory, too. (16 bytes to
store an int!) I should use that "option explicit" thing.

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'm pretty sure it's the pentium processor that does 32-bit arithmetic
faster than 16-bit. Besides the fewer machine cycles in the instructions,
all the arithmetic is done with the 32-bit registers, so the high order
half has to be cleared, something like using a "xor EAX,EAX" instruction
(2 wasted machine cycles) before loading data into a register, like "mov
AX,[si)."

I would never use the single type for anything. Somebody once told me it
actually takes longer in the Intel processors to normalize and unnormalize
a 32-bit floating point value than a 64-bit. That doesn't make much sense,
but some days I believe everything I hear.

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.

I feel a cold breeze coming from the north...

.