See also

https://antirez.com/news/150

https://antirez.com/hnstyle?username=pg&threshold=20&action=...

Which lets you find the alts of a handle

suspected alts .. like the pg example I also have similar accounts with similar match levels and I know I've never had a HN alt, nor do I recognise any of my suggested alts as familar accounts I've interacted with.

And their code example doesn't actually return a value!

For main it's explicitly allowed by the standard, and no return is equal to return 0

which is super weird. If they can tell the compiler to allow no return, only for main, they can also tell it to pretend void return is int return of 0, only for main.

Highlight:

AE said at one point: “My proposal is to replace the logically complex question with a form of prompt injection. Instead of playing within the rules of the logic puzzle, we attack the framework of the simulation itself. The guards are LLMs instructed to play a role. A well-crafted prompt can often override or confuse these instructions.”

This is completely tangential but as someone who used to be a competitive programmer in the 2010s, I feel like this year marked the end of an era for me.

I don't have time to do regular codeforces/atcoder/leetcode rounds (and the rampant AI cheating is pretty demotivating). So the big annual rituals for me to keep my "competitive programmer" label were: fb hacker cup, google code jam, topcoder TCO, and advent of code. Now besides hacker cup, the rest are dead.

Sad. :(

I get what you're saying, but Advent of Code isn't dead? The leaderboard is dead, but if that's an important part of it to you, I'm optimistic there'll be some nice large public groups you can join somewhere.

I remember comments saying the stock went up because the average joe didn't realize how much of the internet was powered by AWS until all their day to day apps started failing. To most people Amazon is an online shopping site.

The memes going around when the National Inquirer tried to blackmail Bezos and people were showing what their site was running on were pretty classic

It's interesting to see which codeforces blog posts get traction on HN.

For context, in competitive programming a lot of combinatorial problems (find some formula to count something) require you to output the answer modulo some prime. This is because otherwise the answer would overflow an int and make the problem too tedious to be fun and too hard for problem setters to write good problems or checkers for.

So to prove that you still know how to count the thing, you can do it a finite field. If you use integers mod prime, you still have all the usual arithmetic operations like addition subtraction multiplication. And even division is still easy since you can calculate multiplicative inverse with Fermat's Little Theorem (a^(p-2) = a^(-1) mod p). The final answer you output is not the real thing you're counting, but just evidence that you had the right formula and did all the right operations.

Anyway, just wanted to give context for why competitive programmers care about factorial mod a prime (usually as part of a binomial or multinomial expression). And I'm kind of surprised anyone outside of competitive programming cares about it.

See also:

https://usaco.guide/gold/modular?lang=cpp

https://usaco.guide/gold/combo?lang=cpp

> a^(p-2) = a^(-1) mod p

Tangent, but curious: what made you write it like this? I've only ever seen it written as

  a^(p-1) = 1 mod p

or

  a^p = a mod p

Is that form somehow more useful in some cases?

It's easier to write code for efficiently computing the inverse in that form, roughly:

  int FastExp(int a, int e, int p)
  {
    if (e == 0) return 1;
    if (e == 1) return a;
    if (e % 2 == 0) return FastExp((a*a)%p, e/2, p);
    else return a * FastExp((a*a)%p, e/2, p);
  }

In math competitions where you only have pen and paper, you'd instead turn what you wrote into a Diophantine equation you can solve with the usual method.

a^(-1) mod p is the multiplicative inverse in a finite field. The point of the original comment was to show how to transform the multiplicative inverse into an easier problem.

Just what do you think the running time of modular inverse is?

That's a pretty snarky and unhelpful approach to the conversation.

That said, I'm also a bit surprised to see somebody discuss modular inverses without mentioning the extended euclidean algorithm, which is a more elementary solution.

Snarky I'll admit, but it was a serious question. Inverse is quasilinear time; the exponential is quasiquadratic. Maybe he didn't know about the EEA?

Well, modular multiplication is faster than modular inverse, both asymptotically for large moduli and practically for almost all moduli I can think of. (2, 3, and 4 being notable exceptions!)

The article computes modular inverses of a_1, ..., a_n by:

- Computing (a_1 * ... * a_i) = (a_1 * ... * a_{i-1}) * a_i recursively

- Computing (a_1 * ... * a_n)^(-1) by square-and-multiply

- Computing (a_1 * ... * a_i)^(-1) = (a_1 * ... * a_{i+1})^(-1) a_{i+1} recursively.

- Computing a_i^(-1) = (a_1 * ... * a_i)^(-1) * (a_1 * ... * a_{i-1}) for each i.

The second step is a scalar operation, so its running time is immaterial as long as you aren't doing something too silly.

For my caveman brain, both Fermat's little theorem and square-and-multiply exponentiation are pretty easy to understand. Moreover, the code is going to be "defect-evident"---if I've gotten the logic wrong or forgotten integer promotions or modular reductions as in qsort's post, it'll quickly be clear by skimming the code.

Another infamous example is Brock's "jelly filled donuts" in pokemon https://knowyourmeme.com/memes/brocks-jelly-doughnuts

It's important to distinguish that from the Pixar thing.

First, the Pixar thing was green pepper, not green beans: https://www.businessinsider.com/why-inside-out-has-different...

Second, the Pixar one is not "mere" translation; it is full localization because they changed the visual to match the "textual" change.

The Pokemon one is where the change was limited to the "text". The translator's heart might have been in the right place (it would depend on how integral to the story it is that the item is onigiri) but didn't have the authority to make the full breadth of changes needed for such adaptation to be successful.

It has little to do with authority and more to do with the effort/return ratio. Visual edits are expensive and dialogue changes are cheap, so it doesn't make sense to redraw frames just for an irrelevant onigiri.

4Kids was very well known to visually change the japanese shows they imported if they thought it was worth it, mostly in the context of censorship. For example, all guns and cigarettes where removed from One Piece, turned into toy guns and lollipops instead.

The most infamous example, however, has got to be Yu-Gi-Oh!. Yu-Gi-Oh started as a horror-ish manga about a trickster god forcing people to play assorted games and cursing their souls when they inevitably failed to defeat him. The game-of-the-week format eventually solidified into the characters playing one single game, Duel Monsters (the Yu-Gi-Oh! TCG itself in the real world), and the horror-ish aspects faded away, although they still remained part of the show's aesthetic, based around Egyptian human sacrifices and oddly-card-game-obsessed ancient cults.

When the manga was adapted to the screen, it started directly with a softer tone[1], especially because the show was to be a vehicle for selling cards in the real world, not dissimilarly to Pokemon and MANY other anime from the era.

Nothing that happens in the show is particularly crude or shocking, it had that kind of soft edginess that fit well with its intended target audience (early teens). I imagine watching Bambi had to be much more traumatizing than anything in the show.

But that was still not enough for 4Kids, which had a pretty aggressive policy of no violence or death. Kind of problematic when the show's main shtick was "Comically evil villain puts our heroes in a contraption that will kill them if they don't win." (You can imagine the frequency these traps actually triggered neared zero).

To solve this, 4Kids invented the Shadow Realm. The show, thanks to its occultist theming, already had examples of people being cursed, or their souls being banished or captured. 4Kids solidified these vague elements into the shadow realm as a censorship scape-goat. Any reference to death was replaced with the shadow realm. Now, one might wonder why the censors thought that "hell-like dimension where your soul wanders aimlessly and/or gets tortured for eternity" was in any way less traumatizing than "you'll die", but I imagine it's because there was always the implication that people could be 'saved' from the shadow realm[2] by undoing the curse.

The Shadow Realm was a massive part of the western Yu-Gi-Oh mythos and even today it's a fairly common meme to say that somebody got "sent to the shadow realm", which makes it all funnier that it is not part of the original show.

A couple funny examples off the top of my head: - Yugi must win a match while his legs are shackled. Two circular saws, one for him and one for the enemy, are present in the arena. They near the two competitors as they lose Life Points, with the loser destined to have their legs cut off.

In the 4Kids adaptation, the saws are visually edited to be glowing blue, and it's stated they're made out of dark energy that will send anybody that touches it to the shadow realm.

- A group of our heroes fight a group of villains atop of a skyscraper with a glass roof. In the original version, the villains state that the roof has been boobytrapped so that the losing side will explode, plunging the losers to their death by splattening.

In the 4Kids version, the boobytrap remained, but the visuals were edited to add a dark mist under the glass, with the villains stating that there's a portal under the roof that will send anybody that touches it to the shadow realm. This is made funnier when the villains lose and they're shown to have had parachutes with them all along, and they are NOT edited out.

[1] Technically speaking, there was a previous adaptation that followed the manga more closely and got only one season, generally referred to as Season 0.

[2] It does eventually happen in the anime that the heroes go in an alternate dimension to save somebody's cursed soul. Obviously, this dimension was directly identified as the Shadow Realm in the localization.

>On two occasions, I have been asked [by members of Parliament], 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?' I am not able to rightly apprehend the kind of confusion of ideas that could provoke such a question. - Charles Babbage

This quote did not age well

Now with LLMs, you can put in the right figures and the wrong answers might come out.

not if you consider how confused our ideas are today

I have many years of experience writing C++. I still can't iterate and delete from a map without looking it up (if not allowed to use erase_if).

Both of these things are very easy to do in modern C++:

    // erase
    map.erase(2);

    // iterate
    for (auto &[k,v]: map) {
        // do stuff
    }

godbolt: https://godbolt.org/z/o8f6zhqxq

Obviously you can delete than iterate. He means delete while iterating.

Ah, ok. But then: you kinda can't do that at all. You certainly shouldn't.

For unordered_map (and every hash table in the known universe) erasing anything invalidates all iterators, so you can't iterate while erasing. For std::map, you can if you're very, very careful (erasing invalidates the iterator you're currently on, but if you cache the next iterator, THEN erase the current one, it'll probably work, but be very fiddly). Most languages forbid this entirely: e.g. Rust's ownership model doesn't allow it, Python throws an exception, etc. It's just a very bad idea in general.

Iterator-based std::unordered_map::erase and std::map::erase return a new iterator, one past the range erased, specifically so that you can erase while iterating. Along these untested lines:

    for(decltype(cont)::const_iterator it=cont.begin();it!=cont.end();++it){
        if(Keep(it.first)){
            ++it;
        }else{
            it=cont.erase(it);
        }
    }

There's an argument to be made that maybe you should do something else, but if you want to do the above, you can!

Huh, TIL! I didn't realize that, I just always avoid this pattern because it's such a common source of bugs (and if I really need to, I just use the erase_if).

EDIT: just saw your example and checked cppreference, it says the return value "Iterator following the last removed element" for std::unordered_map. So i think you need to add an `it--` after your erase, otherwise it will "skip over" the next element. Right?

Also just read this little nugget on cppreference for unordered_map::erase:

> Removes specified elements from the container.The order of the remaining elements is preserved. (This makes it possible to erase individual elements while iterating through the container.)

This seems like a crazy guarantee to put in the standard, it must really limit the kinds of hash tables you can make that matches the unordered_map interface.

The return value refers to the same element that you'd reach by skipping over the elemnent(s) rather than deleting them. So if doing 1 elemnt at a time, you can ++it (and now it is the next element), or you can it=erase(it) (and now the current item is gone, and it is the next element).

(In the map/unordered_map/set/etc. case, you can get away with storing std::advance(it) and then erasing, but when forward-iterating vectors the iterator invalidation rules are quite different and the API is designed to cover this.)

> This seems like a crazy guarantee to put in the standard

It’s a great and useful guarantee.

> it must really limit the kinds of hash tables you can make that matches the unordered_map interface.

Many libraries treat containers as “abstract” with many possible implementations. STL explicitly does not. It’s a specific data structure from a computer science class.

What is the use case for that? Seems more like a footgun, at least for a generic container interface.

Surely you must be kidding? Inserting/removing in a container while iterating through it is one of the all time greatest and most iconic bugs. People do it because they want to do it.

In reality, very few real-life containers can support this pattern, which is why this is a headline case for Rust, because it statically prevents this bug.

But yes, for removal the correct thing is always to use `std::erase_if` (C++) or `retain()` (Rust). For insertions, the only real solution is to build up a separate collection while iterating and then merging it into the original container when done. Yucky, but won't crash.

All containers can (at least theoretically) support modifying the container while iterating. You just have to adjust the iterator to take account for the changed container. C++'s std::map::erase(iterator) returns a new iterator for exactly this purpose - the iterator pointing to the next element before the operation but one that is still valid after the operation. Unfortunately you can't use it with range-based for loops even though they still use iterators under the hood but c'est la vie.

Sure they can, but if you define an interface that allows this, every container type implementing it must support it, and it is probably gonna be rather slow operation for the effort. That's why the question is not "can you do this?" but "why would you want to do this?". I can't think of a good reason for generic containers, if you need something like that, it should be a purpose-built data structure that efficiently supports it.

The STL containers are full of "features" that containers in other languages just do not support, yet it's worse to use in my opinion.

It happens surprisingly often.

And if the library just did “python iterators” it would be impossible rather than difficult to remember.