If you're ever in Southern California, go to In-N-Out. It's a fast food joint that only serves Burgers, Fries, Shakes, and Drinks.
They have plenty of variety within those bounds though... How many fast-food joints can make you an Animal Protein 4x4?
To stay remotely on-topic, I'll note that the decaf espresso I drink at night (Peet's Decaf Sumatra) probably gains me far more health through a good night sleep than I lose from HDL effects. (And it's caffeinated double-shots in the morning, baby!!)
Especially that it's doubly redundant: No coffee is ever caffeinated.
A local cafe makes a drink called a "Shot in the Dark," basically brewed coffee with a shot of espresso added. Furthermore, it would certainly be caffeinated coffee if it's brewed using This.
So ditch them or limit the duration to a more reasonable timeframe (given the current rate of advancement).
Just last week I was granted a patent, from an application I submitted to the USPTO in February 2001. That's four and a half years. Somehow I think the timeframe of patent examination/acceptance would also have to be reduced, if 7-year patents are to be in any way meaningful. I do however agree that 7 years is a much more reasonable duration than 17 years, for software-related patents.
First puzzle: Given a rectangle 2 units high and 200 units long, it's trivial to pack 400 unit-diameter circles into it, in a rectangular arrangement. The question is, how can you fit the 401'st circle? (There is a way, but it's non-obvious; this is not a trick question!)
Second puzzle (given to me by my discrete mathematics professor to solve over spring break, which I did): Sam and Polly are logicians. A Martian comes down in a spacecraft and announces, "I'm thinking of two integers x and y, where 3 <= x <= y <= 97. I'll tell their sum to Sam, and their product to Polly." He does so, and leaves. The following conversation ensues:
Sam: "You can't possibly know what x and y are."
Polly: "I do now."
Sam: "Now I do, too."
Since it's an infinite sequence, you can separate the left-most X and rest still equals 2. Thus X^2 = 2, so X = sqrt(2).
Disprufe(TM) by contradiction:
1. Suppose sqrt(2) ^ sqrt(2) ^ sqrt(2) ^... = n.
2. Then, sqrt(2) ^ (sqrt(2) ^ sqrt(2) ^...) = n.
3. Hence, sqrt(2) ^ n = n.
4. Therefore, n obviously equals 4, because sqrt(2) ^ 4 = 4.
5. Hence, sqrt(2) ^ sqrt(2) ^ sqrt(2) ^... equals 4, not 2, so it can't be the solution to the original problem.
Is the damsel correct? Or is the knight's plan sound?
This is a great puzzle. STOP READING if you don't want to know the answer.
The solution rests with the fact that there must be some a priori bounded probability distribution of the offered amounts of gold; it can't be infinitely variable. (Similar to how you can't "choose an integer at random," with uniform distribution, without first specifying a range.) If the amount on the knight's piece of paper is within a factor of two of the upper limit, he can only lose (a large amount) by switching. And if it's within a factor of two of the lower limit, he can only gain (a small amount) by switching. These endpoints exactly cancel the roughly 25% expected gain from switching from amounts in between. Since the knight doesn't know if his first paper is on the highest end of the probability distribution, or on the lowest end, or in between, his overall expectation for switching turns out to be even money.
When doing stuff like this, I've had success with taking 8 bits at a time to index a table which returns the number of bits set to 1. Repeat until the limit is equalled or exceeded; work backwards to get the exact position. Bigger but faster.
True, except that the data I'm dealing with tends to be fairly sparse (most bits are zero), and my code steps through one SET bit per iteration, not one logical bit. E.g., finding the third-lowest set bit of 0b0100000100010000 takes 3 steps, not 15. So in practice, stepping through the data 8 bits at a time with table lookup (I've tried) winds up being slower than stepping one set bit at a time in registers; the function rarely takes more than 3-4 steps, and the theoretical worst case of 32 steps (finding the 32nd set bit of 0xFFFFFFFF) is vanishingly unlikely. (Even the backward jump instruction after 8 steps is almost never reached.) Vector logic is fast enough that computing population counts 128 bits at a time is a win, but from there, stepping through set bits seems to be fastest.
For data where higher percentages of the bits are set, you're right that table lookup might win out. Either way, it's ironic that so many function bottlenecks like this could be implemented _blindingly_ much faster in silicon, on a custom chip. FWIW, the Altivec instruction set seems to be much better designed for clever abuse like this than SSE; I'm in the process of a long and painful switch, and my ported vector code runs about half as fast per clock on x86. Don't get me started...:-/
The reason they bother is that you can't enter neutered dogs in certain AKA dog shows.
Neuticles are just one step less silly than These. Can you imagine if they started requiring these at auto shows? (Compact-sized, SUV-sized, and, er, Hummer-sized?) Might be a problem on low-riders, though...
Unless you know that n is usually large, wouldn't this be more efficiently implemented with cntlzw?
It would be if I were looking for the n'th leading one, but this code is looking for the n'th trailing one. (e.g. for 0b0010011001011100, the 3rd trailing one is in the fifth-lowest bit.) The equivalent code sequence for leading ones is in fact more complicated, requiring three arithmetic instructions and a branch per iteration. (cntlzw, shift, xor, branch).
I actually use this code as part of an algorithm where I have a very large (e.g. 65k-element) packed single-bit histogram array, and need to find the position of (say) the 1000th set bit. Vector instructions can do a coarse population-count from one end fairly efficiently, but once it's narrowed down to a 32-bit region, it comes down to slicing and dicing. My code operates by clearing the rightmost set bit in each iteration (x & (x - 1)), then at the end, isolating the needed bit (x ^ (x - 1)) and using cntlzw to find its position. To clear the leftmost set bit, you need three instructions: first get its position with cntlzw, then shift 0x80000000 right by that number of bits, and finally XOR to clear the bit. (If there's a shorter sequence, I haven't found it.)
(oh, and for the troll responder-- you are quite spectacularly wrong. But thanks for the giggle.)
The PPC architecture has a special-purpose count register with specialized branch instructions relating to it; e.g., the assembly mnemonic 'bdnz' means "decrement the count register by one, and branch if it has not reached zero." I've used this in some pretty weird loops, including this one that broke the Codewarrior 9.3 compiler (fixed in 9.4.) This computes the location of the n'th trailing one in a 32-bit integer. Pardon my weak attempt at formatting this in HTML:
mtctr n; bdz end
top: subi pd, p, 1; and p, p, pd; bdz end
subi pd, p, 1; and p, p, pd; bdz end
subi pd, p, 1; and p, p, pd; bdz end
subi pd, p, 1; and p, p, pd; bdz end
subi pd, p, 1; and p, p, pd; bdz end
subi pd, p, 1; and p, p, pd; bdz end
subi pd, p, 1; and p, p, pd; bdz end
subi pd, p, 1; and p, p, pd; bdnz top
end: }
return __cntlzw(p ^ (p - 1));
}
The idea was that the instruction stream should stay as linear as possible; most of the time the branches are not taken, and execution falls through to the next line of code. Ironically (siliconically?), the entire function could probably be implemented in a single cycle in silicon; shoehorning bitwise functions like this into standard instructions tends to be extremely wasteful. Perhaps FPGA's will make an end run around this at some point. I've also tried this function with a dynamically-calculated jump at the beginning, similar to the case statement logic in the article.
Hmm, I had a point I was trying to make with this post, but now it's escaped my mind...:-)
Actually, a typical welding arc is brighter than the sun, and doesn't take nearly that much power. Now, to be as bright as the surface of the sun...
When you look at the sun, what do you think you're looking at? That's right, the surface of the sun. The brightness of the sun per angle doesn't change whether you're viewing from earth, or standing right next to it, apart from filtering effects of the atmosphere, which reduces the visible-light brightness by perhaps a factor of two at noon. (Someone know the actual numbers?) Other stars are just as bright as the sun per angle, despite being light-years away; the only reason they don't burn tiny holes in our retinae at night is that the angle is so tiny, and our eyes don't have sufficient focusing power to resolve them completely. (They are very, very subpixel, so to speak.) I wonder if any large telescopes have ever been damaged by starlight?
And how am I even supposed to know how much improvement this provides over my current monitor when the article does not provide a screenshot of the new monitor!?
The irony here is that your current monitor has only a 500:1 contrast ratio, so you would not be able to see the improved contrast anyway. I always think about this when seeing ads for TV's, on TV; it's the equivalent to listening to an ad for CD-quality audio on a cassette tape.
Slashdot Mirror
If you're ever in Southern California, go to In-N-Out. It's a fast food joint that only serves Burgers, Fries, Shakes, and Drinks.
They have plenty of variety within those bounds though... How many fast-food joints can make you an Animal Protein 4x4?
To stay remotely on-topic, I'll note that the decaf espresso I drink at night (Peet's Decaf Sumatra) probably gains me far more health through a good night sleep than I lose from HDL effects. (And it's caffeinated double-shots in the morning, baby!!)
"...Chemical burns, ruined clothes, 11 years, half a million dollars..."
Sounds like Michael Jackson's life story.
Not to mention the color change.
Especially that it's doubly redundant: No coffee is ever caffeinated.
A local cafe makes a drink called a "Shot in the Dark," basically brewed coffee with a shot of espresso added. Furthermore, it would certainly be caffeinated coffee if it's brewed using This.
Ferrous Spew-Lure, You're My Hero...
(ok, it's a stretch.)
Look, up in the sky! It's the Great Pumpkin, Charlie Brown!
If they run out, they'll have to start using combinations of Greek Letters, naming the storms after fraternities/sororities:
"Miami Threatened by Delta Nu!"
"Phi Beta Kappa creates chaos in Palm Beach!"
That way the papers can reuse the same headline for two different stories.
When they said the nano was redesigned from scratch, I guess they weren't kidding.
The REAL question is whether IP drilling operations in ANWR, Alaska will buy us any time.
Yes, the range could certainly be extended by adding a few drill bits.
So ditch them or limit the duration to a more reasonable timeframe (given the current rate of advancement).
Just last week I was granted a patent, from an application I submitted to the USPTO in February 2001. That's four and a half years. Somehow I think the timeframe of patent examination/acceptance would also have to be reduced, if 7-year patents are to be in any way meaningful. I do however agree that 7 years is a much more reasonable duration than 17 years, for software-related patents.
First puzzle: Given a rectangle 2 units high and 200 units long, it's trivial to pack 400 unit-diameter circles into it, in a rectangular arrangement. The question is, how can you fit the 401'st circle? (There is a way, but it's non-obvious; this is not a trick question!)
Second puzzle (given to me by my discrete mathematics professor to solve over spring break, which I did): Sam and Polly are logicians. A Martian comes down in a spacecraft and announces, "I'm thinking of two integers x and y, where 3 <= x <= y <= 97. I'll tell their sum to Sam, and their product to Polly." He does so, and leaves. The following conversation ensues:
Sam: "You can't possibly know what x and y are."
Polly: "I do now."
Sam: "Now I do, too."
Find x and y.
Since it's an infinite sequence, you can separate the left-most X and rest still equals 2. Thus X^2 = 2, so X = sqrt(2).
... = n. ...) = n. ... equals 4, not 2, so it can't be the solution to the original problem.
;-)
Disprufe(TM) by contradiction:
1. Suppose sqrt(2) ^ sqrt(2) ^ sqrt(2) ^
2. Then, sqrt(2) ^ (sqrt(2) ^ sqrt(2) ^
3. Hence, sqrt(2) ^ n = n.
4. Therefore, n obviously equals 4, because sqrt(2) ^ 4 = 4.
5. Hence, sqrt(2) ^ sqrt(2) ^ sqrt(2) ^
What's wrong with this logic?
How thick can the line be? If the pen tip is more than an inch wide, you only need to draw one line.
Is the damsel correct? Or is the knight's plan sound?
This is a great puzzle. STOP READING if you don't want to know the answer.
The solution rests with the fact that there must be some a priori bounded probability distribution of the offered amounts of gold; it can't be infinitely variable. (Similar to how you can't "choose an integer at random," with uniform distribution, without first specifying a range.) If the amount on the knight's piece of paper is within a factor of two of the upper limit, he can only lose (a large amount) by switching. And if it's within a factor of two of the lower limit, he can only gain (a small amount) by switching. These endpoints exactly cancel the roughly 25% expected gain from switching from amounts in between. Since the knight doesn't know if his first paper is on the highest end of the probability distribution, or on the lowest end, or in between, his overall expectation for switching turns out to be even money.
As long as there are no goatse images on, I guess I'm okay with it.
Well, chips these days do have gigantic heatsinks...
So this means that every time I spank the monkey, I'm committing hundreds of millions of acts of patent violation?
Just don't do it in the public domain...
I guess that means Teri Hatcher will be getting into MY pants!
Forget the tribe. My pants have spoken!
When doing stuff like this, I've had success with taking 8 bits at a time to index a table which returns the number of bits set to 1. Repeat until the limit is equalled or exceeded; work backwards to get the exact position. Bigger but faster.
:-/
True, except that the data I'm dealing with tends to be fairly sparse (most bits are zero), and my code steps through one SET bit per iteration, not one logical bit. E.g., finding the third-lowest set bit of 0b0100000100010000 takes 3 steps, not 15. So in practice, stepping through the data 8 bits at a time with table lookup (I've tried) winds up being slower than stepping one set bit at a time in registers; the function rarely takes more than 3-4 steps, and the theoretical worst case of 32 steps (finding the 32nd set bit of 0xFFFFFFFF) is vanishingly unlikely. (Even the backward jump instruction after 8 steps is almost never reached.) Vector logic is fast enough that computing population counts 128 bits at a time is a win, but from there, stepping through set bits seems to be fastest.
For data where higher percentages of the bits are set, you're right that table lookup might win out. Either way, it's ironic that so many function bottlenecks like this could be implemented _blindingly_ much faster in silicon, on a custom chip. FWIW, the Altivec instruction set seems to be much better designed for clever abuse like this than SSE; I'm in the process of a long and painful switch, and my ported vector code runs about half as fast per clock on x86. Don't get me started...
The reason they bother is that you can't enter neutered dogs in certain AKA dog shows.
Neuticles are just one step less silly than These. Can you imagine if they started requiring these at auto shows? (Compact-sized, SUV-sized, and, er, Hummer-sized?) Might be a problem on low-riders, though...
Unless you know that n is usually large, wouldn't this be more efficiently implemented with cntlzw?
It would be if I were looking for the n'th leading one, but this code is looking for the n'th trailing one. (e.g. for 0b0010011001011100, the 3rd trailing one is in the fifth-lowest bit.) The equivalent code sequence for leading ones is in fact more complicated, requiring three arithmetic instructions and a branch per iteration. (cntlzw, shift, xor, branch).
I actually use this code as part of an algorithm where I have a very large (e.g. 65k-element) packed single-bit histogram array, and need to find the position of (say) the 1000th set bit. Vector instructions can do a coarse population-count from one end fairly efficiently, but once it's narrowed down to a 32-bit region, it comes down to slicing and dicing. My code operates by clearing the rightmost set bit in each iteration (x & (x - 1)), then at the end, isolating the needed bit (x ^ (x - 1)) and using cntlzw to find its position. To clear the leftmost set bit, you need three instructions: first get its position with cntlzw, then shift 0x80000000 right by that number of bits, and finally XOR to clear the bit. (If there's a shorter sequence, I haven't found it.)
(oh, and for the troll responder-- you are quite spectacularly wrong. But thanks for the giggle.)
The PPC architecture has a special-purpose count register with specialized branch instructions relating to it; e.g., the assembly mnemonic 'bdnz' means "decrement the count register by one, and branch if it has not reached zero." I've used this in some pretty weird loops, including this one that broke the Codewarrior 9.3 compiler (fixed in 9.4.) This computes the location of the n'th trailing one in a 32-bit integer. Pardon my weak attempt at formatting this in HTML:
static uint32 nth_trailing_one(register uint32 p, register uint32 n) { end: }
return __cntlzw(p ^ (p - 1));
}
The idea was that the instruction stream should stay as linear as possible; most of the time the branches are not taken, and execution falls through to the next line of code. Ironically (siliconically?), the entire function could probably be implemented in a single cycle in silicon; shoehorning bitwise functions like this into standard instructions tends to be extremely wasteful. Perhaps FPGA's will make an end run around this at some point. I've also tried this function with a dynamically-calculated jump at the beginning, similar to the case statement logic in the article.
Hmm, I had a point I was trying to make with this post, but now it's escaped my mind...
Actually, a typical welding arc is brighter than the sun, and doesn't take nearly that much power. Now, to be as bright as the surface of the sun...
When you look at the sun, what do you think you're looking at? That's right, the surface of the sun. The brightness of the sun per angle doesn't change whether you're viewing from earth, or standing right next to it, apart from filtering effects of the atmosphere, which reduces the visible-light brightness by perhaps a factor of two at noon. (Someone know the actual numbers?) Other stars are just as bright as the sun per angle, despite being light-years away; the only reason they don't burn tiny holes in our retinae at night is that the angle is so tiny, and our eyes don't have sufficient focusing power to resolve them completely. (They are very, very subpixel, so to speak.) I wonder if any large telescopes have ever been damaged by starlight?
And how am I even supposed to know how much improvement this provides over my current monitor when the article does not provide a screenshot of the new monitor!?
The irony here is that your current monitor has only a 500:1 contrast ratio, so you would not be able to see the improved contrast anyway. I always think about this when seeing ads for TV's, on TV; it's the equivalent to listening to an ad for CD-quality audio on a cassette tape.
BFH has the specific meaning of Big F***ing Hammer among engineers.
Don't forget the corollary: If brute force isn't working, you're not using enough of it.
Is everything we know about genetics off-base? (no pun intended)
;-)
I thought it was a great pun.
Yep... A friend of mine has the last name Sohm, and does color photography... his company name is Chromosohm.
Tell a mere pun, get modded up allele.
Next thing you know, those wacky astronomers will be naming a plutino Homer.
Appropriate, considering they're at least 400 feet from home plate.
(On the other hand, due to their eccentric orbits, one could construe that they're in foul territory.)