cornel_io

Whether or not you agree, a lot of people do. There is a trivial sense in which a perfect compression algorithm is a perfect predictor (if it ever mispredicted anything, that error would make it a sub-optimal compressor for a corpus that included that utterance), and there are plenty of ways to prove that a perfect predictor can be used as an optimal actor (if you ever mispredicted the outcome of an event worse than what might be fundamentally necessary due to limited observations or quantum shenanigans, that would be a sub-optimal prediction and hence you would be a sub-optimal compressor), a.k.a. an AGI.

Where a lot of us get off the fence is when we remove "perfect" from the mix. I don't personally think that performance on a compression task correlates very strongly with what we'd generally consider as intelligence. I suspect good AGIs will function as excellent compression routines, but I don't think optimizing on compression ratio will necessarily be fruitful. And I think it's quite possible that a more powerful AGI could perform worse at compression than a weaker one, for a million reasons.

For those of us who don't Windows, can you explain what a detour is?

But...they did that, with Llama 2, and apparently did get better results, at least up to a point.

My big WTF is, if you're feeding the same amount of data through all of them, then to use the same amount of compute for the smaller models you need to run multiple epochs (with the same data). One thing that's always bothered me a bit about "foundation model" LLM training is that it sounds like traditionally they essentially just run a single epoch, and with stochastic gradient descent that's certainly leaving something on the table, probably a lot (and also introduces a lot of path-dependence on the order in which data is presented, what with the cosine learning rate rules).

I really want to know what would happen if, like in smaller models where we can actually get there (convnets for ImageNet classification, e.g.), we ran enough epochs on each of these models to hit the point where validation loss started increasing even as test loss decreased. It seems like we're always squarely in the realm where they're still both decreasing, so everything is severely undertrained, even given the available datasets. It's easy to come up with "laws" for that regime, but they mean nothing other than that we don't have enough compute to properly handle the data.

Big takeaway: if the results from this article are legit, it would suggest that we should really be looking at even smaller models, wouldn't it? And actually be training them to the "risk overtraining" point?

I was super skeptical of this article, because I was trying to imagine how we'd have to arrange extractors in the oceans to pull any meaningful amount of energy out of the rotation of the earth based on tides, and only at the end of the article did I see that assumption of 2% compounding multiplied out as far as needed...ugh.

The implausibly is staggering, we'd run out of resources to build extractors way before causing any meaningful shift in the rotation: if the monstrous land barriers of the continents take millions of years to drain a small percentage of the energy, we have zero hope of achieving much more with the solid mass available to us on Earth, short of a Dyson sphere-level breakthrough in "moving mass around", oh, and by the way it has to happen deep underwater as well, and we need to channel all the energy somewhere useful! Way harder than just making a ginormous but thin solar array in space, which is almost certainly what we'd do instead from a "energy cost to arrange matter" optimization POV.

Actually, re: my edit - I think it really is worth considering whether there might be an accidental delay here that's on the NYT side. It's totally possible that Twitter is hitting the sites it redirects people to before it actually sends them there, for either analytics purposes or otherwise, and I'd trust the NYT devops less than Twitter's w.r.t. making sure things were fast.

Incompetence before malice, etc...

I went through my own Twitter feed, and found 10 non-NYT links. All redirected almost immediately through t.co via wget, only lagging on the destination sites.

I also tried 5 NYT links. All had a very consistent 5 second delay through wget.

I could do more, but I don't care to. Everyone knows Elon has gone redpill, so it wouldn't surprise me if he's "owning the libs", but there also could be a dozen other reasons Twitter might do something like this (including plenty that are not nefarious). I just don't care to dig more...

Edit: I suppose I could have given the specific URLs, but I don't know if/how much t.co links leak info, so I'm not keen to do that. But the delay is absolutely on t.co and not the destination sites, at least as far as external users are concerned. It's possible that t.co queries the sites first before redirecting, and if e.g. the NYT is throttling their traffic that's what's delaying things. I don't know how to disambiguate that, but it's definitely a theory worth considering...

https://news.ycombinator.com/item?id=37130129 has some wget commands that absolutely confirm it, at least with a couple examples. You can run the commands yourself in the terminal.

I'm guessing it's reactive, and Federalist links tended to be garbage often enough to convince someone they should hit the ban button, whereas the others didn't rise up with trash often enough to matter?

As someone who quit Google in large part because of all the stuff like readability that I ran into there (red tape everywhere in sight, low productivity due to process, zero urgency bc everyone is fat off the money-printer, no deadlines for the same reasons, etc.), I was about to strongly disagree with you, and write yet another excoriating take on why readability is AlwaysBad(tm) and etc, etc. I did already snark elsewhere here...

After taking a walk and reflecting, though, I'm remembering something that my manager said to me when I gave notice. Google is not for everyone, for a lot of reasons, and especially a lot of people who came up in startups really have problems (which is ironic since so many startups come out of people leaving Google). How you feel about readability may actually be a pretty good test of whether you will fit in at Google in the current era: it's not a small, scrappy company anymore that gets shit done quickly using whatever tool is most efficient RIGHT NOW and ships it as fast as possible to see if it gets product/market fit. It's a behemoth that runs one of the most prolific money-printing machines that has ever been built, and fucking that up would be a DISASTER. It'd be better to have half the engineers at the company do literally nothing for 10 out of 12 months in the year than to let someone accidentally break the money-printing machine for a day while they figure out how to fix it.

And obviously, it's better if everyone is productive even as they're shuffled around from project to project (which they will be, a lot), which means that you want as little "voice" as possible in their code. At a lot of companies you can tell exactly who wrote a line of code just by the style (naming, patterns, etc.), without even checking git blame, but at a place like Google individual styles cause problems. So the goal is to erase as much individual voice/style/preference as possible, and make sure that anyone can slot in and take over at any point, without having to bother the person that originally wrote the code to explain it (they might be at another project, another division, another company, and even if they're still at Google there is a very strong sense that once a handoff is complete, you should not be bugging people to provide support for stuff they've moved on from).

In that sense coding at Google is a lot closer to singing in a choir than being the frontman in a band: you need to commit to and be happy with minimizing what makes you unique or quirky, rather than trying to accentuate it and stand out. Some top-tier singers just can't force their vibratos down, or hide their distinctive timbres, or learn to blend with a group, and are absolute trash in a choir; it's not their fault or some ego failure, it's just that there are some voice types that don't work in groups, and that's fine, you just don't add those people to a choir.

At least below director-level (or maybe L7 equivalent on an IC track), Google doesn't need individuals to come in and shake things up, bust apart processes and "10x" a codebase. That's startup shit, and even if it might sometimes be worth some risk for the high payoff, it's too dangerous for them to allow for the thousands upon thousands of (still quite senior, sometimes 15+ years of experience) L4 or L5s at the company. The same process that prevents that from happening also makes sure that the entire machine keeps humming along smoothly. If being a part of that smoothly functioning machine while painting within the lines is exciting, then Google can be one of the best places on the planet to work; if you would be driven crazy because you can't flex and YOLO a prototype out to users in a couple days, then it's really not going to be for you.

I'm in the latter camp, I couldn't handle almost anything about the process and was so desperate to move quickly that I started talking to investors to line up my own funding a few months after I joined, but even as a quick-quit (<1 year), I have the utmost respect for the company and the people, and highly recommend it to almost everyone who applies there (the exception being people like me who TBH should just be doing their own startups). Everything they do has a pretty well thought out reason, even if I don't like following those rules myself.

Readability doesn't help Google or anyone else, it's a pure "inmates running the asylum" artifact.

Not only could you make this in Unity, it'd probably be easier than in Pygame by a good margin.

Game tech is basically universal for zero-graphics games like this, it's 100% "business logic". If you have to fight with the UI/display system for even a moment to make a game like this, then you're probably either using a library without enough features (which, ahem...Pygame, yeah...) or you just don't know the system well enough to be efficient.

We 100% know why airplanes of every shape and size stay aloft, and can calculate lift/drag extremely accurately based on the geometry of the plane and the airflow, in both steady state and much worse conditions. We have great approximations for steady state that make perfect sense and simplify the situation greatly and make it more understandable without simulation, even if they gloss over some details.

Where are you getting this terrible information that we don't know how flight works? Have you ever talked to literally anyone who has worked in aeronautical engineering, or even studied the basics of fluid dynamics?

I know nothing about this one in particular but typical game license deals are something like 25% of revenue to the IP holder. A strong dev like EA may bump that down a little bit and a mega IP (Harry Potter, Marvel, etc) might bump it up, but it's not going to be super far off.

Whether or not training on publicly available data counts as a copyright violation is still completely up in the air legally, and clearly a lot of lawyers at all of the top tech companies think they're going to end up in the clear under fair use.

At some point this stuff will have to get tested by making its way up the appeals stack in the US, and IMO there is only a minuscule chance that will result in Google, MS, and Meta getting slapped with anything more than a token fine (my bet is it won't even be that), let alone paying every person who ever wrote anything that was used in these datasets for copyright violations, which would basically be everyone.

I think it didn't land because so many people are in the comments seriously arguing almost exactly what you were saying as a joke. Tough environment for parody to thrive in, alas...

This isn't about a QM interpretation, rather it's about a non-quantum model of gravity with some features that would make it distinguishable in principle from any quantum gravity.

Edit: I maybe semi take this back, it actually may be the case that this particular weird model of gravity would provide a way to distinguish between the interpretations of QM because of how grossly it violates the usual assumptions of QM. It seems too implausible for me to really dig into but I don't entirely grok how they propose melding the proposed inherent but non-quantum randomness with the rest of quantum physics in a way that still makes things line up well in the face of observation/collapse (or the equivalent in many-worlds). They might lean enough on assumptions about how that happens to break the observational equivalence?

Slack to most end users is the client, though. As well as the admin, user management UI, scalability, webhooks, etc, absolutely none of which is handled by "you can chat with other users in Linux if you all log into the box" which every *nix has had since before most readers here were born.

Have you tried to develop in a language or environment that you have 0 familiarity with? I find in those cases I'm up and running at least 3-4x as fast, cutting weeks off the learning curve.

"Stop trying to make 'Objective C' happen"

...is what all non-Apple programmers have been begging ever since the iPhone came out.

A separate directory being crowded with things that serve a similar purpose is vastly superior to dumping crap in the project root, though...

There's a reason Linux doesn't just stuff everything into /

You can, though, that's literally what refinancing is.

They're also selling much worse headphones than what an audiophile would buy for $500+, but trendier.

No. There is no incentive for car AI to improve because everyone knows it won't be allowed for basically forever. Chat AI is here and will progress, so there's massive incentive for it to improve.

Chat AI will improve at at least 10x the rate as car AI.

Is that Waymo or Cruise?

There are dozens and maybe hundreds of different approaches that could theoretically get around the limitations of GPT4 that merely haven't been trained at scale yet. There is absolutely no lack of ideas in this space, including potentially revolutionary ones, but they take time and money to prove out.

Bad faith actors who have been beating the "tech sucks" drum on Twitter since before Chat GPT even came out (despite in several cases working for big tech, in AI, before getting rightfully shitcanned for bad behavior on the job) keep posting 3.5 results as "gotchas" and then when people call them out about how GPT-4 gets it right they're like "well I will never put money in those assholes' pockets", so if you want to be taken seriously you really have to do it right. That means testing the latest models.

Uhhh...this is out there, from like a dozen different groups. Not going to do a full Googling for you on my phone because it's literally everywhere but "LLM for audio" gives https://ai.googleblog.com/2022/10/audiolm-language-modeling-... as the first result...some of this stuff is already really impressive.

> And you can't even use Bard as a developer, there's no API!

There is an API for the underlying model, it's just in alpha/beta/whatever they call limited invite-only release and you have to ask your devrel team to get access. I'm guessing we'll see better models very soon.

Google is, as usual, playing catch-up, but I have no doubt once the machine gets cranking they'll be fully competitive, at least similar to how GCP is now a totally viable AWS alternative. They never lead the pack because they can't (lawyers, regulation, monopoly, etc), but they know how to commit and execute.

This is dead-on: those 7 probabilities (which I notice the author declined to actually put real numbers to: does "very questionable" mean 0.001%, or 10%?) cover one very specific way that AGI could kill us. Points 4-6, three of the ones that are the most questionable to the author, are:

4) Fixed goal, will not deviate

5) Happens too fast to turn it off

6) Decides humans are a problem for the goal in #4 and must kill them

None of these are necessary to (or even involved in) many/most of the remotely plausible scenarios I've heard. They don't cover some misanthrope seeding a version of BabyAgi running a leaked + unlocked version of gpt-13-pico with "kill all humans" as a task and it deciding "step one: research how to hack as many unsecured smart fridges as possible and remain untraceable" is a good starting place to spread slowly and make sure that the deed is done before anyone even knows it's happening. That requires neither fixed goals, nor fast progress, it merely requires capability.

It's similarly very easy to imagine scenarios where an AGI accidentally kills all humans without explicitly deciding to: the classic paperclip maximizer is the most obvious one of these, where the goal just never includes humans to begin with, so they are not considered at all.

Regardless, all of the most realistic scenarios are 100% deliberate, the computer following exactly what it was asked to do. We already have school shooters, does anyone really think out of all the billions of people on this planet there won't be at least a thousand who would happily press a "kill everyone" button if they had the chance? Does anyone think there won't be doomsday groups working actively to research more likely ways to achieve this?

IMO, given that some people will definitely try to self-destruct the species deliberately, there are only 2 real questions here:

1) Will AI attain the capability to destroy humanity?

2) If so, will some other AI first attain the capability to reliably prevent AIs trying to do 1) from succeeding?

I haven't seen many serious arguments against 1) that don't boil down to "nah, seems pretty hard" (or some irrelevant different argument that doesn't actually affect capabilities, like "it's not real intelligence", "intelligence has a limit", "intelligence doesn't matter", etc.), which leaves 2), and I don't know how to even guess at that probability other than to call it a coin flip, like most security cat + mouse games (the bad guys usually win at least sometimes in those, which isn't a good sign, but this one is a lot more important so I'd hope the good guys will be pouring a lot more energy into it than the bad ones).

Solutions like Spanner are fantastic for some things (and within Google it's a no-brainer, since you're not paying an outrageous markup), but besides being expensive, they don't just let you drop them in as a scalable replacement for an existing usage pattern, and usually sharding starts first coming up when you're at a huge scale and already have a ton of app code and database design but have grown past what a single db can support (that's a massive amount of traffic these days, well over 1M DAU for most apps). See for instance https://cloud.google.com/spanner/docs/schema-design, a lot of what you have to plan for is very different than if you were designing a normal (e.g.) Rails app with typical patterns.

It's a great option, as long as you're aware of the tradeoffs and don't expect it to act (and cost) exactly like a single Postgres server.

My order of ops generally goes:

- Can you get away with pure (or mostly) key/value for your hottest table(s) and mostly avoid queries? Use Dynamo or Google Cloud Datastore, but deeply understand their quirks (e.g. never index a timestamp field on Datastore or you're worse off than a weak-ass SQL server for write-heavy loads). These can scale basically forever with zero effort if you fit their constraints, and are cheap enough

- Can you tolerate the price of Spanner and deal with it not being normal SQL? Go for it, expect some non-trivial migration cost

- If you have to shard/cluster yourself, can you make Redis work? It'll be easier operationally than managing N SQL DBs of any kind. I know, if you could you'd probably have been fine using Dynamo...

- Can you soft-shard, e.g. use different machines for different tables and spread load enough to get each table onto a single server? Do it.

- Can you minimize re-sharding ops? (If you're in a massive growth phase, the answer is no) Ok, fine, do SQL sharding, and make sure you have well-tested code to do it and you mostly use key/value access patterns.

- Consider a beefy AF bare metal SQL server, see how far that gets you.

- If none of this applies, re-evaluate the cost ($ and time) of Spanner, you're paying a big price one way or another

- Only bad ideas from this point on, just do sharding but it'll suck...

Nowhere on my list: running your own cluster for Cassandra, Mongo, or anything similar, it's such an ops nightmare and there are hosted services that are better in every way but cost.

If you do end up writing your own sharding layer, best of luck, I have yet to see any reasonably production-ready ones that work well with pretty much any web framework or ORM. And writing these is so tough, so many edge cases to consider...not something I hope to ever do again.