Live data from Hacker News

Potato paradox

en.wikipedia.org

131–140 of 142 posts

Re: Potato paradox

#131
A better or more shocking way to understand how the numbers interplay is, to reframe this like this. Imagine a vegetable mystical-vegetable, that had 99.9% water and weighed 100 lbs. If I dehydrated it such that it now has 99% water, what would be its weight? Yes, its 10 lbs.

Re: Potato paradox

#132

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

You should bump it up to five; the ham sandwich theorem references a "pancake theorem" involving the bisection of two layers instead of the ham sandwich's three.

Re: Potato paradox

#133

Earlier quoted context omitted.

> Naturally, if you can look at a program which is now twice as fast and be unimpressed you are looking at the wrong metric. Or, a computer scientist would say, the right one. The actual speed doesn't matter as much as the complexity. In reality, it does, in the end; but it's also important to consider the type of optimization you're doing, and not just stop at being impressed with twice as fast. For example, a primi…

It's like grocery shopping and coupons, however. If you shouldn't be calling the function, then even a 99% reduction is not useful in that context. Would you rather call a slow function, a fast function, or skip it altogether? (A coupon only saves you money if you would buy the item in the first place.)

And then no watter what, if you're broke you will go to all lengths jumping through hoops and calculating tiny scores even if it's a waste of time... Because you're broke :p

Sorry, what's the context? Admin / account and login areas don't care / matter much, because they want it :p they'll wait...

Re: Potato paradox

#134
Took me an embarrassingly long time to figure this out. The key issue that I've latched on to is that they've lost 99 - 98 = 1% of their water content, which is false.

Re: Potato paradox

#135
post #117

Earlier quoted context omitted.

Nice! Except it doesn't quite work for me because the vowel sounds don't match. (For me the second and third "a"s in "banana" are like the "a" in "arm", whereas the two in "Banach" are like the "a" in "at", and those are quite different sounds. Other people may differ -- and indeed I may be mispronouncing "Banach".)

As an American, I'll never understand how the English can indiscriminately throw /ɑː/'s into perfectly normal words, yet when faced with a foreign import that actually asks for it, willfully refuse.

Maybe I made more than one mistake in my description (I definitely made one: the third "a" in "banana" is of course a schwa, not the vowel in "arm") -- but the "a"s I put in "Banach" are (modulo incompetence) pretty much exactly the ones you'll find by clicking the "listen" link after Banach's name at the start of his Wikipedia page. So I'm not sure what you mean about "a foreign import that actually asks for it". And I just checked the etymology of "banana", and the likely Wolof original has exactly one /ɑː/ in it, in the same place as I put one. But, see above, I misdescribed how I say "banana" so I may have caused confusion.

Re: Potato paradox

#136
post #117

Earlier quoted context omitted.

Nice! Except it doesn't quite work for me because the vowel sounds don't match. (For me the second and third "a"s in "banana" are like the "a" in "arm", whereas the two in "Banach" are like the "a" in "at", and those are quite different sounds. Other people may differ -- and indeed I may be mispronouncing "Banach".)

Your banana is like arm? Mine is like umbrella (the u). Buh-nah-nuh.

Whoops. Mine's the same. Two schwas and one a-as-in-arm.

[EDITED to add: Er, except that the first vowel in my "umbrella" isn't the same as I think you're putting in yours. In IPA, my umbrella is /ʌmbrɛlə/ and my banana is /bənɑːnə/, unless I've made mistakes there.]

Re: Potato paradox

#137
This is only a paradox because the framing of the question misleads people , partly by mentioning potatoes, into thinking that they are discussing something that one might actually do in the way it is described. In reality if you did this with real physical objects the part where it says: "You let them dehydrate until they're 98 percent water" hides a process in which one of the operations would involve picking up the potatoes. At this point you would notice that they were much lighter than before.

So as stated it is a trick question, the kind of parlour game found in old books of puzzles.

Finally, it seems to be a common failure of education to allow people to go through their 'mathematical' training and leave them with the impression that 'percent' is some kind of dimension when in fact it is short hand for a ratio: y is x percent of z. If z is not specified then you don't know what y is regardless of how much effort you put into discussing x.

So I suspect that in real life there are not many occasions when the paradox appears surprising.

Re: Potato paradox

#138

Earlier quoted context omitted.

> Naturally, if you can look at a program which is now twice as fast and be unimpressed you are looking at the wrong metric. Or, a computer scientist would say, the right one. The actual speed doesn't matter as much as the complexity. In reality, it does, in the end; but it's also important to consider the type of optimization you're doing, and not just stop at being impressed with twice as fast. For example, a primi…

> Or, a computer scientist would say, the right one. The actual speed doesn't matter as much as the complexity. Except, as an engineer would say, in practice the complexity doesn't matter as much as constant factors and the time and cost of design, implementation, and execution.

Neither are strictly correct in isolation. Of course the complexity matters, and of course the coefficient and reality factors matter. Often focusing on a core algorithm that's far too complex will save you time, money, and grief down the road. Engineering is, of course, knowing how to make the tradeoffs; but it certainly also involves knowing when one of those smart tradeoffs is time invested in getting your algorithmic complexity down.

Re: Potato paradox

#139

Earlier quoted context omitted.

> Naturally, if you can look at a program which is now twice as fast and be unimpressed you are looking at the wrong metric. Or, a computer scientist would say, the right one. The actual speed doesn't matter as much as the complexity. In reality, it does, in the end; but it's also important to consider the type of optimization you're doing, and not just stop at being impressed with twice as fast. For example, a primi…

There is a sorting network called AKS which has O(log(n)) depth. Batcher's Odd-Even Mergesort has a depth of O(log^2(n)). Which is better? In all cases where you can fit n in the total memory capacity of the earth, Batcher's network is vastly superior. Constants matter a whole lot more than you might think. I'm not arguing against revising algorithms to look for better complexity classes, but if you rewrite your algo…

For sure. But that's a far more nuanced argument than "twice as fast." :)

Re: Potato paradox

#140

Earlier quoted context omitted.

It's like grocery shopping and coupons, however. If you shouldn't be calling the function, then even a 99% reduction is not useful in that context. Would you rather call a slow function, a fast function, or skip it altogether? (A coupon only saves you money if you would buy the item in the first place.)

And then no watter what, if you're broke you will go to all lengths jumping through hoops and calculating tiny scores even if it's a waste of time... Because you're broke :p Sorry, what's the context? Admin / account and login areas don't care / matter much, because they want it :p they'll wait...

I've experienced slow admin/internal UIs that were so slow and inefficient they brought down the consumer site... and yes, I'm talking algorithmically. Processing data in triple nested loops because it was "quick and easy" and then the data grew beyond a relatively small threshold (something like 10k records was where it started to break).
Post reply on HN