Most likely you're seeing the causality in the wrong direction - poverty creates a strong incentive to go for immediate benefits rather than absorb the risk of one that is delayed.
But that's why they're arguing that repricing the entire generation fleet is bad compared to having a different auction for new capacity. You don't need the same incentives to keep an existing, profitable plant online as you do to invest in a new plant.
I can assure you the spreadsheets at firms building plants factor in forecasts of revenue for the life of the plant into investment decisions. If they don’t pay past the first few years, that directly translates to lower forecast lifetime plant value for new plants.
I’m not a quant, and I’ve worked energy trading desks long enough to know there is a lot I don’t understand.. but I don’t see how separating auctions by plant age does anything other than move numbers around while keeping the total bill the same. Plants still need the same lifetime revenue to make investment decisions pencil out; whether you front-load payments or spread them evenly, the total in current value needs to be the same.
Even if the total cost is the same, if our payments better align with the behavior we want to incentivize, we may gain greater utility from the spending.
So it can matter how we distribute that revenue as to whether or not the business responds in the desired way, eg, actually investing in new capacity by linking payments directly to new capacity.
Facebook runs a number of quite complex internal distributed systems - databases, caches, proxies, etc. all of these are amenable to various forms of formal verification, and verifying them is the kind of thing that helps prevent outages and data loss.
Your second two had high comments to upvotes, which tends to get articles downranked more quickly. It may simply be that the stuff you're posting is generating disagreement without corresponding upvotes.
The LLM doesn't "know" anything, can't reason about its own knowledge, and has no self-awareness. It has training data, and it can use your prompts to synthesize that training data into probable continuations or responses.
If the training data doesn't include lots of text of people being asked questions and saying "I don't know", then it's unlikely to respond "I don't know" when prompted, regardless of whether anything in its training data that might actually answer your question.
> If the training data doesn't include lots of text of people being asked questions and saying "I don't know", then it's unlikely to respond "I don't know"
There's a problem with your reasoning. The above applies to a foundational model (that is to an autoregressively pretrained model). If the training data doesn't contain "I don't know" in a dialogue context, then, indeed, the model is extremely unlikely to output "I don't know" when asked. That's the nature of autoregressive training.
But we are dealing with fine-tuned, RLHF-, intruction-, RL-trained models. If the model has "grasped" a concept of knowledge, this concept can be elicited during the mentioned training.
Did you just make up in your head how LLMs work and then just run with it? There are a zillion explainers out there, at least put in some time before talking about it.
Humans run on training data too in the same broad sense.
Oh, that's interesting - good point, since it's filtered and not trained from scratch. My prior would be to assume it's just bs'ing as LLMs usually do but it seems worth exploring.
"I don't know" isn't in the training data. Nobody writes engineering books, science papers and blog posts that end with "well, I don't really know, the end".
I do a lot of testing and designing of things like hash tables and filters, and having a really fast, non-CS generator is incredibly useful for being able to clearly identify performance bottlenecks in designs. PCG has been spectacularly useful for that purpose for me.
When was the last time a new PRNG helped you clearly identify a performance bottleneck?
As in, you were using state of the art generator X, and you couldn't see the performance bottleneck, but updating to a newer (faster, or same speed but higher quality) generator Y, and could subsequently identify the performance bottleneck?
If you're using PCG, not in the last 12 years.
(In a parallel comment I suggest trying AES-CTR for this use case)
It's not critical but if you gave me something that behaved statistically like PCG (i.e., I didn't fret about whether it was going to cause me weird problems) but was twice as fast I'd be happy and would shift to it - it would speed up profiling and measuring and that would be nice. We still find ourselves often pre-generating a list into memory to keep the prng entirely off of the measurement path. It wouldn't be magic, but I don't need magic. I like nice things that make my life a little easier in a small corner of my research. :)
Most modern RNGs should be faster than memory bandwidth (when optimized), so unless your list is small enough to fit in cache, its unclear if this is faster?
dgacmu: if you're writing C on x64, try AES-128-CTR (AES-NI, 8 way) using the header wmmintrin.h which has hardware accelerated primitives for this. An LLM can implement the RNG for you based on this comment if you want to test it out quickly. It should be faster than PCG, and higher quality.
Will do. I'm on vacation right now and losing my laptop for a few days, but seems worth trying. My recollection from the RNGs a decade ago (I'm dating myself) was that the AES approaches had higher latency but were quite decent, though slower than PCG. Curious how that's evolved.
> When was the last time a new PRNG helped you clearly identify a performance bottleneck?
While not a bottleneck as such, I contributed to a photorealistic path tracer using the Metropolis algorithm[1], and we got a 10-15% increase in samples/second when we switched from a decent to a much faster and better PRNG. Like you we didn't think the performance of it mattered much until we profiled it.
Granted this was a decade or so ago, would be interesting to compare the state of the art PRNGs.
Anyway, just pointing out that there can be real-world cases.
In photos after you can toggle between the AI modified and original. The original isn't as blurry as the preview shown - there's still a lot of image stacking happening and it's often very decent in my experience.
Edited to add: I have a pixel 10 pro which has a better zoom lens, so I could be having a different experience than you...
There's been a lot of fun, practical work recently on optimal join algorithms! (Full disclosure, this advisor on this paper is one of Andy and my former students, so I'm slightly biased)
Like most academic work, this one builds on some work that's been done over the last few years on ways to make the Yannakakis algorithm actually practical.
