That's tasteless and misleading. Death is very rarely that immediate, especially in bicycle accidents. Furthermore, the guy driving the car probably has a higher risk of death in general -- it's been studied, non-cycling commuters have a higher (39%) mortality rate. The vividness of the bike-car crash tends to distract people from the fact that sitting (in the car) is much more risky, over time.
Clearly, the plan is to link an advertising identity for most-embarrassing stuff to an RFID chip, and then surreptitiously tag people with that RFID tag.
Well, yes and no. The point I was trying to make was that there are already huge individual incentives, we just fail to recognize them.
As to whether it is any of the state's business, I think it's clear that our nanny-state setting is somewhere between 0 and 1. We ARE (usually) required to wear seatbelts, we ARE NOT required to eat vegetables at least once per day. In terms of effectiveness of various nanny-state policies, I am pretty sure (using my informal understanding of mortality rates) that the major danger from your car, comes not from non-use of seatbelts, but non-use of your heart, lungs, and muscles. A rational nanny state would care more about getting us to exercise, than it does about making us wear seatbelts. Whether we have the carrot-nanny (subsidies) or the stick-nanny (penalties), is another issue.
You also mischaracterize the allocation of costs and benefits. It's not "one person" who benefits, it's a whole class of people. Similarly, the state intervenes to obtain land for roads, to build roads, and maintain roads, and not everyone gets equal (direct) benefit from the roads. It's what governments do.
The costs to you personally from not getting enough exercise probably dominate all of that. How much would you pay to not have a 39% higher chance of death? That's the cost of not getting exercise (specifically, of not riding your bicycle to work, according to this study). Problem is, choosing to get enough exercise takes time (takes much more time off a bike, but somehow people don't view it that way) and it takes time to get comfortable on a bike in traffic and it takes time to build the muscles and CV system to just hop on the bike and go and not care about the exertion. Balance that, against our Lake Wobegonesque optimism that we won't be the ones to get heart disease/diabetes/stroke/cancer, and that's how people stay in their Convenient Cars.
And obviously (or maybe not) the car companies don't want you to think about this, and the oil companies don't want you to think about this, and the drug companies don't want you to think about this (think of the cholesterol meds avoided, the diabetes meds avoided, even the erection meds avoided, because bad circulation is a lot of that). You're a revenue stream, so get back to work and continue consuming their stuff. It's good for the GDP.
"only"? Excluding bicycles? In a city, not as dense as Manhattan, I find that a bicycle is quite competitive with the subway (Boston red line), traveling from my home one town out from Cambridge, to the Stata Center in Kendall Square at MIT. I tried both ways attending a conference there, and it was 30 minutes plus-or-minus a minute, either way. (By car, on a low-traffic Saturday morning, is 20 minutes, plus the time to find a parking space and walk from there to where you are going. And sometimes the traffic is insane, which does not affect the bike much.)
But on the Acela, I can travel like a civilized person, not a sardine. I've done all three (bus, plane, Acela), the Acela is pretty darn nice. And I don't need to arrive hours early, and I don't need to sort my luggage before I go. They definitely need to go faster, but you are definitely getting something for the extra money. It might not be worth it to all people.
You could deploy it where the people are, for starters. 1/3rd of us live in places denser than Assen in the Netherlands (a town where 40% of the commuters ride bicycles). I think that means that 1/3rd of us live in places that could have good rail, if we cared to try.
The "outsourcing" mentioned in the article was to entirely different countries, not to rural areas, and mentioned consumer goods, which are also purchased by people in rural areas. Maybe there is rural emissions outsourcing, but that is not what the article said.
Why ban all vehicular transport? Suppose I ride my bicycle to a bar, and have too much to drink. At that point, I can
(1) toss the bike in the back of a cab
(2) put the bike on the front of a bus (they do that around here)
(3) walk my bike home
(4) take my chances, and ride drunk.
If I ride drunk, my odds of harming anyone other than myself are vastly lower than if I drove a car drunk, because I weigh 10x less than even a small car, and will probably be slow. About the same laws currently apply, but any rational approach to harm reduction would not penalize it as severely as drunken driving. (Actually, a rational approach to harm reduction would strongly discourage all driving, not because of the crashes, but because of the lack of exercise. That is an order of magnitude more deadly than the crash risks of biking, and may even be more deadly than drunk driving -- I haven't checked the numbers, but cardiovascular disease kills loads of people each year).
I'm entirely willing to consider that cars are as much a part of this as the drinking, and if there were many fewer cars on the road, drunken cycling would be a lot safer, too.
That is, if you can write a test that looks like that. I work on compilers, so the trick is to write the example that tweaks just the feature that I want to check, and not 17 others. But, my test cases look like squirrelly little programs that could actually be inputs from especially peculiar users.
You ought to also think about demonstrating your error cases. "If you do this wrong thing, it says...." I am sort of a nut about error messages, partly because I once read the Apple Human Interface guidelines and thought they were a good thing. In particular, does the error message provide the user with information that will help him make the error message go away? When you decide that an error has occurred, what special information do you have that might help? My anti-favorite error message was "Bad SOCKS version number". Not "unexpected", not "too old and not-supported", but "BAD". Morally wrong, so unspeakable that not only can the BAD number not be named, even the good numbers cannot be named, because they might therefore name the BAD number by process of elimination. Truly unspeakable, the version number that shall not be named.
Mod parent, grandparent up. Over the entire US, sure, 1% amounts to a lot of gas, but 1% is nothing compared with what you can save on a bike. I put 2500 miles/year on mine, displacing about 25-30% of what would ordinarily be driving (and crappy, city-ish driving, too). 1/3 of us live in communities at least as dense as Dutch towns (with 40% ride share), WTF is wrong with us?
Helps with flaky joints, helps with flexibility, too.
Sorry, but it's mostly the SUVs. I learned to drive, 35 years ago, in a 2000 lb car (Saab 96). I drive now, in a 2000 lb car (Honda Civic hatchback), with a (broken) air conditioner, air bags, power steering, power brakes, and twice the horsepower.
SUVs take up space, frighten other people into driving larger cars, and make it more unpleasant to ride a bike (because you take up space). You can't even see around the damn things, which makes accidents more likely (in particular, I know of one person killed in such an SUV-impaired-visibility accident).
The problem I did not figure out at the time (I think there is a trick idiom, but it was not included in the documentation) was what to do when:
1) I had already fired off a select call with a gazillion socket operations in it, AND
2) Some silly-ass thread has just made a another socket call, which must be performed and added to the set ASAP.
My after-the-fact understanding is that I am supposed to include a dummy descriptor in the set, that I control, and to poke on that to force completion, modify the set, and reissue. (This could be very wrong, but, again, none of it was in the documentation.) But, I must also guard against the possibility that some other I/O also completed at the exact same time.
What I describe, has to be the wrong way to do it, because each new I/O request incurs linear cost, right? Perhaps the designers of select were not imagining its use in an I/O layer of a VM, but I had no control over the timing of these requests, I was just writing a VM, and I needed to get stuff on/off the wire as fast as possible, up to resource constraints. In the-o-ry, I could accumulate requests "for a little while", but that puts you into "do you feel lucky" land, at least when writing a VM. We tried lots of little experiments, and lots of them had bad corner-case behavior.
Re:Should be using Scatter/Gather +IOCP on windows
on
Java IO Faster Than NIO
·
· Score: 2, Interesting
The goodness of this strategy assumes some sort of linear-in-delay metric. If there's a deadline, with high penalties for exceeding it (say, if you are serving web pages), you don't want to be stochastically fair, you want to be fair.
The scheduler I wrote was 100% fair, EXCEPT in the case where a thread exited a critical section that had other threads competing for (i.e., blocked). In that case, the exiting thread would give up its quantum to the head (longest waiter) of the queue, who would do the same, until the quantum expired or the queue of blocked threads was empty, in which case, the last thread through the gate would get the remainder of the quantum (not fair). The result of this is that the lock is left in the unowned state, and threads will get a better chance at blowing right through the critical section in the future.
You could see how different VMs approached the problem, running things like TP benchmarks, or just a beating-on-a-lock benchmark. We blocked threads in FIFO, another VM did LIFO, another VM did something bimodal and weird. And as far as throughput went, when this sort of badness (a hot lock) occurred, we were far and away the fastest, mostly because of the user-mode context switches, but also because of the no-convoy heuristic that kept locks clean.
I'm not getting the "deeply flawed" here. IO Completion ports were easy to understand, and pretty fast, and allowed us to post new IOs as they were requested. What's deeply flawed about that, especially compared to "select", which appears to have a linear-in-outstanding-IOs cost built in to its interface?
Re:Should be using Scatter/Gather +IOCP on windows
on
Java IO Faster Than NIO
·
· Score: 4, Interesting
I'm afraid I have to disagree. No fan of Microsoft, but I helped build a the-Java-Programming-Language-TM Virtual Machine on Windows, with M:N threads, back before Java 1.4, and IO Completion ports worked well, and we got good performance out of them. We rewrote the network IO to work behind the curtain with threads, with the result that the one-socket-per-thread model actually did the I/O completion port thing, with as many as 32k Java threads running in a grand total of about a dozen Windows threads (stacks were small, stacks grew on demand. Certain things were tricky.).
The largest wins of doing it this way were:
1) got to use the underlying OS's preferred way of doing async IO (on another OS, we might do it differently) 2) lots of threads allowed 3) because Java "context switches" were extremely lightweight, lots of "expensive" stuff got faster (e.g., lock contention).
I also accidentally (really -- I had to choose one of two threads to go first, and chose the right one, on a whim) built-in an anti-convoying heuristic for contended locks, that was really useful when code contained a hot lock.
But, the rest of the system was not especially Microsoft-y; all of us came form a Unix background, and when we were done, we did Unix again. IO Completion ports, at least one Windows, were the best choice (and I tried it 2 or 3 other ways, and they sucked).
To Say Nothing of The Dog, by Connie Willis (1998), with its concept of "slippage" to keep time travelers away from critical points in history, and an inability to transport significant objects forward in time.
No, AC is correct. If you carry 0 genes for SS, you are vulnerable to Malaria. If you carry 1 gene for SS, you are protected from malaria, but do not suffer the effects of SS. 2 genes for SS, you get SS.
Without DDT or drugs in a malarial region, if one or both parents are 1-SS, then half their children (statistically) will live. 1-SS/0-SS, half the children are 1-SS, and protected from malaria, half are 0-SS, and likely to succumb. 1-SS/1-SS, half are 1-SS and protected,.25 are 0-SS, and.25 are 2-SS and get SS disease.
Suppose the actual chance of dying from malaria before reproducing is P. IF P >.25P +.25, then the SS gene is favored. 3P/4 > 1/4, implies that P > 1/3. (Assuming no other causes of death, which complicates the math quite a bit.)
No government conspiracy required. People like their ruts, and will pick and choose the data that supports their opinions, and come up with silly-ass reasons to ignore contrary data. Their "reasoning" (to use the word loosely) exists to help ward off the cognitive dissonance in their own head, not to convince anyone else.
So, for example, in Massachusetts, school spending is measured exactly thus-and-so, by state law. And people who want to believe that a school system is wasting money, they will simply ignore it if that data says otherwise. Spend below the state median, below the state average, and someone who doesn't want to raise taxes, will complain that the superintendent is paid too much (90th percentile outcomes, 45th percentile spending, we don't pay him enough). If a group organizes to support an effort to raise taxes by $2 million, and raises $10,000 in campaign funds, people who oppose them will complain that (clearly) they should have donated that $10,000 to the town instead (because with only $1,990,000 more dollars, the funding gap would be closed).
We're talking about an actual town, these are pretty much actual numbers. The reasoning is head-banglingly innumerate. (Be interesting to see if any of the partisans reads Slashdot.)
Seems to me, that if the casinos had to pay out these jackpots, that the machines might get fixed.
Adding to the irony, when I clicked the link to TFA, it popped up a flashing box declaring that I am the 1e6th visitor, I am a winner, I have won a "FREE*" "WALMART GIFT CARD!!" "*see offer details". In the words of the great Ashley Morris, FYYFF. We really ought to hold corporations accountable for their advertising claims, and any disclaimers in a smaller (or non-contrasting, or scrolled far to the bottom) font do not count.
Anything that conducts, is good, so aluminum is fine. Carbon fiber probably not, since it is embedded in a not-so-conductive epoxy matrix.
However, the frame, unless it is also carbon, conducts, so you tilt the bike "into" the magnetic flux (wheels on or just outside the wire, frame tilted in). If you've got CF wheels, the bike is light, so you can just drop the whole thing to the ground if you want to (I have done this, borrowing a friends wonder-bike).
If the frame and wheels are both carbon, you are kinda-sorta out of luck. It wouldn't take very thick copper wire to make a loop, though.
What you need to imagine is that there is a big stream of something flowing out of the top of the loop, around, and back in the bottom. Position your bicycle so that you put a closed conducting arc around the largest possible amount of that flow. For example, position a wheel on a wire, in the plane of the wire or tilted inwards towards the middle of the loop. That puts your wheel perpendicular to the "flow", and thus you cut a large part of the flow, and the detector will sense you.
Note that if you position your bike perfectly vertically in the dead center of the detector, you will intersect little or none of this "flow", and hence you will not be detected. If you lay your bike down flat on the pavement, you will detect a lot.
Some detectors have a figure eight configuration (two side-by-side rectangles, usually) and for those, the flow is directed from one rectangle into the other (over the line separating them). So for those, it is GOOD to be dead center and perfectly vertical, you will intersect a lot of the flow.
And electrically speaking, that "flow" is the alternating magnetic field caused by a current in the detector. Anything conducting that intersects the field, forms a transformer, and that is electrically different from not-a-transformer, and that is what the detector actually detects. It has to be a changing field; a constant, DC field (like a magnet) has no effect. If you knew the frequency of the detector (10-200 KHz, says the article) and moved the magnet back and forth across that wire that fast (10,000x per second) then the magnet would work.
No no fucking no. They do not work that way. You want to align a large conducting loop or blade across the sensor's AC magnetic flux. It's looking to form a short-circuited transformer with the body of your car, or a bicycle wheel.
Slashdot Mirror
That's tasteless and misleading. Death is very rarely that immediate, especially in bicycle accidents. Furthermore, the guy driving the car probably has a higher risk of death in general -- it's been studied, non-cycling commuters have a higher (39%) mortality rate. The vividness of the bike-car crash tends to distract people from the fact that sitting (in the car) is much more risky, over time.
Clearly, the plan is to link an advertising identity for most-embarrassing stuff to an RFID chip, and then surreptitiously tag people with that RFID tag.
Well, yes and no. The point I was trying to make was that there are already huge individual incentives, we just fail to recognize them.
As to whether it is any of the state's business, I think it's clear that our nanny-state setting is somewhere between 0 and 1. We ARE (usually) required to wear seatbelts, we ARE NOT required to eat vegetables at least once per day. In terms of effectiveness of various nanny-state policies, I am pretty sure (using my informal understanding of mortality rates) that the major danger from your car, comes not from non-use of seatbelts, but non-use of your heart, lungs, and muscles. A rational nanny state would care more about getting us to exercise, than it does about making us wear seatbelts. Whether we have the carrot-nanny (subsidies) or the stick-nanny (penalties), is another issue.
You also mischaracterize the allocation of costs and benefits. It's not "one person" who benefits, it's a whole class of people. Similarly, the state intervenes to obtain land for roads, to build roads, and maintain roads, and not everyone gets equal (direct) benefit from the roads. It's what governments do.
The costs to you personally from not getting enough exercise probably dominate all of that. How much would you pay to not have a 39% higher chance of death? That's the cost of not getting exercise (specifically, of not riding your bicycle to work, according to this study). Problem is, choosing to get enough exercise takes time (takes much more time off a bike, but somehow people don't view it that way) and it takes time to get comfortable on a bike in traffic and it takes time to build the muscles and CV system to just hop on the bike and go and not care about the exertion. Balance that, against our Lake Wobegonesque optimism that we won't be the ones to get heart disease/diabetes/stroke/cancer, and that's how people stay in their Convenient Cars.
And obviously (or maybe not) the car companies don't want you to think about this, and the oil companies don't want you to think about this, and the drug companies don't want you to think about this (think of the cholesterol meds avoided, the diabetes meds avoided, even the erection meds avoided, because bad circulation is a lot of that). You're a revenue stream, so get back to work and continue consuming their stuff. It's good for the GDP.
"only"? Excluding bicycles? In a city, not as dense as Manhattan, I find that a bicycle is quite competitive with the subway (Boston red line), traveling from my home one town out from Cambridge, to the Stata Center in Kendall Square at MIT. I tried both ways attending a conference there, and it was 30 minutes plus-or-minus a minute, either way. (By car, on a low-traffic Saturday morning, is 20 minutes, plus the time to find a parking space and walk from there to where you are going. And sometimes the traffic is insane, which does not affect the bike much.)
But on the Acela, I can travel like a civilized person, not a sardine. I've done all three (bus, plane, Acela), the Acela is pretty darn nice. And I don't need to arrive hours early, and I don't need to sort my luggage before I go. They definitely need to go faster, but you are definitely getting something for the extra money. It might not be worth it to all people.
Hybrids. Regenerative braking, stopping for the train is not such a big deal.
I agree about the waiting, which is why I usually take my bike.
You could deploy it where the people are, for starters. 1/3rd of us live in places denser than Assen in the Netherlands (a town where 40% of the commuters ride bicycles). I think that means that 1/3rd of us live in places that could have good rail, if we cared to try.
I don't think this is unique to the US, and somehow other countries (France comes to mind) built their high speed rail.
The "outsourcing" mentioned in the article was to entirely different countries, not to rural areas, and mentioned consumer goods, which are also purchased by people in rural areas. Maybe there is rural emissions outsourcing, but that is not what the article said.
Why ban all vehicular transport? Suppose I ride my bicycle to a bar, and have too much to drink. At that point, I can
(1) toss the bike in the back of a cab
(2) put the bike on the front of a bus (they do that around here)
(3) walk my bike home
(4) take my chances, and ride drunk.
If I ride drunk, my odds of harming anyone other than myself are vastly lower than if I drove a car drunk, because I weigh 10x less than even a small car, and will probably be slow. About the same laws currently apply, but any rational approach to harm reduction would not penalize it as severely as drunken driving. (Actually, a rational approach to harm reduction would strongly discourage all driving, not because of the crashes, but because of the lack of exercise. That is an order of magnitude more deadly than the crash risks of biking, and may even be more deadly than drunk driving -- I haven't checked the numbers, but cardiovascular disease kills loads of people each year).
I'm entirely willing to consider that cars are as much a part of this as the drinking, and if there were many fewer cars on the road, drunken cycling would be a lot safer, too.
"Here's how it works..."
That is, if you can write a test that looks like that. I work on compilers, so the trick is to write the example that tweaks just the feature that I want to check, and not 17 others. But, my test cases look like squirrelly little programs that could actually be inputs from especially peculiar users.
You ought to also think about demonstrating your error cases. "If you do this wrong thing, it says...." I am sort of a nut about error messages, partly because I once read the Apple Human Interface guidelines and thought they were a good thing. In particular, does the error message provide the user with information that will help him make the error message go away? When you decide that an error has occurred, what special information do you have that might help? My anti-favorite error message was "Bad SOCKS version number". Not "unexpected", not "too old and not-supported", but "BAD". Morally wrong, so unspeakable that not only can the BAD number not be named, even the good numbers cannot be named, because they might therefore name the BAD number by process of elimination. Truly unspeakable, the version number that shall not be named.
Mod parent, grandparent up. Over the entire US, sure, 1% amounts to a lot of gas, but 1% is nothing compared with what you can save on a bike. I put 2500 miles/year on mine, displacing about 25-30% of what would ordinarily be driving (and crappy, city-ish driving, too). 1/3 of us live in communities at least as dense as Dutch towns (with 40% ride share), WTF is wrong with us?
Helps with flaky joints, helps with flexibility, too.
Sorry, but it's mostly the SUVs. I learned to drive, 35 years ago, in a 2000 lb car (Saab 96). I drive now, in a 2000 lb car (Honda Civic hatchback), with a (broken) air conditioner, air bags, power steering, power brakes, and twice the horsepower.
SUVs take up space, frighten other people into driving larger cars, and make it more unpleasant to ride a bike (because you take up space). You can't even see around the damn things, which makes accidents more likely (in particular, I know of one person killed in such an SUV-impaired-visibility accident).
The problem I did not figure out at the time (I think there is a trick idiom, but it was not included in the documentation) was what to do when: 1) I had already fired off a select call with a gazillion socket operations in it, AND 2) Some silly-ass thread has just made a another socket call, which must be performed and added to the set ASAP. My after-the-fact understanding is that I am supposed to include a dummy descriptor in the set, that I control, and to poke on that to force completion, modify the set, and reissue. (This could be very wrong, but, again, none of it was in the documentation.) But, I must also guard against the possibility that some other I/O also completed at the exact same time. What I describe, has to be the wrong way to do it, because each new I/O request incurs linear cost, right? Perhaps the designers of select were not imagining its use in an I/O layer of a VM, but I had no control over the timing of these requests, I was just writing a VM, and I needed to get stuff on/off the wire as fast as possible, up to resource constraints. In the-o-ry, I could accumulate requests "for a little while", but that puts you into "do you feel lucky" land, at least when writing a VM. We tried lots of little experiments, and lots of them had bad corner-case behavior.
The goodness of this strategy assumes some sort of linear-in-delay metric. If there's a deadline, with high penalties for exceeding it (say, if you are serving web pages), you don't want to be stochastically fair, you want to be fair.
The scheduler I wrote was 100% fair, EXCEPT in the case where a thread exited a critical section that had other threads competing for (i.e., blocked). In that case, the exiting thread would give up its quantum to the head (longest waiter) of the queue, who would do the same, until the quantum expired or the queue of blocked threads was empty, in which case, the last thread through the gate would get the remainder of the quantum (not fair). The result of this is that the lock is left in the unowned state, and threads will get a better chance at blowing right through the critical section in the future.
You could see how different VMs approached the problem, running things like TP benchmarks, or just a beating-on-a-lock benchmark. We blocked threads in FIFO, another VM did LIFO, another VM did something bimodal and weird. And as far as throughput went, when this sort of badness (a hot lock) occurred, we were far and away the fastest, mostly because of the user-mode context switches, but also because of the no-convoy heuristic that kept locks clean.
I'm not getting the "deeply flawed" here. IO Completion ports were easy to understand, and pretty fast, and allowed us to post new IOs as they were requested. What's deeply flawed about that, especially compared to "select", which appears to have a linear-in-outstanding-IOs cost built in to its interface?
I'm afraid I have to disagree. No fan of Microsoft, but I helped build a the-Java-Programming-Language-TM Virtual Machine on Windows, with M:N threads, back before Java 1.4, and IO Completion ports worked well, and we got good performance out of them. We rewrote the network IO to work behind the curtain with threads, with the result that the one-socket-per-thread model actually did the I/O completion port thing, with as many as 32k Java threads running in a grand total of about a dozen Windows threads (stacks were small, stacks grew on demand. Certain things were tricky.).
The largest wins of doing it this way were:
1) got to use the underlying OS's preferred way of doing async IO (on another OS, we might do it differently)
2) lots of threads allowed
3) because Java "context switches" were extremely lightweight, lots of "expensive" stuff got faster (e.g., lock contention).
I also accidentally (really -- I had to choose one of two threads to go first, and chose the right one, on a whim) built-in an anti-convoying heuristic for contended locks, that was really useful when code contained a hot lock.
But, the rest of the system was not especially Microsoft-y; all of us came form a Unix background, and when we were done, we did Unix again. IO Completion ports, at least one Windows, were the best choice (and I tried it 2 or 3 other ways, and they sucked).
To Say Nothing of The Dog, by Connie Willis (1998), with its concept of "slippage" to keep time travelers away from critical points in history, and an inability to transport significant objects forward in time.
No, AC is correct. If you carry 0 genes for SS, you are vulnerable to Malaria. If you carry 1 gene for SS, you are protected from malaria, but do not suffer the effects of SS. 2 genes for SS, you get SS.
Without DDT or drugs in a malarial region, if one or both parents are 1-SS, then half their children (statistically) will live. 1-SS/0-SS, half the children are 1-SS, and protected from malaria, half are 0-SS, and likely to succumb. 1-SS/1-SS, half are 1-SS and protected, .25 are 0-SS, and .25 are 2-SS and get SS disease.
Suppose the actual chance of dying from malaria before reproducing is P. IF P > .25P + .25, then the SS gene is favored. 3P/4 > 1/4, implies that P > 1/3. (Assuming no other causes of death, which complicates the math quite a bit.)
No government conspiracy required. People like their ruts, and will pick and choose the data that supports their opinions, and come up with silly-ass reasons to ignore contrary data. Their "reasoning" (to use the word loosely) exists to help ward off the cognitive dissonance in their own head, not to convince anyone else.
So, for example, in Massachusetts, school spending is measured exactly thus-and-so, by state law. And people who want to believe that a school system is wasting money, they will simply ignore it if that data says otherwise. Spend below the state median, below the state average, and someone who doesn't want to raise taxes, will complain that the superintendent is paid too much (90th percentile outcomes, 45th percentile spending, we don't pay him enough). If a group organizes to support an effort to raise taxes by $2 million, and raises $10,000 in campaign funds, people who oppose them will complain that (clearly) they should have donated that $10,000 to the town instead (because with only $1,990,000 more dollars, the funding gap would be closed).
We're talking about an actual town, these are pretty much actual numbers. The reasoning is head-banglingly innumerate. (Be interesting to see if any of the partisans reads Slashdot.)
Adding to the irony, when I clicked the link to TFA, it popped up a flashing box declaring that I am the 1e6th visitor, I am a winner, I have won a "FREE*" "WALMART GIFT CARD!!" "*see offer details". In the words of the great Ashley Morris, FYYFF. We really ought to hold corporations accountable for their advertising claims, and any disclaimers in a smaller (or non-contrasting, or scrolled far to the bottom) font do not count.
However, the frame, unless it is also carbon, conducts, so you tilt the bike "into" the magnetic flux (wheels on or just outside the wire, frame tilted in). If you've got CF wheels, the bike is light, so you can just drop the whole thing to the ground if you want to (I have done this, borrowing a friends wonder-bike).
If the frame and wheels are both carbon, you are kinda-sorta out of luck. It wouldn't take very thick copper wire to make a loop, though.
There's a web page that explains it in gory, but still somewhat EE-oriented, detail: http://humantransport.org/bicycledriving/library/signals/detection.htm
What you need to imagine is that there is a big stream of something flowing out of the top of the loop, around, and back in the bottom. Position your bicycle so that you put a closed conducting arc around the largest possible amount of that flow. For example, position a wheel on a wire, in the plane of the wire or tilted inwards towards the middle of the loop. That puts your wheel perpendicular to the "flow", and thus you cut a large part of the flow, and the detector will sense you.
Note that if you position your bike perfectly vertically in the dead center of the detector, you will intersect little or none of this "flow", and hence you will not be detected. If you lay your bike down flat on the pavement, you will detect a lot.
Some detectors have a figure eight configuration (two side-by-side rectangles, usually) and for those, the flow is directed from one rectangle into the other (over the line separating them). So for those, it is GOOD to be dead center and perfectly vertical, you will intersect a lot of the flow.
And electrically speaking, that "flow" is the alternating magnetic field caused by a current in the detector. Anything conducting that intersects the field, forms a transformer, and that is electrically different from not-a-transformer, and that is what the detector actually detects. It has to be a changing field; a constant, DC field (like a magnet) has no effect. If you knew the frequency of the detector (10-200 KHz, says the article) and moved the magnet back and forth across that wire that fast (10,000x per second) then the magnet would work.
See also: http://www.coolmagnetman.com/magpipes.htm -- a falling magnet is also a changing magnetic field.
No no fucking no. They do not work that way. You want to align a large conducting loop or blade across the sensor's AC magnetic flux. It's looking to form a short-circuited transformer with the body of your car, or a bicycle wheel.