Attention itself was the key idea of that paper and, as you sort of acknowledge, was definitely not just throwing things at the wall. It was the culmination of a long line of work gradually progressing toward fully dynamic routing via attention, and it was motivated, if not by deep theory, at least deep intuition from linguistics. The other details of transformers are perhaps sort of arbitrary, but made sense to everyone at the time. There was no claim that those other details were optimal - just that they were one way of surrounding the attention mechanism with computing machinery that worked.
It's true in the Pacific Northwest, the Midwest, Texas, Florida, California. Rail is still mostly shit over medium distances there, although finally there are concrete efforts being made in California, Texas and Florida to fix that.
Fair, though if we invested in high speed rail a lot more cities would be within 4-5 hours of each other (and have the added advantage that the train would be consistently be faster than driving).
We don't know. The nature of consciousness is an unsolved problem.
We do know that LLMs fall into a certain category of mistake that most educated humans look at and go "HA! What was it thinking??"
It's not that humans don't also make those types of errors - it's that we recognize them quickly when they're pointed out to us and usually describe the error as a "stupid mistake," "brain fart," or similar name intended to show explicitly "gosh, I totally failed to actually think before I did that."
The LLMs show no sign of such self-awareness or, well, "intelligence," loose and squishy as those words are.
Maybe GPT-5 will fix that, but so far it doesn't look that way.
You can achieve this without UUID keys if you attach UUIDs to the requests. This has the advantage of working for all kinds of mutating requests, not just creates, but requires that you store these request UUIDs for some period of time as well.
It's still not as elegant because it doesn't work in a multi-process or multi-server back end; if the request fails, you need to make sure that the retry request will hit the same server process (assuming you're keeping the UUIDs in memory on the server). You can use some in-memory data store like Redis to share the request UUIDs across multiple processes/hosts but that can add a lot more complexity, latency and risks and is just not worth it IMO.
Even in a single-host setup, it can be a problem because what happens if your process crashes and restarts just after a resource was created in the database but before the ID was sent to the client (with success message)? You would end up with a duplicate record in your DB after the retry since your newly restarted server would not have the UUID in its memory (even though the resource was in fact already created on the server a few milliseconds before the last crash).
With the Redis (or similar) solution, you need to make sure that the request UUIDs expire after some time and are cleaned up to avoid memory bloat which is a pain... I mean that complex solution probably uses up a lot more resources than just using UUIDs in the database as IDs.
You can use the DB for this as well, just make a table e.g. "requests" with two columns, the user and the request token. Old entries can be purged on a cron job.
If you add a column to store params as well then you can also do better validation:
> Responding when a customer changes request parameters on a subsequent call where the client request ID stays the same
> We design our APIs to allow our customers to explicitly state their intent. Take the situation where we receive a unique client request token that we have seen before, but there is a parameter combination that is different from the earlier request. We find that it is safest to assume that the customer intended a different outcome, and that this might not be the same request. In response to this situation, we return a validation error indicating a parameter mismatch between idempotent requests. To support this deep validation, we also store the parameters used to make the initial request along with the client request identifier.
You can but you add an additional database lookup step which will cost you more in performance (and latency) than just using UUIDs as the ID directly with a single table.
It's only at creation time. When you lookup the record after that you can use the ID directly, and then you don't hit the locality problems from the article.
It might be legal from Canada's perspective, but that doesn't necessarily mean legal action couldn't be taken in the US. Is there something specific to the law on recording phone calls that makes this not a problem?
You can sue anyone for anything anywhere, but I cannot imagine the Canadian police being interested in a citizen doing something lawful in Canada if the California (or wherever) cops call to complain be broke a Californian law.
And I can even less imagine a civil action demanding damages or court actions in Canada for doing something legal there. It would be like a Saudi company suing a US driving school that teaches women.
I don't think there's a there there as far as liability or worry. IANAL, of course.
How do you launch a lawsuit in your own country against a person that lives, works, and operates in and is a citizen of another country? That would be truly bizarre.
