maginx

I'm curious about the 10x via implementation in Go - couldn't it have been realized otherwise? Finding the hotspots, reimplementing them using better algorithms, if necessary move a few critical paths to native etc. Or even improving the JIT itself which might benefit all programs. Just wondering because I wouldn't think that the JIT-overhead was that much that you could gain 10x just reimplementing in Go (or C, assembly etc)... that is something I would only have expected if going from an interpreted context.

That's not my experience - I've found a handful of accepted and verified bugs in major commercial compilers and all were in the codegen/backend, and the code to be generated was quite simple. In one case it was basically an array copy in Java byte code that got erroneously translated into what was effectively a "copy until zero termination" error.

Around 10 years ago I found a JIT bug in a JDK from a big Java vendor. A new version of a web application server had been applied. The production application crashed after around 30 minutes of running, almost simultaneously on both production sites. It was an internal checksum calculation in the application that failed - an obscure error never seen before. The upgrade was rolled back immediately. I was assigned to the case and of course didn't suspect a JIT error. But within a week of investigation I started suspecting it must be (but I didn't dare tell anyone!) and I eventually managed to show this and reproduce it consistently. The vendor confirmed and made a temporary workaround via switches that disabled some new optimizations. Later a real fix was shipped.

I've also found 3-4 JavaScript JIT compiler errors in major browsers, all confirmed. I was a developer on what was for its time a quite complicated JavaScript solution, so we tended to encounter obscure JavaScript errors before others.

I agree - I don't know what field it formally is, but computer science it is not. It is also related to information retrieval aka "Google skills", problem presentation, 'theory of mind', even management and psychology. I'm saying the latter because people often ridicule AI responses for giving bad answers that are 'too AI'. But often it is simply because not enough context-specific information was given to allow the AI to giving a more personalized response. One should compare the response to "If I had asked a random person on the internet this query, what might I have gotten". If you write "The response should be written as a <insert characteristics, context, whatever you feel is relevant>" it will deliver a much less AI. This is just as much about how you pose a problem in general, as it is about computer science.

Agreed - I've worked with PKI in many years, and know why the various systems work...in terms of "why you can decrypt again", not in terms of why it is secure (no other way to decrypt) which no one really knows. But if we assume for a moment the systems are secure, it is truly fascinating when thinking about it in abstract terms: Who would have thought, it is possible to give someone an exact recipe to follow that scramble a message to be sent... we can consider e.g. an encryption routine where the public key is inline so it is really just a standalone scrambling problem. Even though it is completely public, it can only be used to scramble and not unscramble. The sender who literally went through the steps to scramble the message, cannot undo what they just did. (the sender could have saved the original before scrambling!). And it is not because data is thrown away it can't be unscrambled - all the information is there there, fully recoverable, but only by the person who made the scrambling-recipe and there's no practical way to deduce this unscrambling recipe from the scrambling recipe.

I feel exactly the same, and have also implemented it backwards and forwards. I've thought about it in my sleep, trying to recall how it REALLY works. Happens every few years ;-) I always thought it was probably obvious to everyone else what the "magic" is.

Probably what was built was a Fusor. There's tons of instructions how to build one (https://fusor.net/board/) and seemingly there's a lot of focus on how "young" the builders of such are. Just google: fusion reactor teenager. In some of the stories it become apparent the fusor was never actually even finished but just along the way.

https://newsforkids.net/articles/2024/09/04/16-year-old-stud... https://online.kidsdiscover.com/quickread/arkansas-teen-buil... https://interestingengineering.com/energy/nuclear-fusion-rea... ...

Yes the whole tone of voice is typical of LLM's as well.

I don't think so. Consider "It didn’t just attempt to guess the chosen animal but also learned from its mistakes, adding new questions and answers to its knowledge base. What’s more, it had the ability to save progress and load it during the next run.". Data persistence across trials is already implied by the first sentence, so what would the next "What's more, ..." part refer to - it mentions "saving" and "loading"? Even if we grant "saving" to mean updating the in-memory data structure, what would "loading" refer to? Also note the later "No ability to save progress" which directly contradicts "It had the ability to save progress". These sentences, both clearly referring to the original, are in direct contraction with each other and use the exact same terms. Inspection of the code shows that it clearly only saves the memory and not to disk.

In two places the article states that the original game had the ability to save the updated tree ("it had the ability to save progress and load it during the next run" and "It is an amazing example... of how, even with such a simple language, ... and the ability to save new questions").

The later part says the opposite - that the original implementation had "No ability to save progress" and that this is new in the C++ implementation.

I can't help but wonder (also due to other language features) if the author ran the article through an AI to 'tidy up' before posting... because I've often found ChatGPT etc. to introduce changes in meaning like this, rather than just rewriting. This is not to dismiss either the article or the power of LLM's, just a curious observation :)

I also think search engines sometimes remove results based on subject requests - at least I've seen such notices in Google search results, that some hits were removed due to 'right to be forgotten' policies.

Unpopular opinion (it seems): I think it is OK to some extent. Not for serious crimes (violence, murder etc.) but there's an awful lot of 'lesser crimes' reported with full names where I think subjects might deserve a clean slate or where people have some right to privacy. In the extreme case, everything court-related and all infractions could be public and subject to auto-generated news, and forever searchable: traffic fines, civil cases, neighbor complaints (either way) etc. All parts of an immutable record for everyone to look up by name. I personally think that is a violation of privacy, so it has to be balanced. Maybe the best balance is not to write the names to begin with.

In Denmark where I'm from, court cases are almost always public and the subject names are read aloud as well; however the names are not listed on the court lists or in the publicly accessible version of the verdicts. In order for the media to learn the name, a journalist has to physically go and see the trial. This already prevents automation and ensures prioritization by the media. Furthermore, most news media have a policy of only writing the subject's name after a guilty verdict has been found and even then only if the verdict was of some severity (unless it is a public person). I just checked on media outlet and their policy was to only write the name in case of a custodial sentence of at least 24 months. If it weren't for such policies, even relatively small cases would be reported with full name and be searchable forever.

I think it’s very human to be curious about the cause, but it can also be inappropriate, though some ways are more harmful than others. I've seen people ask very direct questions where it seemed their real interest was to assess whether the cause posed a risk to themselves or was something they could avoid. While this reaction is natural, it is also prioritizing personal concerns over the needs of those grieving, who don't have the possibility of changing the circumstances.

Furthermore, such questions can sometimes come across—or even be—blameful. For instance, asking 'What cancer did they die of?', 'Were they a smoker?', 'Were they obese?', or 'Did they work with chemicals?' might suggest judgment or responsibility, even if that’s not the intent. And as mentioned, sometimes it actually IS the intent (trying to find a way the person caused this on themselves), even if the person asking tries to cloak this, perhaps also to themselves. This can add unnecessary pain to those grieving.

The size/computational complexity of usage also only grows as a polynomial with RSA. But even with this in mind, a quantum computer that can crack in polynomial time is still problematic. While you can increase the key size, the operator of the quantum computer could enlarge his computer, a true cat-and-mouse game. Unlike the current situation where usage complexity grows as a polynomial, while cracking grows exponentially. This difference is the reason why we can pick key sizes where signing/decryption takes a millisecond while cracking it takes (presumably) billions of years.

Encountering this by chance is exceedingly unlikely of course, if p and q are randomly generated. In probability terms it amounts to the first half of p (or q) all being zero (apart from a leading 1) so roughly 2^(-n/4) where n is the bit size of n. So for RSA 2048 the probability of this happening is on the order of 2^-512, or in base-10 terms 0.0000000...0000001, with roughly 150 zeros before the one!

I've seen many implementations that relied on iterating (or rather, they used a prime sieve but it amounts to the same thing in terms of the skewed distribution). While maybe not a problem in practice I always hated it - even for embedded systems etc. I always used pure rejection sampling, with a random one in each iteration.

As I understand it, the number of rounds needed (for a given acceptable failure probability) goes down the larger the number is. Note (very importantly) that this is assuming you are testing a RANDOM integer for primality. If you are given an integer from a potential malicious source you need to do the full number of rounds for the given level.

I still see a lot of RSA especially for encryption. While ECC can be used for encryption it is more convoluted and much less supported in hardware, software etc. than RSA decryption/encryption.

The performance of this can matter in some scenarios. In embedded systems, smart cards etc., generating the primes can take a significant amount of time (15-20 seconds typical) even with the 'low' number of iterations. Higher iterations means the user will have to wait even longer. Actually, in such systems it is not unusual to see occasional time-out errors and such when the smart card is unlucky with finding the primes. The timeout value may be a fixed, general value in a part of the stack difficult to change for the specific call.

Another case is short-term keys/certificates, where a fresh key pair is generated, and cert issues, for each and every signature. This setup makes revocation easier to handle (the certificate typically has a lifetime of a few minutes so it is 'revoked' almost immediately).

There are also scenarios where the keys are generated on a central system (HSM's etc.) to be injected into a production line or similar. There performance can matter as well. I worked on a system where the HSM's were used for this. They could typically generate an RSA key in 1-2 seconds, so 12 HSM's were needed to keep up with demand - and this was again with the reduced number of rounds.