I think the one solves the other quite nicely. Saltwater will absolutely destroy all those fancy exposed-parts humanoid robots. And the beauty of it is that the homicidal killbots will take care of our gorilla problem before that.
He also seems to have confused the lossless, very large, WAV with microsoft's audio container format WMA which afaik, can contain WAV or equivalent but probably does not. Especially if the download time is reasonable.
Blow up.
(not very likely with conventional tanks. Does anyone know for composite tanks?)
Controlled slow leak.
(not a problem, but an accident will certainly leave a much bigger hole)
Significant thrust.
(There's enough energy in there to drive the car, right? so if it's all released at once, there's certainly enough energy to launch the car significant distance.)
Projectile tanks.
(if not well secured during thrusting event. much more violent and unpredictable than full vehicle thrusting)
Freezing.
(Occurs concurrently with all of the above. Obviously, with a large rupture this will be well pronounced due to the short time interval.)
Many of these are far more lethal than a gas fire, though none are as cinematically pleasing as a rich fuel-air explosion, and are less likely to destroy evidence.
The final acts were disappointing. Why was the fact that they creating an incredibly precise weapon immediately regarded as evil? In WWII, whole cities were firebombed in the hopes of maybe hitting the actual infrastructure target, as well as some psychological effect. In the current age of the smart bomb, such wholesale and inefficient use of ordnance is considered irresponsible and immoral.
Since you don't know anything about the random computer you have no control over's cache settings, why bother with drivers (or truecrypt) at all? Just use encrypted zip files or equivalent. There's no reason to bother with encrypted volumes or even "believed good" algorithms if you're just going to have plain-text copies sitting in cache or swapfile on random computers you don't own.
Y'know it's much easier if you explicitly enumerate "backing down from the government" in your list of principles. Then you can say you followed your principles whatever happens.
She played fast and loose with the definition of irony, which constitutes abuse of a word in anyone's book who would care about such things. The fact that she later admitted it and tried to cover by claiming that the real irony was that all of the examples were devoid of actual irony. Which by that definition is ironic itself since some of the examples fit the definition of irony to varying degrees of strictness.
Her whole style of music was ironic in that sense. A style I'm going to dub (not very creatively), Alternapop. Since it was called "alternative" at the time despite being quite obviously mainstream.
Ok, from my rather limited experience with HS programming contests, there is a bit of a fog over why you've been rejected, but I agree that you wouldn't want to put in input validation for the first submission. It's definitely a waste of time unless the problem specification indicates that they will be testing for that or if you can quickly see what you're doing wrong.
However if input validation moves you from "run time error" to "incorrect output" then you know specifically that either a) an assumption you made is wrong, or b) the judges are using invalid inputs.* You might have to be tricksy with your outputs (i.e. simulate normal output, but be definitely incorrect) under invalid input situations.
And that tells you that you'd be better off putting that problem at the bottom of the stack and work on the remaining ones. And also get your adviser to start hassling the judges about the test cases. You can still think about your assumptions, but if you can't immediately see what you're doing wrong, it's probably not worth it to work on a resubmit.
*Of course, I'm working under the possibly mistaken assumption that input validation is significantly simpler than the program itself.
I've always found it mildly amusing that programming contests tend to discourage good programming practices.
Those were aluminum and steel tanks. The car uses a composite tank, as is necessary to achieve the pressures needed without ridiculous weight. I'm not sure the results would be different, but there is no reason to assume they'd necessarily be the same.
Why do these new technology cars always implement features not related to the technology they're trying to demo?
I can understand the glued frame maybe (if someone can explain to me why welding a metal frame would be heaver than gluing it). As well as the fiberglass body. (though those two things would prevent me from using it as anything more than a toy, personally)
But why does it need to have "voice recognition, internet connectivity, GSM telephone connectivity, a GPS guidance system, fleet management systems, emergency systems, and of course every form of digital entertainment." As well as "information reports that extends well beyond the speed of the vehicle, and is built to integrate with external systems"
If the underlying technology is good, they should be able to put it into a conventional car. You can get super mileage to a $3 fill with gasoline, too if you're willing to travel in something small and light enough to run on <~10 hp engine. Heck, if it's small and light enough, you won't need any fuel at all, but you won't be very safe commuting in a solar racer.
There is a link to the problem set on the page in the summary. I see no limit of 100 or 64 in any aspect of this problem.
There does a appear to be a limit of 1001 lines *for each test case* however the number of test cases is unspecified.
And besides, since when do you fail to do input validation in the program itself? I know you're trying to save time in a programming contest environment, but if the program comes back with a run-time error, you should really be putting in input validation. Unless you have reason to believe you know what the problem is, in which case, why did you submit early?
You *could* use mscofig as mentioned by others and simply disable the programs that run on startup or run as services*. But using add/remove is far less likely to bork your system if you're a casual user. It's also less effective than the aforementioned registry interface.
*Although I wouldn't recommend a casual user mucking around in the registry, on exception I would make is to get disable the messenger service. I have yet to see a program that requires it, and I can't see what it was supposed to do other than provide an open port to the outside world for spammers to send fraudulent error messages through.
The simple fact is that you are entirely confused about the mechanism by which CO2 retains heat.
CO2 reduces radiative heat rejection by absorbing radiation: It happens to absorb radiation in bands not otherwise covered by atmospheric gases.
An actual greenhouse works by interrupting convection (i.e. wind). Instead of heat being carried away from your plants by bulk fluid processes, it remains in the air trapped inside. There is still some heat transfer by conduction through the glass, but that is *much* slower as air isn't very conductive of heat at all. This is the same principle on which your down winter jacket works, as well as cheap knockoff thermoses, and simple intro-to-physics-lab calorimeters.
The glass itself does absorb radiation, but the principle feature of the glass is that it allows radiation in (and out), but prevents convection out. Any radiation it "traps" is insignificant compared to the fluid processes; radiative cooling, especially at greenhouse temperatures, is extremely slow. (it goes like T^4 though so hot objects cool down very fast.)
The fact that you don't understand how it works does not mean that GW isn't happening. It simply means that you do not understand the mechanism by which you believe it works. Consequently, the solutions suggested by substandard understanding are likewise suspect, especially as they merely trade one problem for another potentially huge problem.
You're absolutely correct that we're not going to get anywhere as long as everyone's running around screaming at the top of their lungs like chicken little.
There's nothing fluffy about a gravity-satellite. Except that their vision has only one, directly above the asteroid.
Since they're continuous thrusters, gravity tug doctrine should be to put the tug in halo orbit, and put more than one. Many relatively small launches are easier than one big launch after all, and they can be replaced as they fail without losing 100% thrust. The orbit would also mean that the exhaust would be less obscured by the payload.
Indeed. However we should get out of the habit of referring to the "reduced by" metric. It makes sense if the reduction is small (say, the file size is 50-75% of the original). But when the reduction is great, it loses its usefulness.
There is a huge difference in the number of files you can store if you reduce by 99% vs. 99.99%, but at first glance, it looks like they're almost the same.
It would be better to say reduce by a factor of 100 and factor of 10,000 respectively or reduce to one hundredth and one ten-thousandth respectively. With the "reduce to" preferred as it is less ambiguous.
Slashdot Mirror
I think the one solves the other quite nicely. Saltwater will absolutely destroy all those fancy exposed-parts humanoid robots. And the beauty of it is that the homicidal killbots will take care of our gorilla problem before that.
He also seems to have confused the lossless, very large, WAV with microsoft's audio container format WMA which afaik, can contain WAV or equivalent but probably does not. Especially if the download time is reasonable.
Unfortunately, you have to use all of them at the same time to accurately reproduce the sound.
"a defining characteristic" means the condition is necessary, but not sufficient.
Your coworker? If he's finishing more work, he must be starting more work...
I think with the car, the failure modes are:
Blow up.
(not very likely with conventional tanks. Does anyone know for composite tanks?)
Controlled slow leak.
(not a problem, but an accident will certainly leave a much bigger hole)
Significant thrust.
(There's enough energy in there to drive the car, right? so if it's all released at once, there's certainly enough energy to launch the car significant distance.)
Projectile tanks.
(if not well secured during thrusting event. much more violent and unpredictable than full vehicle thrusting)
Freezing.
(Occurs concurrently with all of the above. Obviously, with a large rupture this will be well pronounced due to the short time interval.)
Many of these are far more lethal than a gas fire, though none are as cinematically pleasing as a rich fuel-air explosion, and are less likely to destroy evidence.
The final acts were disappointing. Why was the fact that they creating an incredibly precise weapon immediately regarded as evil? In WWII, whole cities were firebombed in the hopes of maybe hitting the actual infrastructure target, as well as some psychological effect. In the current age of the smart bomb, such wholesale and inefficient use of ordnance is considered irresponsible and immoral.
That violates the terms of most credit card companies. Although cars can be pretty low-margin for the dealer if you're a good negotiator.
Since you don't know anything about the random computer you have no control over's cache settings, why bother with drivers (or truecrypt) at all? Just use encrypted zip files or equivalent. There's no reason to bother with encrypted volumes or even "believed good" algorithms if you're just going to have plain-text copies sitting in cache or swapfile on random computers you don't own.
Y'know it's much easier if you explicitly enumerate "backing down from the government" in your list of principles. Then you can say you followed your principles whatever happens.
For the same reason they feel the need to impose their idea of "order" on their desk. Because something is disordered.
She played fast and loose with the definition of irony, which constitutes abuse of a word in anyone's book who would care about such things. The fact that she later admitted it and tried to cover by claiming that the real irony was that all of the examples were devoid of actual irony. Which by that definition is ironic itself since some of the examples fit the definition of irony to varying degrees of strictness.
Her whole style of music was ironic in that sense. A style I'm going to dub (not very creatively), Alternapop. Since it was called "alternative" at the time despite being quite obviously mainstream.
Ok, from my rather limited experience with HS programming contests, there is a bit of a fog over why you've been rejected, but I agree that you wouldn't want to put in input validation for the first submission. It's definitely a waste of time unless the problem specification indicates that they will be testing for that or if you can quickly see what you're doing wrong.
However if input validation moves you from "run time error" to "incorrect output" then you know specifically that either a) an assumption you made is wrong, or b) the judges are using invalid inputs.* You might have to be tricksy with your outputs (i.e. simulate normal output, but be definitely incorrect) under invalid input situations.
And that tells you that you'd be better off putting that problem at the bottom of the stack and work on the remaining ones. And also get your adviser to start hassling the judges about the test cases. You can still think about your assumptions, but if you can't immediately see what you're doing wrong, it's probably not worth it to work on a resubmit.
*Of course, I'm working under the possibly mistaken assumption that input validation is significantly simpler than the program itself.
I've always found it mildly amusing that programming contests tend to discourage good programming practices.
Those were aluminum and steel tanks. The car uses a composite tank, as is necessary to achieve the pressures needed without ridiculous weight. I'm not sure the results would be different, but there is no reason to assume they'd necessarily be the same.
Why do these new technology cars always implement features not related to the technology they're trying to demo?
I can understand the glued frame maybe (if someone can explain to me why welding a metal frame would be heaver than gluing it). As well as the fiberglass body. (though those two things would prevent me from using it as anything more than a toy, personally)
But why does it need to have "voice recognition, internet connectivity, GSM telephone connectivity, a GPS guidance system, fleet management systems, emergency systems, and of course every form of digital entertainment." As well as "information reports that extends well beyond the speed of the vehicle, and is built to integrate with external systems"
If the underlying technology is good, they should be able to put it into a conventional car. You can get super mileage to a $3 fill with gasoline, too if you're willing to travel in something small and light enough to run on <~10 hp engine. Heck, if it's small and light enough, you won't need any fuel at all, but you won't be very safe commuting in a solar racer.
There is a link to the problem set on the page in the summary. I see no limit of 100 or 64 in any aspect of this problem.
There does a appear to be a limit of 1001 lines *for each test case* however the number of test cases is unspecified.
And besides, since when do you fail to do input validation in the program itself? I know you're trying to save time in a programming contest environment, but if the program comes back with a run-time error, you should really be putting in input validation. Unless you have reason to believe you know what the problem is, in which case, why did you submit early?
Why? there is no wind, and the moon is not geologically active. I would think a pile of dust would remain a pile of dust until something hit it.
You *could* use mscofig as mentioned by others and simply disable the programs that run on startup or run as services*. But using add/remove is far less likely to bork your system if you're a casual user. It's also less effective than the aforementioned registry interface.
*Although I wouldn't recommend a casual user mucking around in the registry, on exception I would make is to get disable the messenger service. I have yet to see a program that requires it, and I can't see what it was supposed to do other than provide an open port to the outside world for spammers to send fraudulent error messages through.
The simple fact is that you are entirely confused about the mechanism by which CO2 retains heat.
CO2 reduces radiative heat rejection by absorbing radiation: It happens to absorb radiation in bands not otherwise covered by atmospheric gases.
An actual greenhouse works by interrupting convection (i.e. wind). Instead of heat being carried away from your plants by bulk fluid processes, it remains in the air trapped inside. There is still some heat transfer by conduction through the glass, but that is *much* slower as air isn't very conductive of heat at all. This is the same principle on which your down winter jacket works, as well as cheap knockoff thermoses, and simple intro-to-physics-lab calorimeters.
The glass itself does absorb radiation, but the principle feature of the glass is that it allows radiation in (and out), but prevents convection out. Any radiation it "traps" is insignificant compared to the fluid processes; radiative cooling, especially at greenhouse temperatures, is extremely slow. (it goes like T^4 though so hot objects cool down very fast.)
The fact that you don't understand how it works does not mean that GW isn't happening. It simply means that you do not understand the mechanism by which you believe it works. Consequently, the solutions suggested by substandard understanding are likewise suspect, especially as they merely trade one problem for another potentially huge problem.
I wish I had mod points to give you.
You're absolutely correct that we're not going to get anywhere as long as everyone's running around screaming at the top of their lungs like chicken little.
Ironically (perhaps) by enacting many (and many expensive) socialist measures.
However, the lack of a robots.txt is the problem that actually affects others in this case.
There's nothing fluffy about a gravity-satellite. Except that their vision has only one, directly above the asteroid.
Since they're continuous thrusters, gravity tug doctrine should be to put the tug in halo orbit, and put more than one. Many relatively small launches are easier than one big launch after all, and they can be replaced as they fail without losing 100% thrust. The orbit would also mean that the exhaust would be less obscured by the payload.
There is a link to the copyright notice, but it has a clickthrough which requires you to agree to the copyright terms before allowing you to see them.
Indeed. However we should get out of the habit of referring to the "reduced by" metric. It makes sense if the reduction is small (say, the file size is 50-75% of the original). But when the reduction is great, it loses its usefulness.
There is a huge difference in the number of files you can store if you reduce by 99% vs. 99.99%, but at first glance, it looks like they're almost the same.
It would be better to say reduce by a factor of 100 and factor of 10,000 respectively or reduce to one hundredth and one ten-thousandth respectively. With the "reduce to" preferred as it is less ambiguous.