The issue is that UA are editable by the user, and there is no proof that some random person/scraper isn't just using a suspected trusted bot's UA string. Every ethical service also posts what IP addresses they use, so that people can compare the traffic they get to see if it is actually their bot scraping. What this article describes is the game of every third-party unethical scraper; they do anything and everything to try and get their request through. They steal UA's, they steal residential IP addresses through botnets, they attempt to circumvent CAPTCHAs using AI, etc. So the behavior in this article is not prove for any major AI provider doing unethical scraping.
It's amusing because some insist that Fortnite is a battle royale game in the vein of PUBG, while others insist that it's a tower defense/shooter game like Orcs Must Die. And still others insist it's not a game but a venue for things like digital concerts. Clearly, it can't be all of those things!
IEEE 754 basically had three major proposals that were considered for standardization. There was the "KCS draft" (Kahan, Coonen, Stone), which was the draft implemented for the x87 coprocessor. There was DEC's counter proposal (aka the PS draft, for Payne and Strecker), and HP's counter proposal (aka, the FW draft for Fraley and Walther). Ultimately, it was the KCS draft that won out and become what we now know as IEEE 754.
One of the striking things, though, is just how radically different KCS was. By the time IEEE 754 forms, there is a basic commonality of how floating-point numbers work. Most systems have a single-precision and double-precision form, and many have an additional extended-precision form. These formats are usually radix-2, with a sign bit, a biased exponent, and an integer mantissa, and several implementations had hit on the implicit integer bit representation. (See http://www.quadibloc.com/comp/cp0201.htm for a tour of several pre-IEEE 754 floating-point formats). What KCS did that was really new was add denormals, and this was very controversial. I also think that support for infinities was introduced with KCS, although there were more precedents for the existence of NaN-like values. I'm also pretty sure that sticky bits as opposed to trapping for exceptions was considered innovative. (See, e.g., https://ethw-images.s3.us-east-va.perf.cloud.ovh.us/ieee/f/f... for a discussion of the differences between the early drafts.)
Now, once IEEE 754 came out, pretty much every subsequent implementation of floating-point has started from the IEEE 754 standard. But it was definitely not a codification of existing behavior when it came out, given the number of innovations that it had!
Everyone has already made several comments on the incorrect use of EPSILON here, but there's one more thing I want to add that hasn't yet been mentioned:
EPSILON = (1 ulp for numbers in the range [1, 2)). is a lousy choice for tolerance. Every operation whose result is in the range [1, 2) has a mathematical absolute error of ½ ulp. Doing just a few operations in a row has a chance to make the error term larger than your tolerance, simply because of the inherent inaccuracy of floating-point operations. Randomly generate a few doubles in the range [1, 10], then randomize the list and compute the sum of different random orders in the list, and your assertion should fail. I'd guess you haven't run into this issue because either very few people are using this particular assertion, or the people who do happen to be testing it in cases where the result is fully deterministic.
If you look at professional solvers for numerical algorithms, one of the things you'll notice is that not only is the (relative!) tolerance tunable, but there's actually several different tolerance values. The HiGHS linear solver for example uses 5 different tolerance values for its simplex algorithm. Furthermore, the default values for these tolerances tend to be in the region of 10^-6 - 10^-10... about the square root of f64::EPSILON. There's a basic rule of thumb in numerical analysis that you need your internal working precision to be roughly twice the number of digits as your output precision.
Your last comment is essential for numerical analysis, indeed. There is this "surprising" effect that increasing the precision of the input ends up by decreasing that of the output (roughly speaking). So "I shall just use a s very small discretization" can be harmful.
One of the major projects that's ongoing in the current decade is moving the standard math library functions to fully correctly-rounded, as opposed to the traditional accuracy target of ~1 ULP (the last bit is off).
For single-precision unary functions, it's easy enough to just exhaustively test every single input (there's only 4 billion of them). But double precision has prohibitively many inputs to test, so you have to resort to actual proof techniques to prove correct rounding for double-precision functions.
For what it’s worth, this is basically the first word you learn when discussing numerical precision; and I mean word—nobody thinks of it as an abbreviation, to the point that it’s very often written in lower case. So welcome to the club.
to me this feels like wasted effort due to solving the wrong problem. The extra half ulp error makes no difference to the accuracy of calculations. the problem is that languages traditionally rely on an OS provided libm leading to cross architecture differences. If instead, languages use a specific libm, all of these problems vanish.
Standardizing a particular libm essentially locks any further optimizations because that libm's implementation quirks have to be exactly followed. In comparison the "most correct" (0.5 ulp) answer is easy to standardize and agree upon.
> The extra half ulp error makes no difference to the accuracy of calculations
It absolutely does matter. The first, and most important reason, is one needs to know the guarantees of every operation in order to design numerical algorithms that meet some guarantee. Without knowing that the components provide, it's impossible to design algorithms on top with some guarantee. And this is needed in a massive amount of applications, from CAD, simulation, medical and financial items, control items, aerospace, and on and on.
And once one has a guarantee, making the lower components tighter allows higher components to do less work. This is a very low level component, so putting the guarantees there reduces work for tons of downstream work.
All this is precisely what drove IEEE 754 to become a thing and to become the standard in modern hardware.
> the problem is that languages traditionally rely on an OS provided libm leading to cross architecture differences
No, they don't not things like sqrt and atanh and related. They've relied on compiler provided libs since, well, as long as there have been languages. And the higher level libs, like BLAS, are built on specific compilers that provide guarantees by, again, libs the compiler used. I've not seen OS level calls describing the accuracy of the floating point items, but a lot of languages do, including C/C++ which underlies a lot of this code.
> The first, and most important reason, is one needs to know the guarantees of every operation in order to design numerical algorithms that meet some guarantee
sure, but a 1 ulp guarantee works just as well here while being substantially easier to provide.
> And the higher level libs, like BLAS, are built on specific compilers that provide guarantees
Sure, but Blas doesn't provide any accuracy guarantees so it being built on components that sort of do has pretty minimal value for it. For basically any real application, the error you experience is error from the composition of intrinsics, not the composed error of those intrinsic themselves, and that remains true even if those intrinsics have 10 ULP error or 0.5 ULP error
Many of the conversions so far have been clearly faster. I don't think anything has been merged which shows a clear performance regression, at least not on CPUs with FMA support.
using fma makes it possible to write faster libm functions, but going back to a 1 ulp world with the same fma optimizations would give you another 20% speedup at least. the other issue is that these functions tend to have much larger code size which tends not to be a significant problem in micro benchmarks, but means that in real applications you increase cache pressure allowing things down in aggregate
> Not much hydrogen there, so not much water, which probably is the biggest problem.
Actually, the cloud layer at that level is mostly sulfuric acid, from which you can get your water. It also means you need to be in a hazmat suit when you walk outside, but that's still a step up from everywhere else, where you need a bulky pressure suit instead.
There are 16 /8's in the class E address space that were never allocated, and 19 /8's (by my count) allocated to individual companies. If you waved a wand and returned all of that space to IANA for allocation, you would have staved off IPv4 address exhaustion by... about 3 years.
2.7 - 4.0 years, by my math, so I would agree with your assessment.
...but that's based on pre-IANA-runout rates, though, and doesn't account for the pent-up backpressure of demand. So probably a lot less, in reality.
Not even remotely worth the effort, even if there were a legal pretext for "reclaiming" IPv4 space (there isn't; there's already precedent denying it).
> US also didn't have Jus soli citizenship until the whole civil war and slavery debacle.
Actually, my understanding is that the US did largely follow jus soli. What it wasn't was unconditional jus soli, but the principle was birth in the bounds of the US conferred citizenship except if positive law existed not conferring citizenship.
If lawyers use it, they may have the ability to claim work product exemption, although this itself is going to be dependent on a lot more factors I can't analyze.
Non-lawyer discussing their lawyer's communications with a third party has defeated attorney-client privilege for eons, and that's basically what happened here. Especially when you're sharing those communications with a third party who explicitly told you that they will share those communications with the government if the government asks. There's no reason to overturn this.
Well, calling Claude a "third-party communique" here is the stretch.
Say a person used Excel via Office 365 to run some calculations to be given to their lawyer for their defense. Is that considered to be "communicating with a third party?" I don't think so, it's just a computer tool.
We call them "chatbots" and anthropomorphize LLMs, but, despite the name of Claude's parent company, Claude is not a person.
> Well, calling Claude a "third-party communique" here is the stretch.
Why? The privacy policy explicitly says that when you're using it, you're sending your data to Anthropic.
> Say a person used Excel via Office 365 to run some calculations to be given to their lawyer for their defense. Is that considered to be "communicating with a third party?" I don't think so, it's just a computer tool.
Very possibly, actually. At the very least, I wouldn't assume that it's okay to do that without first consulting with a lawyer. I do know of at least one feature in Office (desktop, not the web version) that prompted lawyers to say "if you don't roll this back, we cannot legally use your product anymore and maintain attorney-client privilege." It depends a lot on the actual contractual agreements in the terms of service and privacy policy, and while I know most people don't read them, those things actually matter!
reply