________________________________________
/ "We report here our experimental \
| demonstration of flexible egocentric |
| tooling in a pet cow (Bos taurus), |
| Veronika, who uses a deck brush to self- |
| scratch. Across randomized trials, she |
| preferred the bristled end but switched |
| to the stick end when targeting softer |
| lower-body areas. This adaptive |
| deployment of tool features reveals |
| multi-purpose tool use not previously |
\ reported in non-primate mammals." /
----------------------------------------
\ ^__^
\ (oo)\_______
(__)\ )\/\
||----w |
|| ||
For me, the cow was just below the bottom of the screen, which caused me to first wonder what the heck and then get great comic relief after scrolling down!
Very interesting to watch, though I don't really have a great idea of what's going on most of the time. Performance seems to be fairly poor despite my system being pretty beefy (Ryzen 9 7950x3d). I see the performance monitor and notice that the render loop seems to fairly regularly exceed the latency for 60fps, despite this being a 'simple' task by modern standards. I'd give more helpful feedback as to why, but the minified code makes it hard to say.
Do you plan on monetizing this somehow? If not, open sourcing some, if not all, would be pretty cool, even if it weren't necessarily licensed in a way that others could 'take' it, if that's your concern. Nonetheless, a very cool project.
FPS dips usually line up with big ecological events (population blooms, mass reproduction, lots of giant organisms, pathogen waves). The sim and rendering are decoupled, so you get (hopefully) brief spikes when a lot happens at once, then it settles again as populations crash/thin out. It’s normal behavior, not a runaway bug.
I’ve spent a lot of time optimizing hot paths and getting calculations down, but when the ecology goes a bit wild, you’ll still see temporary spikes. If you want to focus on stats only, you can switch to Simmer mode (no graphs) or turn off the arena, which reduces rendering work quite a bit.
Yes, some parts are inherently O(n²) (mate finding, crowd density, predator/prey proximity, pathogen spread). Ecology needs pairwise relationships.
To keep it sane, I don’t do naive all-vs-all. I use:
Zone-based spatial indexing so most checks only run against local neighbors (roughly n/16 instead of n). Temporal caching of indices so they’re not rebuilt every tick. Statistical sampling for crowd density at high population (estimate from a fixed-size sample instead of full scans).
So in practice it’s closer to O(n² / k), with k ≈ 16–50 depending on zone layout and population. You still see spikes during blooms, but it’s usually 10–30× faster than naive pairwise checks.
Could use quad trees, or similar bucketing. But I think he already stated that he tried to avoid the processing of long distance pairs. So probably he does some localized bucketing. Personally, I don't even fully understand what his simulation is doing. There are tradeoffs between accuracy / performance, depending on the specific problem. So hard to judge here.
Thanks for the feedback. There are some O(n²) components (mate finding, pathogen spread, proximity), but they’re mitigated with zone-based spatial hashing and throttling, so it’s not naive all-vs-all.
One big recent win was actually on the rendering side: I was rebuilding complex morphology geometry every frame for large organisms. I’ve added caching for that, which significantly reduced spikes during population blooms.
At very high populations the sim tick itself becomes the bottleneck, even for mostly O(n) logic per organism. When populations crash (which they usually do ecologically), performance recovers.
Quad trees / more adaptive structures are on my radar, but I’m trying to balance complexity vs predictability for now.
The battery pack contactor is one of the only, if not actually the only, moving pieces in a battery pack. A solenoid connects or disconnects the battery pack from the rest of the car's electronics. In this case, it seems to fail in the open state, meaning the battery was not able to power the car. Either there was simply a bad production batch of these particular solenoids or a change in supplier for this part.
Model Ys still have a separate, standard 12V battery that power many of the car's non-drivetrain related parts. So in this case, the battery pack contactor failing open would cause the car to lose the ability to drive, but the doors/windows/lights/screen would all still likely be working.
That's not correct; you can say sentences like "The only moving parts in a dishwasher are the two pumps, the sprayer arms, the water inlet valve, and the detergent dispenser"; or "there are only two hard problems in computer science". So "one of the only" sounds just fine to me.
you can say sentences like "The only moving parts in a dishwasher are the two pumps, the sprayer arms, the water inlet valve, and the detergent dispenser"; or "there are only two hard problems in computer science".
In the dishwasher example, "only" refers to "moving parts" which is a collective singular, like how "baseball team" is properly an "it," not a "they."
Same goes for the compsci example. By modifying the plural with adjectives, you narrow its scope.
It's definitely not a collective singular, you say "the moving parts are", not "the moving parts is"; and "there are hard problems", not "there is hard problems".
Either way, the usage in the original comment was exactly the same as the dishwasher example: "the only moving parts are X, Y, and Z" => "X is one of the only moving parts".
"8 is one of the only" is a little off because it doesn't have an object, it relies on that being implicit from the prior sentence. "Only" here is an adjective, not a noun. The usage is a little awkward.
It would be more correct to say "there are only 4 positive integers less than 10. 8 is one of them."
This is only true on the energy and transportation sides of emissions. Some processes like the creation of cement and refining of steel create CO2 through chemical processes, regardless of the energy source.
You don't necessarily need fossil fuels for steel production. It is also nothing impossible in capturing CO2 from cement making - it's mainly centralized production and much simpler problem than transportation.
You do need a carbon source for steel production. It’s integral to steel. You don’t need coal per se, but you do need to burn carbon. Every technique so far will release some CO2 as a waste result.
The steel industry is one of the largest emitters of CO2, contributing 6%–7% of global greenhouse gas emissions.
That said, there's a difference between sourcing that carbon from fossil fuels, carbon "new" to the current land|sea|atmosphere cycle having been drawn up from where it was sequestered millions of years past, and carbon that is already part of the surface dynamic.
Major steel players, those in the billion tonne per annum mining and processing chain, are already going hard at replacing current steel making with several alternatives and have already built pilot plants to trial low | zero "new carbon" production techniques.
The carbon needed for steel as an alloying element is a small fraction of the carbon needed for reduction of iron ore. The latter is replaceable with renewable energy (hydrogen or direct electrolytic reduction).
Also, note that 70% of steel production in the US isn't from ore at all, but is from scrap metal. Most of the steel used in renewable energy infrastructure will not be consumed, but will be recycled.
On the other hand, steelmaking also uses limestone as flux, to remove impurities from molten steel. When heated on the steel this drives off CO2. Calcium oxide could be used instead, but then that has to be sourced without CO2 emission, just as in cement manufacture.
I think there are at least two ways to make lime without CO2 emission. The first is normal limestone calcination, but with CO2 capture. The other is to use calcium silicate. This means dissolution of the silicate with hydrochloric acid, separation of silica, then high temperature reaction of calcium chloride with steam to produce lime and hydrogen chloride. I understand there's a company trying to commercialize this latter process.
You can eliminate the vast majority of emissions by using hydrogen. Then the waste will be water instead of CO2. This is no longer hypothetical. Pilot plants have been successful enough that at least SSAB is investing billions into hydrogen-based steel production.
Interestingly, I got substantially different results depending on whether I used chrome with my typical extensions or not. Looking at the flamegraph, I don't seem to see the full picture of why there's such a substantial difference. Bitwarden/React Developer tools (the 2 primary extensions I use) don't seem to make enough of an impact to account for the roughly 40% performance increase seen without them. The browserbench javascript accounted for ~38.6% of the overall time taken for the benchmark, but the sum of my extensions was only 6.5%. I'm not incredibly familiar with browser performance profiling, so there's probably more to the story.
I understand where that sentiment comes from, especially looking at the slew of mid-sized companies that have never turned a profit despite paying multiple hundred K TCs, but if you look at the profits of the giants, it paints a different picture. The labor of thousands of very highly compensated engineers is still a drop in the bucket of the revenue generated by their labor. Alphabet seemingly employs somewhere between 20-40 thousand engineers, and it is their labor that produced all (?) of their revenue generating products. Spreading last year's revenue (~$282B) across their engineering staff would yield a revenue in the ballpark of $9M per engineer.
We all know that their engineers are paid well, but that's still potentially more than an order of magnitude off of the value they generate. Of course, there are many other expenses to running their business, but to claim that broadly developers are overvalued when one of the most prolific employers of developers is generating 10x+ the revenue of what they spend on them, is likely no more than only occasionally correct.
That raises an interesting question. If developers are toiling equally hard at company A and company B, on similar products, but company A currently had a dominant market position over company B thanks to network effects - are the developers at company A in any way responsible for its outsize gains and therefore due millions of dollars in TC?
I don't think OP is being overly negative in relation to the tone of the rest of the comments here. Nobody else up until this comment had mentioned anything about the actual important performance characteristics that the paper's authors' are claiming, and this does put it into perspective with the current state of the art. And OP does even end on an optimistic note anyway. No need to resort to personal attacks.
Edit: I appreciate you toning down the more combative part of your comment.
I think the excitement around this is partially people overestimating the properties of this particular material, but also partially people excited that if this is true, the method by which it works might result in the discovery of materials with even better properties.
Even this paper doesn't claim to have a particularly good superconductor as far as overall performance is concerned. It's not particularly close to the state of the art in critical field or current. But if it does turn out that their hypothesis claiming that the internal stress of the material allows it to bypass the current need for extremely high pressures / low temperatures, then perhaps there can be new materials developed that are better superconductors while still overcoming the current limitations presented by REBCOs and other leading superconductors. Also, that's not even mentioning that LK-99 has no particularly exotic materials. REBCOs rely on rare earth elements like Yttrium, but this just uses lead, copper, and phosphorus.
Hey Billy, very small nitpick on your site: The "Mission Sets" nav button is broken on the Viceroy page, and it looks like it's just down to the href missing the correct target (# instead of #mission-sets).
Tiny bug aside, I hope you find success in this venture. I'm sure there'll be a lot of naysayers, but I find it inspiring that someone is actually trying to do something in the sustainable air travel space with technology we have today rather than putting all of their eggs in the basket of yet to be seen technology.
