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

> The task is to place four black queens and one black bishop on the chessboard so that there is no square not under their attack

> In other words, after arranging the five black pieces, it must be impossible to place the white king anywhere without it being in checkmate.

These two sentences mean very different things in the normal rules of chess. And if you replace the word “checkmate” with the word “check” in the second sentence it still doesn’t mean the same thing as the first sentence.

The first sentence implies that all the pieces must be defended.

Edit: Eh, I guess it depends on how you view the word “attack” since all the pieces are the same colour.


You can saturate the entire power budget on pretty much all GPUs just by moving data in and out of HBM. There is no compute needed at all to do this, and bandwidth bound workloads are extremely common in the scientific computing space.


Thanks for the correction, I guess I was mistaken. I always had this mistaken belief that moving data is less energy intensive.


Is it? Nobody else can really build on their work.


AIU the intent of this publication is not to further research but to make it clear to anyone that we need to move to post quantum cryptography ASAP.


If only AI safety research had a mechanism this clear. "We have proof that building the machine will kill everybody, so get to work making a provably safe version."


"AI safety" is essentially incoherent. It's like trying to build an all-purpose chemistry lab that can't produce explosives.


Neat, an ontological argument against AI safety. Similar argument:

"God doesn't exist" is essentially incoherent. God is the perfect being, and if he didn't exist, he wouldn't be perfect.

I think the logical mistake is obvious.


Except that you have the logic backwards. It's an argument that something ("safe" general purpose AI) can't exist rather than that it has to.

People want AI to be able to do every good thing but no bad thing, which is impossible twice. First because false positives and false negatives trade against each other, so a general purpose AI which can do anything approximating all the good things is going to have the bias leaning heavily towards being able to do things in general and therefore being able to do many things that are bad. And second because "good" and "bad" aren't things that anybody can agree on and then some people will demand that it must do X while others demand that it not do X (e.g. "help the rebels win the war"), which means someone is inherently going to be unsatisfied and it's not a thing that can be sensibly regarded as everyone working towards a common goal.


You've made a great argument for calling a general halt to AI development, but I'm not sure that was your intent.


Only that doesn't work either, because what people want is for themselves to have it but not their opponents, and you not building it while your opponents do is the opposite of that.

It's like calling for a general halt to the production of military equipment. How do you expect that to actually happen?


The first one is a difficult balance but not really impossible. The second is basically utilitarianism: Of course you can't maximize all wishes because they often contradict each other, but there can be a reasonable trade-off. Some tradeoffs are clearly better than others.


> The first one is a difficult balance but not really impossible.

It's a direct trade off. If you want it to do more "good" things you make it able to do more "bad" things.

> Of course you can't maximize all wishes because they often contradict each other, but there can be a reasonable trade-off. Some tradeoffs are clearly better than others.

The easy tradeoffs are the ones nobody disputes and everybody is already trying to do. There is no lobby for having it hallucinate more or give you ingredients that will combine to make poison when you ask for a tasty recipe.


But the algorithm still isn't practical on existing quantum computers, or ones that are going to be around any time soon, so there's no reason not to publish in full.


> See, some of the most reputable people in quantum hardware and quantum error-correction—people whose judgment I trust more than my own on those topics—are now telling me that a fault-tolerant quantum computer able to break deployed cryptosystems ought to be possible by around 2029.

https://scottaaronson.blog/?p=9718


Could be one of the intents, but the main intent is reputation building.


Wake me up when there's an actual working machine.


That may be the intent, but it is very anti-science.


Partial disclosures are actively pro-science.

Evidence that a hard problem is solvable, and information on solution characteristics, are a big help to others.

Even non-disclosure is just science-neutral, not anti-science.

Partial disclosures are common where disclosures involve risky things, or where a problem was solved as part of an economic concern. But there are non-conflicting opportunities to partially inform others.


That's the whole point. And it's not "build on their work", it's "question their work", because so far every time someone's announced some magic quantum thing it's been followed up shortly afterwards by people poking holes on it, a famous recent example being the "quantum computer" that was replaced by /dev/random and it produced the same results. So the magic here isn't the quantum, it's coming up with a way to publish a claim in a way that it can't be refuted.


I am somewhat cynically waiting for the AI community to rediscover the last half a century of linear algebra and optimisation techniques.

At some point someone will realise that backpropagation and adjoint solves are the same thing.


There are plenty of smart people in the "AI community" already who know it. Smugly commenting does not replace actual work. If you have real insight and can make something perform better, I guarantee you that many people will listen (I don't mean twitter influencers but the actual field). If you don't know any serious researcher in AI, I have my doubts that you have any insight to offer.


I am sure they are aware...


It doesn’t work per-song. Songs have multiple chords, some even with alterations. If you tune an E so that it is perfectly a major third above C, then that E won’t be a perfect fifth above an A note. The Am chord has the notes A, C and E, so Am has notes that all belong to C major.

Additionally, some songs even change keys, which makes “per-song” not enough of a constraint.


I’m trying to make sense of this question.

GEMMs are dense O(N^3) work operations that have roughly the same access pattern and data reuse properties across all matrices. Of course, I’m simplifying things a lot here; tall-skinny and short-fat patterns are much harder to get performance out of but the spirit of the approach is the same as big square matrices.

Sparse LU solves have a different character. There is nowhere near O(N^3) work. You typically expect something closer to O(N^2) but getting performance out of these operations is notoriously difficult because it depends a lot on the sparsity pattern of the linear system. Making matters worse is that you may commonly have a sparse A that factorises to dense L and/or U matrices.


I'm working with small matrices (e.g. 10x10 to 100x100), where I believe the effect of caches/pipelines/registers/etc will kick in before the O(N^2)-vs-O(N^3) discussion. Then dispatching to the hardware accelerators (SME2 FMLA or AMX FMA) and doing a _dense_ solve with 512-bit vectors could still be faster than a sparse solve at small matrix sizes or NEON.

Though as mentioned elsewhere in the thread, these accelerators only offer throughput, and latency suffers...


> Personally I have a bunch of machines dedicated to gaming in my house (https://lanparty.house)

Woah, that is extremely cool. Very nice work, sir.


The circumference of Earth at the equator is about 40,000 km and the speed of light is about 300,000 km/s. The appropriate division results in about 0.13 s.

That seems to track. The vast majority of requests won’t go half way around the Earth, so maybe halving that time at 0.06 seems like a reasonable target.


Light travels at about 0.69c in fiber optic cables (c being the speed of light in vacuum, which, as you stated, is about 300,000 km/s).


Ah yes I forgot about that. Thanks for the correction.


I don’t understand what the visualisation screenshot in the README is trying to communicate to me.


It starts from the identifier. At every stage, it outputs a sub-expression which is the “mirrored use” and corresponds to the boxed representation below it. When it reaches the top of the expression, it prints the final type of the expression which is the lone specifier-qualifier list.

As per the screenshot, “arr” is an array of 4 elements. Consequently, “arr[0]” is an array of 8 elements. Then, “arr[0][0]” is a pointer. And so on, until we arrive at the specifier-qualifier list.


Ok that helps. Thank you.


It’s a natural observation, but it doesn’t address the floating point problem. I think the author should have said “fast or would accumulate floating point error” instead of “fast and would accumulate floating point error”.

You could compute in the reverse direction, starting from 1/n instead of starting from 1, this would produce a stable floating point sum but this method is slow.

Edit: Of course, for very large n, 1/n becomes unrepresentable in floating point.


Three techniques I’ve used to handle floating point imprecision/error:

1. Use storage that handles the level of scale and precision you need.

2. Use long/integer (if it fits). This is how some systems store money, e.g. as micros, but even though it’s sensical, there is still a limit and a wild swing of inflation may lead you to migrate to different units, then another wild swing of deflation may have you up-in-arms with data loss. Also it sounds great but could be a pita for storing arbitrary scale and precision.

3. Use ranges when doing comparison to attempt to handle floating point error by fuzzy matching numbers. This isn’t applicable for everything, but I’ve used this before; it worked fine and was much faster than BigDecimal, which mattered at the time. Long integers are really the best for this sort of thing, though; they’re much faster to work with.

4. BigDecimal. The problem with this is memory and speed. Also, as far as we know yet, you couldn’t store pi fully in a BigDecimal, and doing calculations with pi as a BigDecimal would be so slow things would come to a halt; it’s probably the way aliens do encryption.


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

Search: