eihli
> We know how these machines work, it's not mysterious, there's nothing "extra" happening.
It sounds like you're saying "We don't know how brains work, they're mysterious, there's something 'extra' happening", and using that as justification for why you're saying a computer, an AI, can't "understand".
I think most people on Hackernews now who would use the phrase "my AI worked overnight and hypothesized, compared, etc..." already know how an LLM works, and still chooses to use those words. So the issue isn't that they don't understand. It's that they understand and still use those words. So the disagreement is somewhere else.
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.
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:
(define-relation (layero layer in out) ;; [2]
(conde
((== layer `(Linear ,in ,out)))
((== layer `(Relu ,in ,out))
(== in out))
((fresh (percent)
(== layer `(Dropout ,in ,out ,percent))
(== in out)
(countero percent)
(<o '(1) percent)
(<o percent '(0 0 1 0 0 1 1))))))
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.
Thanks for getting me started down this path!
[1] https://arxiv.org/abs/1809.02840
[2] https://github.com/eihli/reason/blob/523920773b7040325c8098a...
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.
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.
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...
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.
https://docs.zohopublic.com/file/pze38c35faf87eb654907b51890...
I'm using it to power https://scratchoff-odds.com right now.
I have 4+ years worth of daily scratch off lottery ticket results from a dozen or so different states.
Every day, the state updates their website with the numbers of tickets remaining at each ticket level. I've been scraping that and saving it.
If anyone would find this data interesting I'd be happy to share the SQLite database. I just ask that you share your code/queries and what you find.
- Are the grand prizes truly random? Or are they stratified?
- Do games end with an unusually high number of grand prizes unclaimed?
- Is there a buffer when a game is first released when no grand prize is possible?
You could scan some Working Papers to get ideas of things to check the integrity of: https://docs.zohopublic.com/file/pze38fbeed85562834d5696105b...
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.
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...
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)
So 8888X or X8888 is (2 * 16) / (16^5)?
And then 8888XX or X8888X or XX8888 is...
(16^2 + 16^2 + 16^2) / (16^6) ???
Is there anything you can share with this? I'd like to read more about how and why researchers came to that conclusion. Thanks.
Remote: Optional
Willing to relocate: Yes
Technologies: Clojure, Lisps, Python, Django, React, TypeScript, JavaScript, Linux, Shell, Ansible, Docker
Résumé/CV: https://resume.owoga.com
Email: [email protected]
I have a strong preference to working in Clojure or another lisp-like language. Industry-wise, I'm fairly open with a slight preference for finance, crypto, AI/ML, or security. My ideal role involves generalization over specialization with a preference for backend, devops, and internal tools. Bonus points for anything academic or research-related.
https://www.pewresearch.org/fact-tank/2020/03/30/qanons-cons...
How many of those 3% who have heard or read a lot about it actually believe it is hard to estimate.
I have family that are fervent believers so this hits close to home.
If you've heard or read a lot about it, it's either because you believe it or are personally invested in it (I presume most likely due to having relationships with people who believe it).
Take a rough slice and say 10% of those people who have heard or read a lot about it are believers and the other 90% are their friends and family.
Sooo... 55 million registered republicans; Guesstimate 50% of those are considered "conservative" republicans by the terminology of the Pew poll; 3% of those have heard a lot about Q; 10% of those are believers. 55 * 0.5 * 0.03 * 0.1 and that's ~800,000 Q followers.
Is 800,000 mainstream for a conspiracy theory? I wonder how many people believe the earth is flat.
https://matthewdowney.github.io/encrypting-keys-in-clojure-a...
1. Generate a new set of API keys.
2. Read my encrypted map of keys from disk, decrypt it with a passphrase, assoc in the new key & secret, encrypt it again, and write it to disk.
3. At the entry point for my application, use (.readPassword (System/console)) to securely read in the passphrase, and then use it to decrypt the key file and read it into a Clojure map.
4. Instead of passing the key map around (allowing it to potentially escape into a debug log, or be printed at the REPL if I do something dumb), the top level code of my application passes the credentials into a signer-factory for each api that closes over the credentials.
;; The factory is shaped something like this
(defn request-signer-factory
[{:keys [key secret]]
(fn [request-to-sign]
(sign-request request-to-sign key secret)))
;; Then an API endpoint looks like this
(defn place-order!
[signer {:keys [price qty side market post-only?]}]
(let [request (comment "Format the order data for the exchange")
signed (singer request)]
(do-http-request! signed)))
It's a good idea though to add a web version to the "marketing" page at ezmonic.com. I'll add that to my todo list. Thanks!
A simple example is imagine a game with 10 tickets sold for $1 each and a single $9 grand prize.
If 1 ticket is sold each day and if the lottery publishes the number of remaining winning tickets each day, then you can just wait 1 day and if 1 ticket was sold and 9 tickets remain and the prize wasn't claimed, well now there is a 1/9 chance of winning $9 and the expected value is even.
I started scraping several state for daily numbers and calculating the expected value of each game. Every now and then one gets over 100% EV. (Not taking into account annuity discounts and taxes)
It's also an excuse to try out a lot of different technology and patterns that would be too experimental for most real jobs, so it's a great side project.
I'm currently working on a user section with Clojure, Fulcro (https://fulcro.fulcrologic.com/), and Crux (https://github.com/juxt/crux).
Another fun little side project that was also an excuse to work with Clojure was https://ezmonic.com/. The app was built with ShadowCLJS, Re-Frame, and ReactNative. I've used the Major System mnemonic to remember things like my credit card numbers and I've always wanted to know how optimally short the mnemonics I come up with are. That app uses the CMU phonetic dictionary to search for an optimal phrase.