enonimal

nominative determinism having a field day

I don't have an answer but I'd love to know this too. Why has Postgres got this unique staying power?

we may think more similarly than you seem to think...

this was more a slam on python packaging in general, than it is on the OpenAI implementation.

I wouldn't be surprised if many of the issues under this topic are more related to Python package version nightmares, than OpenAI's Python implementation itself.

> Number of Posts with negative sentiment, grouped by Topic

> # 1 Result: Python Packaging

Checks out

how do you perceive privacy in such a world?

> "Who says plasticity is good"

In Machine Learning, we might think of this idea as "setting your Learning Rate too high"

Thank you -- I had always wondered what the optimization was behind that Algo!

law:

prompt engineering before it was cool

maybe a fun karpathy video here...

AFAICT, this is a more advanced way of using Embeddings (which can encode for the vibes similarity (not an official term) of prompts) to determine where you get the most "bang for your buck" in terms of testing.

For instance, if there are three conversations that you can use to test if your AI is working correctly:

(1) HUMAN: "Please say hello"

    AI: "Hello!"

(2) HUMAN: "Please say goodbye"

    AI: "Goodbye!"

(3) HUMAN: "What is 2 + 2?"

    AI: "4!"

Let's say you can only pick two conversations to evaluate how good your AI is. Would you pick 1 & 2? Probably not. You'd pick 1 & 3, or 2 & 3.

Because Embeddings allow us to determine how similar in vibes things are, we have a tool with which we can automatically search over our dataset for things that have very different vibes, meaning that each evaluation run is more likely to return new information about how well the model is doing.

My question to the OP was mostly about whether or not this "vibe differentiated dataset" was constructed prior to the evaluation run, or populated gradually, based on each individual test case result.

so anyway it's just vibes man

This is a cool idea -- is this an inner-loop process (i.e. after each LLM evaluation, the output is considered to choose the next sample) or a pre-loop process (get a subset of samples before tests are run)?

> Take courage and set out to write up the Great Discovery; if after many hours of red- hot thinking and writing you discover to your dismay a fatal flaw . . . all is not lost. Go back to the first paragraph and write something along the lines of “It is tempting to think that . . . ”

XD

From the ARCHITECTURE.md:

> Those pointers point to undocumented functions forming CUDA Dark API. It's impossible to tell how many of them exist, but debugging experience suggests there are tens of function pointers across tens of tables. A typical application will use one or two most common. Due to they undocumented nature they are exclusively used by Runtime API and NVIDIA libraries (and in by CUDA applications in turn). We don't have names of those functions nor names or types of the arguments. This makes implementing them time-consuming. Dark API functions are are reverse-engineered and implemented by ZLUDA on case-by-case basis once we observe an application making use of it.

Just tagging here to say I enjoy the site, but I agree with my parent ^ the popup slows me down

JSON not including comments has caused so much labor for the world.