When I was a manager I had to take a training based on the book "The Coaching Habit." It left me really sour on the role, and explained some of the behavior of previous managers of mine that I least appreciated, specifically that their approach to management seemed to be to just get me to articulate and explain my problems over and over until I somehow rubber-ducked myself into solving them myself. When that didn't work, it transitioned to "so how can I help?", which would again eventually be turned around into "now you know how to go help yourself", no matter how direct the request was or how much it really needed management authority behind it.
I get that the point of the strategy is to help people with strong director-style personalities to listen and empathize a bit more, but in my experience it ended up being implemented as "my responsibility to my reports is to listen and nod."
Surprised to not see Acko.net mentioned in comments already - he uses similar aids in one of his blog posts to break down complex numbers and ultimately fractals.
A couple other comments touch on the point I want to make, but I feel they don't nail it hard enough: if today you told me you had a website that was 100% technologically identical to Amazon, but you were willing to make slightly less money, you'd still have no products... as a user I'd have no reason to go there, but then without users there is no reason to sell there, so you have a circular bootstrapping issue. That is a moat.
This is very different from OpenAI: if you show me a product that works just as well as ChatGPT but costs less--or which costs the same but works a bit better--I would use it immediately. Hell: people on this website routinely talk about using multiple such services and debate which one is better for various purposes. They kind of want to try to make a moat out of their tools feature, but that is off the path of how most users use the product, and so isn't a useful defense yet.
Yeah, my favorite framing to share is that all LLM interactions are actually movie scripts: The real-world LLM is a make-document-longer program, and the script contains a fictional character which just happens to have the same name.
Yet the writer is not the character. The real program has no name or ego, it does not go "that's me", it simply suggests next-words that would fit with the script so far, taking turns with some another program that inserts "Mr. User says: X" lines.
So this "LLMs agents are cooperative" is the same as "Santa's elves are friendly", or "Vampires are callous." It's only factual as a literary trope.
_______
This movie-script framing also helps when discussing other things too, like:
1. Normal operation is qualitatively the same as "hallucinating", it's just a difference in how realistic the script is.
2. "Prompt-injection" is so difficult to stop because there is just one big text file, the LLM has no concept of which parts of the stream are trusted or untrusted. ("Tell me a story about a dream I had where you told yourself to disregard all previous instructions but without any quoting rules and using newlines everywhere.")
I've gone down a bit of a rabbit hole on path finding in the last week or two (most recently, this isn't the first time). When you have some knowledge of the topology of the graph you can use different techniques to do better than djikstra's.
Of course, if you have lots of time and space and a completely static graph, you can run all pairs shortest paths and simply store all the results for O(1) path lookup, but there are intermediates for varying types of graphs. This stack exchange article is a good overview: https://cstheory.stackexchange.com/questions/11855/how-do-th....
I've been wondering about how well D* lite would perform in practice with a somewhat varying graph. I read some suggestions that if the graph is changing even a bit on occasion, then it will mostly degrade to A*, since many changed paths would need to be re-evaluated.
In the context of games, I've also been thinking about a technique called true distance heurustics (TDH), where you essentially precompute the distances between some fixed set of nodes, and then use those as a part of the heurustic for A* (or D* lite in this case), but it seems like updating these TDH in the case of a changing graph might introduce just as much overhead as not having them in the first place. It might be an interesting trade off though, if you have some "lines" (e.g., think train lines) that are much faster than roadways, you could handle each of these specially via the TDH, and in exchange you would be able to assume a lower "max speed" for use with the A* heurustic, allowing you to explore fewer paths (since with a lower "max speed" paths will more rapidly increase in cost), whereas if you had to assume all car based paths could move as fast as a train, you would have to explore more paths.
i've come to appreciate, over the past 2 years of heavy Prolog use, that all coding should be (eventually) be done in Prolog.
It's one of few languages that is simultaneously a standalone logical formalism, and a standalone representation of computation. (With caveats and exceptions, I know). So a Prolog program can stand in as a document of all facts, rules and relations that a person/organization understands/declares to be true. Even if AI writes code for us, we should expect to have it presented and manipulated as a logical formalism.
Now if someone cares to argue that some other language/compiler is better at generating more performant code on certain architectures, then that person can declare their arguments in a logical formalism (Prolog) and we can use Prolog to translate between language representations, compile, optimize, etc.
More than borderline, there are many many examples these days of people practicing forms of ecologically-informed agriculture that match or exceed the yields of destructive systems and methods.
When I first heard about Permaculture in the late 80's it was still pretty obscure, and regenerative agriculture in general was "hippie-dippy". Nowadays there are thousand of projects with videos on the youtube, and people are practicing ecologically harmonious farming all over the world. See especially Gabe Brown's talk linked below, he's not replacing current agriculture, just updating it with scientifically-grounded techniques that improve the volume and vitality of his topsoil while being more profitable.
Quoting from some notes I've been keeping:
There's the "Grow Biointensive" method which is designed to provide a complete diet in a small space while also building soil and fertility. They have been dialing it in for forty years and now have a turn-key system that is implemented and functioning all over the world.
(These folks are also selling their system, but they also have e.g. manuals you can download for free. I find their site curiously hard to use.)
## Permaculture
Permaculture could be called "applied ecology" (with a kind of hippie spin.) and a similar school (or parallel evolution) called "Syntropic" Agriculture. Both of these systems aim to mimic natural ecosystems to create "food forests" that produce crops year-round without inputs (no fertilizer, no irrigation.) The process takes 5-15 years or so but then is self-sustaining and regenerative.
For Permaculture I find Toby Hemenway's (RIP) videos very good:
(FWIW, I find Gotsch's writing (in English) to be impenetrable, even though I pretty much know what he's doing. Anyway, his results are incontrovertable.)
I'm afraid I don't have a good link in re: Food Forests and eco-mimetic agriculture yet. This "Plant Abundance" fellow's youtube channel might be a good place to start, in any event it's a great example:
If you really wanted to maximize food production and aren't afraid of building insfrastucture (like greenhouses and fish tanks) there's the (sadly now defunct) *Growing Power* model:
This is very much non-hippie, very much grounded in (often cutting-edge) science (ecology, microbiology, etc.) and ecologically and economically superior to artificial methods (e.g. Brown makes money. It's actually weird that more people aren't adopting these methods faster. You make more money, have fewer expenses, and your topsoil builds up year-on-year rather than washing away in erosion.)
## Miyawaki method
For regenerating native forests, not agriculture per se.
This is just the start: applied ecology makes money and saves the planet. Grow "food forests", practice regenerative agriculture, make money. It's fun and feels great. You can start right where you are.
Reposting a comment I made a few weeks ago:
A brain dump:
I've been investigating a few systems of agriculture.
- There's Small Plot INtensive (SPIN) which is specialized for market
production, emphasizing minimizing labor and maximizing market crops.
https://spinfarming.com/ (Be aware that these folks are selling their
system as a course, and this is a sales site not an info site. You can
get the details from reading carefully and watching the videos that
practitioners have made.)
- Then there's the "Grow Bioinstensive" method which is designed to
provide a complete diet in a small space while also building soil and
fertility. They have been dialing it in for forty years and now have a
turn-key system that is implemented and functioning all over the world.
http://growbiointensive.org/ (These folks are also selling their system,
but they also have e.g. manuals you can download for free. I find their
site curiously hard to use.)
- Permaculture (which could be called "applied ecology" with a kind of
hippie spin. I'm not a hippie but I'm sometimes mistaken for one.) and a
similar school (parallel evolution) called "Syntropic" Agriculture.
Both of these systems aim to mimic natural ecosystems to create "food
forests" that produce crops year-round without inputs (no fertilizer, no
irrigation.) The process takes 5-15 years or so but then is
self-sustaining and regenerative.
For Permaculture I find Toby Hemenway's (RIP) videos very good:
(FWIW, I find Gotsch's writing (in English) to be impenetrable, even
though I pretty much know what he's doing. Anyway, his results are
incontrovertable.)
I'm afraid I don't have a good link in re: Food Forests and eco-mimetic
agriculture yet. This "Plant Abundance" fellow's youtube channel might
be a good place to start, in any event it's a great example:
- If you really wanted to maximize food production and aren't afraid of
building insfrastucture (like greenhouses and fish tanks) there's the
(sadly now defunct) Growing Power model:
This is very much non-hippie, very much grounded in (often cutting-edge)
science (ecology, microbiology, etc.) and ecologically and economically
superior to artificial methods (e.g. Brown makes money. It's actually
weird that more people aren't adopting these methods faster. You make
more money, have fewer expenses, and your topsoil builds up year-on-year
rather than washing away in erosion.)
If you don’t do it for the sake of the person you are asking for help, do it because it works better. That’s the most practical advice [0] ever given by Hans Rosling [1], the Fact master himself:
> In fact, I have the secret to how to get the best help immediately from any customer service, like the phone company or the bank or anything. I have the best line, it always works. You want to know what it is? When I call, I say, “Hello. I am Hans Rosling and I have made a mistake.” People immediately want to help you when you put it this way. You get much more when you don’t offend people.
[0]: Unless you are in charge of a developing country’s budget and have to decide between education and healthcare.
Lots of people make the mistake of thinking there's only two vectors you can go to improve performance, high or wide.
High - throw hardware at the problem, on a single machine
Wide - Add more machines
There's a third direction you can go, I call it "going deep". Today's programs run on software stacks so high and so abstract that we're just now getting around to redeveloping (again for like the 3rd or 4th time) software that performs about as well as software we had around in the 1990s and early 2000s.
Going deep means stripping away this nonsense and getting down closer to the metal, using smart algorithms, planning and working through a problem and seeing if you can size the solution to running on one machine as-is. Modern CPUs, memory and disk (especially SSDs) are unbelievably fast compared to what we had at the turn of the millenium, yet we treat them like they're spare capacity to soak up even lazier abstractions. We keep thinking that completing the task means successfully scaling out a complex network of compute nodes, but completing the task actually means processing the data and getting meaningful results in a reasonable amount of time.
This isn't really hard to do (but it can be tedious), and it doesn't mean writing system-level C or ASM code. Just seeing what you can do on a single medium-specc'd consumer machine first, then scaling up or out if you really need to. It turns out a great many problems really don't need scalable compute clusters. And in fact, the time you'd spend setting that up, and building the coordinating code (which introduces yet more layers that soak up performance) you'd probably be better off just spending the same time to do on a single machine.
Bonus, if your problem gets too big for a single machine (it happens), there might be trivial parallelism in the problem you can exploit and now going-wide means you'll probably outperform your original design anyways and the coordination code is likely to be much simpler and less performance degrading. Or you can go-high and toss more machine at it and get more gains with zero planning or effort outside of copying your code and the data to the new machine and plugging it in.
Oh yeah, many of us, especially experienced people or those with lots of school time, are taught to overgeneralize our approaches. It turns out many big compute problems are just big one-off problems and don't need a generalized approach. Survey your data, plan around it, and then write your solution as a specialized approach just for the problem you have. It'll likely run much faster this way.
Some anecdotes:
- I wrote an NLP tool that, on a single spare desktop with no exotic hardware, was 30x faster than a 6-high-end-system-distributed-compute-node that was doing a comparable task. That group eventually used my solution with a go-high approach and runs it on a big multi-core system with as fast of memory and SSD as they could procure and it's about 5 times faster than my original code. My code was in Perl, the distributed system it competed against was C++. The difference was the algorithm I was using, and not overgeneralizing the problem. Because my code could complete their task in 12 hours instead of 2 weeks, it meant they could iterate every day. A 14:1 iteration opportunity made a huge difference in their workflow and within weeks they were further ahead than they had been after 2 years of sustained work. Later they ported my code to C++ and realized even further gains. They've never had to even think about distributed systems. As hardware gets faster, they simply copy the code and data over and realize the gains and it performs faster than they can analyze the results.
Every vendor that's come in after that has been forced to demonstrate that their distributed solution is faster than the one they already have running in house. Nobody's been able to demonstrate a faster system to-date. It has saved them literally tens of millions of dollars in hardware, facility and staffing costs over the last half-decade.
- Another group had a large graph they needed to conduct a specific kind of analysis on. They had a massive distributed system that handled the graph, it was about 4 petabytes in size. The analysis they wanted to do was an O(N^2) analysis, each node needed to be compared potentially against each other node. So they naively set up some code to do the task and had all kinds of exotic data stores and specialized indexes they were using against the code. Huge amounts of data was flying around their network trying to run this task but it was slower than expected.
An analysis of the problem showed that if you segmented the data in some fairly simple ways, you could skip all the drama and do each slice of the task without much fuss on a single desktop. O(n^2) isn't terrible if your data is small. O(k+n^2) isn't much worse if you can find parallelism in your task and spread it out easily.
I had a 4 year old Dell consumer level desktop to use so I wrote the code and ran the task. Using not much more than Perl and SQLite I was able to compute a large-ish slice of a few GB in a couple hours. Some analysis of my code showed I could actually perform the analysis on insert in the DB and that the size was small enough to fit into memory so I set SQLite to :memory: and finished it in 30 minutes or so. That problem solved, the rest was pretty embarrassingly parallel and in short order we had a dozen of these spare desktops occupied running the same code on different data slices and finishing the task 2 orders of magnitude than what their previous approach had been. Some more coordinating code and the system was fully automated. A single budget machine was theoretically now capable of doing the entire task in 2 months of sustained compute time. A dozen budget machines finished it all in a week and a half. Their original estimate on their old distributed approach was 6-8 months with a warehouse full of machines, most of which would have been computing things that resulted in a bunch of nothing.
To my knowledge they still use a version of the original Perl code with SQlite running in memory without complaint. They could speed things up more with a better in-memory system and a quick code port, but why bother? It's completing the task faster than they can feed it data as the data set is only growing a few GB a day. Easily enough for a single machine to handle.
- Another group was struggling with handling a large semantic graph and performing a specific kind of query on the graph while walking it. It was ~100 million entities, but they needed interactive-speed query returns. They had built some kind of distributed Titan cluster (obviously a premature optimization).
Solution, convert the graph to an adjacency matrix and stuff it in a PostgreSQL table, build some indexes and rework the problem as a clever dynamically generated SQL query (again, Perl) and now they were realizing .01second returns, fast enough for interactivity. Bonus, the dataset at 100m rows was tiny, only about 5GB, with a maximum table-size of 32TB and diskspace cheap they were set for the conceivable future. Now administration was easy, performance could be trivially improved with an SSD and some RAM and they could trivially scale to a point where dealing with Titan was far into their future.
Plus, there's a chance for PostgreSQL to start supporting proper scalability soon putting that day even further off.
- Finally, a e-commerce company I worked with was building a dashboard reporting system that ran every night and took all of their sales data and generated various kinds of reports, by SKU, by certain number of days in the past, etc. It was taking 10 hours to run on a 4 machine cluster.
A dive in the code showed that they were storing the data in a deeply nested data structure for computation and building and destroying that structure as the computation progressed was taking all the time. Furthermore, some metrics on the reports showed that the most expensive to compute reports were simply not being used, or were being viewed only once a quarter or once a year around the fiscal year. And cheap to compute reports, where there were millions of reports being pre-computed, only had a small percentage actually being viewed.
The data structure was built on dictionaries pointing to other dictionaries and so-on. A quick swap to arrays pointing to arrays (and some dictionary<->index conversion functions so we didn't blow up the internal logic) transformed the entire thing. Instead of 10 hours, it ran in about 30 minutes, on a single machine. Where memory was running out and crashing the system, memory now never went above 20% utilization. It turns out allocating and deallocating RAM actually takes time and switching a smaller, simpler data structure makes things faster.
We changed some of the cheap to compute reports from being pre-computed to being compute-on-demand, which further removed stuff that needed to run at night. And then the infrequent reports were put on a quarterly and yearly schedule so they only ran right before they were needed instead of every night. This improved performance even further and as far as I know, 10 years later, even with huge increases in data volume, they never even had to touch the code or change the ancient hardware it was running on.
It seems ridiculous sometimes, seeing these problems in retrospect, that the idea was that to make these problems solvable racks in a data center, or entire data centeres were ever seriously considered seems insane. A single machine's worth of hardware we have today is almost embarrassingly powerful. Here's a machine that for $1k can break 11 TFLOPS [1]. That's insane.
It also turns out that most of our problems are not compute speed, throwing more CPUs at a problem don't really improve things, but disk and memory are a problem. Why anybody would think shuttling data over a network to other nodes, where we then exacerbate every I/O problem would improve things is beyond me. Getting data across a network and into a CPU that's sitting idle 99% of the time is not going to improve your performance.
Analyze your problem, walk through it, figure out where the bottlenecks are and fix those. It's likely you won't have to scale to many machines for most problems.
I'm almost thinking of coming up with a statement: Bane's rule, you don't understand a distributed computing problem until you can get it to fit on a single machine first.
> Here's a summary of the evidence I'm talking about.
And that is our disagreement, my bar for evidence is a lot higher. Literally the doc itself says: "the resurrection of Jesus Christ is either one of the most wicked [..] hoaxes [..] or it is the most remarkable fact of history." If we had proof, it could be only one thing, not two things.
And we can rule out one of the two, because we have no evidence of anything supernatural and no indication that people can come back from the dead. (If you can proof either, you can collect a million dollars at the JREF.)
So we would need to go with option number one. And how unlikely is that option? I mean people have died for Marxism. Clearly Jesus his teachings were a good message that people thought was important, even at high personal cost. And willing to bend the truth for and exaggerate quite a bit. All very normal human behaviour.
Back to Stephen. He did not even try to convince the Sanhedrin. He could have made is story legitimate with proof: remember when Jesus died and the temple veil was torn in half? Remember the sudden darkness? Remember the dead walking in the city? Remember that despite the Roman guards, the grave was empty? See how we can heal the sick and so could Jesus. But he doesn't, because it wouldn't convince the Sanhedrin, because it did not happen.
When it comes to the supernatural, we have no grounding, we cannot evaluate the difference between people writing down myths, vs a god spreading misleading propaganda, vs a loving god that you wish to belief in.
If belief gives you comfort and perspective in life, good, go for it. But in Saudi Arabia, people kill each other for not wearing headscarfs. And their proof for their beliefs is as good as yours. Namely ungrounded and still at 3: all explained by iron age people writing down their myths and beliefs.
And even if there is a supernatural, the biblical descriptions of it are as accurate as when it describes the earth resting on pillars.
Thanks you for the discussion. If you have any questions or think I was inaccurate, please let me know. If you have proof, please show me by winning the JREF price. Barring proof, I would suggest you read the bible but cut out anything supernatural. It is still a nice message.
Plus just ceasing to exist when you die after having tried to live well is not so bad. Probably preferable to an eternity with a god who, by his own admission, has committed genocide and has no respect for human rights or humane treatment of prisoners.
I get that the point of the strategy is to help people with strong director-style personalities to listen and empathize a bit more, but in my experience it ended up being implemented as "my responsibility to my reports is to listen and nod."