Hugo Gernsback wrote an editorial advocating a similar idea in the May 1956 issue of his "Radio-Electronics" magazine as a solution to the educational needs of the USA to produce enough technicians and engineers to defeat the Soviets in the technological arms race. See page 33 in the PDF scan of that issue at AmericanRadioHistory.com.
"THE ELEMENTS OF TELEDUCATION"
"... The threat to our future can be met..."
(snip)
"In short, without going into details, this is the way the proposed system, outlined by the writer in 1945, works:
"From a central point or points the best technical and science teachers in the land instruct via large wall projection color television AA the classes in the land. If the instructor of the moment is at Yale, the rest of the country is connected to that point. The next lecture may come from MIT in Massachusetts, from Caltech in California or from any other point because all institutions of learning are tied in to the national teleducation closed-circuit hookup. Such lectures will not be merely talk. The teacher - be he a physics, chemical, electrical or electronics professor - will instruct directly from the laboratory all important experiments and make clear any technical point by actual physical demonstration."
I think that's being too harsh. As the paper described in its conclusions of the 3 groups who make use of R, the largest and primary group is the users, people who don't do programming in R, but rather make use of it for generating and displaying statistics in an interactive environment.
In other words, it's a good programming language if you don't do any programming, but just feed parameters to analysis and plotting packages. So no, it would not be a good "computational vehicle" for AP Statistics. That is, not if the students are actually learning anything in AP Statistics.
"R is a dynamic language for statistical computing that combines lazy functional features and object-oriented programming. This rather unlikely linguistic cocktail would probably never have been prepared by computer scientists, yet the language has become surprisingly popular. With millions of lines of R code available in repositories, we have an opportunity to evaluate the fundamental choices underlying the R language design. Using a combination of static and dynamic program analysis we assess the success of different language features."
Normally, writes to disk can't be confirmed faster than one per full revolution of the platters. Thus, a 7200 RPM disk can not perform more than 7200 transactions a minute.
It can perform transactions at a much higher rate than that by using group commit, and any performance-sensitive system (including journaling file systems) will indeed use group commit. But the mean latency for any one commit does end up being limited to the time to perform half a disk rotation, and that's what non-volatile DIMMs are about - reduced I/O latency.
Because those battery tubes, to achieve their low filament-power consumption, used directly-heated cathodes (as you noted). If you think about this a bit further, you'll realize that this greatly limits the number of circuit topologies, because all of the cathodes in every tube must be connected together via the filament power supply. Imagine constructing logic gates where every transistor's emitter had to be directly connected to ground. Do-able, but limiting.
Yes! This is the book that taught me how to program. The rigor of Dijkstra's predicate calculus (aka Hoare triples) is sorely missed in today's bug-filled programming practice.
For anyone whose interested, the Planet Money blog and podcast is a great place to start. Their reporting and research is done by actual economists rather than ideologues and talking heads
Planet Money is a joke. None of their correspondents are economists. David Kestenbaum is a journalist who happens to have a PhD in physics. Adam Davidson is not an economist; his background is journalism. Davidson clearly has a Milton Friedman bias in his economic reporting; just look at his blog posts on the subject of economic stimulus.
For a critical look at NPR (Nice Polite Republicans) check out the NPR Check blog.
Don't we want to encourage more fuel-efficient road vehicles? Seems like upping the gas tax would be a good way to do that.
Perhaps once we're all driving electric vehicles we might then consider a per-mile tax. Until then, the incursion on civil liberties and privacy from vehicle tracking doesn't seem to be outweighed by the societal benefits.
It seems to me that these vehicle-tracking ideas are a clever political scam that combines avoidance of a politically-costly raising of the gas tax, corporate welfare for some well-connected companies, and a plausible-sounding policy-wonkish cover story.
That's a little unfair; you've no citations in your post:-)
However, the fact that batons leave marks (physical evidence) whereas tasers do not implies that police are less likely to inappropriately use batons than tasers, since the inappropriate use of batons results in evidence visible to a board of review.
It's clear from news reports that police are overusing Tasers by using them as torture devices in circumstances where, if they had instead beaten the subject with a baton, the evidence of physical injury would have resulted in the censure or firing of the police officer.
It seems that there are quite a few incidents wherein police officers have reached for their TASER rather than reaching for their deescalation skills. I don't think you can blame this on the tool though -- you have to blame it on the operator. These same personalities would probably have wielded the police baton in the same inappropriate manner.
The police baton is less likely to result in death.
Use the textbook "How to design programs" by Matthias Felleisen, Robert Bruce Findler, Matthew Flatt and Shriram Krishnamurthi., It's available free on the web or hardcopy from MIT press. Unfortunately the HtDP web-site seems to be down today. Check out the wikipedia entry. It's been used in high schools. They have a summer seminar for teachers, too.
Use the text "How to design programs" and Scheme. It's been used in high schools, is quite approachable, and is easily motivated by connection to recurrence relations, which seem to be a theme in my 14 year old's math curriculum. The book is free on the web, and the programming environment is also free and supported on many popular platforms.
You miss my point. RED reduces the frame drop rate, especially in congested situations, to the point where the retransmit rate for TCP or SCTP is low enough that it doesn't matter.
You are correct that for SCSI presumes a mostly loss-less interconnect; the issue is what lower-level protocol to use to deliver this. FCoE assumes link-level flow control, but that introduces congestion spreading, which cripples the network throughput. To solve that problem, the data-center ethernet folks assume that the IEEE working group will eventually come up with NICs and swtiches which implement congestion control at a very low level (layer 2).
An alternative way to solve the problem is to use an intermediate protocol layer, above ethernet but below SCSI, that implements reliable transport and congestion control. TCP is one candidate; that gives you iSCSI and iFCP. SCTP is another candidate; it solves the application-level framing problem so the hardware HBAs could cheaply parse IP packets and find the SCTP and SCSI headers (cheap means "near gate-cost parity with Fibre Channel"), thus enabling direct data placement.
iSCSI over TCP can only deliver this by using an intermediate copy of the TCP packets, to coalesce the TCP stream so that the upper-level protocol headers can be parsed. SCTP avoids this complexity along with the head-of-line blocking problems introduced by the TCP byte-stream abstractions.
Retransmitting the dropped frames isn't really a problem. Any ethernet switch that implements RED will keep the loss-rate acceptably low. Adding forward or backward ECN makes it even better.
Raw Fibre Channel over Ethernet doesn't add anything to detect and retransmit lost frames other than the upper-level SCSI driver timeout; that's why they need the loss-less part. But that's simply an artifact of their implementation; the critical architectural component that's missing from TCP (and hence iSCSI) is the application-level framing. That's what allows cheap hardware to do direct data placement.
The problems they are trying to solve are two-fold:
1) there are a number of legacy protocols (UDP-based stuff, reliable multicast, etc) that have no congestion control. Typically in the past the datacenter would provision a separate network for these if low loss and/or low latency were important. What with virtualization and cost-pressure, everyone now wants a single converged network fabric. To handle these legacy protocols in a converged network, the network hardware itself (switches and NICs) now has to provide congestion control.
2) TCP doesn't provide application-level framing, hence hardware cannot parse upper-level protocol headers in TCP segments. Therefor it isn't possible to build cheap NICs/HBAs that can handle 10 GbE wire-rate iSCSI or iWARP RDMA or iFCP. Rather than fix this by moving iSCSI, iWARP, etc to SCTP, which does provide application-level framing over IP (along with TCP-compatible congestion control), the industry has decided to instead use raw Ethernet frames for application-level framing and push the congestion control into the NICs and switches (i.e. FCoE).
Meanwhile, the IETF can say "I told you so", since the storage industry ignored the network weenie's advice to base iSCSI on SCTP back in 2002 or so.
This all seems brain-dead to me, but I'm sure Cisco will make a mint out of owning all the datacenter switching infrastructure.
Slashdot Mirror
"THE ELEMENTS OF TELEDUCATION"
"... The threat to our future can be met
(snip)
"In short, without going into details, this is the way the proposed system, outlined by the writer in 1945, works:
"From a central point or points the best technical and science teachers in the land instruct via large wall projection color television AA the classes in the land. If the instructor of the moment is at Yale, the rest of the country is connected to that point. The next lecture may come from MIT in Massachusetts, from Caltech in California or from any other point because all institutions of learning are tied in to the national teleducation closed-circuit hookup. Such lectures will not be merely talk. The teacher - be he a physics, chemical, electrical or electronics professor - will instruct directly from the laboratory all important experiments and make clear any technical point by actual physical demonstration."
You want Bootstrap, which is billed as "algebraic video game programming".
"Unlike Python, Scratch or Javascript, functions and variables behave exactly the same way in Bootstrap that they do in your child's math book."
http://www.bootstrapworld.org/
Workshops: http://www.bootstrapworld.org/
It also provides a good foundation for further CS education: http://www.programbydesign.org...
I think that's being too harsh. As the paper described in its conclusions of the 3 groups who make use of R, the largest and primary group is the users, people who don't do programming in R, but rather make use of it for generating and displaying statistics in an interactive environment.
In other words, it's a good programming language if you don't do any programming, but just feed parameters to analysis and plotting packages. So no, it would not be a good "computational vehicle" for AP Statistics. That is, not if the students are actually learning anything in AP Statistics.
http://www.bootstrapworld.org/
http://programbydesign.org/
If a child can be taught to construct a good logical argument in English composition class, that child can be taught computer science. And should be.
"is it finally time for AP Statistics to switch its computational vehicle to R?"
No. Absolutely not. R is not a reasonable language for computing: http://r.cs.purdue.edu/pub/eco...
No one uses R for it's amazing language*. The language sucks.
From Morandat, Hill, Osvald, Vitek, "Evaluating the Design of the R Language", http://r.cs.purdue.edu/pub/eco...
"R is a dynamic language for statistical computing that combines lazy functional features and object-oriented programming. This rather unlikely linguistic cocktail would probably never have been prepared by computer scientists, yet the language has become surprisingly popular. With millions of lines of R code available in repositories, we have an opportunity to evaluate the fundamental choices underlying the R language design. Using a combination of static and dynamic program analysis we assess the success of different language features."
Normally, writes to disk can't be confirmed faster than one per full revolution of the platters. Thus, a 7200 RPM disk can not perform more than 7200 transactions a minute.
It can perform transactions at a much higher rate than that by using group commit, and any performance-sensitive system (including journaling file systems) will indeed use group commit. But the mean latency for any one commit does end up being limited to the time to perform half a disk rotation, and that's what non-volatile DIMMs are about - reduced I/O latency.
Because those battery tubes, to achieve their low filament-power consumption, used directly-heated cathodes (as you noted). If you think about this a bit further, you'll realize that this greatly limits the number of circuit topologies, because all of the cathodes in every tube must be connected together via the filament power supply. Imagine constructing logic gates where every transistor's emitter had to be directly connected to ground. Do-able, but limiting.
Megan McArdle is not a liberal source. http://www.balloon-juice.com/2011/08/04/under-pressure/
Yes! This is the book that taught me how to program. The rigor of Dijkstra's predicate calculus (aka Hoare triples) is sorely missed in today's bug-filled programming practice.
For anyone whose interested, the Planet Money blog and podcast is a great place to start. Their reporting and research is done by actual economists rather than ideologues and talking heads
Planet Money is a joke. None of their correspondents are economists. David Kestenbaum is a journalist who happens to have a PhD in physics. Adam Davidson is not an economist; his background is journalism. Davidson clearly has a Milton Friedman bias in his economic reporting; just look at his blog posts on the subject of economic stimulus.
For a critical look at NPR (Nice Polite Republicans) check out the NPR Check blog.
Don't we want to encourage more fuel-efficient road vehicles? Seems like upping the gas tax would be a good way to do that.
Perhaps once we're all driving electric vehicles we might then consider a per-mile tax. Until then, the incursion on civil liberties and privacy from vehicle tracking doesn't seem to be outweighed by the societal benefits.
It seems to me that these vehicle-tracking ideas are a clever political scam that combines avoidance of a politically-costly raising of the gas tax, corporate welfare for some well-connected companies, and a plausible-sounding policy-wonkish cover story.
That's a little unfair; you've no citations in your post :-)
However, the fact that batons leave marks (physical evidence) whereas tasers do not implies that police are less likely to inappropriately use batons than tasers, since the inappropriate use of batons results in evidence visible to a board of review.
It's clear from news reports that police are overusing Tasers by using them as torture devices in circumstances where, if they had instead beaten the subject with a baton, the evidence of physical injury would have resulted in the censure or firing of the police officer.
It seems that there are quite a few incidents wherein police officers have reached for their TASER rather than reaching for their deescalation skills. I don't think you can blame this on the tool though -- you have to blame it on the operator. These same personalities would probably have wielded the police baton in the same inappropriate manner.
The police baton is less likely to result in death.
Use the textbook "How to design programs" by Matthias Felleisen, Robert Bruce Findler, Matthew Flatt and Shriram Krishnamurthi., It's available free on the web or hardcopy from MIT press. Unfortunately the HtDP web-site seems to be down today. Check out the wikipedia entry. It's been used in high schools. They have a summer seminar for teachers, too.
Use the text "How to design programs" and Scheme. It's been used in high schools, is quite approachable, and is easily motivated by connection to recurrence relations, which seem to be a theme in my 14 year old's math curriculum. The book is free on the web, and the programming environment is also free and supported on many popular platforms.
You miss my point. RED reduces the frame drop rate, especially in congested situations, to the point where the retransmit rate for TCP or SCTP is low enough that it doesn't matter.
You are correct that for SCSI presumes a mostly loss-less interconnect; the issue is what lower-level protocol to use to deliver this. FCoE assumes link-level flow control, but that introduces congestion spreading, which cripples the network throughput. To solve that problem, the data-center ethernet folks assume that the IEEE working group will eventually come up with NICs and swtiches which implement congestion control at a very low level (layer 2).
An alternative way to solve the problem is to use an intermediate protocol layer, above ethernet but below SCSI, that implements reliable transport and congestion control. TCP is one candidate; that gives you iSCSI and iFCP. SCTP is another candidate; it solves the application-level framing problem so the hardware HBAs could cheaply parse IP packets and find the SCTP and SCSI headers (cheap means "near gate-cost parity with Fibre Channel"), thus enabling direct data placement.
iSCSI over TCP can only deliver this by using an intermediate copy of the TCP packets, to coalesce the TCP stream so that the upper-level protocol headers can be parsed. SCTP avoids this complexity along with the head-of-line blocking problems introduced by the TCP byte-stream abstractions.
Retransmitting the dropped frames isn't really a problem. Any ethernet switch that implements RED will keep the loss-rate acceptably low. Adding forward or backward ECN makes it even better.
Raw Fibre Channel over Ethernet doesn't add anything to detect and retransmit lost frames other than the upper-level SCSI driver timeout; that's why they need the loss-less part. But that's simply an artifact of their implementation; the critical architectural component that's missing from TCP (and hence iSCSI) is the application-level framing. That's what allows cheap hardware to do direct data placement.
The problems they are trying to solve are two-fold:
1) there are a number of legacy protocols (UDP-based stuff, reliable multicast, etc) that have no congestion control. Typically in the past the datacenter would provision a separate network for these if low loss and/or low latency were important. What with virtualization and cost-pressure, everyone now wants a single converged network fabric. To handle these legacy protocols in a converged network, the network hardware itself (switches and NICs) now has to provide congestion control.
2) TCP doesn't provide application-level framing, hence hardware cannot parse upper-level protocol headers in TCP segments. Therefor it isn't possible to build cheap NICs/HBAs that can handle 10 GbE wire-rate iSCSI or iWARP RDMA or iFCP. Rather than fix this by moving iSCSI, iWARP, etc to SCTP, which does provide application-level framing over IP (along with TCP-compatible congestion control), the industry has decided to instead use raw Ethernet frames for application-level framing and push the congestion control into the NICs and switches (i.e. FCoE).
Meanwhile, the IETF can say "I told you so", since the storage industry ignored the network weenie's advice to base iSCSI on SCTP back in 2002 or so.
This all seems brain-dead to me, but I'm sure Cisco will make a mint out of owning all the datacenter switching infrastructure.
So why the heck didn't they base FCoE on SCTP, instead of trying to require the darn _network_hardware_ to implement TCP-like congestion control?
SICP is probably too advanced for high school. Use Scheme, but use the "How to Design Programs" approach instead of SICP.
Teach them Scheme using the text "How to Design Programs" http://www.htdp.org/