Technically, those are quasi-experiments (approximately, relying on the experiments already done by nature rather than setting up your own experiment) and they are rightly seen as of somewhat lesser value than controlled experiments
You have to be careful here. Controlled experiments can also give unexpected results because of a conscious or unconscious bias somewhere. Confounding factors abound.
The classic recent example is HRT. Controlled experiments showed that HRT reduced heart disease. It's now accepted that HRT has a net negative health benefit in the population at large (but that doesn't mean that it's not a benefit for some). There was a selectional bias in the controlled studies even though the researchers took every care to try to avoid any bias.
Another example: cycling helmets. There's an infamous paper by TRT showing that cycle helmets prevent 88% of head injuries. (You'll find that figure quoted all over the place). Unfortunately, using _exactly_ the same data you find that cycle helmets also prevent >80% of knee injuries. The fundamental problem with the paper was that it was really considering the injury risk between white middle class children riding in parks (who predominantly wore helmets) against black poor children riding in the street (who didn't wear helmets).
Every single country that has brought in a mandatory cycle helmet law (and enforced it) has seen the head injury risk _increase_ (most saw a net decrease in injuries but a much larger decrease in the numbers of cyclists post law) and head injury rates are _positively_ correlated with helmet wearing rates.
There's been no good research (to my knowledge) to explain why helmeted cyclists are more at risk. There are numerous hypotheses, from increased risk of rotational injury due to the increased size of the head to risk compensation. I only know of one tiny study (researcher in Bath, UK) who has attempted any measurements at all. His study is much too small (and he was the primary subject) to draw any robust conclusions but he found that cars passed a helmeted cyclist several inches closer than an unhelmeted one. That would imply that if it is risk compensation then it's not all down to the cyclist taking more risks with a helmet and so cannot be (completely) allowed for by the cyclist regardless of what a cyclist might claim.
The problem is you are causing me to make a $200+ decision in 0.5 seconds.
The problem is that you need to take some more driver training.
You NEVER need to make a decision like that when approaching any set of lights.
case 1. You cannot see the lights because they're around a corner. You're driving at a safe speed to stop comfortably in the distance you can see to be clear. At the point you can see the lights you will easily be able to stop if they change at that moment because they could just as easily be a broken down truck across the road and you're going to have to stop.
case 2. The lights are red when you first see them. You release (some of) the throttle to minimize fuel consumption as you approach the lights and hope they will change to green before you have to start braking to a stop. But even if they do change to green as you approach you'll still be ready to stop for any red light jumpers coming the other way.
case 3. The lights are green. You assess the road conditions etc for what the safe speed through the junction is. If there are cars stopped at the other reds then you are reasonably safe that someone isn't going to crash the lights just as you get there so your speed can possibly be a little higher. If you cannot see then you slow down a bit to give you a bit of breathing room. You then, having chosen your safe speed assess at what point ahead it's no longer safe to stop, is there someone tailgating you, is there gravel or sand visible on the road that might mean you don't want to brake too hard unless it's a real emergency. You then drive to that point. Prior to that if something (anything) happens up ahead that you don't understand, expect, or the lights to go amber you're going to stop (or at least slow down until you understand what you can see). Beyond that point it's only the unexpected that you're going to react to, the lights go to amber and you're going to carry on. You've already assessed that that is the safe option before the lights changed.
Driving is all about assessing the road ahead so that you are always ready with your next action. Of course things can go wrong and you can need to slam on the brakes. But once the danger is over you need to stop and ask yourself what you could do differently to avoid getting into that situation in the future. (and this applies regardless of who's fault it is. The best drivers are so aware of what is happening around them that the other car doesn't even realize they've nearly caused an accident.)
We still don't have the data we need to make a comparison.
What you have to remember is that if one car stops correctly then every car behind it will. This doesn't apply to cyclists who can nearly always get to the red light past any cars.
Try the following (adjust as you see fit to get whatever result you want to get:-)
Assume that 50% of motorists will go through on red if the car in front of them doesn't stop. The other 50% will stop. (same as is quoted for cyclists)
Watch the junction for 1000 cycles of the lights.
In 500 cases there will be no cars going through on red. That will leave 500 cases where there is at least 1 car going through on red. Of those 500 there will be 250 where the first car after the one that goes through stops and 250 where at least two cars go through. Of those 250 there will be 125 where the first car after the two that went through stops and 125 where at least three cars go through.
If we carry on like this then we find that on average only one car goes through on red for each change of the lights.
Now if you've ever watched a junction in the UK like this where there is a steady stream of traffic the cars are always fairly close together. My quick mental estimate gives a separation (nose to nose) of about 1 second. Therefore in three seconds of red there is time for about three cars to go through. Therefore to even see a red light jumper you need to see four cars jump the red.
Now it just so happens that of those 1000 measurements above, average 1 car jumping the lights, 688 of those cars will occur in a case where there's 1-3 cars jumping the lights, i.e. no 3 seconds plus drivers. The remaining 312 occuring on the fourth or more car.
If 10% go through on red after 3 seconds and a further 20% go through between 0 and 3 seconds then there should be roughly twice as many jumpers in the 0-3 cars jump the lights range as in the 4+ cars jump the lights. And 312 isn't far off half of 688.
Of course, I've made a huge assumption that the probability of a car jumping the lights is independent of how long the light has been red. But, in practice, like cyclists, I think that the red light jumping motorists actually stop once the other traffic has started. But cyclists can often proceed when it would be impossible for a car to do so due to the enormously larger footprint of the car.
So it's not surprising that we see a similar probability of red light jumping from motorists and cyclists. They're both people with the same wants and desires.
AIUI, in the US they've been shortening the amber phase to the point where it's taking an emergency stop to avoid crossing the line on red.
I'm not aware of this happening in the UK. Almost every red light camera is on a 30mph road. I've never seen one on a road faster than 40mph. Amber phases are usually three seconds and almost never even as short as two seconds.
This all adds up to the only people who are ever caught by red light cameras in the UK are those who are blatantly ignoring the amber phase.
I can't find the original press release now but this RAC survey: http://news.bbc.co.uk/1/hi/uk/3005364.stm counted motorists as "scrambling through on amber" if the light had been _red_ for less than three seconds. Unfortunately, AFAIAA, the data for motorists going through on red has never been released. One hypothesis for why the raw data was suppressed is that this was really a study intending to show how bad cyclists were relative to other road users but the results didn't really support that claim.
We then have to ask what happens if you vibrate the semiconductor in a non-uniform but static gravitational field.
The ultimate success would be a gravity shield where we could setup standing waves that nulled out the gravitational field. Even if it turned out that the energy required to do this matched the gravitational potential energy of any object that had it's gravity nulled it would make a fantastic addition to a space elevator, the climbers would now only need to carry enough energy to overcome friction on their way up.
More precisely, if the experimenter can freely choose the directions in which to orient his apparatus in a certain measurement, then the particle's response (to be pedantic--the universe's response near the particle) is not determined by the entire previous history of the universe.
end quote
I've not read the whole thing yet but it sounds like they've managed to prove that if free will exists then there is no non-local hidden variable theorem compatible with the results of QM.
Debit cards are protected too. I've had my card details stolen and used, and I got my money back. I've had bad (non-existent) service from a few companies, and the bank has given me my money back. In no case has my money just been "gone". I don't have a credit card at all, and I've never lost money from an online transaction. Less FUD please.
It's not FUD.
Under the consumer credit act, when credit is extended for a purchase by a consumer, (for at least 100GBP) the credit company becomes jointly and severally liable for the completion of the contract.
That means that if the supplier goes bankrupt you can still get your money back from the credit company. Even if the supplier doesn't go bankrupt but just doesn't supply the goods you can still sue the credit company for your loss and then leave it up to them to get the money back from the supplier.
This automatically applies to all credit cards. It also applies to debit cards if you extend an overdraft in order to do the purchase. (It is the use of credit that is important)
Some visa debit cards also provide the same protection when not using an overdraft. This is a courtesy from the bank and is not required by law. (AIUI Visa is moving to requiring anyone supplying a visa debit card to offer this protection. I do not know if that has completed yet.)
This is independent of any redress you might have if your card is stolen and/or used fradulently. In that case the card supplier has a duty of care to you (e.g. verify signatures etc) and so you have a potential claim against the card supplier independent of the consumer credit act.
It's the summer ice extent that matters. It's dark in the winter so any albedo effect is irrelevant.
The ice melts during the summer. So if you've only got 1ft thick ice then it will melt before the winter freeze restarts. If you've got 100ft thick ice then (in the past) the winter freeze restored the thinning due to the summer melt.
That's not happening now. You can argue that summer 2007 was a freak year for ice extent. 2008 wasn't, and yet the summer 2008 minimum was barely more than the 2007 minimum.
That's the problem with single year ice (which also tends to be more salty and so melts at a lower temperature)
If there is one thing I'll complain about, it's the choice of the value 0
The choice of the value 0 in the computer is by the compiler, not the C language.
Infact, on AS400 the null pointer is not all bits zero - which makes a mess of code that attempts to memset structures to zero and then tries to test for null pointers. A pointer with all bits zero is NOT null on that platform.
Note that if(!ptr) works fine as a test for null, just that:
memset(&ptr, 0, sizeof ptr); if(!ptr) printf("Ptr is null\n"); else { dereference ptr } will crash.
Thanks, wow... so, doesn't that mean they broke functionality that worked in previous revisions of C?
?
No functionality broken. You can't use a const int to define an array size in C prior to C99 at all. (That's where this entire subthread started - someone was commenting about the use of #define rather than const int which is a reasonable criticism of C++ code but not C code)
It is an(other) area where C and C++ will forever behave differently (I assume).
$ cat compiler.c #include
struct c { char c[2]; };
int test(void) {
struct s { struct c { char c[1]; } s; };
struct c t;
return 1//**/2
+sizeof t.c; }
int main(void) {
switch(test())
{
case 1: printf("c89\n"); break;
case 2: printf("c99\n"); break;
case 3: printf("c++\n"); break;
default: printf("Unknown\n"); break;
}
return 0; }
$ gcc -std=c99 -o test test.c test.c: In function `main': test.c:7: error: variable-sized object may not be initialized test.c:7: warning: excess elements in array initializer test.c:7: warning: (near initialization for `data') $ g++ -o test test.c $
I can't tell much from the code on the link, but I do see #define used for constants which is no longer appropriate (yet is EXTREMELY common to see). C99 had the const keyword in it, probably even before that.
I don't know where to start here.
const has been in C since c89.
const int SIZE=4; int data[SIZE];
is fine in C++ and does the same as using a #define for SIZE.
It doesn't work in C prior to C99.
In C99 it defines a VLA - i.e. it's identical to using int SIZE=4; and not using const for the array parameter.
2002, 2003 were record lows compared to previous years.
2007, 2008 were record lows[1] even when compared against the 2002, 2003 lows.
Personally, I find it scary that 20 years ago climate scientists were saying a century for the Arctic to be ice free in summer. Then they changed that to the mid 21st century. Now they're talking decades.
(Note that there is some confusion - you have to be careful when people are saying the north pole might be ice free. Sometimes they are just referring to the north pole itself - 2008 was never expected to have an ice free summer but, due to ice drift and the ice actually at the north pole being first year ice there was a chance that that ice might melt in 2008 making the pole ice free even though the Arctic wasn't going to be.)
Tim.
[1] for the pedants 2008 wasn't a record because 2007 was lower. Not sure whether both of 2002,2003 was a record year and I can't be bothered to go and find the exact numbers.
Then a bug is discovered in the game rendering engine that causes actual delivered framerate to be understated by somewhere between 20-50%...... with the new compiler.
So you quickly send out an announcement saying that the latest data is suspect. Once you've understood the flaw you'll have good data that can accurately be compared with the archived data from previous tests that is all still good.
I know. Terrible isn't it. Every single working physicist hung up their boots and gave up the day Einstein published his Special Relativity paper. What with the QM crowd as well everybody was screwed. There weren't any physicists at all left and it was the man in the street who had always been saying that Newton was a load of balls who stepped in and took physics forwards into the 20th century.
Einstein is an excellent example - he didn't believe in the uncertainly principle. So certain he was that it was wrong that he proved if dpdx > h then dEdt > h as well. He was wrong about the uncertainty principle but that doesn't make his proof wrong, in fact we only understand QM tunnelling because of this.
Exactly the same with climate scientists. If new data arrives that completely upsets the apple cart of global warming that won't render all their knowledge and experience useless. It will be them who explain what this sudden turnabout actually means to us. The fact that (almost) all of them do not believe that data will appear is no more a problem than no physicist believes that we'll be able to communicate faster than light.
Deniers don't just use a single data point. They use every year since 1998 - and point out that every one of those years is cooler than 1998. That's a lot of data points, right? All those cool years (compared to 1998) can't be outliers, can they?
I'm assuming this was sarcasm, but just in case it's not:
1998 is the outlier. It was pretty much at the peak of both the solar and El nino cycles and was an extreme on top of that.
Currently we're around the minimum of the solar and La nina.
Its mass for a start. If that was known then it would either have already been found (LEP or Fermilab) or will be found (CERN) or won't be found (yet) because we'd know where to look for it.
We have a good idea of what sort of range its mass is likely to have but that's not certain. Some physicists are even hoping that it won't be found, pointing to a much larger mass and interesting new physics to explore.
We're approaching a nadir much like classical physics pre 1905. Are we destined to now spend our time dotting the 'i's and crossing the 't's or is there something as revolutionary as relativity and quantum physics just around the corner?
Those, however, all use embedded Linux distros. They don't use a desktop distro and then pull phone-specific add-ons, which I think was the parent poster's point.
Don't think it would work anyway. I use debian but I use my own installer (which starts with an ext3 dump of the minimal system you can install - basically a debootstrap then remove every package that doesn't require the "Yes, do as I say!" response to remove it)
My ext3 dump (uncompressed) rolls in at 72960000 bytes (as of the last build) - note that there is no kernel or modules in this.
It can obviously be made a lot smaller fairly easily - 25MB of that comes from/usr/share/locale/. But carrying an extra 25Mb of "junk" around for a desktop system makes sense. For an embedded system it's crazy. (another 6MB from zoneinfo)
Of course each package could be separated. Now you get passwd-core, passwd-locale-zh_TW, login-core, login-locale-dz etc with passwd, login being meta packages that pull in all the locales.
There's about 4MB of man pages, despite the fact that man is not installed. Again the packages could be split but, again, it's a lot of extra work to maintain.
I suspect that actually much of this splitting could be automated if someone really wanted to. But is there enough demand for it, especially as I expect anyone working on a system where they really need to care about getting things pared down will be deleting individual files they don't want/need?
Torture doesn't work either except as a tool to get somebody to admit to things you've already decided you want them to admit to or as a tool of terror. That is why the KGB used it.
Russian Professor: "Who wrote chaika?" (the seagull) Student: "I don't know". Professor: "Useless. Incompetent."
One week later Professor: "Name a work by Chekhov" Student: "I don't know any" Professor: "Get out and learn something about Russian literature"
Another week later. Professor: "An easy question. Who wrote War and Peace?" Student: "Err... I don't know." pause Student: "But I do know something." Professor: "Yes?" Student: "It wasn't me" Professor: "GET OUT!"
professor walks out of class muttering under his breath. KGB officer: "Professor. Is there a problem?" Professor: "Just one of my students." KGB officer: "Oh? Is he criticising the rodina?" Professor: "Nothing like that. I just asked him who wrote War and Peace. And you know what he said?" KGB officer: "No?" Professor: "IT WASN'T ME! He said he knew something. He said he knew he hadn't written War and Peace." KGB officer: "Hmmm. I can see that's a bit of a problem student." Professor: "Indeed!"
one month later KGB officer: "Professor. You remember that student who said he hadn't written War and Peace." Professor: "Yes?" KGB officer: "We've been talking to him. It's taken a month but he has finally admitted that he did write War and Peace."
In other words, it's fine to steal things as long as they're of low value. I'm fairly certain the hotel *could* have me arrested for stealing their soap, it's just not usually worth their time.
In the hotels I usually stay in you're invited to take the soap/shampoo/conditioner etc.
I've got some rather nice shampoo and conditioner at home now from my most recent stay in a hotel, ironically, one that used to be a prison and I was staying in one of the cells (actually three cells knocked into a single room) with the original metal studded door (although you can open the door from the inside and the peephole looks out rather than in)
A lot of FOSS projects fall into a similar mentality and lose sight of their objectives. Rather than writing a great program for the community, it's a great program for the core users. It doesn't matter if the project doesn't serve the needs of anyone else
Obviously there are some people (especially students) who have a lot of time on their hands, love to program, and want a big project to get involved with.
But those same people then go on to full time programming jobs. Even when working full time it can take months and months and years to get to grips with an existing big project from your employer and most programmers are not prepared to give up all their free time to do the same for a big OS project. (Many "professional" programmers never really get to grips with the project they are on which is why you find so many "bug fixes" that actually only fix the symptom - this may or may not be a good commercial decision, personally I think not because eventually that "symptom fix" causes another problem and then someone first has to rediscover the "symptom fix" which is usually some weird bit of code somewhere/* Don't know why but length is one character too long here */ length--; (usually without the comment!), remove it, then find the original problem that caused that hack and finally fix the original problem properly)
Unix got it so right. A small task to solve a small problem. You want to be able to diff two files but ignore ALL whitespace differences (rather than just white space differences at the start and end of the line) and it's probably not going to take an experienced programmer more than an hour or two to add that functionality, including finding the source code, working out how to compile it etc. Feeding it upstream then becomes fairly simple to do.
Want to have a search in open office that ignores all white space when doing the search. I've not looked at open office source at all but I'd guess an experienced programmer would probably have to allow an entire weekend just to get to grips with compiling and installing openoffice (especially as they will want to be able to run their patched version alongside the package installed version). Now they need to find the search and replace code. If it's a one off for themselves they may be able to hack it so that search and replace always ignores white space, but if they want to feed it upstream then they're going to have to learn how to change dialogs, how to get at those flags, how to save the defaults (IIRC open office remembers these flag settings the next time you bring up a dialog, Excel doesn't which is a pain when you're doing a something like "paste special" where Excel keeps resetting your selection of what you actually want to paste)
I don't know what the solution is. Maybe Open Office needs a "framework" like the kernel is to the GNU utilities. Now search and replace can be a "package" that gets installed. I want to change the way search and replace works and I've only got to look at a few thousand lines of code. (c.f. Sendmail and milters.)
I've fed patches upstream when I've found bugs. There's a fix in the postgresql ODBC driver from me (an obscure corner case; IIRC an ODBC driver should return no records found when it does an update and doesn't update any records. It was returning OK which is what it should return when it has updated records and this difference from the ODBC spec happened to break an application I was trying to get to work with postgresql)
Debian *does* just work, for me, because I can see what's going on.
It's the "*does* just work" that's so valuable to me. I don't mind spending hours getting something working, but once it's working I expect it to stay working.
I run my own news server (inn, then inn2) and every night I get a status email. From 2001 to the present day there have been just 7 days when I haven't got that email. 6 of them were back in 2002 because I allowed/var to completely run out of disk space and didn't notice straight away. One was in 2004 (I don't know why, the "Daily Usenet report from Feb 5 04:15:05 to Feb 6 04:15:04 is missing)
That's nearly 3000 days of continuous running without a team of people ready to respond as soon as there's a problem. Kernel updates, package updates all happen automatically at night, I don't have a "sandbox" where I test stuff first which obviously I'd want if this was a production system.
In those 3000 days, disks have been replaced as they start showing problems, the motherboard replaced twice etc. but the software "just keeps working".
This is real scary. And it goes to prove that bad guys always come up with new ways to steal. I don't believe there is a technical solution to this arms race.
A good start would be for banking sites to work with Javascript turned off, and, maybe, even suggest you turn off Javascript while using online banking.
Requiring you to turn it _ON_ is insane, but extremely common.
Slashdot Mirror
Technically, those are quasi-experiments (approximately, relying on the experiments already done by nature rather than setting up your own experiment) and they are rightly seen as of somewhat lesser value than controlled experiments
You have to be careful here. Controlled experiments can also give unexpected results because of a conscious or unconscious bias somewhere. Confounding factors abound.
The classic recent example is HRT. Controlled experiments showed that HRT reduced heart disease. It's now accepted that HRT has a net negative health benefit in the population at large (but that doesn't mean that it's not a benefit for some). There was a selectional bias in the controlled studies even though the researchers took every care to try to avoid any bias.
Another example: cycling helmets. There's an infamous paper by TRT showing that cycle helmets prevent 88% of head injuries. (You'll find that figure quoted all over the place). Unfortunately, using _exactly_ the same data you find that cycle helmets also prevent >80% of knee injuries. The fundamental problem with the paper was that it was really considering the injury risk between white middle class children riding in parks (who predominantly wore helmets) against black poor children riding in the street (who didn't wear helmets).
Every single country that has brought in a mandatory cycle helmet law (and enforced it) has seen the head injury risk _increase_ (most saw a net decrease in injuries but a much larger decrease in the numbers of cyclists post law) and head injury rates are _positively_ correlated with helmet wearing rates.
There's been no good research (to my knowledge) to explain why helmeted cyclists are more at risk. There are numerous hypotheses, from increased risk of rotational injury due to the increased size of the head to risk compensation. I only know of one tiny study (researcher in Bath, UK) who has attempted any measurements at all. His study is much too small (and he was the primary subject) to draw any robust conclusions but he found that cars passed a helmeted cyclist several inches closer than an unhelmeted one. That would imply that if it is risk compensation then it's not all down to the cyclist taking more risks with a helmet and so cannot be (completely) allowed for by the cyclist regardless of what a cyclist might claim.
Tim.
The problem is you are causing me to make a $200+ decision in 0.5 seconds.
The problem is that you need to take some more driver training.
You NEVER need to make a decision like that when approaching any set of lights.
case 1. You cannot see the lights because they're around a corner. You're driving at a safe speed to stop comfortably in the distance you can see to be clear. At the point you can see the lights you will easily be able to stop if they change at that moment because they could just as easily be a broken down truck across the road and you're going to have to stop.
case 2. The lights are red when you first see them. You release (some of) the throttle to minimize fuel consumption as you approach the lights and hope they will change to green before you have to start braking to a stop. But even if they do change to green as you approach you'll still be ready to stop for any red light jumpers coming the other way.
case 3. The lights are green. You assess the road conditions etc for what the safe speed through the junction is. If there are cars stopped at the other reds then you are reasonably safe that someone isn't going to crash the lights just as you get there so your speed can possibly be a little higher. If you cannot see then you slow down a bit to give you a bit of breathing room. You then, having chosen your safe speed assess at what point ahead it's no longer safe to stop, is there someone tailgating you, is there gravel or sand visible on the road that might mean you don't want to brake too hard unless it's a real emergency. You then drive to that point. Prior to that if something (anything) happens up ahead that you don't understand, expect, or the lights to go amber you're going to stop (or at least slow down until you understand what you can see). Beyond that point it's only the unexpected that you're going to react to, the lights go to amber and you're going to carry on. You've already assessed that that is the safe option before the lights changed.
Driving is all about assessing the road ahead so that you are always ready with your next action. Of course things can go wrong and you can need to slam on the brakes. But once the danger is over you need to stop and ask yourself what you could do differently to avoid getting into that situation in the future. (and this applies regardless of who's fault it is. The best drivers are so aware of what is happening around them that the other car doesn't even realize they've nearly caused an accident.)
Tim.
We still don't have the data we need to make a comparison.
What you have to remember is that if one car stops correctly then every car behind it will. This doesn't apply to cyclists who can nearly always get to the red light past any cars.
Try the following (adjust as you see fit to get whatever result you want to get :-)
Assume that 50% of motorists will go through on red if the car in front of them doesn't stop. The other 50% will stop. (same as is quoted for cyclists)
Watch the junction for 1000 cycles of the lights.
In 500 cases there will be no cars going through on red. That will leave 500 cases where there is at least 1 car going through on red.
Of those 500 there will be 250 where the first car after the one that goes through stops and 250 where at least two cars go through.
Of those 250 there will be 125 where the first car after the two that went through stops and 125 where at least three cars go through.
If we carry on like this then we find that on average only one car goes through on red for each change of the lights.
Now if you've ever watched a junction in the UK like this where there is a steady stream of traffic the cars are always fairly close together. My quick mental estimate gives a separation (nose to nose) of about 1 second. Therefore in three seconds of red there is time for about three cars to go through. Therefore to even see a red light jumper you need to see four cars jump the red.
Now it just so happens that of those 1000 measurements above, average 1 car jumping the lights, 688 of those cars will occur in a case where there's 1-3 cars jumping the lights, i.e. no 3 seconds plus drivers. The remaining 312 occuring on the fourth or more car.
If 10% go through on red after 3 seconds and a further 20% go through between 0 and 3 seconds then there should be roughly twice as many jumpers in the 0-3 cars jump the lights range as in the 4+ cars jump the lights. And 312 isn't far off half of 688.
Of course, I've made a huge assumption that the probability of a car jumping the lights is independent of how long the light has been red. But, in practice, like cyclists, I think that the red light jumping motorists actually stop once the other traffic has started. But cyclists can often proceed when it would be impossible for a car to do so due to the enormously larger footprint of the car.
So it's not surprising that we see a similar probability of red light jumping from motorists and cyclists. They're both people with the same wants and desires.
Tim.
AIUI, in the US they've been shortening the amber phase to the point where it's taking an emergency stop to avoid crossing the line on red.
I'm not aware of this happening in the UK. Almost every red light camera is on a 30mph road. I've never seen one on a road faster than 40mph. Amber phases are usually three seconds and almost never even as short as two seconds.
This all adds up to the only people who are ever caught by red light cameras in the UK are those who are blatantly ignoring the amber phase.
I can't find the original press release now but this RAC survey:
http://news.bbc.co.uk/1/hi/uk/3005364.stm
counted motorists as "scrambling through on amber" if the light had been _red_ for less than three seconds. Unfortunately, AFAIAA, the data for motorists going through on red has never been released. One hypothesis for why the raw data was suppressed is that this was really a study intending to show how bad cyclists were relative to other road users but the results didn't really support that claim.
Tim.
We then have to ask what happens if you vibrate the semiconductor in a non-uniform but static gravitational field.
The ultimate success would be a gravity shield where we could setup standing waves that nulled out the gravitational field. Even if it turned out that the energy required to do this matched the gravitational potential energy of any object that had it's gravity nulled it would make a fantastic addition to a space elevator, the climbers would now only need to carry enough energy to overcome friction on their way up.
Tim.
quote
More precisely, if the experimenter can freely choose the directions in which to orient his apparatus in a certain measurement, then the particle's response (to be pedantic--the universe's response near the particle) is not determined by the entire previous history of the universe.
end quote
I've not read the whole thing yet but it sounds like they've managed to prove that if free will exists then there is no non-local hidden variable theorem compatible with the results of QM.
Tim.
Debit cards are protected too. I've had my card details stolen and used, and I got my money back. I've had bad (non-existent) service from a few companies, and the bank has given me my money back. In no case has my money just been "gone". I don't have a credit card at all, and I've never lost money from an online transaction. Less FUD please.
It's not FUD.
Under the consumer credit act, when credit is extended for a purchase by a consumer, (for at least 100GBP) the credit company becomes jointly and severally liable for the completion of the contract.
That means that if the supplier goes bankrupt you can still get your money back from the credit company. Even if the supplier doesn't go bankrupt but just doesn't supply the goods you can still sue the credit company for your loss and then leave it up to them to get the money back from the supplier.
This automatically applies to all credit cards. It also applies to debit cards if you extend an overdraft in order to do the purchase. (It is the use of credit that is important)
Some visa debit cards also provide the same protection when not using an overdraft. This is a courtesy from the bank and is not required by law. (AIUI Visa is moving to requiring anyone supplying a visa debit card to offer this protection. I do not know if that has completed yet.)
This is independent of any redress you might have if your card is stolen and/or used fradulently. In that case the card supplier has a duty of care to you (e.g. verify signatures etc) and so you have a potential claim against the card supplier independent of the consumer credit act.
Tim.
It's the summer ice extent that matters. It's dark in the winter so any albedo effect is irrelevant.
The ice melts during the summer. So if you've only got 1ft thick ice then it will melt before the winter freeze restarts. If you've got 100ft thick ice then (in the past) the winter freeze restored the thinning due to the summer melt.
That's not happening now. You can argue that summer 2007 was a freak year for ice extent. 2008 wasn't, and yet the summer 2008 minimum was barely more than the 2007 minimum.
That's the problem with single year ice (which also tends to be more salty and so melts at a lower temperature)
Tim.
If there is one thing I'll complain about, it's the choice of the value 0
The choice of the value 0 in the computer is by the compiler, not the C language.
Infact, on AS400 the null pointer is not all bits zero - which makes a mess of code that attempts to memset structures to zero and then tries to test for null pointers. A pointer with all bits zero is NOT null on that platform.
Note that if(!ptr) works fine as a test for null, just that:
memset(&ptr, 0, sizeof ptr); if(!ptr) printf("Ptr is null\n"); else { dereference ptr } will crash.
ptr=0; if(!ptr) ... is fine.
Tim.
Gaaah. the <stdio.h> is obviously missing. I even previewed that post :-(
Thanks, wow... so, doesn't that mean they broke functionality that worked in previous revisions of C?
?
No functionality broken. You can't use a const int to define an array size in C prior to C99 at all. (That's where this entire subthread started - someone was commenting about the use of #define rather than const int which is a reasonable criticism of C++ code but not C code)
It is an(other) area where C and C++ will forever behave differently (I assume).
$ cat compiler.c
#include
struct c { char c[2]; };
int test(void)
{
struct s { struct c { char c[1]; } s; };
struct c t;
return 1//**/2
+sizeof t.c;
}
int main(void)
{
switch(test())
{
case 1: printf("c89\n"); break;
case 2: printf("c99\n"); break;
case 3: printf("c++\n"); break;
default: printf("Unknown\n"); break;
}
return 0;
}
$ gcc -ansi -o c89 compiler.c ./c89 ./c99 ./c++
$ gcc -std=c99 -o c99 compiler.c
$ g++ -o c++ compiler.c
$
c89
$
c99
$
c++
$
$ gcc -std=c99 -o test test.c
test.c: In function `main':
test.c:7: error: variable-sized object may not be initialized
test.c:7: warning: excess elements in array initializer
test.c:7: warning: (near initialization for `data')
$ g++ -o test test.c
$
I can't tell much from the code on the link, but I do see #define used for constants which is no longer appropriate (yet is EXTREMELY common to see). C99 had the const keyword in it, probably even before that.
I don't know where to start here.
const has been in C since c89.
const int SIZE=4;
int data[SIZE];
is fine in C++ and does the same as using a #define for SIZE.
It doesn't work in C prior to C99.
In C99 it defines a VLA - i.e. it's identical to using int SIZE=4; and not using const for the array parameter.
Tim.
Not sure where your confusion lies.
2002, 2003 were record lows compared to previous years.
2007, 2008 were record lows[1] even when compared against the 2002, 2003 lows.
Personally, I find it scary that 20 years ago climate scientists were saying a century for the Arctic to be ice free in summer. Then they changed that to the mid 21st century. Now they're talking decades.
(Note that there is some confusion - you have to be careful when people are saying the north pole might be ice free. Sometimes they are just referring to the north pole itself - 2008 was never expected to have an ice free summer but, due to ice drift and the ice actually at the north pole being first year ice there was a chance that that ice might melt in 2008 making the pole ice free even though the Arctic wasn't going to be.)
Tim.
[1] for the pedants 2008 wasn't a record because 2007 was lower. Not sure whether both of 2002,2003 was a record year and I can't be bothered to go and find the exact numbers.
Then a bug is discovered in the game rendering engine that causes actual delivered framerate to be understated by somewhere between 20-50%... ... with the new compiler.
So you quickly send out an announcement saying that the latest data is suspect. Once you've understood the flaw you'll have good data that can accurately be compared with the archived data from previous tests that is all still good.
Tim.
I know. Terrible isn't it. Every single working physicist hung up their boots and gave up the day Einstein published his Special Relativity paper. What with the QM crowd as well everybody was screwed. There weren't any physicists at all left and it was the man in the street who had always been saying that Newton was a load of balls who stepped in and took physics forwards into the 20th century.
Einstein is an excellent example - he didn't believe in the uncertainly principle. So certain he was that it was wrong that he proved if dpdx > h then dEdt > h as well. He was wrong about the uncertainty principle but that doesn't make his proof wrong, in fact we only understand QM tunnelling because of this.
Exactly the same with climate scientists. If new data arrives that completely upsets the apple cart of global warming that won't render all their knowledge and experience useless. It will be them who explain what this sudden turnabout actually means to us. The fact that (almost) all of them do not believe that data will appear is no more a problem than no physicist believes that we'll be able to communicate faster than light.
Tim.
But they strongly implied, if not stated out right, that the amount of ice would be significantly less in 2008. Turned out they were completely wrong.
Are we reading the same article? In my version it says:
Drobot predicts a 59% chance of a new record minimum this year
As it happens, 2008 was the second lowest on record, despite a strong rebound during the winter months.
http://gatewaypundit.blogspot.com/2008/02/brrrr-disappearing-arctic-ice-is-back.html
Tim.
Deniers don't just use a single data point. They use every year since 1998 - and point out that every one of those years is cooler than 1998. That's a lot of data points, right? All those cool years (compared to 1998) can't be outliers, can they?
I'm assuming this was sarcasm, but just in case it's not:
1998 is the outlier. It was pretty much at the peak of both the solar and El nino cycles and was an extreme on top of that.
Currently we're around the minimum of the solar and La nina.
Tim.
Its mass for a start. If that was known then it would either have already been found (LEP or Fermilab) or will be found (CERN) or won't be found (yet) because we'd know where to look for it.
We have a good idea of what sort of range its mass is likely to have but that's not certain. Some physicists are even hoping that it won't be found, pointing to a much larger mass and interesting new physics to explore.
We're approaching a nadir much like classical physics pre 1905. Are we destined to now spend our time dotting the 'i's and crossing the 't's or is there something as revolutionary as relativity and quantum physics just around the corner?
Tim.
Those, however, all use embedded Linux distros. They don't use a desktop distro and then pull phone-specific add-ons, which I think was the parent poster's point.
Don't think it would work anyway. I use debian but I use my own installer (which starts with an ext3 dump of the minimal system you can install - basically a debootstrap then remove every package that doesn't require the "Yes, do as I say!" response to remove it)
My ext3 dump (uncompressed) rolls in at 72960000 bytes (as of the last build) - note that there is no kernel or modules in this.
It can obviously be made a lot smaller fairly easily - 25MB of that comes from /usr/share/locale/. But carrying an extra 25Mb of "junk" around for a desktop system makes sense. For an embedded system it's crazy. (another 6MB from zoneinfo)
Of course each package could be separated. Now you get passwd-core, passwd-locale-zh_TW, login-core, login-locale-dz etc with passwd, login being meta packages that pull in all the locales.
There's about 4MB of man pages, despite the fact that man is not installed. Again the packages could be split but, again, it's a lot of extra work to maintain.
I suspect that actually much of this splitting could be automated if someone really wanted to. But is there enough demand for it, especially as I expect anyone working on a system where they really need to care about getting things pared down will be deleting individual files they don't want/need?
Tim.
Torture doesn't work either except as a tool to get somebody to admit to things you've already decided you want them to admit to or as a tool of terror. That is why the KGB used it.
Russian Professor: "Who wrote chaika?" (the seagull)
Student: "I don't know".
Professor: "Useless. Incompetent."
One week later
Professor: "Name a work by Chekhov"
Student: "I don't know any"
Professor: "Get out and learn something about Russian literature"
Another week later.
Professor: "An easy question. Who wrote War and Peace?"
Student: "Err... I don't know."
pause
Student: "But I do know something."
Professor: "Yes?"
Student: "It wasn't me"
Professor: "GET OUT!"
professor walks out of class muttering under his breath.
KGB officer: "Professor. Is there a problem?"
Professor: "Just one of my students."
KGB officer: "Oh? Is he criticising the rodina?"
Professor: "Nothing like that. I just asked him who wrote War and Peace. And you know what he said?"
KGB officer: "No?"
Professor: "IT WASN'T ME! He said he knew something. He said he knew he hadn't written War and Peace."
KGB officer: "Hmmm. I can see that's a bit of a problem student."
Professor: "Indeed!"
one month later
KGB officer: "Professor. You remember that student who said he hadn't written War and Peace."
Professor: "Yes?"
KGB officer: "We've been talking to him. It's taken a month but he has finally admitted that he did write War and Peace."
Tim.
In other words, it's fine to steal things as long as they're of low value. I'm fairly certain the hotel *could* have me arrested for stealing their soap, it's just not usually worth their time.
In the hotels I usually stay in you're invited to take the soap/shampoo/conditioner etc.
I've got some rather nice shampoo and conditioner at home now from my most recent stay in a hotel, ironically, one that used to be a prison and I was staying in one of the cells (actually three cells knocked into a single room) with the original metal studded door (although you can open the door from the inside and the peephole looks out rather than in)
http://www.malmaison-oxford.com/the-hotel/architecture
http://www.google.co.uk/imgres?imgurl=http://farm3.static.flickr.com/2077/2110748750_f0f86a21fa.jpg%3Fv%3D0&imgrefurl=http://flickr.com/photos/67596892%40N00/2110748750&h=500&w=375&sz=122&tbnid=YfqUxyrH4O0-BM::&tbnh=130&tbnw=98&prev=/images%3Fq%3Dmalmaison%2Boxford%2Bimages&hl=en&usg=__6NfZj9MmXRT88WAWGDKWStGjHn0=&sa=X&oi=image_result&resnum=4&ct=image&cd=1
Tim.
A lot of FOSS projects fall into a similar mentality and lose sight of their objectives. Rather than writing a great program for the community, it's a great program for the core users. It doesn't matter if the project doesn't serve the needs of anyone else
Obviously there are some people (especially students) who have a lot of time on their hands, love to program, and want a big project to get involved with.
But those same people then go on to full time programming jobs. Even when working full time it can take months and months and years to get to grips with an existing big project from your employer and most programmers are not prepared to give up all their free time to do the same for a big OS project. (Many "professional" programmers never really get to grips with the project they are on which is why you find so many "bug fixes" that actually only fix the symptom - this may or may not be a good commercial decision, personally I think not because eventually that "symptom fix" causes another problem and then someone first has to rediscover the "symptom fix" which is usually some weird bit of code somewhere /* Don't know why but length is one character too long here */ length--; (usually without the comment!), remove it, then find the original problem that caused that hack and finally fix the original problem properly)
Unix got it so right. A small task to solve a small problem. You want to be able to diff two files but ignore ALL whitespace differences (rather than just white space differences at the start and end of the line) and it's probably not going to take an experienced programmer more than an hour or two to add that functionality, including finding the source code, working out how to compile it etc. Feeding it upstream then becomes fairly simple to do.
Want to have a search in open office that ignores all white space when doing the search. I've not looked at open office source at all but I'd guess an experienced programmer would probably have to allow an entire weekend just to get to grips with compiling and installing openoffice (especially as they will want to be able to run their patched version alongside the package installed version). Now they need to find the search and replace code. If it's a one off for themselves they may be able to hack it so that search and replace always ignores white space, but if they want to feed it upstream then they're going to have to learn how to change dialogs, how to get at those flags, how to save the defaults (IIRC open office remembers these flag settings the next time you bring up a dialog, Excel doesn't which is a pain when you're doing a something like "paste special" where Excel keeps resetting your selection of what you actually want to paste)
I don't know what the solution is. Maybe Open Office needs a "framework" like the kernel is to the GNU utilities. Now search and replace can be a "package" that gets installed. I want to change the way search and replace works and I've only got to look at a few thousand lines of code. (c.f. Sendmail and milters.)
I've fed patches upstream when I've found bugs. There's a fix in the postgresql ODBC driver from me (an obscure corner case; IIRC an ODBC driver should return no records found when it does an update and doesn't update any records. It was returning OK which is what it should return when it has updated records and this difference from the ODBC spec happened to break an application I was trying to get to work with postgresql)
Tim.
Debian *does* just work, for me, because I can see what's going on.
It's the "*does* just work" that's so valuable to me. I don't mind spending hours getting something working, but once it's working I expect it to stay working.
I run my own news server (inn, then inn2) and every night I get a status email. From 2001 to the present day there have been just 7 days when I haven't got that email. 6 of them were back in 2002 because I allowed /var to completely run out of disk space and didn't notice straight away. One was in 2004 (I don't know why, the "Daily Usenet report from Feb 5 04:15:05 to Feb 6 04:15:04 is missing)
That's nearly 3000 days of continuous running without a team of people ready to respond as soon as there's a problem. Kernel updates, package updates all happen automatically at night, I don't have a "sandbox" where I test stuff first which obviously I'd want if this was a production system.
In those 3000 days, disks have been replaced as they start showing problems, the motherboard replaced twice etc. but the software "just keeps working".
Tim.
This is real scary. And it goes to prove that bad guys always come up with new ways to steal. I don't believe there is a technical solution to this arms race.
A good start would be for banking sites to work with Javascript turned off, and, maybe, even suggest you turn off Javascript while using online banking.
Requiring you to turn it _ON_ is insane, but extremely common.
Tim.