Hacker Newsnew | past | comments | ask | show | jobs | submit | hatthew's commentslogin

I agree in general, but as a one-off thing I'd very much enjoy getting a lime with a message saying "this was cheaper than sending a letter myself"

I've started sending paperbacks instead of greeting cards when someone I know needs a get-well-soon card. In stores around here, greeting cards are often $7ish + postage. I can frequently ship a paperback with a gift receipt for $5 total. I include a gift message on the gift receipt, and choose a book I think someone might like to read while they're out of commission.

I guess it's a bit like postal arbitrage, if I accept the cost of greeting cards themselves as part of the cost of the activity.

To the extent that anyone has commented much, those who have commented had very positive reactions to what amounts to a book recommendation and a copy of the book I'm recommending along with a little note.


Haven't done it in a long time, but years ago I had a similar realization that picture frames were cheaper than cards. So you can frame a little note, either with a picture or just suggest they can reuse it if they like. Buying greeting cards always felt like kind of a waste. Lately our kids' schools have been doing a thing each year where the kids do some art and then you can buy cards (and other things) with it, so we've been using those as they're at least a bit personal. Once that's done, maybe I'll give picture frames again (or paperbacks or cans of tomato soup...)

This is a good idea, but I also want to point out that a regular piece of paper makes a perfectly good greeting card

It absolutely does! I like the addition of the thing to read (in the case of the book) or the thing to look at (usually a funny or interesting picture in the case of the greeting card) but I agree that the purchased thing is not truly necessary.

Would you say a country of 300 people isn't small?

Big, small, etc. are relative terms. There is no way to decide whether or not 300 is small without implicitly saying what it's small relative to. In context, it was obvious that the point being made was "valve is too small to have direct employees working on things other than the core business"


the implied observation is that valve is extremely small relative to what it does and how big most people would expect it to be


An answer of "yes" will generally eliminate many edges, with potential for >1 bit. However, an answer of "no" will generally eliminate just that one edge, which is generally <1 bit.


We have to make a distinction between "expected information gain" vs "maximum information gain". An answer of "yes" generally gains >1 bit, but an answer of "no" generally gains <1 bit, and the average outcome ends up <1. It is impossible for a single yes/no question to have an expected gain of >1; the maximum possible is precisely 1.


The total probabilities add up to 1. But I’m not following how that relates to the average bits.

Despite summing to 1, the exact values of P(true) and P(false) are dependent on the options which have previously been discounted. Then those variables get multiplied by the amount of information gained by either answer.


It is definitional, which I mean in the strictest mathematical sense: the information content of a result is directly derived from how “unexpected” it is.

A result which conveys 2 bits of information should occur with 25% expected probability. Because that’s what we mean by “two bits of information.”


So, you have n options, you ask a question, and now you're down to m options.

The number of bits of information you gained is -log₂ (m/n).

If you ask a question which always eliminates half of the options, you will always gain -log₂ (1/2) = 1 bit of information.

If you go with the dumber approach of taking a moonshot, you can potentially gain more than that, but in expectation you'll gain less.

If your question is a 25-75 split, you have a 25% chance of gaining -log₂ (1/4) = 2 bits, and a 75% chance of gaining -log₂ (3/4) = 0.415 bits. On average, this strategy will gain you (0.25)(2) + (0.75)(0.415) = 0.8113 bits, which is less than 1 bit.

The farther away you get from 50-50, the more bits you can potentially gain in a single question, but - also - the lower the number of bits you expect to gain becomes. You can never do better than an expectation of 1 bit for a trial with 2 outcomes.

(All of this is in the article; see footnote 3 and its associated paragraph.)

The article explicitly calls out the expectational maximum of one bit:

>> You'll also notice that you're never presented with a question that gives you more than 1 expected information, which is backed up by the above graph never going higher than 1.

So it's strange that it then goes on to list an example of a hypothetical (undescribed, since the scenario is impossible) yes/no question with an expected gain of 1.6 bits.


The article states "Suppose we have calculated the expected information gained by potential truth booths like below: Expected information: 1.60 bits ..." This is impossible because of the general fact in information theory that (p(true) * bits_if_true) + (p(false) * bits_if_false) <= 1. If they had said "Suppose we have calculated the maximum information gained...", then 1.6 bits would be valid. They said "expected information" though, so 1.6 bits is invalid.


Yes, you learn more than 1 bit in that case. However, if you are told A is false, you still don't know whether B or C is true, so you gain less than 1 bit. Assuming A, B and C all have equal probability, your average/expected information gain is <1 bit.

If you ask the question "which of A, B, or C is true?" then you're not asking a yes/no question, and it's not surprising that you expect to gain more than 1 bit of information.


but that’s all consistent. “Expected” gain is less than 1 for the truth booths and sometimes > 1 for actuals; and is > 1 on expected value of the match ups, which aren’t binary questions.


Sure, and the issue is that the article says "Suppose we have calculated the expected information gained by potential truth booths like below:" and then lists some values >1

edit: just saw that the article fixed this recently, and the values are now <1


IMO the article reads like it was written by a high schooler trying to reach a page count. It has original content, but it rehashes the same points many times, is short on actual substance, and doesn't have a clear point.


I think it may be language thing but sure, we've switched it to the AP story.


While poking around on other pages from the same .en subdomain of TFA on archive.org, I found error pages from GTranslate (Google Translate?) which could explain the weird formatting and language issues.

I don't mean to disparage the site by calling it blogspam, but I do take your point. Thanks for your efforts and for your gentle nudging; I will seek to be more expressive and less judgemental.


My context window is about a day. I can remember what I had for lunch today, and sometimes what I had for lunch yesterday. Beyond that, my lunches are gone from my context window and are only in my training data. I have vague ideas about what dishes I ate, but don't remember what days specifically. If I had to tell you what separate dishes I ate in the same meal, I don't have specific memories of that. I remember I ate fried plantains, and I ate beans & rice. I assume they were on the same day because they are from the same cuisine, and am confident enough that I would bet money on it, but I don't know for certain.

One of my earliest memories is of painting a ceramic mug when I was about 3 years old. The only reason I remember it is because every now and then I think about what my earliest memory is, and then I refresh my memory of it. I used to remember a few other things from when I was slightly older, but no longer do, because I haven't had reasons to think of them.

I don't think humans have specific black and white differences between types of knowledge that way LLMs do, but there is definitely a lot of behavior that is similar to context window vs training data (and a gradient in between). We remember recent things a lot better than less recent things. The quantity of stuff we can remember in our "working memory" is approximately finite. If you try to hold a complex thought in your mind, you can probably do that indefinitely, but if you then try to hold a second equally complex thought as well, you'll often lose the details of the first thought and need to reread or rederive those details.


Eclipse was great for java specifically, but a lot of its useful/reliable features came from java being easy to standardize around. Strong static typing and javadocs combined allow for a lot of convenient and reliable features like previews, intellisense, refactoring, etc. For me, vscode feeling worse come from the fact that I'm using it for python and javascript which are inherently harder to design IDE features for, and also vscode is designed to be a good all-round programming editor, not a java-specific editor.

Taking its broader scope into account, I feel like vscode is a significantly better IDE than eclipse, though if I went back to exclusively coding in java and nothing else ever, I might switch back to it.


And so pray tell, what benefits has the industry produced by herding around JS and python in the last two decades? Java was a decent language and getting better and its tooling was stellar, beyond anything those two ecosystems can muster today.

It was 20 wasted years of running in circles. Lots of motion, little progress.


Vite and Bun are about a billion years ahead of their analog in the Java ecosystem in the early 2000s. I do agree that the editor story for Java was very good, though -- way ahead of its time.


I don't know what greatness it brings to the table. I'm sure it's fabulous.

Nonetheless, in the Java of yesteryear we packaged shit into .war files and deployed to app servers. Took all of 30s. Projects (Java backend + JSP frontend) ran just fine right in the ide, no bundling, transpiling, pruning, minifying, or whatever myriad of incantation a js project needs to do to get itself live. it was all live the moment you hit Ctrl-S in the IDE. The class file was created and Tomcat was already running the new code if you set it up integrated to the IDE.

There was zero mental or temporal overhead from source changes to observing results.


saying "a coin may land on head or on tail" is useful when other people are saying "we will soon have coins that always land on heads"


this is doable, you just have to rig the coin


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: