I've been a licensed HAM for a while, but what actually prompted me to start learning Morse code was when I was troubleshooting some hardware that only had a blinking light to communicate back to me. Instead or print statements, I started using blinks to tell me what was happening. I realized it would be so much faster if I knew Morse code.
LICW is a great place to learn. But I also recently discovered https://morsecode.world/ and really like it.
I got my ham license before the "no code" license became a thing. I missed my "Extra" CW test by one point and never tried again, which is sorta cool, because the "Advanced" class is now gone, so I'm keeping mine.
I've got a lot of friends who are avid CW users. One friend used to do CW in his car, which is also very cool.
I learned CW with SuperMorse (on DOS). I went from no skills to passing the General/Advanced in two weeks. It was a fun and easy way to learn.
Hey! Thanks for all of the work you do. I love reading your stuff.
Lately, I've been playing a lot with the code from Neural Guided Constraint Logic Programming for Program Synthesis [1]. I want to apply it to searching for neural network architectures. Something like:
And a `layerso` that is just a sequence of `layers`. And then use some metric that captures how effective the training run was and use that metric for teaching the search network.
I'm sure there's better ways to do it than the way I'm going about it. But it's a fun way to learn a bunch of cool new stuff.
Those working papers have things like "guaranteed low-end prize structures" per pack of tickets.
Tips based on those working papers:
- Buy from a fresh pack until you get a winner then stop. Since there's a guaranteed number of winners per pack, each loser you scratch improves the odds for the rest of the pack.
- Don't buy from a pack that's already had a big winner. Most working papers stipulate no more than 1 large prize per pack.
I see one game in Missouri has a score of 146. Is there anything stopping someone from buying all the remaining tickets (other than time and money obviously) and pocketing the $4 million difference?
Also, is it possible someone has grand prize winner but incorrectly throws it in the trash (because they overlooked the fact that it was a winner/didn’t scratch it all the way off)? Would the website pick up on that?
Nothing stopping someone from buying all the remaining tickets. But if you do the math, I think you'll find it's still not worth it. How fast can you scratch/verify tickets? If you take the lump sum, you get something like 60% of the grand prize. If you take the annuity, it pays out over 20-40 years. Taxes will take out another chunk.
But everyone's situation is different. If you already have losses that could be tax-deducted from the win, that would help you. If you could monetize the process by selling your story or gaining youtube fame, that would help. Some youtuber did buy $1,000,000 worth of tickets without any particular strategy and presumably made profit from the youtube side of his business. As expected, he got back ~70% so it only cost him ~$300k + production costs.
Some states only publish claim numbers for prizes over a certain amount. For prizes below that amount, I estimate using the % claimed of all published prizes.
If 25% of the prizes greater than $30 have been claimed, then I assume 25% of the prizes lesser than $30 have been claimed. Everything in the low numbers has large enough data pools for it to average out accurately. It's not until you get to the $600+ prize level where things would be really inaccurate.
You'll also note there's usually a lag for prizes $600+.
When you look at aggregates across states, you might see something like 25% of prizes below $600 have been claimed but only 19% of prizes above $600 have been claimed. I figure that's because $600+ has to be claimed at lottery headquarters and go on taxes. So people might delay, try to hide the money from their spouse, wait for tax reasons, the headquarters has to manually process it rather than the automated machine at a retail outlet, whatever...
Actually that other explanation is for fractional tickets in other locations of the database, like prizes remaining.
Specifically in `num_tx_initial` it might be because they don't report the number of tickets printed. But if they print the odds of a win and numbers of winners available, then you can estimate how many non-winners there are and thus how many printed tickets there are.
I am a university Prof and a statistician. I'd love to get these data into my courses if you are willing to share it. It's a great example that students can easily relate to.
Employees could really game the system. On average there's 1 "big" prize (outside the GLEP prizes) every 4 packs. Any time you see a pack go from start to ~5 remaining without a big prize, buy every remaining ticket.
There's also guaranteed restrictions on the maximum number of losers in a row. So if you see ~6+ (depends on ticket) losers in a row, then buy the next few until you win. I've run simulations on those distributions and it's profitable. But it's a situation that only an employee could take advantage of. And it probably comes up rarely.
I'm a bit confused. How does the employee know that the previous 6 tickets were losers? It's not like all customers are scratching them off then and there in front of them?
> It's not like all customers are scratching them off then and there in front of them?
A good number of tickets (most tickets?) are purchased by habitual players who'll buy many tickets per sale, and many of those people will even scratch them off in the store:
> “Some customers come in up to three times a day to play, spending up to one hour to scratch-off tickets right in the store after spending $300 or more.”
If you don't see this happening often, you're not likely living in poor or low-income neighborhoods, not patronizing the local convenience stores, or at least not paying attention to the 1 or 2 individuals that you'll often see lingering near the counter.
I've heard of this off and on for years, but seeing as I don't know anyone who has actually done it I think practically it's not too profitable. If he has everything in a sqlite db though, hmm..
Nope. Like throwing a coin, with scratch-off ticket packs actions don't have any effect on the following packs. They're mixed to prevent precisely attacks such as the one you describe.
I would be interested, if you are willing to share the data. Actually, I am thinking now: what if you introduce some anomaly in the data. Something like the man did in the article (draw from a different distribution), and a challenge would be to detect it.
Had an idea when I saw one of these on a cruise ship.
Every time we spent time within eyesight of the machine, I timed it and counted how many plays went in. After a couple of days, I had something resembling an average number of plays per hour. The machine was one where the prizes were visible, so you could tell how many had been won.
Now I had a bound on the number of plays per prize.
Estimate number of plays based on amount of time passed. Check if prize has been claimed. If not, it's due.
You don't have to be too accurate with your numbers. Just get within ~50% to beat the vig.
"Serious play means you value play as a tool for fostering creative thinking."
This could be the seed, test-bed, and proof-of-concept for a set of libraries that would be useful for speech to text, autocomplete, natural language processing, etc...
Can you please share how you got the 2^40 number? I've been trying to think of how to figure out the odds of these.
Odds of 4 hex 8's in a row given a 4 digit string is (1/16)^4.
Odds of 4 hex 8's in a row given a 5 digit string is
number of ways to arrange 8s in the first 4 digits (1) times 16 possible 5th digits plus number of ways to arrange 8s in the last 4 digits (1) times 16 possible 1st digits, all divided by the number of possible arrangements (16^5)
I did 10 8's (mythic!) at the beggining of the hash (2^4)^10 = 2^40.
I didnt account they could start at any position, so the actual number is probably
(64-10)/2^40 ≈ 1 / 2^35
We should also subtract strings longer than 10 that were double counted. However i think the probability of such things is negligible relative to 2^35.
If instead we were doing 4 8's i think it would be:
(64-4)/((2^4)^4) = 60/2^16 ≈ 2^10
I've always been bad at calc probabilities so i may have messed this up.
> Odds of 4 hex 8's in a row given a 5 digit string is number of ways to arrange 8s in the first 4 digits (1) times 16 possible 5th digits plus number of ways to arrange 8s in the last 4 digits (1) times 16 possible 1st digits, all divided by the number of possible arrangements (16^5)
You're double counting "88888". But then again so am i.
The logic for detecting a table is to get rid of everything but vertical lines over a certain length, save that in one image, then get rid of everything but horizontal lines of a certain length, save that image. Then overlay the two and take the bounding rectangle. So you don't need the table to have a border as long as you have vertical and horizontal lines and they extend far enough to encompass all the data you need.
I was a graduate researcher implementing HTM in a hardware accelerator. The largest problem is there was never any sort of specification for HTM outside of a white paper that only vaguely described it's internal structures. And the picture the white paper painted is a design with N^N different hyperparamaters.
Oh, and then the whole thing output a jumble of meaningless bits that had to be classified, an algorithm Numenta kept hidden away as the secret sauce...but if you have to use a NN classifier to understand the results of your HTM... Too many red flags of snakesoil. And I really wanted it to work. Doesn't help that Jeff Hawkins has largely abandoned HTM for new cognitive algorithm pursuits.
I journal a little bit about my experience here: https://owoga.com/posts/2025-03-18-learning-morse-code/
I've been a licensed HAM for a while, but what actually prompted me to start learning Morse code was when I was troubleshooting some hardware that only had a blinking light to communicate back to me. Instead or print statements, I started using blinks to tell me what was happening. I realized it would be so much faster if I knew Morse code.
LICW is a great place to learn. But I also recently discovered https://morsecode.world/ and really like it.