Oops, I misread your equation. It's not 7x, but 7/x, of course. But apart from my first sentence (which claims you had been correct), I don't have to take away anything from my post.
What does that mean? (Not a native speaker, I honestly don't know. Maybe it's asking for the solution to 7x = 0.11? I read the transcript excerpt, but it's not clear there either.)
You got it correct. They encountered 7 polar bears. They assumed they have seen 11% of all bears. The question was the total number of bears under this assumption. Eric May correctly got 63 by approximating 0.11 by 1/9 -- 64 would be a better estimate, but since it's an estimate, one bear more or less doesn't make a big difference anyway -- after Charles Monnett, also correctly, estimated the number of dead bears to 27 (3*9).
What followed is obviously a case of failed communication, and confusion arising from it. Lynn Gibson is trying to clear that confusion. From the last lines quoted by JoshuaZ (I didn't go to the original source, since the relevant part seems to be covered in that post), I conclude that the confusion obviously was caused by Charles Monnett making the 11% assumption only for the three dead bears (which may be related to the fact that the four living ones had been observed a week earlier, which he noted before; but that's speculation).
Even the same compiler will give you a different binary output, with different optimization flags or diffrerent architecture flags.
If you intend to compare the generated binaries, you of course use the same flags.
Even with the same platform and optimization flags, a compiler might give you a different assembly for the same algorithm depending on specified alignments and/or instruction optimization.
This is about comparing output from compiling the same source code.
And yeah, your post also assumes that the cpu itself where you run the compilers isn't flawed or tampered in any way.
Sure. However there you can do the same: Run the thing on several CPUs and compare. You could even go to a different platform and cross-compile to your destination platform.
But will they continue it when they notice that those pupils are then able to think not only about algorithms, but also about the stuff politicians tell?
Actually I didn't know that work. But then, thinking about it and formally proving it are two things, so it's nice that this idea has also been formally proven.
You're assuming that two different compilers would output identical binary images, but why would they?
No, I'm not. I only assumed that two correctly working compilers would output functionally equivalent code (what I tacitly did assume was that the source-provided compiler doesn't invoke undefined behaviour, though). Note that I did not propose to compare the output of the two different compilers, but to compare the output of the one source provided compiler compiled with two different binary-provided compilers.
So say you have the source of gcc, and binary versions of Microsoft C and Borland C.
Step 1: You compile the gcc source code with Microsoft C (let's call the resulting binary vgcc). Step 2: You compile the gcc source code with vgcc (let's call the resulting binaty gvgcc). Step 3: You compile the gcc source code with Borland C (resulting in bgcc). Step 4: You compile the gcc source code with bgcc (resulting in gbgcc). Step 5: You compare gvgcc with gbgcc.
If both Microsoft C and Borland C correctly translate the gcc source code (and the gcc source code contains no undefined behaviour), then vgcc and bgcc, while not the same, have equivalent behaviour. Especially they both translate the gcc source code into the same executable. In other words, gvgcc and gbgcc must be binary identical.
However, even if you get a free compiler like gcc, you either get the source (which you then have to compile yourself, shifting the problem to the compiler you use to compile it) or you get a precompiled version where you have to trust that whoever compiled it did not insert a backdoor.
Actually the only way to be completely sure without trusting anyone is to actually study the generated machine code (that's assuming you can trust your computer to faithfully execute that, of course). Of course in practice nobody would go that far (and few would even have the resources to do so), but instead there's one point where you put trust in (possibly the compiler+linker), and from there on you just go on.
Of course, another way would be to bootstrap by writing yourself an assembler in machine code, then a compiler for the source language of that compiler in assembly (using your self-written assembler), and then use that to compile the compiler you got in source (and to get an optimized compiler, compile the compiler with that compiler again). But again, few people have the resources to do so.
Well, one way to increase trust would be to build the source-provided compiler with two different compilers, then use both of these generated compilers to re-compile the compiler, and then compare the generated executables. If only one starting compiler has been compromised, or if both have been compromised independently, then the compiler executables thus generated will differ. Thus if the compiler executables generated that way are the same, they are very likely not compromised, or else there's a conspiracy and both original compilers contain the same malicious modification. The more separate compilers you add to the mix, the less likely a conspiracy becomes (and moreover if some compiler is really compromised, you'll also learn which one -- although you cannot exclude the possibility that the difference is just due to a "self-propagating bug" instead of due to malicious code, but then, neither is desired).
Dosn't look like sincere regret at all! more like a forced one...
No, he sincerely regrets that he thought he could get away with it. He won't do that again. At least not until he has analysed how he got caught, and has found ways to avoid that.
Is a solar powered pocket calculator a "pretty show piece"?
As long as the rest of the computer needs conventional power, a solar-powered CPU doesn't give you any advantage. What I think they actually wanted to show is "see, our processor needs that little energy that you can even put it on a solar cell!" Given that processors are usually hidden somewhere in a case, having a solar cell attached to it wouldn't usually do much good anyway. Of course if all components of the computer can be made to consume that little energy, the whole computer may be solar cell driven; however in that case you'd certainly not put separate cells for each component; instead you'd power the whole computer from a central solar cell unit.
Also note that processors needing little energy are useful even without solar cells.
If it passes in front of the star (resp. one of them), then it can be determined how much light it blocks, and thus how large it is. I don't know if this applies here, though.
Slashdot Mirror
What I didn't find in either article: What resolution did those satellites have?
Either way ... polar bears are good eatin'
I prefer not to be eaten by one. :-)
Oops, 40%, of course (and that "&" should have been a "%" as well).
Reminder to self: Proofread!
No, of = "divided by".
If 2 of 5 people are ill, is that 20% (2/5), or 1000& (2*5)?
Oops, I misread your equation. It's not 7x, but 7/x, of course. But apart from my first sentence (which claims you had been correct), I don't have to take away anything from my post.
No, seven of is always a quotient, not a product.
11 percent is 11 of 100 is 0.11. (per cent = of hundred, literally)
The equation therefore is 7/x=11/100.
What does that mean? (Not a native speaker, I honestly don't know. Maybe it's asking for the solution to 7x = 0.11? I read the transcript excerpt, but it's not clear there either.)
You got it correct. They encountered 7 polar bears. They assumed they have seen 11% of all bears. The question was the total number of bears under this assumption. Eric May correctly got 63 by approximating 0.11 by 1/9 -- 64 would be a better estimate, but since it's an estimate, one bear more or less doesn't make a big difference anyway -- after Charles Monnett, also correctly, estimated the number of dead bears to 27 (3*9).
What followed is obviously a case of failed communication, and confusion arising from it. Lynn Gibson is trying to clear that confusion. From the last lines quoted by JoshuaZ (I didn't go to the original source, since the relevant part seems to be covered in that post), I conclude that the confusion obviously was caused by Charles Monnett making the 11% assumption only for the three dead bears (which may be related to the fact that the four living ones had been observed a week earlier, which he noted before; but that's speculation).
Seven of ~1.571428... percent is 11 percent. What shittily-worded question.
Your text doesn't make sense.
7 of 63.6... is 11 percent. If it shall be an integer, 7 of 64 is the best approximation.
To not repeat myself, I just refer you to my previous answer.
If you intend to compare the generated binaries, you of course use the same flags.
This is about comparing output from compiling the same source code.
Sure. However there you can do the same: Run the thing on several CPUs and compare. You could even go to a different platform and cross-compile to your destination platform.
But will they continue it when they notice that those pupils are then able to think not only about algorithms, but also about the stuff politicians tell?
Actually I didn't know that work. But then, thinking about it and formally proving it are two things, so it's nice that this idea has also been formally proven.
No, I'm not. I only assumed that two correctly working compilers would output functionally equivalent code (what I tacitly did assume was that the source-provided compiler doesn't invoke undefined behaviour, though). Note that I did not propose to compare the output of the two different compilers, but to compare the output of the one source provided compiler compiled with two different binary-provided compilers.
So say you have the source of gcc, and binary versions of Microsoft C and Borland C.
Step 1: You compile the gcc source code with Microsoft C (let's call the resulting binary vgcc).
Step 2: You compile the gcc source code with vgcc (let's call the resulting binaty gvgcc).
Step 3: You compile the gcc source code with Borland C (resulting in bgcc).
Step 4: You compile the gcc source code with bgcc (resulting in gbgcc).
Step 5: You compare gvgcc with gbgcc.
If both Microsoft C and Borland C correctly translate the gcc source code (and the gcc source code contains no undefined behaviour), then vgcc and bgcc, while not the same, have equivalent behaviour. Especially they both translate the gcc source code into the same executable. In other words, gvgcc and gbgcc must be binary identical.
How many of those animals run on two legs?
I'm confused.... are you agreeing or disagreeing?
Or maybe your idea of 'debate' is just to insult the other person.
Maybe he's politician.
Red stories are an old hat.
Yeah, and many children form a "gun" with their hand, point it at someone else and say "bang, you're dead". Few of them become killers.
However, even if you get a free compiler like gcc, you either get the source (which you then have to compile yourself, shifting the problem to the compiler you use to compile it) or you get a precompiled version where you have to trust that whoever compiled it did not insert a backdoor.
Actually the only way to be completely sure without trusting anyone is to actually study the generated machine code (that's assuming you can trust your computer to faithfully execute that, of course). Of course in practice nobody would go that far (and few would even have the resources to do so), but instead there's one point where you put trust in (possibly the compiler+linker), and from there on you just go on.
Of course, another way would be to bootstrap by writing yourself an assembler in machine code, then a compiler for the source language of that compiler in assembly (using your self-written assembler), and then use that to compile the compiler you got in source (and to get an optimized compiler, compile the compiler with that compiler again). But again, few people have the resources to do so.
Well, one way to increase trust would be to build the source-provided compiler with two different compilers, then use both of these generated compilers to re-compile the compiler, and then compare the generated executables. If only one starting compiler has been compromised, or if both have been compromised independently, then the compiler executables thus generated will differ. Thus if the compiler executables generated that way are the same, they are very likely not compromised, or else there's a conspiracy and both original compilers contain the same malicious modification. The more separate compilers you add to the mix, the less likely a conspiracy becomes (and moreover if some compiler is really compromised, you'll also learn which one -- although you cannot exclude the possibility that the difference is just due to a "self-propagating bug" instead of due to malicious code, but then, neither is desired).
No, he sincerely regrets that he thought he could get away with it. He won't do that again. At least not until he has analysed how he got caught, and has found ways to avoid that.
As long as the rest of the computer needs conventional power, a solar-powered CPU doesn't give you any advantage. What I think they actually wanted to show is "see, our processor needs that little energy that you can even put it on a solar cell!" Given that processors are usually hidden somewhere in a case, having a solar cell attached to it wouldn't usually do much good anyway. Of course if all components of the computer can be made to consume that little energy, the whole computer may be solar cell driven; however in that case you'd certainly not put separate cells for each component; instead you'd power the whole computer from a central solar cell unit.
Also note that processors needing little energy are useful even without solar cells.
You want to sell the sun?
If it passes in front of the star (resp. one of them), then it can be determined how much light it blocks, and thus how large it is. I don't know if this applies here, though.
No, but they built planets there.
Not quaack. Arrrr!
That's unfair!
This is no vibrator. This is taking energy out of vibrations. Therefore it's an anti-vibrator.