For anyone using these models for anything remotely sensitive, keep in mind that Anthropic says [0]:
> We retain inputs and outputs for up to 2 years and trust and safety classification scores for up to 7 years if your chat is flagged by our automated trust and safety systems as violating our Usage Policy.
And, since those automated systems apparently have a ludicrous false-positive rate, you should assume that your inputs and outputs are being retained for 2 years even if you are doing nothing that any reasonable person would consider to be problematic.
Oh, and they'll train on that data [1]:
> We will use your chats and coding sessions (including to improve our models) if:
>You choose to allow us to use your chats and coding sessions to improve Claude, learn more here
> Your conversations are flagged for safety review (in which case we may use or analyze them to improve our ability to detect and enforce our Usage Policy, including training models for use by our Safeguards team, consistent with Anthropic’s safety mission)
It appears that the usual controls (including for businesses) to prevent Anthropic from training on your data will not apply.
If you want to get correct answers out of math, it helps to start with correct definitions.
A random variable is a random variable and is not the same thing as a stochastic process. You now seem to be talking about stochastic processes, which are a different thing.
Is it just me or do the first few examples seem worse than doing the same things without effects?
I can have a function fail by having it invoke an “exception” effect that doesn’t continue it. Or I can return a result and have that result contain the failure. If I use effects, I need to thread the effect through the call tree. (The effect has one nice property that a stack trace may be available, but this has runtime cost.)
If I’m writing a generator, then I can express it with effects, but it’s not immediately obvious to me that the resulting in-progress generation can be captured as a first-class value, whereas a conventional Iterable can, even in languages like Rust without a heavy runtime. (Maybe it’s in the article.)
And effects that continue twice are gross. Okay, there are cases where a continuation wants to be continued more than once and that a full-powered continuation should be used instead of a some more restrictive at-most-once or exactly-once scheme, but the function being continued really needs to be prepared for it, and the compiler cannot generate decent code without knowing how many times something can return. And I don’t see anything in the declaration of effects that gives any bounds on number of times that something can be continued.
> This is under-taught in comp sci so I'll say it in all caps for visibility. THERE IS NO KNOWN GENERIC WAY TO MEASURE INFORMATION ENTROPY!!!!
Both your comment and the OP seem to conflate a distribution with a sample from a distribution.
A distribution over strings has entropy. A single string can have a Kolmogorov complex but does not have entropy in the Shannon sense per se.
When you write a compression algorithm, you are often effectively building an algorithm to look at a single sample from an unknown distribution (the input data) and trying to invent a distribution that is both easy to describe and that produces the input data with respectably large probability. And then you output the description of the distribution and enough data to identify the sample in question, and the latter takes space that is roughly the entropy of the distribution you just made up.
> "What's the probability of this data assuming i always have the most perfect model to predict it?". You then calculate entropy based on that oracles answer.
Careful here. The most perfect model may be the one that outputs the data in question with probability one, and the entropy is exactly zero.
If you want information theory to give you meaningful answers, you need to ask it more carefully specified questions.
> A setup where company.example sends email from companymailings.example but sets a reply-to for [email protected] is perfectly valid
So shouldn’t this be done explicitly by setting a policy at _dmarc.companymailings.example instead of implicitly by setting at otherwise entirely useless record (of type A? some unused TXT variant?) at companymailings.example?
While nothing good can be said about the design of DNSSEC here, it seems to me that the new np feature’s semantics are also misguided. I get it: if I own company.com and I’m not using foo.company.com, then maybe I should set np=reject on company.com’s DMARC rule so that no one can spoof email from it.
But it seems odd that www.company.com should be considered present for this purpose even if it has no MX records. And if I want to send from noreply.company.com, then setting some unrelated DNS record type there to prevent it from being not “not present” seems like a giant kludge.
And lots of domains have subdomains that are intended for some non-email purpose (api.company.com or whatever), and those shouldn’t be allowed without further policy. Nor should (technically invalid for SMTP but maybe allowed anyway) delights like _dmarc.company.com itself.
Why didn’t the DMARC spec say that a domain is “not present” if it lacks MX records?
A major confounding factor is everything else in the air. Humans produce lots of different gases, and CO2 is usually a proxy for the overall concentration of our effluent gases. But in a submarine, or in some buildings, there are gas filters (usually carbon, possibly with various modifications) that can remove or destroy some of these gases but have no effect on CO2. So the air in a submarine at 15000ppm CO2 could be very different from the air in a an unventilated room that reaches 15000ppm CO2.
Even if you live in an air quality paradise, it’s not ideal for your indoor air to be the air that manages to sneak through all the little cracks in your structure. Especially if you have cold outdoor temperatures, indoor humidity such that the outdoor temperatures are below the indoor dew point, and airflow through the walls that can lead to condensation and possibly mold in those walls.
Your indoor air should enter through windows or intentional intakes, not incidental gaps.
No one is arguing that there are practical audio microphones + ADCs that produce accurate, undistorted 32-bit float output across the full representable range. But they don’t need to! For professional use, the ability to produce perceptually accurate output, with inaudible noise, across a very wide dynamic range, is extremely useful. Think of it as fancy, real-time AGC. It does not need to be perfect. If you can record a loud transient without substantial distortion, and also record sounds with 2^16-fold lower amplitude (~96dB lower) while still remaining well above the noise floor immediately after the transient is gone, this ability is useful. Plenty of real-world noises are well above 120dB, and plenty of human-audible sounds are below 20dB. You can’t play back the recording, at least not without making parts inaudible or injuring your audience, but you can edit it. And a setup like this lets you do it with one microphone and no fiddling with gains in advance.
One possibility (pure speculation) is a bad antialiasing filter. The Nyquist frequency at 44.1ksps is 22.05kHz, which is only ~10% above the audible band. This means that you need a rather sharp filter both when downmixing and when playing to avoid potentially audible aliasing into the audible band or attenuation within the audible band.
If you look at a site like audiosciencereview.com and pull up measurements of a DAC or ADC, you can find graphs of the antialiasing filter response. Some are great and some are not.
One could think of 16/44.1 PCM as being a codec that is potentially perfect but requiring some degree of care to encode and decode correctly.
(Personally, I wish researchers would not forgot quite so often that there is a non-mRNA COVID vaccine available in the US. Where's all the analysis of the effects of the Novavax vaccine?)
> Higher sample rates are lower latency for the same block size
This a truly bizarre statement. On the one hand, of course higher sampling rates are lower latency for the same block size measured in samples. But all sampling rates have (almost [0]) identical latency for the same block size measured in time and lower sampling rates allow less computation for those shorter blocks.
[0] If you are concerned about needing to know future samples in order to calculate the actual signal amplitude at a time between samples, then (a) this matters less at higher sampling rates and (b) this is at most a small number of samples and we're talking about block sizes that presumably exceed, say, 5, so this isn't really a big deal.
I’m amused that there is no discussion of failure modes. What if the resource someone GETs turns out not to exist? What if the POST fails and needs a retry? What if redirects are involved?
I suspect that the lack of ability to form nulls in the beam is as big or even a bigger limitation than the reduction in gain when going from a big array to a phone.
The SNR in Shannon’s Law has a log in front of it, but spectrum reuse is more or less linear. If there are five visible satellites and I can null out four of them, then I can receive from and transmit to the fifth without substantial interference. (I’m not saying this is easy! Contemplate how many WiFi generations have had MIMO and how limited it still is.)
So I believe that it’s comparatively straightforward to demonstrate a shiny new direct-to-cell system with a single phone on a stage, but achieving usefully large aggregate bandwidth in a dense area will be more challenging.
FWIW the problem with Iridium, historically anyway, was that available bandwidth was very low, so they had to charge a silly amount for usage of that bandwidth, so very few people used it. Iridium used low-ish frequencies, with narrow bandwidth, and (I think) no MIMO whatsoever, not even polarization diversity.
> the market is moving to satellite service on regular phones.
I don’t think there a unified “market” here. The fixed rooftop terminals and fixed-ish roaming terminals use high (tens of GHz) frequencies with correspondingly wide bandwidth, have excellent beamforming capabilities and some degree of MIMO to improve spectrum reuse, and consume an amount of power that would be outrageous for a phone. Phones don’t have reliably clear views of the sky and have much weaker RF capabilities.
Oh, and phones are well served by existing 4G and 5G networks in dense areas, with better spectrum reuse than seems practical for a satellite constellation.
I expect that we will actually see two separate markets that happen to share the same satellites and backhaul.
Zyrtec/cetirizine is a weird one. Everyone seems to agree that it is a second-generation antihistamine. The FDA seems to play along. But there is no particular shortage of anecdotal evidence of people who find it quite sedating (hi there!), there are some papers questioning its status [0], and the FAA puts it in a category with diphenhydramine, not with loratadine and fexofenadine [1].
I know little about radiology, but MRI is a 3D medium. I would not be at all surprised if one could slice an MRI the wrong way to produce a 2D image that fails to show a feature that exists in the source data.
> We retain inputs and outputs for up to 2 years and trust and safety classification scores for up to 7 years if your chat is flagged by our automated trust and safety systems as violating our Usage Policy.
And, since those automated systems apparently have a ludicrous false-positive rate, you should assume that your inputs and outputs are being retained for 2 years even if you are doing nothing that any reasonable person would consider to be problematic.
Oh, and they'll train on that data [1]:
> We will use your chats and coding sessions (including to improve our models) if:
>You choose to allow us to use your chats and coding sessions to improve Claude, learn more here
> Your conversations are flagged for safety review (in which case we may use or analyze them to improve our ability to detect and enforce our Usage Policy, including training models for use by our Safeguards team, consistent with Anthropic’s safety mission)
It appears that the usual controls (including for businesses) to prevent Anthropic from training on your data will not apply.
[0] https://privacy.claude.com/en/articles/7996866-how-long-do-y...
[1] https://privacy.claude.com/en/articles/10023580-is-my-data-u...