That is dependent upon the quality of the AI. The argument is not about the quality of the components but the method used.
It's trivial to say using an inadequate tool will have an inadequate result.
It's only an interesting claim to make if you are saying that there is no obtainable quality of the tool that can produce an adequate result (In this argument, the adequate result in question is a developer with an understanding of what they produce)
I especially love the quadratic fit, chosen with no justification, that brings the US within the uncertainty envelope in the second plot. Also notice how much work the Mexico and USA data points are doing to the previous linear model fit. Oh, my high leverage data point can't be an outlier because it's within uncertainty when I fit the data with the potential outlier included. This is basic linear model validation stuff.
> Has a hard to explain fixation on doing things a certain way, e.g. always wants to use panics on errors (panic!, unreachable!, .expect etc) or wants to do type erasure with Box<dyn Any> as if that was the most idiomatic and desirable way of doing things
Yes! I see this constantly. I have a Rust guide that Claude adheres to maybe 50% of the time. It also loves to allocate despite my guide having a whole section about different ways to avoid allocations.
Two use-cases recently where Claude sucked for me:
1. Performance-critical code to featurize byte slices for use in a ML model. Claude kept trying to take multiple passes over the slice when the featurization can obviously be done in one. After I finally got it to do the featurization in one pass it was double-counting some bytes but not others (double counting all of them would have been fine since the feature vector gets normalized). Overall it was just very frustrating because this should have been straight-forward and instead it was dogshit.
2. Performance-critical code that iterates over lines of text and possibly applies transformations, similar to sed. Claude kept trying to allocate new Strings inside of the hot-loop for lines that were not transformed. When I told it to use Cow<'a, str> instead so that the untransformed lines, which make up the majority of processed lines, would not need a new allocation, Claude completely fucked up the named lifetimes. Importantly, my CLAUDE.md already tells Claude to use copy-on-write types to reduce allocations whenever possible. The agent just ignored it, which is _the_ issue with LLMs: they're non-deterministic and any guidance you provide is ultimately just a suggestion.
It's not just assuming that everyone learns the same way. It's assuming that everyone learns the way that all of the research literature on learning claims does not work.
Learning requires active recall/synthesis. Looking at solved examples instead of working them yourself does not suffice in math, physics, chemistry, or CS, but somehow it is supposed to work in this situation?
Machine learning people use "tensor" to just mean an N-dimensional array of numbers. The term is divorced from its meaning in Physics and Mathematics, which caused me some confusion when I started looked at machine learning papers coming from physics.
But the energy transported to Earth from your space power plant still creates waste heat when it is used to do work (and also when it is transported to earth). You cannot beat the second law.
They don't even decouple at high material standards of living. Recent increases to GDP produced emissions too but those new emissions were offset by reductions in emissions of existing industries.
This "decoupling" gets us basically nothing because it's not like we can just stop emissions tomorrow since GDP and emissions are "decoupled".
Counter example: if we can make computation 1000x more efficient per teraflop, we could use computers to trivially design drugs to cure cancer etc (just a random example) and yet our energy consumption would not change. GDP may be the wrong measure, but there would be economic growth or standard of living growth for no change in energy consumption.
An Apple Watch has more processing power than a Cray 2, but it uses a rechargeable battery instead of a 150kW power supply.
The problem is that cycles expand to fill the space available, so another 1000X drop in efficiency would mean new kinds of applications rather than being limited to affordable super computing.
While individual computers are far more powerful and use far less energy, the power consumed by computing on Earth as a whole is far higher than it was. (Not even counting energy vampires like crypto.)
There's no reason to assume that trend would stop. Displays could easily have much higher resolutions (possibly holographic), IOT could be truly ubiquitous, AI could be in everything, entertainment could be social, interactive, and immersive, and so on.
> if we can make computation 1000x more efficient per teraflop, we could use computers yo trivially design new drugs to cure cancer etc
You're assuming two things: that cancer and disease can be cured by any feasible increase in computing power (not that outrageous an assumption), and that the energy savings won't be offset by keeping an even older population of disease survivors comfortable and alive. Reality is not as simple as "cure all our ailments and we're good to go".
How does UDP work if you're also using delta compression? I would naively expect that the accumulation of lost diff packets over time would cause game state drift among the clients.
The simplest way I've done it: say client and server start on tick 1, and that's also the last acknowledgement from the client that the server knows about. So it sends a diff from 1 to 2, 1 to 3, 1 to 4, until server gets an ack for tick 3, for example. Then server sends diffs from 3 to 5, 3 to 6, etc. The idea is that the diffs are idempotent and will take the client to the latest state, as long as we can trust the last ack value. So if it's a diff from 3 to 6, the client could apply that diff in tick 3, 4, 5 or 6, and the final result would be the same.
This is done for state that should be reliably transmitted and consistent. For stuff that doesn't matter as much if they get lost (explosion effects, or what not), then they're usually included in that packet but not retransmitted or accounted for once it goes out.
This is different (and a lot more efficient) than sending the last N updates in each packet.
> The idea is that the diffs are idempotent and will take the client to the latest state, as long as we can trust the last ack value. So if it's a diff from 3 to 6, the client could apply that diff in tick 3, 4, 5 or 6, and the final result would be the same.
Can you elaborate or give an example of how this works?
1: x = 1
2: x = 2
3: x = 3, y = 5
4: x = 4
5: x = 5
6: x = 6
7: x = 7, y = 1
Diff from 2 to 4 would be "x = 4, y = 5".
Diff from 3 to 6 is "x = 6", which will always be correct to apply as long as client is already on ticks 3~6. But if you apply at tick 2, you lose that "y = 5" part. This can't happen in a bug-free code because the server will only send diffs from the latest ticks it knows for sure the client has (because the client sends acks)
Cool thanks, that makes sense! In my head I was thinking the diff from 2 to 4 would be something like "x += 2, y += 5", and 3 to 6 would be "x += 3, y += 0"... which of course wouldn't be idempotent and wouldn't allow you to apply the update to different client states.
And with special rules such that if `active = false`, no other properties of the entity needs to be encoded. And if `active = true` is decoded, it sets all properties to their default value. Then you get a fairly simple way to transmit an entity system. Of course you'd want to encode these properties in a much smarter way for efficiency. But the basic idea is there
If you get your data small enough to fit multiple updates into a single packet, you can send the last N updates in each packet.
If your updates are bigger; you probably will end up with seqs, acks and retransmitting of some sort, but you may be able to do better than sending a duplicate of the missed packet.
Exactly, you assign a sequence number to each update, have the client send acks to convey which packets it has received, and the server holds onto and sends each unacked update in the packet to clients (this is an improvement over blindly sending N updates each time, you don't want to send updates that you know the client has already received).
If the client misses too many frames the server can send it a snapshot (that way the server can hold a bounded number of old updates in memory).
It's close but TCP will retransmit frames rather than packing multiple updates in a single frame.
It's common for people to build this kind of retransmission logic on top of UDP (especially for networked games), it's sometimes referred to as "reliable UDP".
You don’t delta compress everything, only a significant part of the payload. Each diff is referential to a previous packet with a unique id. If you don’t have the previous packet, you just ignore the update.
Every 30 frames or so, you send a key frame packet that is uncompressed so that all clients have a consistent perspective of world state if they fell behind.
Using sentTime lets clients ignore old data and interpolate to catch up if behind as well.
It does work, I wrote one from scratch to create a multiplayer space rpg and the bandwidth savings were incredible.
reply