HN user

eihli

86 karma
Posts0
Comments25
View on HN
No posts found.
AI 2040: Plan A 12 days ago

Now show me a writeup that explains how the brain works so I can understand why the brain does those things.

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.

Morse Code Translator 11 months ago

I've been learning it, mostly as a fun hobby.

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.

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:

    (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))))))

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.

Thanks for getting me started down this path!

[1] https://arxiv.org/abs/1809.02840

[2] https://github.com/eihli/reason/blob/523920773b7040325c8098a...

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.

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.

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

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.

Not directly related but while I have the eyes of some technical people reading about the lottery, I want to throw this out there.

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.

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.

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)

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) ???

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.

"Everyone researcher I know who tried to make HTM work came away with the same conclusion"

Is there anything you can share with this? I'd like to read more about how and why researchers came to that conclusion. Thanks.

Location: San Francisco

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: eihli@owoga.com

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.

"Identical shares (3%) of conservative Republicans and moderate and liberal Republicans have heard or read a lot about the conspiracy theories."

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.

This is great. I started hacking on something very similar (https://ezmonic.com) but you took it all the way with NLTK and finding noun phrases. Another great addition would be to find rhyming phrases if it's possible given a number. Maybe add some rules to the Mnemonic system so that certain parts of speech are ignored, so you can throw extra syllables in when needed by adding some adjectives or adverbs. I'm curious if the flexibility to create rhythmic rhymes would aid in memorization, or if the added phonemes would cancel out the benefit.

I came across a blogpost describing this workflow recently and I'm curious to hear HN opinions about it. Any pitfalls?

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)))
I like this workflow more than others which are centered around only encrypting credentials inside of your Git repository, and decrypting them when you clone / pull, because it means that not even on my development machine are keys just sitting around in plaintext.

You're right :) I do have a calculation for "lag" of tickets over a certain amount. Most states require tickets over $600 to be claimed at a lottery headquarters, not a gas station, so there is a noticeable lag in the percentage of remaining tickets over that value. I average out that lag per state, adjust the remaining tickets, and round to the nearest whole number.

A web version was my first iteration. It's pretty barebones, but it's available. http://ezmonic.net (Note that it's only served on `http`, so don't put any credit cards in there.)

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!

I've had a feeling that certain state scratch off lottery games can be beaten thanks to certain actions the states take in the name of transparency. For example, they publish daily reports of the number of prizes remaining.

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)

https://scratchoff-odds.com

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.