It doesn't matter what Man knocks on what Door, so long as there's a 1:1 amount of Men:Doors, which is the case if both sets have the same cardinality.

so even if man n knocks on door 2n, man 2n simply knocks on door n.

for infinite men and infinite doors there are infinite sets of combinations, such as man n and door 2n, but if each man knocks on 1 door, each door only gets knocked once and the cardinality of the set of men and the set of doors is the same then there are no remaining doors to be knocked on.


tl;dr what Pop said is accurate.

CrimsonVision wrote:

tl;dr what Pop said is accurate.

The gist of what I said is true, but I made a wrong point and that's what Toadfish was alluding to: Just because |M| = |D| does mean that K is necessarily bijective. |M| = |D| only means that there is at least one mapping that has this property, not that every mapping does. E.g., if K takes every man and has him knock on one particular door, then even if M and D have the same cardinality it's still not bijective.

1 man doesnt have to only knock on one door they can knock on as many doors as they want.

A one-to-many relation is not a function, which is under consideration here.

Now how many doors go unanswered if the same inf number of men answers a door knocked on?
The answer is 1 :].

wat

Inasmuch as mathematics (specifically set theory) is philosophy, then yes we were.

Kats wrote:

_{Programming tricks? Shit... programming tricks. Think, Kats, think... Uh... Uh...}

SOMETIMES I LIKE TO PRESS CTRL+K TO COMPILE MY PROJECT...

_{Nailed it...}

sometimes i compile 4 times in a row just to be safe

The more code you delete, the better your program will be

edit:
That isn't to say you should optimize for the minimal number of characters or lines in a way that would harm readability/maintainability.

It's just that the less lines you can achieve something in, the less likely it is to have bugs.

Refactoring a complex heavily nested solution into a modular clean OOP/component/strategy pattern system will help reduce bug counts.

Better is a term that has many definitions. Apparently, a simple, "Hello, world!" program is better than most other programs on this website

[Edit]

I think you're trying to convey an idea of something like "trim the fat" rather than "less code is better", but it certainly comes off sounding like the latter.

Okay, that makes sense then. I still don't quite agree with the way it's phrased, especially in a place with a lot of newbie programmers. They don't know about the many, many situations where you can implement a naive approach in just a few lines and have something that is dramatically worse than a longer but far-more-efficient approach; putting that idea into their head early on might make them believe that the shorter code is necessarily better because it's shorter.

Not exactly related to the previous discussion, but there are times when uglier code isn't so bad. In programming, the Holy Grail is code that's both fast and elegant, but there are often times when you need to make tradeoffs--especially when optimizing.

One common optimization trick is called loop unrolling. When you know you have a multiple of N iterations to go through, you can do them one after the other to save time in the loop.


The unrolled loop checks the condition on the loop 87% less often. In this case we're also avoiding var lookup/assignment for the total var 87% of the time as well. Skipping the condition check means skipping at least four instructions; they operate fast, but they'll eventually add up if the loop is large. After the unrolled portion is done, a regular list cleans up any leftovers.

You can unroll however many times you want; a power of 2 is best so you can use bitwise math and avoid an expensive modulo operation. If the loop tends to be over a certain size (you can unroll however many times you want), you can cut out quite a lot of instructions this way. And if the loop body is fairly tight, like this one is, then the savings might be considerable. If for instance your condition check and the jumps involved take up 40% of the loop's execution time, then unrolling 8 times would save you up to nearly 35%. This loses its luster if the loop body gets complex, so only use it for simple operations that have to be done a lot of times, and frequently.

There's also an optimization technique called loop-flipping. I'm not actually sure if DM does this internally, and if it doesn't then I might quite like to add it. Here's what an unflipped while() loop looks like:

- Evaluate condition
- If false, jump to after loop
- Loop body
- Jump (always) to condition

A do-while loop looks like this:

- Loop body
- Evaluate condition
- If true, jump to loop body

It avoids the unconditional jump at the end, because a do-while always acts at least once, before checking any conditions. If DM flipped loops--and I don't think it currently does--it would look like this:

- Jump (always) to condition
- Loop body
- Evaluate condition
- If true, jump to loop body

The unconditional jump would in that case only be done once. You can force a flip with an if(); it's more code internally but it should perform nearly the same (actually, infinitesimally better).


That compiles out to this:

- Evaluate condition
- If false, jump to after loop
- Loop body
- Evaluate condition
- If true, jump to loop body

Although your profile data is extremely compelling, it turns out while() and for() loops are not flipped. I can't explain why the flipped form in your results performs moderately worse--way more so in fact than the if() alone could account for.