<-> Mar 21 2016, 8:08 pm i love this thread as much as i don't understand anything being said in it
 <-> Apr 9 2016, 8:33 pm In response to Popisfizzy Popisfizzy wrote: Ter13 wrote: If there are an infinite number of men knocking on an infinite number of doors, how many doors remain to be knocked on? Oh, that's easy. Let D be the doors, and let M be the men. The knocking is a function K : M → D. If M and D have the same cardinality, then every door has a man knocking on it. If |M| < |D|, then there are infinitely many doors unknocked on If |M| > |D|, then there are too many men for how many doors there are (i.e., at least one door has two or more men knocking on it). You may have said that as a joke, but this is stuff in set theory and is very important. The work of Cantor is not to be overlooked. That's actually incorrect. Say the nth man knocks on door 2n.
 <-> Apr 9 2016, 10:10 pm 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.
 <-> Apr 9 2016, 10:44 pm 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.
 <-> Apr 9 2016, 10:46 pm 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.
 <-> Apr 11 2016, 10:16 pm 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 :].
 <-> Apr 11 2016, 10:35 pm (Edited on Apr 12 2016, 12:24 am) 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
 <-> Apr 12 2016, 8:02 am 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*
 <-> Apr 12 2016, 1:26 pm In response to Ghost of ET Inasmuch as mathematics (specifically set theory) is philosophy, then yes we were.
 <-> Apr 17 2016, 9:21 pm Programming tricks? Shit... programming tricks. Think, Kats, think... Uh... Uh... SOMETIMES I LIKE TO PRESS CTRL+K TO COMPILE MY PROJECT... Nailed it...
 <-> Apr 22 2016, 11:17 pm 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
 <-> Apr 22 2016, 11:46 pm i press ctrl+r to compile because running immediately after compile is faster workflow but if you modify icon files it doesn't count them as "project files" and i hit ctrl r out of instinct and always have to facepalm
 <-> Apr 23 2016, 12:31 am Using define macros to group commonly repeated statements together thus avoiding proc call overhead.
 <-> Apr 28 2016, 6:12 pm (Edited on Apr 29 2016, 2:57 am) 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.
 <-> Apr 28 2016, 6:16 pm In response to Optimumtact If that's true then ive been programming wrong this entire time.
 <-> Apr 28 2016, 6:22 pm (Edited on Apr 28 2016, 6:46 pm) 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  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.
 <-> Apr 28 2016, 8:03 pm 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.
 <-> Apr 28 2016, 8:10 pm 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.
 <-> Apr 29 2016, 2:57 am In response to Popisfizzy I updated with a less flippant answer
 <-> May 2 2016, 2:52 pm 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 loopfor(i=1, i<=N, ++i) total += mylist[i]// unrolled 8xvar/Nbig = N & ~7N -= Nbigfor(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
Page: 1 2 3 4 5 6