You're right. Correlation isn't causation. But correlation is nevertheless good EVIDENCE of causation. I'm sick and tired of people parroting "correlation is not causation" every time a correlation is used as evidence for causation.
That alleged "data" in the analog groove is buried far below the noise floor of the best disc/reproduction system. The signal to noise ratio (in this context the same as dynamic range mentioned above) means any "data" that's allegedly on the disc is swamped by noise; the S/N ratio of the CD is figured as the ratio between the maximum sampled sine amplitude and the amplitude of the quantization noise. The quantization noise is the "step pattern" made by the discrete sampling, figured as subtracting the quantized signal ("sampled" to a particular amplitude representable by a discrete integer) from the original signal. You get the 96dB dynamic range often given for 16 bit sampling from the 2^-16 quantization noise (assuming full scale is 2^0), and 20*log10(1/2^-16)=96dB
The 44.1kHz/16 bit sampling of a CD is in no way an audio compromise, never mind when compared to vinyl. Higher sampling rates and widths are still useful to give more headroom when recording/mixing/mastering, but any reasonable recording fits well within a 16 bit/96dB dynamic range.
And, of course, there's a paper in the new (9/07) JAES doing double blind testing between new higher-resolution formats and good old CD-style sampling. No audible difference between the signal coming out of the player and one that undergoes a 44.1kHz/16 bit A/D/A conversion out of the higher res player.
A lot of that fuzzy tube sound is the output transformer core saturation, which is a particularly nasty and complex form of distortion that you'll never get with a direct-coupled (i.e. typical) transistor amp and is otherwise difficult to simulate in simple analog electronics.
I'll wager she didn't hear an improvement, she said something to stroke your ego and make you happy while also preempting your inevitable interrogation about the improvement.
ext3 with the dir_index feature does just fine by me, although I'm not sure what kernel version it was added in, if at all (I've got it by default in my Red Hat Enterprise Linux 4 installs).
The significant increase in unsprung weight by putting reasonably sized motors in the wheels is going to make the ride harsher than inboard (sprung) motors.
How heavy are these in-wheel motors? I couldn't find it on that website in my quick look.
The decision to move instruction-level parallelization from runtime (in the CPU, hardware, expensive) to compile-time (software, cheap on a marginal cost basis) ended up being a poor one for general-purpose computing. You save silicon not having all the fancy instruction scheduling, reordering, etc., but you lose the knowledge of the runtime environment the hardware has when you move it into the compiler.
Sure, there's a lot more processing you can do off-line in the compiler, but you also have a lot less information about how the code is actually going to be executed at compile time.
Theoretically, JIT compilers (Java and.NET bytecode to native code and Transmeta x86 to native VLIW) can do a better job because they can profile the running code and get a better handle on likely execution paths. These would be a good match to the VLIW Itaniums to compensate for them lacking that "complex" hardware to keep the execution units supplied.
The Itanium2 makes a good supercomputer chip because you can optimize your code very carefully and you've got a good idea what the data looks like and what branches will be taken, etc. at compile time.
I think EPIC is the result of flawed thinking. You hear much of moving the complexity of the OoO CPUs from "expensive" silicon into software. Yeah, that's great, but it's not really equivalent because one happens at runtime and one happens at compile time. The CPU has much more information about the code and dataset than the compiler does and can make better decisions. A better comparison would be between an OoO CPU and dynamic translation and optimization in a JIT or the Transmeta "Code Morphing" stuff (a x86 to VLIW JIT that gets excellent parallelization).
We measure octane differently. In the US we post (RON + MON)/2 on the pumps, where in Europe I think you guys just use RON which is about 5 points higher I think.
No, "Right to Work" is a political euphemism for a law that prevents labor unions from negotiating a contract with employers that prohibits them from hiring non-union laborers.
The difference is that US lines tend to use in-band signaling and get 24 lines to a DS1 whereas Europe tends to use ISDN which gets 23 lines to a DS1 with a separate line for signaling (call setup/takedown, dialing, etc.).
So the maximum usable bandwidth of the lines in the US is 56k with the degredation from the in-band signaling (which may account for the high bit).
I've worked in the medical transcription industry for some time and the providers KNOW that their work is being sent overseas. They don't know and don't care as long as their line/page rate is cheap.
I've been involved in several contract negotiations where outsourcing was explicitly brought up and it was made very clear that they don't care how the work gets done as long as they get it cheap. These are large hospitals, too.
The UltraSPARC III isn't exactly the fastest CPU around; it gets thoroughly trounced by the P4, Athlon XP, MP, and POWER4, among others. We'll have to wait and see until the dual-core Ultras come out early next year.
Slashdot Mirror
You're right. Correlation isn't causation. But correlation is nevertheless good EVIDENCE of causation. I'm sick and tired of people parroting "correlation is not causation" every time a correlation is used as evidence for causation.
That alleged "data" in the analog groove is buried far below the noise floor of the best disc/reproduction system. The signal to noise ratio (in this context the same as dynamic range mentioned above) means any "data" that's allegedly on the disc is swamped by noise; the S/N ratio of the CD is figured as the ratio between the maximum sampled sine amplitude and the amplitude of the quantization noise. The quantization noise is the "step pattern" made by the discrete sampling, figured as subtracting the quantized signal ("sampled" to a particular amplitude representable by a discrete integer) from the original signal. You get the 96dB dynamic range often given for 16 bit sampling from the 2^-16 quantization noise (assuming full scale is 2^0), and 20*log10(1/2^-16)=96dB
The 44.1kHz/16 bit sampling of a CD is in no way an audio compromise, never mind when compared to vinyl. Higher sampling rates and widths are still useful to give more headroom when recording/mixing/mastering, but any reasonable recording fits well within a 16 bit/96dB dynamic range.
And, of course, there's a paper in the new (9/07) JAES doing double blind testing between new higher-resolution formats and good old CD-style sampling. No audible difference between the signal coming out of the player and one that undergoes a 44.1kHz/16 bit A/D/A conversion out of the higher res player.
A lot of that fuzzy tube sound is the output transformer core saturation, which is a particularly nasty and complex form of distortion that you'll never get with a direct-coupled (i.e. typical) transistor amp and is otherwise difficult to simulate in simple analog electronics.
I'll wager she didn't hear an improvement, she said something to stroke your ego and make you happy while also preempting your inevitable interrogation about the improvement.
Well, for your particular example:
;)
SELECT * FROM foo LEFT OUTER JOIN y ON foo.bar = y.x AND y.z > 4 WHERE y.x IS NULL
But I'm sure there are nasty cases where you can't substitute joins readably or maybe at all.
ext3 with the dir_index feature does just fine by me, although I'm not sure what kernel version it was added in, if at all (I've got it by default in my Red Hat Enterprise Linux 4 installs).
I found it. The lighest one seems to be 185kg, way too heavy to put in a car wheel and maintain a reasonable ride.
The significant increase in unsprung weight by putting reasonably sized motors in the wheels is going to make the ride harsher than inboard (sprung) motors.
How heavy are these in-wheel motors? I couldn't find it on that website in my quick look.
HP already has spun off the test and measurement division (cf. Agilent).
The decision to move instruction-level parallelization from runtime (in the CPU, hardware, expensive) to compile-time (software, cheap on a marginal cost basis) ended up being a poor one for general-purpose computing. You save silicon not having all the fancy instruction scheduling, reordering, etc., but you lose the knowledge of the runtime environment the hardware has when you move it into the compiler.
.NET bytecode to native code and Transmeta x86 to native VLIW) can do a better job because they can profile the running code and get a better handle on likely execution paths. These would be a good match to the VLIW Itaniums to compensate for them lacking that "complex" hardware to keep the execution units supplied.
Sure, there's a lot more processing you can do off-line in the compiler, but you also have a lot less information about how the code is actually going to be executed at compile time.
Theoretically, JIT compilers (Java and
The Itanium2 makes a good supercomputer chip because you can optimize your code very carefully and you've got a good idea what the data looks like and what branches will be taken, etc. at compile time.
I think EPIC is the result of flawed thinking. You hear much of moving the complexity of the OoO CPUs from "expensive" silicon into software. Yeah, that's great, but it's not really equivalent because one happens at runtime and one happens at compile time. The CPU has much more information about the code and dataset than the compiler does and can make better decisions. A better comparison would be between an OoO CPU and dynamic translation and optimization in a JIT or the Transmeta "Code Morphing" stuff (a x86 to VLIW JIT that gets excellent parallelization).
IBM used (uses?) both PowerPC and POWER chips in its lineup. I've got an RS6000 box with a PowerPC logo on it right here...
Gallium melts around room temperature.
We measure octane differently. In the US we post (RON + MON)/2 on the pumps, where in Europe I think you guys just use RON which is about 5 points higher I think.
No, "Right to Work" is a political euphemism for a law that prevents labor unions from negotiating a contract with employers that prohibits them from hiring non-union laborers.
Since when was necrophillia associated with mid-life crises?
Sorry buddy, but Billy Bob Clinton wasn't too shabby academically, even if he did like getting hummers from ugly fat chicks in the oval office.
There's nothing preventing you from moving your entire computer, data and all.
Now that's transfer rate.
How do you moderate an entire article as flamebait? ;)
Cool stuff, but the write-up is a little, uhm, polarizing?
The difference is that US lines tend to use in-band signaling and get 24 lines to a DS1 whereas Europe tends to use ISDN which gets 23 lines to a DS1 with a separate line for signaling (call setup/takedown, dialing, etc.).
So the maximum usable bandwidth of the lines in the US is 56k with the degredation from the in-band signaling (which may account for the high bit).
I've worked in the medical transcription industry for some time and the providers KNOW that their work is being sent overseas. They don't know and don't care as long as their line/page rate is cheap.
I've been involved in several contract negotiations where outsourcing was explicitly brought up and it was made very clear that they don't care how the work gets done as long as they get it cheap. These are large hospitals, too.
Yes, really. A common mistake, but still a mistake.
VW GmbH became VW AG in '60, 5 years before the first "Audi" model was ever produced.
VAG is Volkswagen Aktiengesellschaft (think Inc. or Ltd.), not Volkswagen Audi Group.
And they're going to give as much as possible to the schools in the form of their products which doesn't cost them anything (whereas cash does).
The UltraSPARC III isn't exactly the fastest CPU around; it gets thoroughly trounced by the P4, Athlon XP, MP, and POWER4, among others. We'll have to wait and see until the dual-core Ultras come out early next year.
Still no instruction reordering...