81–90 of 142 posts
Earlier quoted context omitted.
No. You won't have a potato anymore. But you won't have water anymore either. You'll have a black hole.
Is potato-blackhole distinguishable from same mass water black-hole?
https://en.wikipedia.org/wiki/No-hair_theorem
We don't know if black holes have hair, so the answer to your question is "We don't know".
https://en.wikipedia.org/wiki/Black_hole_information_paradox
Why is this a "paradox"? Not sure what this applies to either. It's not even counterintuitive.
Quine (who never went by QuineQuine, more's the pity) had an answer to this problem: Differentiate between veridical and falsidical paradoxes.
A veridical paradox is a paradox of the linked type: It appears absurd, but there is no problem in the logic, so it doesn't lead to a contradiction. Therefore, the conclusion is valid.
A falsidical paradox is similar to the Liar Paradox: It appears absurd and has a hole in the logic, such that there is no conclusion (it contradicts itself, and is also called an antinomy, as in the Liar Paradox) or the conclusion is invalid (as in one of the many fake proofs that 1 = 0). In Quine's words:
> In a falsidical paradox there is always a fallacy in the argument, but the proposition purportedly established has furthermore to seem absurd and to be indeed false.
Earlier quoted context omitted.
Slowing down the rest of the program? :)
Well yeah, just add a wait loop somewhere else
A fresh lake gets infested with algae and the amount of algae doubles every day. The algae covers the whole lake in 10 days. How many days did it take the algae to cover half the lake?
http://metaist.com/blog/2010/02/disease-screening-base-rate-...
Neat. This bumps up my list of food-related maths from 3 to 4. So far: https://en.wikipedia.org/wiki/Ham_sandwich_theorem https://en.wikipedia.org/wiki/Pizza_theorem https://en.wikipedia.org/wiki/Layer_cake_representation
Earlier quoted context omitted.
And https://en.wikipedia.org/wiki/Fair_cake-cutting
Let's not forget https://en.wikipedia.org/wiki/Spaghetti_sort
This is not that uncommon when optimizing code. Your program is slow so you profile it, and find out that f() takes 99% of the time. So you work a lot to optimize f(), and re-profiling shows that now f() takes 98% of the time. Doesn't seem that impressive after all the work you've put into optimizing f(), but your program is actually twice as fast :)
This just shows that the percentage of total time a function takes is really not the thing you should be looking at when optimizing code and you want to know how much faster your code really is. For example, say your function f() takes 100% of the time. You then make it twice as fast. You look at the percentage, and, surprise, it still is taking 100% of the time!
It's understandable though in the context of the sequence of actions you might be going through as a tinkerer (as opposed to a scientist). You start with a list of functions and the % of time they take. Improving the top one will have the biggest effect, so this is a good thing to look at when deciding what to to. Then you go back to the same list afterwards.
I can see this (and lots of variations of this) happening