NohatCoder

This seems to be about people who think they are smarter than they are. There are dumb and smart people alike who fall in this category, but also plenty who do know their own limits.

The whole thing scrolls in a very weird fashion. Despite only taking up around 1/6 of my screen it manages to scroll so that part of the map is hidden. The whole thing lacks instructions on how to play, along with rules. What units do what? What does the terrain do? How is damage calculated?

This review seems to miss one of the most important competitors. The Ryzen 5 7600 costs only $20 more, and performs a good deal better for not a whole lot more power. I don't think there is a lot of customers to whom the iGPU difference is important, but not important enough to get a discreet graphics card.

It is certainly very broad. And as much as some people try, you can't make any complete generalisations about what autistic people can or cannot do.

We do actually have some methods of calculating an expected performance. For instance we know that a Zen4 CPU can do 4 256 bit operations per clock, with some restrictions on what combinations are allowed. We are never going to hit 4 outright in real code, but 3.5 is a realistic target for well optimised code. We can use 1 instruction to detect newline characters within those 32 bytes, then a few more to find the exact location, then a couple to determine if the line is a result, and a few more to extract that result. Given a high density of newlines this will mean something on the order of 10 instructions per 32 B block searched. Multiply the numbers and we expect to process approximately 11 B per clock cycle. On a 5 GHz CPU that would mean we would expect to be done in 32 ms, give or take. And the data would of course need to be in memory already for this time to be feasible, as loading it from disk takes appreciably longer.

Of course you have to spend some effort to actually get code this fast, and that probably isn't worth it for the one-shot job. But jobs like compression, video codecs, cryptography and that newfangled AI stuff all have experts that write code in this manner, for generally good reasons, and they can all ballpark how a job like this can be solved in a close to optimal fashion.

As a cryptographer I can't stand this quote. Nothing against Neumann, but the people who choose to spread it as sage wisdom really only manage to convey misinformation. In context it is a superfluous philosophy quip.

We have had fast reliable cryptographic random number generators for decades. They really do work with just a tiny seed and a bunch of arithmetic. The numbers produced are indistinguishable from any other proper random source, and they work for any purpose.

Too many people don't understand this, and entire companies are founded on selling snake oil true random.

So you suggest transferring a trit using 3 wires. Wires for data transfer already take up a tremendous amount of space in a lot of CMOS logic.

The primary point of CML is that a differential signal is interference resistant. Therefore it can be used for higher data rates in out-of-chip buses. It does not provider faster ALUs than CMOS.

The way we use transistors does not leave any room for tri-level circuits to be more efficient.

The high clock speeds we get rely on fast switching of power levels, this is generally done by targeting a voltage well beyond the switching threshold. The smallest transistors we produce generally have a big variability in amplification, they would be really bad for analogue circuitry, but in digital they just have to amplify enough, and it is ok if some of them amplify way better than that.

Now consider tri-state, we have to target a voltage in the middle band if we are to produce the middle signal, so less room for over-targeting means slower switching. We probably also need to supply the whole circuit a higher voltage to make proper room for the signal levels, that is a big L in efficiency.

One could build a circuit with three levels of input current, but that ends up more or less doubling the transistor count, so not an obvious win. I guess that is what the Setun did. If adding this complexity to a tube doesn't increase its cost much I guess that makes sense, but in the transistor world it is just a doubling.

Wrong prices. Anyway, you'd get even lower graphics performance. The 8700G is 12 CUs, and those two models come with 8 and 4 CUs, making them even less compelling alternatives to a dedicated graphics card.

I wonder how many times that has happened? Specifically someone intentionally modifying the behaviour of a closed source program by changing an LGPL library that it depends on.

They are produced on an older processing node than the AM5 lineup. So if AMD switched to only produce AM5 CPUs and Radeon 7000 graphics chips, the old factories would lack something worthwhile to produce. Therefore AMD can negotiate much lower rates for using those older facilities, making it viable to continue production as long as the products sell. There aren't any truly new chips, it is just new binning and marketing of the old models.

A quick check puts a Ryzen 5 5600 and a Radeon RX 6600 at $360 combined, where the 8700G is set to $330. And a RX 6600 will deliver around double the graphics performance. So even without factoring in motherboard and memory the 8700G is hard to justify for a cheap gaming rig.

It also degrades the visual quality of the sprites by not rendering them in 1 to 1 scale. From a modern standpoint where a bit of 3D does not have a wow factor I think it actually looks worse.

What I read is that it is the best theoretically possible error correction mechanism, given a convolutional code as input, and thus also the highest cost mechanism that one would consider.

This doesn't mean that it is universally the best way of doing error correction, other ways of generating redundancy may provide a better set of tradeoffs.

Also, convolutional code is a system that can be configured in many ways, the complexity of the code generation feeds back into the decoding, so a simple convolutional code would be Viterbi decodable at the time, but a more complex system would overall provide better error correction, even though choosing such a system meant that Viterbi would be computationally infeasible.

This is about error correction. The probes add a redundant convolutional code to their signal. Decoding this is easy as long as the error rate is low, a computer program can simply guess what bits have flipped. The issue becomes harder with a higher error rate, and a Viterbi decoder is computationally expensive, but can correct higher error rates than other constructions.

Since the signal strength degrades with distance to Earth, error correction naturally becomes much more of an issue later in the mission. I guess that the probes may have switched between different levels of redundancy through the mission, as the transmission error rate rises. But there was never a point where the convolutional code wasn't useful, it just became slightly more useful with a better decoder.

The problem is, nobody cares if the can actually says Play-doh on the label. When kids become brand aware it matters what phone they get, not so much the brand of a toy gun. You can pump them full of commercials to sell stuff, but anyone can do so, and it doesn't matter what your brand used to be before they were born.

"A spokesperson for Nord Pool said it was up to the market participant to resolve the issue."

That is no way to operate a power exchange. This is not just money being made and lost, the whole grid will go down if such an error is allowed to stay. Saying not our problem when you are in the prime position to fix it is criminally irresponsible.

Of course the prevalent reason to make a service is that it can be monetized to Hell and back again. Does it fit the customer's needs? Who cares, as long as they have no clue what they will end up paying until it is too late to migrate away.

The computer part of this "quantum computer" is not really developed. So mostly they just have some way of storing a qbit, of which they have built more than 1000 copies, but no way of making them do anything significant.

For the last 10 years you have been adding stuff that did nothing but increase the complexity. Now you wonder why new people can't keep up with the complexity.

I still haven't figured what a vector DB is, beyond something something AI.

If you do a rewrite you can throw away the memory buffer and handle all data with opaque pointers, thus allowing complete integration with the GC.

And yes, you could just leave the buffer dangling there, and tell people not to use it, but it doesn't ease any part of the task of designing the new thing.

It wouldn't solve the issue, but it would remove all the things in the way of one competent person sitting down and writing a spec.

The DOM is garbage collected, you cannot hold a reference to a DOM element in a non-garbage-collected environment without having to manually mark as held and free.

Remember that some old IEs had memory leaks because one could make circular references through the DOM and JavaScript, and they each had separate garbage collectors. Well working garbage collection is not an afterthought, and you can't get two distinct garbage systems to work together in the seamless manner that a single system can operate.

It is a virtual machine by the normal definition of the word, doesn't mean it can't be AOT compiled.

The part of parsing that can be skipped is a minuscule part of compilation, won't do much for performance.

I guess that the binary representation could theoretically be a bit smaller. However the current status is that compilers need to ship a fair amount runtime stuff, like an allocator and basic string handling, so the resulting binary isn't necessarily smaller than the source code of a fully featured language. That of course weighs down compilation as well.

It has been almost 6 years since all major browsers first supported WASM. Can you really call that early?

The lack of integration with anything. The primary method of storage being flat memory that cannot hold a DOM reference in a way that doesn't break garbage collection. The lack of string handling.

I'm not saying that it is impossible, but you would end up pretty much building a new language with all the required features, sitting next to the useless array-based thing.

I really don't get the WebAssembly design. It is not Assembly, it doesn't offer any of the benefits of Assembly. The only thing that makes it assembly-like is that it is completely unreadable and mostly unwritable to humans. For those who don't know, WebAssembly implements a stack machine VM, the only appreciable effect of this design decision is that all code becomes spaghetti code.

We could have made a simple AOT-compileable Basic/C/Java-like language, called it a web standard and let people decide for themselves how many layers of compilers they would like to stick in front. But no, that would make everything too easy to debug. We gotta have an incomprehensible binary file, because that looks fast the same way a red car does.

If that is what they want then they should scrap WASM and start over. The design is just fundamentally wrong for a JavaScript replacement.

You can write all your HTML/CSS/JavaScript by hand and have no weird integration issues.

WASM is designed not to be written by hand. It is the only component that forces you to use a compiler chain.