Hacker Newsnew | past | comments | ask | show | jobs | submit | JonChesterfield's commentslogin

Xmos and Graphcore are the same stable too.

The effects are multiplicative, positive and negative.

So, two negative effects make a positive??

Pretty torn on this. One the one hand he's not wrong. On the other, it probably means proton are going to leak everyone's email to the world and cease trading shortly afterwards.

Since I'm a customer and don't care _at all_ about any "feature work" that might be being done on email at this point, this isn't great. Leave the damn thing totally alone would seem much better.


Stack overflow started as maximize signal to noise for professionals.

It transitioned to emphasize "less toxic" and in the process minimized signal.

The result has no purpose.


Well, there would be a lot of credible-at-first-glance shite in it, which is rather damaging for an introductory textbook, so there's that.


I'm two chapters in now and if AI wrote this well we'd be much less pissed off about it.


Wonderful.

This construction splits the space into 'small' models with a quadratic lookup cost and 'large' with sub-exponential cost. The small one is by enumerating all SAT problems with their answers, then looking up the answer. The large one is something in polynomials I don't understand. An answer from openai about where the cutoff is was:

    the constructed lookup machine has vastly more states than the estimated total number of physically distinguishable configurations of the observable universe.
I'm not inclined to consider "wrote down all the answers ahead of time, so that's free" as a quadratic time solution to SAT. Nor very convinced by the other half.

So on balance, if this is considered proof that the exponential time hypothesis is false, and openai model reading of the lean was vaguely on point, then I reject the axioms of this system. Not a proof, even if there is lean. I'm OK with being downvoted for that position.



by fucking sorry written at the end of the proof


They do that to make it easier for readers to verify the statement (which is entirely contained in that file) separately from the proof (which is spread over thousands of files and github can't even show them all).

Proof is at https://github.com/openai/math/tree/main/lean/OAI/Algorithms...



awesome, thanks!


I was confused too, but it looks like https://github.com/openai/math/blob/main/lean/ComparatorChal... (with the sorry at the end) is just the problem statement; the actual proof is a big pile of lean in the Algorithms folder, with the final theorem stated here https://github.com/openai/math/blob/7ef5c0cc5ca4b0e072b7a050...


Weird paper. Models have had tokens for each byte for ages now. They can read and write individual bytes just fine, in addition to also having multibyte tokens.


The point is not to have byte tokens: it's to have only byte tokens, so that the usual failures of tokenisation (e.g. the number of Rs in strawberry) can be avoided.


Would byte tokens really solve how many r’s? It seems like it would require a level of introspective awareness of the tokens being processed that I don’t think transformers have. But I’m not expert enough to go beyond that intuition, so could easily be wrong.


Models generally are capable of counting


Sure, but they could count bytes without being byte level tokens.

Can models introspect about the tokens that were passed to them?


How can an LLM read individual bytes if all it gets is the tokenized ones? Or does it just get the ones that we didn't know how to tokenize?


    0 -> token_THE
    1 -> token_PART_prefix
    2 -> token_FULLSTOP
    ...
    0x3100 -> token_BYTE_00
    0x3101 -> token_BYTE_01
    0x3102 -> token_BYTE_02
and so on

The tokenizer would have to know to switch over to lexing as individual bytes rather than whatever else it might have been able to tokenize into but that seems like a question of labeling more than anything else.


It's written down in the tokenizer. 256 of the tens or hundreds of thousands of tokens correspond to each byte, done.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: