Perhaps something akin to a tag? E.g. if memory safe purists were popular on codeberg I'd hope there was just a way to filter projects by that feature (or at least by language) rather than the C projects get kicked out and we end up with 50 platforms for the 50 communities of coding opinions.
Importantly, Wikipedia's policy is a bit more detailed about what LLM contributions are and aren't allowed. There is always ambiguity, but going through specific cases and examples up front in the policy went a long way.
Simple/common tests is not an explanation for why only now Opus 5 is the only model encoding the answers like this. Something like the holdout test suite being leaked or Anthropic cheating (e.g. 'accidentally' including previous hold out run data in Opus 5 training) makes a much stronger fit.
Modern Ethernet networks can be full-duplex because of all the buffering and separation between ports. If you're running ethernet on an actual shared medium like 10BASE5 or hubbed ethernet, it has to be half duplex to handle collisions better.
And the proposed switch design - transmitting most packets to most ports without buffering - is basically a hub. If you transmit two packets at the same time you will most likely create a collision. A real switch can buffer one of the packets.
What you're describing are drops, which behave differently than collisions. No frame is successfully delivered in a collision while one is during a drop. This project cannot have collisions because the links are full duplex.
Unknown flooding is actually a pretty base requirement of ethernet switches per the 802.1 standard, even when the table is not full, anyways. Without it you can't form switched paths unless every switch in the path has recently heard a broadcast (or following regular flow) from the intended receiver. If you start each test case as a short loved one with an IPv4 client ARPing for neighbors or in a simple topology the this can easily be missed but wreak havoc in the real world. To not do so is as egregious to say you're an ethernet switch which does not flood broadcasts in terms of false claims of being an Ethernet compliant switch.
I think there is a law of the universe which says it must happen right after you've mentally decided to type enter but before your fingers have finished.
There is no way to fire a lot of people in a way everyone likes, only ways which suck more than others for different people. Whether you think they are dramatic is not one of the sucks they are very concerned with as you're one if the ones who will forget this layoff in a few hours
But there are ways to reduce headcount without causing waves. Those include things like simply not backfilling for people that leave the company or who are fired for low performance.
Letting a bunch of people go all at once is a sign of poor management and poor planning. Or it's a sign that Patreon wants to go public and ATM the stock market loves layoffs.
Not everyone will jump for joy at these options either. Hell, I'm not even sure there is a way to expand headcount that someone won't have issue with. The business planning is just as bad or good regardless the reaction to the announcement though.
It bothers me because there is no reason it can't just give 3 results: single, mixed/low thread, all core and yet there is often debate on which 2 numbers in such benchmarks instead.
But, of all of the 2-pick-only options, choosing a custom mix and calling it multi-core requires guessing your actual workload on both the content of the mixed test suite as well as the scaling profile of the CPU to reason with. On the other hand, just testing "single core" and "all core" at least only requires you to guess based on what you think the scaling profile of the CPU is.
Nothing beats just testing your actual workload, but that doesn't mean all other ways of testing have to be equally good.
> But, of all of the 2-pick-only options, choosing a custom mix and calling it multi-core requires guessing your actual workload on both the content of the mixed test suite as well as the scaling profile of the CPU to reason with.
Yes, that's pretty much the whole point of Geekbench: to offer non-experts a way to measure CPU performance and produce scores that are relevant to a specific class of devices and users and use cases, rather than artificially inflated.
Benchmarking experts can already use something like SPEC, which does offer single-thread and both types of multi-thread test modes (SPECrate and SPECspeed).
It has nothing to do with whether it's an expert benchmark or not, even the dumpster fire that is UserBenchmark manages to show the three categories separately. It's just a bad practice among any kind of benchmark, basic or not. After all, the Geekbench is already doing the work needed during the tests.
Geekbench is not just intended to be used to benchmark consumer systems, it is intended to be used by consumers to benchmark their systems and to have its scores interpreted by consumers. For that audience, the most important thing that a multi-core score needs to do is counteract the naive assumption that a 20-core CPU will be twice as fast as a 10-core CPU. Having one of the top-line scores be a perfectly-scaling multi-core score that you know will be widely misinterpreted by your audience and used by vendors to mislead consumers would be serious benchmarking malpractice.
You start by saying it's used by the users and then end by saying it'd be abused by the vendors. You can't play both sides as reasons at the same time.
Besides, UserBenchmark is clearly intended to be used by users as well. It's right in the name. There has not been confusion with it, if anything labeling the scores as what they are instead of hiding it under how you want a user to see it is both clearer and avoiding benchmark malpractice - not the other way around.
When I'm starting from mostly ignorance, being an apprentice is better than trying , making little progress, and giving up. The problem will be if we never transition from being an apprentice, to independence.
And that's a fine start, but my question was not why they avoided inventing everything from scratch themselves. Apprenticing to see how it can be done is only half the journey to understanding things from first principles, trying to then do it yourself is the other half. Usually you learn more in the second half than the first, you just need the first to make the second feasible.
Not that there is anything wrong with just wanting to make another visualizer and learn some things along the way, it's just a hollow way to try to learn first principles.
Novices apprenticed to humans, instead of AIs; if they could find one. Flight dynamics guys might be too busy for a 17-year old apprentice from Brazil.
My analogy: AI is like a calculator. In the hands of someone
who doesn't understand math, it produces answers they can't
verify. In the hands of someone learning, it lets you tackle
problems that would otherwise take years to reach.
But the real answer is what I can demonstrate: I understand
why Newton-Raphson converges for Kepler's equation, why RK4
needs 4 evaluations per step, why adaptive timestep matters
near perihelion, and why N-body perturbations from Jupiter
dominate over Saturn for most NEOs. I wrote the physics
isolation boundary myself because I understood why it mattered.
Could I implement all of this from scratch without AI? Not yet.
But I understand what's there and that's where I'm starting
from, not ending.
reply