Even publications, semianalysis is the only major, decent one in my experience (excluding personal blogs).

Everything is low SNR for AI - have you seen ICML/ICLR/NeurIPS recently?? There is almost no point even going except for meeting people which we do by scheduling talks back and forth every few months anyways.

I also find IRL, then a carefully curated twitter timeline with the politics toggle on the settings page set to off, are the only ways to get high SNR information about AI.

I also feel it's topic-based. On general systems engineering, think databases, OS, architecture, webtech, the SNR on this site is generally amazing. But these days those articles are fewer than before. For example, 2 years back when every other article was about sqlite and postgres, while it was a very unidimensional few months, you could learn a lot from here.

Sad that the one language that managed to occupy that nice spot in language design space for an extended period of time, isn't doing so anymore.

Of course, you can actively restrict yourself to standard go, but not needing to do that was the whole point.

/pull/:id/changes is not working, but /pull/:id.diff _is_. It seems parts of the API is also ok? some gh commands I tried worked.

Files changed works on the mobile app somehow. I guess a particular api version or something is down.

Anyway if someone needs files changed and merge status, check the mobile app. Past actions are also loading on that.

[Android, India]

Good luck explaining that one

If you liked 3B1B's style, you will prefer strang over axler. Axler and treil to a greater extent focus on bringing out the abstract elegance and the kind of rigour a math major enjoys. Strang's book also has videos accompanying - on MIT OCW.

B&V VMLS on your list is interesting - they focus a lot on real-world instantiations of the concepts and have you code up things in the (excellent) exercises. Depending on your goals, you can do only this, or strang and then this. Definitely look at the exercises in any case though.

The nature of the ecosystem also means that pricing is closely tied to "procurement" which could be routing, limits, whatever at a company level.

If stripe wants to be _the_ one that charges that fee, they either have to continuously try to ensure that all the different middlenen use stripe (most of them do!) but even better is to acquire the largest middleman.

You don't want someone else who happens to do all the routing+limits+policies, end up not using stripe. They already have this hold in existing stripe financial products where they apply all the policies, and everything goes through them.

It is also an easy deal from an investor point of view.

echo -n "sk-proj-12345..." | systemd-creds encrypt --with-key=tpm2 --name=openai_key - openai.cred

And then at runtime export OPENAI_API_KEY=$(sudo systemd-creds decrypt openai.cred)

Comments URL: https://news.ycombinator.com/item?id=49317760

Points: 243

# Comments: 208

As for moving to this versus your bespoke feature extractor, _given_ that your existing features and their compositions are not antithetical to their language representation, an LLM will be an equal or better feature extractor. But for example, considering the basic feature genre, if your collaborative filter has learnt features that smartly recommending a show with one text feature "sci-fi" to people whose preferences have the text feature "comedy" because of learned behaviour despite the text, then you have to verbalise this feature "scifi,laugh track" or maybe providing samples of the subtitles of the show or add a "frequently co-watched with" section (which contains comedy shows) to the prompt, to effectively get an LLM to do the same thing (or many other ways to induce a hybrid embedding)

In many cases, people have almost entirely verbalizable features and feature compositions in their existing systems even if it may not exactly be optimal. So it's a good idea to try out LLMs there.

Composition mentioned everywhere above is crucial. Provided you can verbalise your important features, LLMs can perform very strong deductions and compositions out of the box above and beyond our own feature interactions that we use with say xgboost setups. And it's dynamic in the sense that it gives you a foundation model you don't have to retrain to use new (verbalizable) interactions.

Because pre-LLMs humans partially "autogenerated" kernels through hyperparameter search and in some sense eating the code complexity in return for performance, and thus built tools for the same automatic verifiability that is useful for LLMs.

In some other tasks, we never built the same level of automatic verifiability since the level of automation in creation being much lower meant it's not giving you as much of a marginal benefit. We prefer code readability and simplicity and such in say, web services, because, say, the database IO time is going to dominate. Here getting an LLM to write a cromulent C# web service is more difficult since it's not easy to automatically verify whether code is cromulent or not. So if you put up LLMs to it, you end up with slop (which works).

OTOH, in kernel design, you give it access to every perf counter, every observable possible and have it optimise all of them. And all are verifiable/hill-climbable and you generally don't give a crap if the code is readable or reusable.

Comments URL: https://news.ycombinator.com/item?id=49309227

Points: 4

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=49308570

Points: 2

# Comments: 0

You took away the wrong thing. The theory tells you that no good algorithm exists for _all_ possible inputs. This means you have to try to limit yourself to a subset of the problem space, and use heuristics to move all the remaining pathological cases (if any) to a corner you then monitor and ensure doesn't occur in practice too often.

Package managers are designed the way they are _because_ of the inherent NP-hardness, not _despite_ it as this article conveys.

In the formal models of dependency resolution, the three core conditions are: 1) Root package is included, 2) Dependency closure (everything required is present) 3) Version uniqueness (at most one version per package name)

NPM, yarn etc drop 3) which makes it not NP hard.

Go limits itself to minimum version selection which admits a linear time solution.

Cargo allows multiple major versions, thus reducing most cases of 3), and then relies on heuristics to prune and reduce the pathological cases to be relatively rare. There have been cases of real world trees that had issues, but then you add a heuristic that catches that type, and then eventually it becomes super rare. This style of design is adopted because of the known NP-hardness. We don't go around looking for algorithms to solve the general case, and we simplify the problem where possible knowing the benefit we get in return, or we watch and shift around the pathological cases to a rare corner, all because of knowing it is NP hard.

Amazon's SMT solvers and similar all use in principle similar tricks - only passing simplified encodings, portfolio solving i.e Promise.any(multiple solvers with same problem), timeouts + fallback, etc.

Another common example is the MIPs used by food delivery and other gig platform companies where the complexity of the solver is intentionally and aggressively slashed using as many tricks as possible.

One way large models are served on a bunch of cerebras chips is by essentially distributing layers' weights across chips. Few layers's weights per chip - as many as the KV cache + activations + weights will allow. You use pipelining to hide the latency of the inter-chip 150 GB/s link.

On GPUs, you amortize the cost of loading weights from HBM to SRAM across multiple users - thereby making it cheaper _per_ user. But here, there is no such amortization. The weights are already there. It is the activations that stream through.

You _could_ do batching/continuous batching, but that would just service more users at lower token/s each without any amortization of fixed cost, due to fixed cost (loading weights) being non-existent.

> Launching first in the OpenAI API to a select group of customers with expanded access to more businesses as capacity grows.