swid

Not really. There are ways to prove ownership of one of several hundred million tokens. If you give out this many tokens, the odds that some will be stolen or sold must be fairly close to 1.

It surely is different. If you set the temp to 0 and do the test with slightly different wording, there is no guarantee at all the scores would be consistent.

And if an LLM is consistent, even with a high temp, it could give the same PR the same grade while choosing different words to say.

The tokens are still chosen from the distribution, so a higher probability of the same grade will result in the same grade being chosen regardless of the temp set.

This isn't true in practice because you won't be able to control where allocations are made in the dependencies you use, including inside the Go standard library itself. You could rewrite/fork that code, but then you lose access to the Go ecosystem.

The big miss of the OP is that it ignores the Go region proposal, which is using lessons learned from this project to solve the issue in a more tractable way. So while Arenas won't be shipped as they were originally envisioned, it isn't to say no progress is being made.

My nephew was reading at age two… he is obviously a very special kid, but no one really pushed him to do that. Apparently this would kind of freak people out in public.

I’m not sure if reading before age one is biologically possible, but I have a surprising data point in my life, so who knows.

And productized in days!

I'm going to ignore the actual names used here - you can use any name you want. I think this pattern is vulnerable to introducing bugs that allow security bugs. I'm imagining process being some kind of sanitization or validation. Then, you have this thing called result, and some of the time it might be "safe" or processed, and sometimes not. Sometimes people will process it more or less than once with real consequences.

So yeah, definitely it is much better to name the first one in a way that makes it more clear it hasn't been processed yet.

There is no objectively correct way to do the merge, but there are ways that are obviously wrong.

Async/await themselves are not that much magic really, it's a bit of syntactic sugar over promise chains. Of course, understanding promises is its own bag.

ChatGPT explanation: https://chatgpt.com/share/68c30421-be3c-8011-8431-8f3385a654...

After thinking about it more, yes I agree with your take. Maybe it can even delete different ids using an =.

Most of what you say I agree with. But if this outer query is run only once with version A there is a caveat with where it says “where id = X”.

This cannot match more than one X at a time. So that forces the inner query to be run once, as we can only have one id, and running it twice may produce 2.

I am not sure though to be honest.

…

We are too deep for me to reply now, but to your next comment I didn't mean only one row, but only one id. It is easy for a small difference in word choice to get things wrong.

I think if it did return two rows; ie limit 2- the query with = will fail. Hmmm maybe that will happen even with limit 1 under certain plans. I wouldn’t trust it.

The comment about = is mine and I thought about rewriting that part of the comment after the fact. It is soooo hard to explain these things without writing a book.

The reason = mean it runs once is because the outer query will only run once, and in this case that query, when using =, can only delete based on a single id. But if that outer query was subquery in a context where it could be run more than once, you are back to where you started. Hence me saying their fix was sort of incidental.

I wrote this to a deleted comment, but even if the CTE was materialized, the subquery of the CTE would still not be...

For instance, with the stand alone query:

  DELETE … WHERE id IN (
    SELECT id … LIMIT 1 FOR UPDATE SKIP LOCKED
  )
  

the planner is free to turn that IN ( subquery ) into a nested‐loop semi‐join, re-executing the subquery as many times as it deems optimal. Therefore it can delete more than 1 row.

It is allowed to be a planner choice though! Very surprising, but if you understand the docs, it will follow that it is not actually a bug. It could change in the future and has changed in the past apparently - but that change was to give the planner more opportunity to optimize queries by not materializing parts of the query and inlining that part into the parent.

Regarding selects: [0]: “A key property of WITH queries is that they are normally evaluated only once per execution of the primary query… However, a WITH query can be marked NOT MATERIALIZED to remove this guarantee. … By default, a side-effect-free WITH query is folded into the primary query if it is used exactly once in the primary query’s FROM clause.

Regarding CTEs: [1]: “A useful property of WITH queries is that they are normally evaluated only once per execution of the parent query… However, the other side of this coin is that the optimizer is not able to push restrictions from the parent query down into a multiply-referenced WITH query"

Now, in either case - if you don't want the planner to inline the query - you might have to be explicit about it (I think since postgres 10?), or otherwise - yes, the output of the query will depend on the plan and this is allowed based on the docs.

[0]: https://www.postgresql.org/docs/current/sql-select.html

[1]: https://www.postgresql.org/docs/current/queries-with.html

I think arguably there is no bug here, but the blog doesn't do a good job of explaining the issue and their fix may work because they remove the CTE and switch to `=`, but they prove they don't understand why the difference when they suggest "using id IN (...) might still be necessary"; if you do that, then the problem will return.

There are two factors here.

The subquery

    SELECT id FROM task_queue WHERE queue_group_id = 15 FOR UPDATE SKIP LOCKED LIMIT 1

can return different ids each time you run it. If it was ordered, then it would always return the same id and if postgres optimized in a way that it runs more than once it would just get the same result each time anyway.

Otherwise, you need to force postgres to evaluate your subquery exactly once by materializing it. There are different ways this might be accomplished - the blog post does this incidentally by using `=`. But it is not the only way to tell postgres that.

For instance, like this. But it is fragile - without AS MATERIALIZED, it could be run more than once.

    WITH candidate AS MATERIALIZED (
      SELECT id FROM task_queue WHERE queue_group_id = 15 FOR UPDATE SKIP LOCKED LIMIT 1
    )
    DELETE FROM task_queue t USING candidate c WHERE t.id = c.id
    RETURNING t.item_id;

I see what you saying, but it is very subtle, wouldn’t you agree?

Under a different plan, the inner query would only be evaluated once, it is hard to mentally parse how it will first find the rows with the group id and then pass into the sub query.

And still I am not sure how using a CTE or not in the manner in the post is supposed to avoid this issue, so now I’m a bit skeptical it does. I see how a sort would.

I hope if the sub query was its own CTE, the limit would be applied correctly, but am no longer sure… before this post I wouldn’t have questioned it.

Edit to say - now I see you need to explicitly use AS MATERIALIZED if you bump the subquery to a CTE. Someone should really write a better blog post on this… it raises an interesting case but fails to explain it… they probably have not even solved it for themselves.

This is interesting - I don’t expect undefined behavior like this. Should the query delete more than one row or not?

The blog post doesn’t really give answers - it isn’t obvious to me that the second query can’t be executed in the exact same way. The even cop to this fact:

> This structure appears less ambiguous to the planner and typically encourages it to evaluate the subquery first.

So then - their bug still exists maybe?

I have thoughts - probably we do expect it never should delete multiple rows, but after considering the query plan, I can see it being ambiguous. But I would have expected Postgres to use only a single interpretation.

The comment you are replying to is saying the chance of error decreases with more pilots since there is redundancy. They are not saying it’s like too many chefs in a kitchen.

At a household or personal level, phones just don’t use much energy. But then again, Apple does sell a lot of phones.

I wouldn’t really be concerned though. Even if phones did use twice the energy as before, it would still be under a dollar of power for the whole year.

And this is exactly why you should not rely on AI without fundamental understanding.

That would only be true if the payout odds are even. And in my comment I explicitly say not 1:1 payout. Go ahead and ask the AI for clarification, I’m sure it can explain it to you. On Wikipedia, the factor is “b” - ie 2:1 payout and you would bet on a 50/50 event.

The intuition should be incredibly obvious here. I have a fair coin and will pay you 200 dollars for heads and take 1 dollar for tails. You would flip that coin as many times as I let you.

Even in your reply to this - ChatGPT is telling you in one situation you should not bet because the expected gain is nothing, and the other you don't know what to do - which is not equivalent. But the edge it is talking about is the expected gain over the probability of the event with the payout odds. If there is no edge, you won't bet. But you can have an edge with 50/50 odds, and if so you would bet.

You state the case of no knowledge vs knowing 50/50 probability are equivalent, but they are clearly not.

If you have no data but one side is actually heavily favored to win, you cannot determine how much you should bet on that probability even though there is an opportunity to make good sized bets. If neither side is favored to win, then you can still make good sized bets if the payout is not 1:1.

The Kelly Criterion formulates all this - the probability of win/loss does in fact matter, and if you don't "know" that, you cannot make a good bet. Knowing it is 50/50, you can bet on it.

Lets says I have a coin. I have no data on it. I do not know if it will come up heads or tails or if it is a fair coin.

I throw the coin N number of times and determine the coin is fair. I still do not know which side the coin will come up.

But this isn't the same as having no data on the coin. I've determined the coin is fair by gathering data, which otherwise I would not know. Often this added piece of information is crucial to making good decisions and not at all equivalent to the first case.

For instance, I might want to bet you that the next 10 throws in a row will all be heads. If you know the coin is fair, this is a good bet - but without data on the coin, it could be a trap.

I worked on compilers at Fortify which does static code analysis, and it's always surprised me SSA does not come up more in context about how to write clean, maintainable, and secure code.

SSA makes auditing code for dataflow issues much easier - both for people and programs. If you learn how to transform your code to SSA, you might find yourself choosing to write code this way so that you know, exactly, where that input to whatever sensitive string you are building came from. You can more easily trace the lifetime of that input and see what transformations it has been through already.

I feel like I am the only person in the world talking about SSA outside of compilers! It is useful for humans as well, and we all want to write readable and secure code.

There is a fun post that explores this idea via an anime called Death Note.

https://gwern.net/death-note-anonymity

Demonstrably, humans do think, and arguably demonstrably, early life would go down a path of simple predictions (in the form of stimulus -> response). And demonstrably, evolution did lead to human level intelligence.

So I don’t think there needs to be a semantic debate over where in the process intelligence started. The early responses to stimulus is a form of prediction, but not one that requires thinking.

There can be much disagreement that prediction is at the core of intelligence, or if optimizing ability to predict leads to intelligence. But from the established facts, it is the case the higher forms of life were bootstrapped from the lower ones, and also our biochemistry does have reward functions. Successfully triggering those rewards will generally hinge on making successful predictions. Take from that what you will.

It seems to me predicting things in general is a pretty good way to bootstrap intelligence. If you are competing for resources, predicting how to avoid danger and catch food is about the most basic way to reinforce good behavior.

Weather patterns have a daily/ seasonal rhythm… the strength and direction of the wind will have some distribution that is different at different times of the day. Temperature and humidity as well, like the other poster said.

I’ve heard clips of hot water being poured vs cold water, and if you heard the examples, you would probably guess right too.

Time of day seems almost easy. Are there animals noises? Those won’t sound the same all day. And traffic too. Even things like the sound of wind may generally be different in the morning vs night.

This is not to suggest the researchers are not leaking data, or that the examples were cherry picked, it seems probable they are doing one or the other. But it is to say, if you were trained on a particular intersection, and heard a sample from it, you could probably train a model to predict time of day reasonably well.

I like the definition proposed in the post - all possible mazes should be equally likely. A function could return the same maze each time and pass the criteria above.

My male friend once left the room with two girls I didn’t know very well; one of whom he was dating. We were all around 20 years old.

In the ten minutes he was gone, they looked up his sign and his girlfriend decided they were not compatible and literally dumped him when he got back. I guess with the lens of time, maybe there was more going on, but at the time it seemed like this was solely based on the advice of the astrology website. I was flabbergasted and have had a very negative opinion on astrology ever since.

You make the bubble after you are already moving in the direction you want to go. The bubble will keep moving. What else would it do? Out of all the questions, this is not a hard one…