lotto 649 stats
- Thread starter Sheba
- Start date
speaking of errors, here's a few on this website..
http://www.cbc.ca/news/background/gambling/lotteries.html
the odds of winning the super7 are understated, based on the odds posted on olgc's site and for buying one ticket and getting 3 tickets in total for playing, but then they also round up the fractions as posted on the olgc site.. trying to decieve people into thinking that the odds of winning the super 7 aren't much worse than the 6/49
This site also shows the breakdown of where the prize money goes and how much the average joe spends on tickets by province.. similar to another post on here asking about where the winning money goes..
http://www.cbc.ca/news/background/gambling/lotteries.html
the odds of winning the super7 are understated, based on the odds posted on olgc's site and for buying one ticket and getting 3 tickets in total for playing, but then they also round up the fractions as posted on the olgc site.. trying to decieve people into thinking that the odds of winning the super 7 aren't much worse than the 6/49
This site also shows the breakdown of where the prize money goes and how much the average joe spends on tickets by province.. similar to another post on here asking about where the winning money goes..
Data on Lotto 6/49
Peter
Your sum total for all 2058 draws (364.783) is right when you include the bonus. Again I checked against my own database (which I believe always been one of the accurate ones around here).
And since I deal with facts, I did a double check for that data. I compared it with BCLC self-extracting file. And I had also done this to verify the frequencies for numbers 4 and 6 in the first question in this thread (this time using data from Loto-Quebec site).
gsobier
There is no good or bad methods for verifying data. Each method may have its use depending on what you are looking for, the kind of error, etc. You also have to know the limitations in each case. The sum method is a quick way to find if your data is right when comparing with somebody else. By using the sum of all numbers and possibly also the sum for each position, if all values are equal, then it is quite likely that the two databases are the same. But this is not a foolproff method. If you invert results for two draws while maintaining the proper positions, then the totals will be the same but the databases are not equal.
Peter
Your sum total for all 2058 draws (364.783) is right when you include the bonus. Again I checked against my own database (which I believe always been one of the accurate ones around here).
And since I deal with facts, I did a double check for that data. I compared it with BCLC self-extracting file. And I had also done this to verify the frequencies for numbers 4 and 6 in the first question in this thread (this time using data from Loto-Quebec site).
gsobier
There is no good or bad methods for verifying data. Each method may have its use depending on what you are looking for, the kind of error, etc. You also have to know the limitations in each case. The sum method is a quick way to find if your data is right when comparing with somebody else. By using the sum of all numbers and possibly also the sum for each position, if all values are equal, then it is quite likely that the two databases are the same. But this is not a foolproff method. If you invert results for two draws while maintaining the proper positions, then the totals will be the same but the databases are not equal.
Re: Data on Lotto 6/49
GillesD:
An error is an error... ...there is no maybe here. I've written a very simple program to compare and stop with a prompt at the point where a discrepancy is noticed. From there, you investigate and attempt to seek out the truth. I did this with files from 4 different sources. One source was so poor (which will remain undisclosed unless someone really wanted to know), I felt ill
thinking about it
.
It would be a great help to everyone on this forum to arrange with LT to sumit a history file for all to download if you feel your data is correct. I'd like to compare yours with mine if you feel strongly about yours
.
Regards,
George
GillesD:
An error is an error... ...there is no maybe here. I've written a very simple program to compare and stop with a prompt at the point where a discrepancy is noticed. From there, you investigate and attempt to seek out the truth. I did this with files from 4 different sources. One source was so poor (which will remain undisclosed unless someone really wanted to know), I felt ill
thinking about it.It would be a great help to everyone on this forum to arrange with LT to sumit a history file for all to download if you feel your data is correct. I'd like to compare yours with mine if you feel strongly about yours
.Regards,
George
GillesD said:
Re: Data on Lotto 6/49
Yes there are many ways to compare.
1) by each number
2) each number by position
3) sum total by position
4) total sum total
I agree, for a Quick check, sum totals are the fastest, but as you stated, if the are inverted from one draw to the next, it is not reliable
5) odd/even count, by position
I'm sure there are many more.
Thankyou Gilles,GillesD said:
Yes there are many ways to compare.
1) by each number
2) each number by position
3) sum total by position
4) total sum total
I agree, for a Quick check, sum totals are the fastest, but as you stated, if the are inverted from one draw to the next, it is not reliable
5) odd/even count, by position
I'm sure there are many more.
Re: Re: Data on Lotto 6/49
Peter:
What can I tell you?... ...there is only one sure way as you know... ...my simple little program does the job. Some of these methods, are good only afterwards for data integrity review. If you don't check properly, you will never know
for sure.
On a lighter note, we are still trying to
so we got an excuse, wrong data
.
Regards,
George
Peter:
What can I tell you?... ...there is only one sure way as you know... ...my simple little program does the job. Some of these methods, are good only afterwards for data integrity review. If you don't check properly, you will never know
for sure.On a lighter note, we are still trying to
so we got an excuse, wrong data.Regards,
George
peter said:Thankyou Gilles,
Yes there are many ways to compare.
1) by each number
2) each number by position
3) sum total by position
4) total sum total
I agree, for a Quick check, sum totals are the fastest, but as you stated, if the are inverted from one draw to the next, it is not reliable
5) odd/even count, by position
I'm sure there are many more.
Re: Re: Data on Lotto 6/49
Peter and GillesD:
I wrote something today which provided me a opportunity to install a checksum counter for the entire draw. I have a checksum value of 364,783 for 2058 draws just like you guys do... ...364,934 is the for 2059 draws.
FYI... ...a little trvia...
More than 30 years ago IBM introduced CHECKSUM verification in its Backup Program called DDR (Disk Dump Restore).
Here is what they did...
1. wrote data to tape
2. read the original data from DASD and count the EBCDIC heXidecimal values for a CHECKSUM count
3. read the data from tape and counted the EBCDIC heXidecimal values for a CHECKSUM count
4. if the CHECKSUMs did not match, DDR would complain at the System Console where the backup was initiated from by the operator.
5. backup would have to be rerun when this kind of error was encountered. (sometimes it was the totaly the Operator's fault because the READ/WRITE heads on the tape drive were dirty which was very critcal).
What does the have to do with the lottery? There are some things in data processing which are related in some way to lottery in concept/procedure, if you apply it properly to improve your game. CHECKSUM is one of them.
Regards,
George
Peter and GillesD:
I wrote something today which provided me a opportunity to install a checksum counter for the entire draw. I have a checksum value of 364,783 for 2058 draws just like you guys do... ...364,934 is the for 2059 draws.
FYI... ...a little trvia...
More than 30 years ago IBM introduced CHECKSUM verification in its Backup Program called DDR (Disk Dump Restore).
Here is what they did...
1. wrote data to tape
2. read the original data from DASD and count the EBCDIC heXidecimal values for a CHECKSUM count
3. read the data from tape and counted the EBCDIC heXidecimal values for a CHECKSUM count
4. if the CHECKSUMs did not match, DDR would complain at the System Console where the backup was initiated from by the operator.
5. backup would have to be rerun when this kind of error was encountered. (sometimes it was the totaly the Operator's fault because the READ/WRITE heads on the tape drive were dirty
which was very critcal).What does the have to do with the lottery? There are some things in data processing which are related in some way to lottery in concept/procedure, if you apply it properly
to improve your game. CHECKSUM is one of them.Regards,
George
peter said:Thankyou Gilles,
Yes there are many ways to compare.
1) by each number
2) each number by position
3) sum total by position
4) total sum total
I agree, for a Quick check, sum totals are the fastest, but as you stated, if the are inverted from one draw to the next, it is not reliable
5) odd/even count, by position
I'm sure there are many more.
Re: Re: Data on Lotto 6/49
Peter and GillesD:
I wrote something today which provided me a opportunity to install a CHECKSUM verification counter for the entire draw. I have a checksum value of 364,783 for 2058 draws just like you guys do... ...364,934 is the for 2059 draws.
FYI... ...a little trvia of a good 'ol trick called CHECKSUM...
More than 30 years ago IBM introduced CHECKSUM verification in its Backup Program called DDR (Disk Dump Restore).
Here is what they did...
1. wrote data to tape
2. read the original data from DASD and count the EBCDIC heXidecimal values for a CHECKSUM count
3. read the data from tape and counted the EBCDIC heXidecimal values for another CHECKSUM count
4. if the compared CHECKSUMs did not match, DDR would complain at the System Console where the backup was initiated from by the operator.
5. backup would have to be rerun when this kind of error was encountered. (sometimes it was the totaly the Operator's fault because the READ/WRITE heads on the tape drive were dirty which was very critcal).
What does the have to do with the lottery? There are some things in data processing which are related in some way to lottery in concept/procedure, if you apply it properly to improve your game. CHECKSUM is one of them.
Regards,
George
Peter and GillesD:
I wrote something today which provided me a opportunity to install a CHECKSUM verification counter for the entire draw. I have a checksum value of 364,783 for 2058 draws just like you guys do... ...364,934 is the for 2059 draws.
FYI... ...a little trvia of a good 'ol trick called CHECKSUM...
More than 30 years ago IBM introduced CHECKSUM verification in its Backup Program called DDR (Disk Dump Restore).
Here is what they did...
1. wrote data to tape
2. read the original data from DASD and count the EBCDIC heXidecimal values for a CHECKSUM count
3. read the data from tape and counted the EBCDIC heXidecimal values for another CHECKSUM count
4. if the compared CHECKSUMs did not match, DDR would complain at the System Console where the backup was initiated from by the operator.
5. backup would have to be rerun when this kind of error was encountered. (sometimes it was the totaly the Operator's fault because the READ/WRITE heads on the tape drive were dirty
which was very critcal).What does the have to do with the lottery? There are some things in data processing which are related in some way to lottery in concept/procedure, if you apply it properly
to improve your game. CHECKSUM is one of them.Regards,
George
peter said:Thankyou Gilles,
Yes there are many ways to compare.
1) by each number
2) each number by position
3) sum total by position
4) total sum total
I agree, for a Quick check, sum totals are the fastest, but as you stated, if the are inverted from one draw to the next, it is not reliable
5) odd/even count, by position
I'm sure there are many more.