Live data from Hacker News

Potato paradox

en.wikipedia.org

51–60 of 142 posts

Re: Potato paradox

#51
post #48
post #37

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

[deleted]

Let's say your program takes 100 seconds, of which 99% is spent in f(). Then if you optimize f() such that only 98% of the total time spent in f, then:

    orig_time = 100
    orig_not_f = 0.01 * orig_time = 1
    new_f = 0.98 * new_total
    new_total = new_f + orig_not_f
    new_total = 0.98 * new_total + orig_not_f
    new_total - 0.98 * new_total = orig_not_f
    0.02 * new_total = 1
    new_total = 1 / 0.02 = 50

Re: Potato paradox

#52
post #41
post #28

Another angle on this problem: How much water must you add to the potatoes to make them 100% water? Of course, you can add all the water in the universe and they'll still not be 100% water. The water-percent increment just gets smaller and smaller, the more water you add. This "potato paradox" illustrates the same effect, but in the other direction, where a small relative decrease yields a large absolute decrease.

If you add water to the potato infinitely (hypothetically speaking), does the water percentage approach 100%? And also, does the solid percentage approach 0%?

No.

You won't have a potato anymore. But you won't have water anymore either.

You'll have a black hole.

Re: Potato paradox

#53
post #5

A much more important example of this than "martian potatoes" is uranium enrichment. Natural uranium is ~1% U235; bombs need 90+% U235. So when you've enriched it from 1% to 2% it doesn't seem like you've made a lot of progress towards 90. If instead of enriching U235 you think of it as eliminating U238, though, then you've done half of the work.

If instead of enriching U235 you think of it as eliminating U238, though, then you've done half of the work. That's the wrong way to think of it though. The right way to measure progress is in terms of Separative Work Units: https://en.wikipedia.org/wiki/Separative_work_units If you start with 10000 kg of natural (0.7%) uranium and you want to separate it into 45 kg of highly-enriched (90% U235) uranium and 9955 kg o…

[deleted]

Re: Potato paradox

#54
post #37

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

beautiful

Re: Potato paradox

#55

Earlier quoted context omitted.

And https://en.wikipedia.org/wiki/Fair_cake-cutting

I guess mine is sort of an anti-food-related math concept, then! https://en.wikipedia.org/wiki/No_free_lunch_theorem

https://en.wikipedia.org/wiki/Blancmange_curve

Re: Potato paradox

#57
q:100 people are seated in a room. 99% of them are enginners and 1% managers. How many engineers should leave the room to make it 98% enginners and 2% managers? a:50

Re: Potato paradox

#58
post #22
post #2

This isn't a paradox at all. It's a slightly non-intuitive result.

Since you're arguing terminology, I'll just quote the second dictionary definition: a seemingly absurd or self-contradictory statement or proposition that when investigated or explained may prove to be well founded or true. "in a paradox, he has discovered that stepping back from his job has increased the rewards he gleans from it"

[deleted]

Re: Potato paradox

#59
post #37

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

If you understand Amdahl's law, it's not suprising at all!

Re: Potato paradox

#60
post #37

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 is an interesting observation, and confirms the way I optimise code:

1) Create a benchmark (some code that performs the task that I want to optimise), and measure the absolute time it needs.

2) Use a profiler to see where most of the time is spent. Optimise that code.

3) Run benchmark to see if your optimisation are effective.

Or, in other words: the percentage tells you where to focus your effort. The absolute time tells you how successful your optimisation is.

Post reply on HN