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.
In response to Toadfish
Toadfish wrote:
That's actually incorrect. Say the nth man knocks on door 2n.

It took me a minute to see your point, but yes, I was not rigorous enough as I should have been. At the same time, cardinality can be a difficult to grasp if you've never done much with set theory before.

To be more accurate, if |M| = |D| then there is at least one K : M → D such that there is one man to every door. Of course, once you have some background on this stuff, that statement is essentially true by definition.
In response to CrimsonVision
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.
In response to CrimsonVision
CrimsonVision wrote:
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.

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

Now how many doors go unanswered if the same inf number of men answers a door knocked on?



The answer is 1 :].
In response to Ghost of ET
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
In response to Popisfizzy
I thought you guys were talking about some sort of philosophy o>O.

I know at least one of you have taken a class/majored in it :P. So i just thought... assumed*
In response to Ghost of ET
Inasmuch as mathematics (specifically set theory) is philosophy, then yes we were.
Programming tricks? Shit... programming tricks. Think, Kats, think... Uh... Uh...

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

Nailed it...
In response to Kats
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
Using define macros to group commonly repeated statements together thus avoiding proc call overhead.
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.
In response to Optimumtact
If that's true then ive been programming wrong this entire time.
In response to Optimumtact
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.
Oranges is part of a ss13 dev team, and for work does contract programming, so from his perspective, trimming the fat and less code is better have been the same thing in every project he's dealt with.
In response to MrStonedOne
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.
In response to Popisfizzy
I updated with a less flippant answer
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.

// simple loop
for(i=1, i<=N, ++i)
total += mylist[i]

// unrolled 8x
var/Nbig = N & ~7
N -= Nbig
for(i=1, i<=Nbig,)
total += mylist[i++] + mylist[i++] + mylist[i++] +\
mylist[i++] + mylist[i++] + mylist[i++] +\
mylist[i++] + mylist[i++]
for(, i<=N, ++i)
total += mylist[i++]

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).

if(condition)
do
loop_body()
while(condition)

That compiles out to this:

- Evaluate condition
- If false, jump to after loop
- Loop body
- Evaluate condition
- If true, jump to loop body
I'm not actually sure if DM does this internally, and if it doesn't then I might quite like to add it.

profile would suggest it already does this:
                         Profile results (total time)
Proc Name Self CPU Total CPU Real Time Calls
--------------------------- --------- --------- --------- ---------
/mob/verb/flippedwhile 28.587 28.587 28.587 500
/mob/verb/normalwhile 28.338 28.338 28.337 500
/mob/verb/checkloopflipping 0.005 56.930 56.929 1


mob
verb/checkloopflipping()
. = 0
for (var/i in 1 to 500)
. += normalwhile()
world << .
for (var/i in 1 to 500)
. += flippedwhile()
world << .

verb/normalwhile()
. = 0
while (. < 500000)
.++

verb/flippedwhile()
. = 0
if (. < 500000)
do
.++
while (. < 500000)


In response to MrStonedOne
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.
way more so in fact than the if() alone could account for.

It's the scope traversal, is my bet. Traversals in DM's VM are pretty damn costly.
Page: 1 2 3 4 5 6