this seems a bit steep! With 6 billion people in the world, this is >25 GB for every man, woman and child on the planet. Per year! I doubt the average is even close to that.
These vehicles are heavily subsidized by the states where you may sell them, and they're interested in getting their investment back. California lays out wads of cash for some cleaner vehicles, so California wants them driven in California (for example; there are several other states involved). The automakers are not allowed to sell them anywhere else. It's that simple.
This isn't even close to true, and neither is the article. The PZEV _designation_ specifically is only meaningful in the states that have accepted it. The vehicles themselves are sold, in identical form, everywhere. There is no subsidy to th e automaker, although some states are giving tax incentives to purchasers, so it doesn't help the states if they are or are not sold elsewhere.
My Prius has the PZEV sticker, and was sold in Tennessee, and still is. It's just that the local air authorities don't assign any meaning to it.
OK, this has got to be a seriously flawed study, for any car! $3.25/mile over 100,000 miles means I will have spent $325,000 on car maintenance in the lifetime of my Prius. Does anyone find this number just a bit untenable? Even for a Hummer, this number is untenable.
You asked to see how the data are averaged, and wanted to see it normalized to variance. Here is the site where those records live. Enjoy.
Climate Research Unit Page
There are MUCH older proponents of this separation. In the Augsburg Confession (penned by Melanchthon to reperesent the early views of the nascent Lutheran movement to the princes of Germany and the Roman Catholic Church), the following was stated (rather colorfully!):
Therefore, since the power of the Church grants eternal things, and is exercised only by the ministry of the Word, it does not interfere with civil government; no more than the art of singing interferes with civil government . For civil government deals with other things than does the Gospel. The civil rulers defend not minds, but bodies and bodily things against manifest injuries, and restrain men with the sword and bodily punishments in order to preserve civil justice and peace.
Before everyone starts planning their purchase of a tritium-powered laptop, keep the following numbers in mind:
Assuming a perfectly efficient conversion of the energy released by the 18 keV beta particles from tritium, the specific power available from a tritium battery is 18 keV * 3x10^10 disintegrations/sec/Ci * 1.6x10^-19 Joules/eV = 86 microwatts/Ci.
The last time I checked (a long time ago), the price of bulk tritium was about $10/Ci (probably still true within an order of magnitude), so the price of one of these batteries (assuming, again 100% conversion of beta energy to output power, which is not even close to correct), is $100,000/watt.
Realistically, I think the efficiency could possibly approach 10% if they get very good at collecting the electron showers produced by the betas, but maybe tritium will come down a factor of 10 in price to compensate. I suspect that any large deviation in price from the $100k/W number is unlikely. For most people, that is a showstopper for daily use, since it significantly increases the price of a laptop, from about $1000 to about $1,000,000 (assuming your laptop takes 10 Watts, which is pretty optimistic). Of course, that would also imply that you are carrying around 100,000 Curies of tritium with you (again, at the 10% efficiency level). That's a LOT of tritium.
These are only likely to be important as very long-term sources of sub-milliwatt power. Nonetheless, they may be quite useful there. The efficiency might be quite a bit better that current radiothermal generators, although that will take some work to achieve.
OK, I vote with a lot of other people on Grace/xmgrace for 2d plotting.
For higher dimensionality visualization, though, nobody has mentioned openDX (www.opendx.org). What other plotting and visualization program can easily plot 6-dimensional data (for example, a rank-3 tensor field) on a 3d space?
OpenDX takes a little while to really understand, but once you get it, the payoff is trmendous. It has a very general data model that allow one to have arbitrary topology connecting your values, from completely scattered points with no explicit relation, to various meshes such as simplices (triangles/tets), cubic/hypercubic lattices, and many more.
Also, it represents data in files very flexibly, so one can put structural information in a small, simple file, and reference a larger (potentially huge), external file for the actual data.
That depends on the receiver. The Rockwell/Conexant/NavMan/SiRF receivers used in the DeLorme Earthmate are (at least were in the serial version; don't know about the new USB ones) quite sophisticated. They use a separate receiving chain for the Doppler data, so the velocity solution is independent of the position solution. The error ellipse on a zero velocity point was only about 0.1 m/s in radius. That's plenty good to get a nice velocity on a crew hull. They only return data 1 point per second, but that should realistically be enough, since a hull doesn't accelerate THAT fast.
I work in a Free Electron Laser (FEL) center. The FEL is a few-million-dollar machine which is about 25 meters long, stem to stern. We have occasionally used it to carve Lucite blocks to present as going-away presents for departing associates. We figured that, since the operating budget of the machine (note: not the incremental cost of this task) runs about $500/hour, these could be considered $1000 gifts!
We also use the laser for demonstrations for visiting high school students (etc) to carve hot dogs and to engrave names on tongue depressors. I think it is fairly memorable for the students to see a building-sized apparatus used for this. The only hope is that it gets some of them excited about science.
Warning! Hybrid battery cycles are nothing like EV battery cycles. In an EV, the battery is repeatedly drained from 100% to (typically) a very low charge, resulting in a short life between replacements. On the other hand, a hybrid batery, which is just used for short-term energy buffering, can be pampered by the control electronics.
In the Toyota Prius, the battery is tightly controlled for state-of-charge (SOC) between about 50% and about 90%, and not allowed to deep discharge or overcharge. The battery temperature is also controlled. This results in the battery not being overworked. In accelerated lifetime tests published a couple years ago by Toyota, it appeared that the internal resistance of the batteries in a 1st generation Prius would be expected to decrease (effectively making the batteries better) for the first 80,000 miles (or so) and to return to the as-delivered resistance at about 150,000 miles. After that, the resistance is rising, and one could really say the pack will be wearing out between then and 200,000+ miles. Also, the $8,000 battery cost is nonsense. Even a new Hybrid battery direct from Toyota was only about $5000 in the early Priuses. If a replacement market has to develop, one can bet that off-brand packs will be available for a lot less than that once competition cuts in. Of course, if the packs outlive the cars anyway, thuis may not happen.
The oldest (that I know of) Prius was a taxi in Vancouver, BC which was retired with its original battery pack at 200,000 miles. There is no evidence that hybrid battery packs will not, in general, live as long as the rest of the vehicle. IIRC, the car was then bought back by Toyota for engineering analysis, to what really does start to wear out.
Note: I am an extremely happy Prius driver... I am also an advocate for green technology that really works. Nothing makes me happier than technology which is not only cleaner than its predecessors, but nicer to use. This is the case with the Prius. It is peppy, extremely quiet, and smooth to drive. Since it has no transmission as you normally think of one, and even the term continuously-variable transmission doesn't really describe the power splitting transaxle, one can drive up and down hills, and accelerate briskly, with no bump from a transmission upshifting & downshifting. It's really nice!
I'm not getting something in this discussion. Or, more likely, the powers-that-be are intentionally ignoring this.
It seems that there is no need to make hardware changes to USB to prevent unauthorized writing of data to external USB memory. At least in the UNIX/Linux/MacOSX model, you could just make the automount daemon (or windows equivalent) require certain privileges (e.g. specific group membership) before allowing r/w access to an external device. If computers installed in a corporate/secure environment had this requirement, it would prevent external filesystems from having data written to them. For a home/nonsecure environment, the daemon responsible would allow anyone to attach r/w.
Devices (such as HID things like mice) at present don't store any data, so allowing r/w access to such components would be harmless. At least in a corporate environment, it would also be easy enough to require that your mouse be a specified model/brand and (maybe in the future) even present credentials if requested by the computer before attaching. This would make it at least quite difficult for people to figure out a backdoor by storing data in a bogus mouse-like device somehow. This still doesn't require a hardware change, since all you would be doing is asking the mouse to sign a message, for example, to verify it is authentic before allowing it to interact with the system, and on systems where security was being checked, the mouse would just be a regular mouse.
Setting things up this way would make it easy for a user with administrative privileges (who, presumably, has the authority to transfer data on and off the computer), to use external devices, but would make it quite difficult for the regular users to do so.
Is there an obvious security hole in this model, assuming that unauthorized users cannot find methods of privilege escalation?
Re:python's list processing rules
on
Dive Into Python
·
· Score: 1
I didn't say anything of the sort! I in fact speculated that ruby might have better long integer handling than python. This appears to be the case, after a little more fiddling around on my part to check the numbers.
All I did was present some numbers showing why a particular test case (to which my message was a reply) got the result it did.
Although I like python very much, I am open to the fact that other languages might implement different things with very different efficiencies.
Re:python's list processing rules
on
Dive Into Python
·
· Score: 4, Informative
Actually, that took me a while to figure out, too. If you try it with 50000 instead of 100000, on my machine python takes 0.384 seconds while ruby takes 0.537 seconds. With 100000, the comparison is much as you show (except about twice as fast in both cases). If, instead of squaring x, you take x alone, python is also faster.
Apparently, there is something quite different about ruby's handling of long integers (>32) bits from python's. In the python case, this expression automatically switches to infinite-precision integers (at least for python 2.3). I don't use ruby, so I don't know what it is producing when the numbers get beyond 32 bits. Does it automatically go to long integers?
Anyway, the speed difference in this pair of examples seems contrived to get ruby to do something much faster than python, since it requires 'special' values including integer overflow to exercise this effect. Maybe ruby really has better long integer handling than python. Can any on who knows ruby comment on the result of the overflow?
Yup. Anytime I see a terrible movie, I try to compare it to Plan 9. None even come close. The level of mastery of awful movie production shown in this movie is unbelievable. Recently, I got it on DVD for my kids to see, since they didn't believe me that it was incontrovertibly appalling. They both finished seeing it with wide-eyed horror and understanding of how bad it is.
It is the only case I know of where the movie hype (the movie advertises itself as the worst movie ever) actually understates the case.
I can't really think of anything one could do to make a movie worse. Boring won't suffice. Bad special effects will never hold a candle to this. Lack of plot? Try again. Acting? Ouch. Continuity? Huh?
As a number of people have correctly pointed out briefly, Peltier effect devices, also known as thermoelectric coolers (TE coolers) are the most likely way to accomplish this. There are companies (Products for Research, e.g.) that specialize in pre-packaged TE cooling units for various types of equipment. The basic coolers almost all come from Melcor.
With very careful design and construction, you can use a multi-stage TE cooler to get more than a 50C offset from room temperature. It requires careful attention to insulation, and to heatsinking of the first (hottest) stage.
Before you go cooling your camera, though, you should check whether it is designed to run cold. Any device, cooled to -30C (or even to 10 degrees below room temperature, in Tennessee humidity) will start to condense water. To run a camera cold, it must be designed to be water-tight, and must almost certainly have a dry-gas-filled double window (or vacuum double window) on the front, with the outer window heated to prevent fogging.
Overall, unless the camera was specifically designed to be cooled, you may be better off buying one that is appropriately designed, unless you have a lot of time, money, and expertise to put into the engineering. Certainly talk to the manufacturers of the camera you have before you start cooling it, and see if they sell a kit cor conversion.
I was doing maintenance on a client-server network used by students and faculty at my university (where I was an undergraduate), in 1979. The network consisted of a home-designed ethernet-like net with hubs connected to 30 MB 'dishwasher' disk packs, controlled by a PDP-11/15. It was runing RT-11 with an external time-slicing layer I wrote to share between RT-11 and the network management.
While 'cleaning up' a bunch of the disk driver code, to make it more portable, I slipped and turned off the writing of the appropriate zero-padding required for short blocks being sent to disk. It didn't get noticed for about a day, when a large number of students started reporting strangely corrupted files. At this point, I figured out what I had done, and fixed the code. I then had to spend the next few days, every waking hour, hand-locating bits and pieces of the files scattered around the disk, since there was also significant directory damage.
I am a physicist at Vanderbilt University, in the Free Electron Laser Center, who has been doing various kinds of distributed data acquisition and control for about 25 years. I have run into many of the same problems with closed interfaces the author describes, and am slowly developing a strategy to minimize the impact of this problem.
First, I try to avoid products which depend on a closed library/DLL/whatever to control them. This has resulted in my shifting away from a lot of PCI-card devices to (when possible) external devices which communicate via GPIB/IEEE-488, rs233/422/488 interfaces, USB interfaces, network interfaces and (I hope soon) FireWire/IEEE-1394 interfaces. For such devices, one can often find programming specifications, although not always. Obviously, using the slower interfaces may result in lower performance in high-bandwidth environments, so it won't always be an option. However, the fastest current IEEE-1394 looks very promising, as it can support speeds that only a few years ago would saturate a PCI bus.
I have also discovered another interesting phenomenon: 'hidden' standards. In the past year, I became aware of a little-advertised standard, VXI-11, (www.vxi.org), which is a protocol for communicating with GPIB-like devices over TCP/IP. Although one almost never hears about it, a lot of devices support it. Tektronix and Agilent Infiniium scopes use it, and Ethernet-GPIB converters from Agilent, Tektronix and National Instruments all use this. The protocol is open, sunrpc based, and quite easy to implement. However, each company hides any reference to it deep inside the documentation, and basically provides their own Windows dll for communicating with their devices. The Agilent E5810 Ethernet-GPIB converter (a very elegant box) even calls itself a GPIB-LAN interface for Windows, as its official product name, even though it is almost fully VXI-11 compliant and can be used from any platform. I have no idea why they actively _hide_ its cross-platform compatibility.
<slight advertisement> I am trying to address some of these issues by releasing a lot of the code I am working on to interface various devices. I am a python fan, so I have a sourceforge project PythonLabTools which is a library of open-source code to implement communications with various types of devices which are effectively GPIB devices but run over the net via TCP/IP. I am also adding other classes of interface support to this library. An example is the Verinier Software LabPro, a low-end but quite nice and inexpensive a/d, d/a, and digitial i/o box which communicates via serial and USB. There are also data analysis tools in this package (fitting, et.c), and support for the National Instruments DSTP protocol, which allows LabVIEW to share data over a network, and (in this case) allows a Python program to directly interact with a LabVIEW program. This allows separation of the fancy user interface capabilities of LabVIEW from more intensive data analysis which can be executed in Python. <end advertisement>
I am looking forward to a day when more and more external devices with published interfaces become available. Internal devices (PCI or whatever), of course, take a lot of work to make drivers, but since communications with external devices can be carried out in userland, they are easier to provide cross-platform support for. I am alos watching as bandwidth on external interfaces rises to the point where there may not be any need for internal cards and the hassles they create.
I spent a fair amount of time a couple days ago lobbying our National Instruments representative for opening up the interfaces to more of their devices, especially their FireWire/1394 based products, which are right now only supported on Windows (which _really_ galls me, since Apple and Sony spearheaded this interface!). We are a fairly significant customer of theirs, and I think they actually listen.
Here comes this problem again. The article explains it, but buries it at the bottom.
What the group has attained is a transmission line with a phase velocity greater than the speed of light. This is actually not too hard to do with a resonant line (which they have), but they have constructed a cute, cheap way to demonstrate it. The group velocity, which is the speed at which information moves, is still less than c, and they explicitly say so.
The best use for a setup like this is to bring a good demonstration of the difference between the two to an undergraduate laboratory setting, to hammer into students forever the importance of the difference.
I know this is slightly OT, but I have got openDX running quite robustly on OSX10.1.4 with the December 2001 developer tools. It took very minor hacking of one makefile plus a few switches. I am preparing to compile a clean binary and post it somewhere in the next few days (if I have time)
A number of times during the time I spent on the teaching faculty at a University, we reviewed how to adjust the curriculum. One of the more interesting things that often came up was various polls of people in technical fields (engineers, scientists) who had been out 20+ years. When asked what they thought they should have taken more of at the university, in retrospect, the majority response was for more humanities, philosophy, languages, literature and music. Few thought they needed more engineering/science courses.
Many of the technical details one learns in college are quickly outdated, and only serve the first few years of a career. After that, you must learn on your own what you need to keep ahead at work. Good, insightful courses in how our civilizations work, though, and how we live and think, are seen as highly valuable many years later.
Ahhh... not exactly true that this is fixed for free.
I have an early iMac DV with system 8.6. The upgrade to 9.0.x which fixes this is not free from 8.6, so I will be a beneficiary of this upgrade.
I think this is a good example of a small class-action suit working properly: it causes Apple to fix a problem at low cost to them (since the fix is just a CD mailed out) and benefits the users.
yes, I know that there are very significnt variations which make this an unscientific number.
However, the kernel I built was a fairly well-provisioned one with plenty of drivers (USB, networking), filesystems,... so I expect my build shouldn't be unusually fast.
My experience is that the other stuff one builds often has a relatively minor effect on the total time, so the number is probably not a crazy comparison.
Not knowing these benchmarks were available, I just spent today compiling 2.4.6-smp for my Dual 500 MHz G4 PowerMac. My complete kernel rebuild time, using 4 jobs, was 3min,10sec, putting it ahead of the Dual-PIII/1GHz but behind the Dual Athlon/1.2GHz. I was very pleased with this speed.
There should be no question about the absolute velocity accuracy of GPS exceeding that of your car speedometer. I have consistently measured the error, and it hovers around 0.1 m/s rms, over a 1 hour period, with maximum errors of about 0.3 m/s. Now, in USA/English units, 0.1 m/s is about 0.22 mph (miles/hour), which is much better than your car speedometer.
Most decent GPS units actually measure the velocity completely independently of the position. I use an Earthmate, which is based on a Rockwell Zodiac/Jupiter board. It has separate processing for the Doppler information to provide the velocity information (according to the Rockwell information sheets), so even if the position is somewhat poorly converged, the velocity is quite good. I believe this is pretty typical of other units, too.
Slashdot Mirror
this seems a bit steep! With 6 billion people in the world, this is >25 GB for every man, woman and child on the planet. Per year! I doubt the average is even close to that.
OK, this has got to be a seriously flawed study, for any car! $3.25/mile over 100,000 miles means I will have spent $325,000 on car maintenance in the lifetime of my Prius. Does anyone find this number just a bit untenable? Even for a Hummer, this number is untenable.
You asked to see how the data are averaged, and wanted to see it normalized to variance. Here is the site where those records live. Enjoy.
Climate Research Unit Page
There are MUCH older proponents of this separation. In the Augsburg Confession (penned by Melanchthon to reperesent the early views of the nascent Lutheran movement to the princes of Germany and the Roman Catholic Church), the following was stated (rather colorfully!):
Therefore, since the power of the Church grants eternal things, and is exercised only by the ministry of the Word, it does not interfere with civil government; no more than the art of singing interferes with civil government . For civil government deals with other things than does the Gospel. The civil rulers defend not minds, but bodies and bodily things against manifest injuries, and restrain men with the sword and bodily punishments in order to preserve civil justice and peace.
Gotta love the title!
Before everyone starts planning their purchase of a tritium-powered laptop, keep the following numbers in mind:
Assuming a perfectly efficient conversion of the energy released by the 18 keV beta particles from tritium, the specific power available from a tritium battery is 18 keV * 3x10^10 disintegrations/sec/Ci * 1.6x10^-19 Joules/eV = 86 microwatts/Ci.
The last time I checked (a long time ago), the price of bulk tritium was about $10/Ci (probably still true within an order of magnitude), so the price of one of these batteries (assuming, again 100% conversion of beta energy to output power, which is not even close to correct), is $100,000/watt.
Realistically, I think the efficiency could possibly approach 10% if they get very good at collecting the electron showers produced by the betas, but maybe tritium will come down a factor of 10 in price to compensate. I suspect that any large deviation in price from the $100k/W number is unlikely. For most people, that is a showstopper for daily use, since it significantly increases the price of a laptop, from about $1000 to about $1,000,000 (assuming your laptop takes 10 Watts, which is pretty optimistic). Of course, that would also imply that you are carrying around 100,000 Curies of tritium with you (again, at the 10% efficiency level). That's a LOT of tritium.
These are only likely to be important as very long-term sources of sub-milliwatt power. Nonetheless, they may be quite useful there. The efficiency might be quite a bit better that current radiothermal generators, although that will take some work to achieve.
OK, I vote with a lot of other people on Grace/xmgrace for 2d plotting.
For higher dimensionality visualization, though, nobody has mentioned openDX (www.opendx.org). What other plotting and visualization program can easily plot 6-dimensional data (for example, a rank-3 tensor field) on a 3d space?
OpenDX takes a little while to really understand, but once you get it, the payoff is trmendous. It has a very general data model that allow one to have arbitrary topology connecting your values, from completely scattered points with no explicit relation, to various meshes such as simplices (triangles/tets), cubic/hypercubic lattices, and many more.
Also, it represents data in files very flexibly, so one can put structural information in a small, simple file, and reference a larger (potentially huge), external file for the actual data.
That depends on the receiver. The Rockwell/Conexant/NavMan/SiRF receivers used in the DeLorme Earthmate are (at least were in the serial version; don't know about the new USB ones) quite sophisticated. They use a separate receiving chain for the Doppler data, so the velocity solution is independent of the position solution. The error ellipse on a zero velocity point was only about 0.1 m/s in radius. That's plenty good to get a nice velocity on a crew hull. They only return data 1 point per second, but that should realistically be enough, since a hull doesn't accelerate THAT fast.
I work in a Free Electron Laser (FEL) center. The FEL is a few-million-dollar machine which is about 25 meters long, stem to stern. We have occasionally used it to carve Lucite blocks to present as going-away presents for departing associates. We figured that, since the operating budget of the machine (note: not the incremental cost of this task) runs about $500/hour, these could be considered $1000 gifts!
We also use the laser for demonstrations for visiting high school students (etc) to carve hot dogs and to engrave names on tongue depressors. I think it is fairly memorable for the students to see a building-sized apparatus used for this. The only hope is that it gets some of them excited about science.
Warning! Hybrid battery cycles are nothing like EV battery cycles. In an EV, the battery is repeatedly drained from 100% to (typically) a very low charge, resulting in a short life between replacements. On the other hand, a hybrid batery, which is just used for short-term energy buffering, can be pampered by the control electronics.
In the Toyota Prius, the battery is tightly controlled for state-of-charge (SOC) between about 50% and about 90%, and not allowed to deep discharge or overcharge. The battery temperature is also controlled. This results in the battery not being overworked. In accelerated lifetime tests published a couple years ago by Toyota, it appeared that the internal resistance of the batteries in a 1st generation Prius would be expected to decrease (effectively making the batteries better) for the first 80,000 miles (or so) and to return to the as-delivered resistance at about 150,000 miles. After that, the resistance is rising, and one could really say the pack will be wearing out between then and 200,000+ miles. Also, the $8,000 battery cost is nonsense. Even a new Hybrid battery direct from Toyota was only about $5000 in the early Priuses. If a replacement market has to develop, one can bet that off-brand packs will be available for a lot less than that once competition cuts in. Of course, if the packs outlive the cars anyway, thuis may not happen.
The oldest (that I know of) Prius was a taxi in Vancouver, BC which was retired with its original battery pack at 200,000 miles. There is no evidence that hybrid battery packs will not, in general, live as long as the rest of the vehicle. IIRC, the car was then bought back by Toyota for engineering analysis, to what really does start to wear out.
Note: I am an extremely happy Prius driver... I am also an advocate for green technology that really works. Nothing makes me happier than technology which is not only cleaner than its predecessors, but nicer to use. This is the case with the Prius. It is peppy, extremely quiet, and smooth to drive. Since it has no transmission as you normally think of one, and even the term continuously-variable transmission doesn't really describe the power splitting transaxle, one can drive up and down hills, and accelerate briskly, with no bump from a transmission upshifting & downshifting. It's really nice!
I'm not getting something in this discussion. Or, more likely, the powers-that-be are intentionally ignoring this.
It seems that there is no need to make hardware changes to USB to prevent unauthorized writing of data to external USB memory. At least in the UNIX/Linux/MacOSX model, you could just make the automount daemon (or windows equivalent) require certain privileges (e.g. specific group membership) before allowing r/w access to an external device. If computers installed in a corporate/secure environment had this requirement, it would prevent external filesystems from having data written to them. For a home/nonsecure environment, the daemon responsible would allow anyone to attach r/w.
Devices (such as HID things like mice) at present don't store any data, so allowing r/w access to such components would be harmless. At least in a corporate environment, it would also be easy enough to require that your mouse be a specified model/brand and (maybe in the future) even present credentials if requested by the computer before attaching. This would make it at least quite difficult for people to figure out a backdoor by storing data in a bogus mouse-like device somehow. This still doesn't require a hardware change, since all you would be doing is asking the mouse to sign a message, for example, to verify it is authentic before allowing it to interact with the system, and on systems where security was being checked, the mouse would just be a regular mouse.
Setting things up this way would make it easy for a user with administrative privileges (who, presumably, has the authority to transfer data on and off the computer), to use external devices, but would make it quite difficult for the regular users to do so.
Is there an obvious security hole in this model, assuming that unauthorized users cannot find methods of privilege escalation?
I didn't say anything of the sort! I in fact speculated that ruby might have better long integer handling than python. This appears to be the case, after a little more fiddling around on my part to check the numbers.
All I did was present some numbers showing why a particular test case (to which my message was a reply) got the result it did.
Although I like python very much, I am open to the fact that other languages might implement different things with very different efficiencies.
Actually, that took me a while to figure out, too. If you try it with 50000 instead of 100000, on my machine python takes 0.384 seconds while ruby takes 0.537 seconds. With 100000, the comparison is much as you show (except about twice as fast in both cases). If, instead of squaring x, you take x alone, python is also faster.
Apparently, there is something quite different about ruby's handling of long integers (>32) bits from python's. In the python case, this expression automatically switches to infinite-precision integers (at least for python 2.3). I don't use ruby, so I don't know what it is producing when the numbers get beyond 32 bits. Does it automatically go to long integers?
Anyway, the speed difference in this pair of examples seems contrived to get ruby to do something much faster than python, since it requires 'special' values including integer overflow to exercise this effect. Maybe ruby really has better long integer handling than python. Can any on who knows ruby comment on the result of the overflow?
Yup. Anytime I see a terrible movie, I try to compare it to Plan 9. None even come close. The level of mastery of awful movie production shown in this movie is unbelievable. Recently, I got it on DVD for my kids to see, since they didn't believe me that it was incontrovertibly appalling. They both finished seeing it with wide-eyed horror and understanding of how bad it is.
It is the only case I know of where the movie hype (the movie advertises itself as the worst movie ever) actually understates the case.
I can't really think of anything one could do to make a movie worse. Boring won't suffice. Bad special effects will never hold a candle to this. Lack of plot? Try again. Acting? Ouch. Continuity? Huh?
As a number of people have correctly pointed out briefly, Peltier effect devices, also known as thermoelectric coolers (TE coolers) are the most likely way to accomplish this. There are companies (Products for Research, e.g.) that specialize in pre-packaged TE cooling units for various types of equipment. The basic coolers almost all come from Melcor.
With very careful design and construction, you can use a multi-stage TE cooler to get more than a 50C offset from room temperature. It requires careful attention to insulation, and to heatsinking of the first (hottest) stage.
Before you go cooling your camera, though, you should check whether it is designed to run cold. Any device, cooled to -30C (or even to 10 degrees below room temperature, in Tennessee humidity) will start to condense water. To run a camera cold, it must be designed to be water-tight, and must almost certainly have a dry-gas-filled double window (or vacuum double window) on the front, with the outer window heated to prevent fogging.
Overall, unless the camera was specifically designed to be cooled, you may be better off buying one that is appropriately designed, unless you have a lot of time, money, and expertise to put into the engineering. Certainly talk to the manufacturers of the camera you have before you start cooling it, and see if they sell a kit cor conversion.
OK, this will date me a little.
I was doing maintenance on a client-server network used by students and faculty at my university (where I was an undergraduate), in 1979. The network consisted of a home-designed ethernet-like net with hubs connected to 30 MB 'dishwasher' disk packs, controlled by a PDP-11/15. It was runing RT-11 with an external time-slicing layer I wrote to share between RT-11 and the network management.
While 'cleaning up' a bunch of the disk driver code, to make it more portable, I slipped and turned off the writing of the appropriate zero-padding required for short blocks being sent to disk. It didn't get noticed for about a day, when a large number of students started reporting strangely corrupted files. At this point, I figured out what I had done, and fixed the code. I then had to spend the next few days, every waking hour, hand-locating bits and pieces of the files scattered around the disk, since there was also significant directory damage.
I am a physicist at Vanderbilt University, in the Free Electron Laser Center, who has been doing various kinds of distributed data acquisition and control for about 25 years. I have run into many of the same problems with closed interfaces the author describes, and am slowly developing a strategy to minimize the impact of this problem.
First, I try to avoid products which depend on a closed library/DLL/whatever to control them. This has resulted in my shifting away from a lot of PCI-card devices to (when possible) external devices which communicate via GPIB/IEEE-488, rs233/422/488 interfaces, USB interfaces, network interfaces and (I hope soon) FireWire/IEEE-1394 interfaces. For such devices, one can often find programming specifications, although not always. Obviously, using the slower interfaces may result in lower performance in high-bandwidth environments, so it won't always be an option. However, the fastest current IEEE-1394 looks very promising, as it can support speeds that only a few years ago would saturate a PCI bus.
I have also discovered another interesting phenomenon: 'hidden' standards. In the past year, I became aware of a little-advertised standard, VXI-11, (www.vxi.org), which is a protocol for communicating with GPIB-like devices over TCP/IP. Although one almost never hears about it, a lot of devices support it. Tektronix and Agilent Infiniium scopes use it, and Ethernet-GPIB converters from Agilent, Tektronix and National Instruments all use this. The protocol is open, sunrpc based, and quite easy to implement. However, each company hides any reference to it deep inside the documentation, and basically provides their own Windows dll for communicating with their devices. The Agilent E5810 Ethernet-GPIB converter (a very elegant box) even calls itself a GPIB-LAN interface for Windows, as its official product name, even though it is almost fully VXI-11 compliant and can be used from any platform. I have no idea why they actively _hide_ its cross-platform compatibility.
<slight advertisement> I am trying to address some of these issues by releasing a lot of the code I am working on to interface various devices. I am a python fan, so I have a sourceforge project PythonLabTools which is a library of open-source code to implement communications with various types of devices which are effectively GPIB devices but run over the net via TCP/IP. I am also adding other classes of interface support to this library. An example is the Verinier Software LabPro, a low-end but quite nice and inexpensive a/d, d/a, and digitial i/o box which communicates via serial and USB. There are also data analysis tools in this package (fitting, et.c), and support for the National Instruments DSTP protocol, which allows LabVIEW to share data over a network, and (in this case) allows a Python program to directly interact with a LabVIEW program. This allows separation of the fancy user interface capabilities of LabVIEW from more intensive data analysis which can be executed in Python. <end advertisement>
I am looking forward to a day when more and more external devices with published interfaces become available. Internal devices (PCI or whatever), of course, take a lot of work to make drivers, but since communications with external devices can be carried out in userland, they are easier to provide cross-platform support for. I am alos watching as bandwidth on external interfaces rises to the point where there may not be any need for internal cards and the hassles they create.
I spent a fair amount of time a couple days ago lobbying our National Instruments representative for opening up the interfaces to more of their devices, especially their FireWire/1394 based products, which are right now only supported on Windows (which _really_ galls me, since Apple and Sony spearheaded this interface!). We are a fairly significant customer of theirs, and I think they actually listen.
What the group has attained is a transmission line with a phase velocity greater than the speed of light. This is actually not too hard to do with a resonant line (which they have), but they have constructed a cute, cheap way to demonstrate it. The group velocity, which is the speed at which information moves, is still less than c, and they explicitly say so.
The best use for a setup like this is to bring a good demonstration of the difference between the two to an undergraduate laboratory setting, to hammer into students forever the importance of the difference.
I know this is slightly OT, but I have got openDX running quite robustly on OSX10.1.4 with the December 2001 developer tools. It took very minor hacking of one makefile plus a few switches. I am preparing to compile a clean binary and post it somewhere in the next few days (if I have time)
A number of times during the time I spent on the teaching faculty at a University, we reviewed how to adjust the curriculum. One of the more interesting things that often came up was various polls of people in technical fields (engineers, scientists) who had been out 20+ years. When asked what they thought they should have taken more of at the university, in retrospect, the majority response was for more humanities, philosophy, languages, literature and music. Few thought they needed more engineering/science courses.
Many of the technical details one learns in college are quickly outdated, and only serve the first few years of a career. After that, you must learn on your own what you need to keep ahead at work. Good, insightful courses in how our civilizations work, though, and how we live and think, are seen as highly valuable many years later.
Ahhh... not exactly true that this is fixed for free.
I have an early iMac DV with system 8.6. The upgrade to 9.0.x which fixes this is not free from 8.6, so I will be a beneficiary of this upgrade.
I think this is a good example of a small class-action suit working properly: it causes Apple to fix a problem at low cost to them (since the fix is just a CD mailed out) and benefits the users.
yes, I know that there are very significnt variations which make this an unscientific number.
... so I expect my build shouldn't be unusually fast.
However, the kernel I built was a fairly well-provisioned one with plenty of drivers (USB, networking), filesystems,
My experience is that the other stuff one builds often has a relatively minor effect on the total time, so the number is probably not a crazy comparison.
Not knowing these benchmarks were available, I just spent today compiling 2.4.6-smp for my Dual 500 MHz G4 PowerMac. My complete kernel rebuild time, using 4 jobs, was 3min,10sec, putting it ahead of the Dual-PIII/1GHz but behind the Dual Athlon/1.2GHz. I was very pleased with this speed.
There should be no question about the absolute velocity accuracy of GPS exceeding that of your car speedometer. I have consistently measured the error, and it hovers around 0.1 m/s rms, over a 1 hour period, with maximum errors of about 0.3 m/s. Now, in USA/English units, 0.1 m/s is about 0.22 mph (miles/hour), which is much better than your car speedometer.
Most decent GPS units actually measure the velocity completely independently of the position. I use an Earthmate, which is based on a Rockwell Zodiac/Jupiter board. It has separate processing for the Doppler information to provide the velocity information (according to the Rockwell information sheets), so even if the position is somewhat poorly converged, the velocity is quite good. I believe this is pretty typical of other units, too.