I'm sure it varies, but personally I have a very prosaic reason that I would still drive myself in most scenarios: If someone else is driving I tend to get motion sickness.
I'm definitely not the most comfortable writing in public forums, so guilty as charged with throwing my comments through an LLM to make sure my point isn't being misconstrued.
I think Google basically _is_ the standards committees, at this point. Not in the sense of having majority control just by themselves, but in the sense of (1) the cartel being argued over here (browsers funded by Google) having that or close to it, and (2) Chrome being the main source of new features getting implemented, so that the job of the standards committees is mostly to play catch-up with Chrome.
> Aren’t coding copilots based on tokenizing programming language keywords and syntax?
No, they use the same tokenization as everyone else. There was one major change from early to modern LLM tokenization, made (as far as I can tell) for efficient tokenization of code: early tokenizers always made a space its own token (unless attached to an adjacent word.) Modern tokenizers can group many spaces together.
Merging like that doesn't work -- it will tend to overestimate the number of distinct elements.
This is fairly easy to see, if you consider a stream with some N distinct elements, with the same elements in both the first and second halves of the stream. Then, supposing that p is 0.5, the first instance will result in a set with about N/2 of the elements, and the second instance will also. But they won't be the same set; on average their overlap will be about N/4. So when you combine them, you will have about 3N/4 elements in the resulting set, but with p still 0.5, so you will estimate 3N/2 instead of N for the final answer.
I have a thought about how to fix this, but the error bounds end up very large, so I don't know that it's viable.
Robbery/burglary? SWATing? The possibilities are delightful and endless. The former is a major concern for people who are known to be rich; the latter for people who are infamous online (and has the [dis]advantage that it can be carried out by anybody, anywhere in the world, typically repeatedly, and with usually zero repercussions.)
Thanks for linking the graph, that's kind of wild. I agree with you that the lowest datapoint seems crazy. I can think of a few explanations.
- Random bad luck.
- As you say, failing to control for something -- although, if you then treat the lowest datapoint as being effectively the default risk, this would suggest support for radiation hormesis (that people who got a bit more than background radiation actually did better.)
- Some kind of data collection artifact. Perhaps the people with the absolute lowest dose, in a radiation-worker dataset, are selected for being ones who are not getting an accurate measurement (i.e. sloppy about wearing dose badges or something), and those people genuinely do have worse outcomes.
I'm not a statistician, but I think there's a bit in your excerpt that is actually a concerning display of poor statistical literacy.
If you're fitting a function which grows asymptotically (i.e. is monotonically increasing at least past a certain point), the best (polynomial) fit absolutely cannot have a negative quadratic as the leading term. If your model gives one, it is 100% guaranteed to be an artifact. Treating it as "suggesting some downward curvature" is a pretty bad misunderstanding.
If you have doubts about this, consider what would happen if we added datapoints at higher doses. Every single datapoint we add to the right side of the graph will make the fit of a negative quadratic significantly worse. Ultimately, if you continue the graph indefinitely to the right, the fit of a negative quadratic is guaranteed to be infinitely bad. Any hint to the contrary is inherently an artifact of the limited dataset.
(It may well be the case that, under certain conditions with a range-restricted dataset like this, such a finding might indeed be more likely if the true function has some downward curvature. But that's not statistics, it's voodoo. All the associated statistical parameters, p-value, likelihood ratio, etc., are absolutely meaningless nonsense.)
I think that in this case it is definitely a case of analytic-cotorsion.
There is _heated_ and mostly opinionated debate about the low-dose regime. Briefly some people believe low-doses of radiation have a threshold (that one could get a certain amount before having excess cancer risk), there is "no-threshold" meaning relative risk = 1 and dose = 0, and there are people who say that some radiation is good for us because it stimulates our repair mechanisms and kills weak cells.
All of this heated debate brings us to the currently misunderstood findings, and is why the author's say over-and-over that the linear model is a good fit.
People, specifically the regulators and the nuclear industry, make a _bunch_ of health decisions on excess risk based on Linear-No-Threshold (LNT) models because they believe it is conservative.
The main issue here is that in order to get good statistics, you have to irradiate people, and the two best datasets prior to today are Hiroshima survivors and the small number of low-dose exposures. People are torturing this analysis to resolve the debate, which in my opinion only feeds it.
As I understand it, Schnorr signatures are the "natural" (and simplest) construction for a digital signature in elliptic curve cryptography. The reason ECDSA exists is simply https://patents.google.com/patent/US4995082 (now expired), which made Schnorr illegal to use, so something worse had to be invented.
Schnorr signatures have a "linearity" property -- if you add together two signatures you get a valid signature of the same text using the sum of the keys.
Sometimes you don't want people to be able to obtain signatures-with-the-sum-of-the-keys, or you don't want to enable bulk key-cracking via the same techniques that allow bulk validation.
Also, confusingly, "EdDSA" signatures (aka ed25519 signatures) are Schnorr signatures:
1. Uses hashing instead of either multiplicative inverse (slow) or a source of randomness (footgun) for the nonce.
2. Hashes the public key into the signature in order to deliberately break linearity. Signatures with different keys will use different hashes, and hashing isn't linear, so adding the signatures no longer yields anything useful. The signature verifier checks this (they can, since they have your public key), so a defective implementation can't skip this step without producing bogus signatures.
EdDSA signatures are not Schnorr signatures. A Schnorr signature is dlog proof made non interactive with fiat Shamir binded with the message, and that is equivalent/verifiable as an EdDSA signature, up to one time signing per message (as Schnorr is not deterministic)
EdDSA being deterministic, means it’s not Schnorr by definition.
The other difference of EdDSA is having a different keygen process: SHA512 then clamp the first 32 bytes (and this process breaks down all additive key derivation that’s nice to have) clamping is not the problem and you have to clear cofactors for Schnorr over that curve anyway, but it’s the hashing at the beginning that’s different and has nothing to do with cofactor clearing.
The other difference of EdDSA is not having a standardized verifier (keywords are “cofactored” and “cofactorless” verifier) and this breaks down another nice property of Schnorr signatures which is signature aggregation.
Overall the standards for EdDSA -unfortunately- still leave a lot to be desired.
