If the language you are using doesn't support exceptions (C, Perl, etc), you are going to have problems. Exceptions make sure that if an error occurs, and you aren't aware of it, your program dies, and doesn't go on its merry way, causing a security hole/unstable software.
Unless it's an uninitialized-memory error or a buffer overrun that overwrites some other program variables, in which case a C++ program will still keep going on its merry way without throwing an exception, causing difficult-to-duplicate and hard-to-trace bugs.
If it's possible to check for the error at all, then anything that you can implement with exceptions you can implement without exceptions (though I agree that exceptions are a _neater_ way of doing it).
If your program can't check for the error (as is common for memory errors without extensive and slow wrapping on memory accesses), then exceptions won't be triggered and you're still screwed.
[Aside: You can propagate error codes up between levels either by making error codes bit vectors and masking subcall errors on to the parent call's failure code, or by implementing your own error stack (if you anticipate using deep recursion). Messy, so exceptions are still _preferable_, but it can still be _done_ without exceptions. Almost as cleanly, if you wrap error-handling helper functions nicely.]
Imagine if, instead of being locked down all day, the US prison population was educated. Classes all day, homework all night. Give them job skills. Rehabilitate criminals into functional members of society so that when they get out they know how to do something other than be a pain in the ass!
You are assuming that most criminals *want* to be something other than a pain in the ass.
Some will, certainly.
Many won't.
Problems occur when, as happens every few decades, someone has the bright idea that *all* prisoners should just be "rehabilitated", and then sent out into the world as productive, honest members of society.
Any real scheme should take into account the fact that a large number of people in prison are truly criminal - inclined to committing crimes - and will continue to do so. Help the ones who are interested in being helped, but don't assume they all will be.
The primary purpose of prison, IMO, should be neither punative nor rehabilitative - it should be to keep the prisoners from further harming the rest of society.
So the actual program (let's say Joust) is on a ROM cartridge or something?
The program code and all sprite data is on the ROM cartridge, and stays there (the ROM cartridge just looks like normal memory as far as the system's concerned). RAM is used as scratch space only.
The question going through my mind is - why would the graphics driver care what the name of the executable is? If you had a way of cheating to improve performance, wouldn't you just apply it across the board?
Why would they _not_ implement this speed/quality cheat for everything they could? If they were worried about benchmark programs noticing quality problems, the logical thing to do would be to special-case WinBench, not Quake.
HP is going CMP because SMT is too difficult in terms of writing the compilers.
Actually, I think they're doing it because it means they don't have to design a new processor core.
As far as each thread being executed in an SMT chip is concerned, they're running on a single-thread processor. The same scheduling optimizations that benefit code in a single-thread system will benefit the code running SMT with other threads. SMT actually makes this job a bit easier, by reducing the effective latency of instructions (if neither thread's stalled, each thread will execute every other clock, making a 10-cycle-latency instruction look like a 5-cycle-latency instruction, which in turn makes each thread less _likely_ to stall; nice feedback loop here).
The only extra complexity would be in the operating system's scheduling and context switching routines, and that wouldn't be much more complicated than on a multiprocessor system.
Running Joust on 128 BYTES ram? I think you and Michael are pulling our legs. By way of comparison, this post is 129 bytes long.
The RAM is only used to store game state that changes while you play. This would be the level number, the score, the position and velocity of your character, and the positions and velocities of enemy characters and of the eggs that spawn.
This most certainly would fit in 128 bytes.
The Atari has a very, very bizzare internal architecture. A good page describing it is at:
This is very hard. Weird sh*t happens when you try that. You get heavier, shorter and time slows down. IANAP (I am not a Physicist) but we aren't going to get close to the speed of light until we radically change our physics
Actually, we could do it now. It would just be horrifically expensive.
Method number one is to use an external power source to accelerate the ship. The least expensive way to do this is to build a giant laser array in space and use this to propel a solar sail. This would still take something like the US's entire military budget for the last century to implement (out of our price range for now).
Method number two is to use a fuel with a very high energy density, with a nearly-perfect drive. Antimatter works decently for this (antiproton annihilation produces charged particles (mesons) that can be directed with a magnetic field before they decay). However, the entire world production of antiprotons is something like a few nanograms per year. A pure-antimatter-drive ship would need hundreds of tonnes. Other approaches to interstellar craft use various types of fusion drive. The problem is that you need a fusion reaction that leaves most of its energy as kinetic energy of charged particles, which rules out the easiest two or three forms of fusion (which aren't terribly "easy" to produce as it is).
So, we could build an interstellar near-C laser launched sailcraft now, for an insane amount of money, and we'll probably be able to build interstellar-capable fusion craft within the next hundred years or so. Both methods are difficult, but neither is impossible and neither requires new physics.
If a physicist out there is planning on the whole "But it's impossible!" rant, skip it. We WILL find a way.
The universe has its own idea of what its laws are, and doesn't care how much we *want* to find a way. Hard limits exist.
First theres the problem with the propulsion system: we're simply not fast enough in our spaceships. In order to get anywhere we need to approach the speed of light or even exceed it
Getting to another star system would require near-C travel, but getting to other planets certainly doesn't. Chemical rockets can get just about anywhere in the inner solar system in a couple of years, and anywhere in the outer solar system within about five years.
Use an ion drive, and you can get just about anywhere within 1-2 years.
Sure, you won't be commuting to Mars for the weekend, but this is certainly good enough for colonization and trade. Think back to the old days of wooden ships on Earth.
Second humans are really not meant to be put in space. We need to adapt, and we need to adapt in a serious way. Most of our body is made up of this little molecule H2O, and we need lots of it to survive. Water is not easy to get in space! Food is another problem. Another is that the human bonestructure degenerates in space.
Humans aren't going to change their basic structure. We can, however, build contained environments that can support us.
Water isn't a problem. We already have water-reclamation systems that are perfectly efficient (we just don't use them because they're expensive). Your ship is air- and water-tight - you won't lose any mass to space.
If you have a big enough ship, food isn't a problem - grow it the old-fashioned way. Or stockpile a year's worth of army rations (this will take mass, but not an unmanageable amount of mass; it's just probably cheaper to grow food).
Gravity similarly isn't a problem. You can either live with bone degeneration, or you can connect two ship parts with a long cable and spin them to get a wonderful simulation of gravity and avoid all zero-g related health problems.
In summary, I don't think we need any new magical technology for in-system space travel. We have pretty much everything we need already.
Actually 1T-SRAM has been around for awhile. The GameCube uses some for main memory. See the/. article
I checked the article and Mosys's site, but the only detailed descriptions of the technology are behind registration scripts.
Could you give a brief description of the operating principles of single-transistor SRAM, or should I just bite the bullet and register on Mosys's site?
The text book answer is to charge up a realy big capacitor, you can get 1 Farad caps now for car stereos. Once its chargege up the Cap is imploded by an explosive charge to give it a realy big boast and when its compressed enough you just throw the switch. The water shoots up pretty good.
It sounds like you're thinking of the standard EMP current spike generator - that's made by crushing an inductor, not a capacitor. Someone posted a good description of the physics involved a while back, but I'm afraid I don't have the link handy.
[You run a starting current through the inductor, then rig explosives to create a travelling short that moves along the inductor decreasing its inductance. As inductance decreases, current increases to keep the stored energy constant.]
Excuse my ignorance, but isn't passing 100 amps through a bridge rectifier going to be a problem? Do they make diodes with this kind of current capacity?
Sure they do. You're at U of T; go down to Queen and Spadina and head east to SupremeTronic:). That's where I got the one I used for an electrolysis rig a while back.
The one I bought might only have been rated to 30 amps, but the straightforward solution is to just run three or four in parallel with a big aluminum bar bolted across the cases to keep them at the same temperature (otherwise thermal runaway will cause the hottest one to fail, then the next, and so on).
Dude, F=BLI. There's no squaring at work here. You'll need 100's, if not K and M amps to do anything resembling a railgun.
But, P=I^2R. Your Joule heating will be considerable. You'll need some good engineering so that your toy won't disintegrate itself.
And V=LdI/dT. You'll need city bus size capacitors and hydrogen thyratrons to switch massive currents quickly. For railguns we're talking mega-amps in 20 nanoseconds.
Depends on what you call a "railgun".
If you're trying to make a small water fountain, you can get away with a newton of force or less. You'd also be working in continuous mode, which means a capacitor bank isn't needed (just a DC or approximately DC power supply that can provide the needed current).
One-tesla magnets are easy to buy or build - about one tesla is the saturation point of most ferromagnetic materials, so a chunk of iron will turn a 0.01-T or 0.001-T solenoid into a 1T magnet in short order (depending on the permeability of garden-variety scrap iron).
Similarly, high-strength permanent magnets will be in the Tesla range (probably more like half a tesla, but still strong enough for our purposes).
At one tesla, for a force of 1N, and assuming a water tube 1 cm wide, a current of 100 amps is adequate. A step-down transformer, a bridge rectifier, and a wall plug, and you're there.
For a proof-of-concept tabletop railgun, you can similarly relax constraints. If I'm trying to fling, say, a 10g segment of copper plumbing pipe across a room, I don't need a capacitor bank - I need a marine battery. If I can fire the projectile at 10m/s, that gives me a good 5m or so before it hits the floor from tabletop height (10m if I fire it at an angle instead of level); more than enough for a party trick. At that low a speed, it's in the railgun for tens of milliseconds or longer - I don't need nanosecond discharge circuitry. My hypothetical 10g projectile would have a kinetic energy of about half a joule, which means that if my railgun is about a foot and a half long, I again need only 1N of force. A marine battery can supply the required 100 amps of current without any problems at all (in fact, I'd want to drop a resistor in series with it to make sure it doesn't supply much more than that when I short the railgun across it).
Preventing the slug from spot-welding itself to the rails is left as an exercise for the reader:).
In summary, while I'd need heftier electronics to build a military-grade weapon, tabletop railguns and similar motor-principle conversation pieces aren't that hard to build.
[Aside: I'd actually build a coilgun instead of a railgun if I wanted a military-grade weapon. Much, much easier to build at high power than an ultra-high-current railgun (it's just a series of high-power RF or IF coils repelling the slug with induced currents). Even here, millisecond-level timing is perfectly adequate.]
Tinfoil is a pretty poor choice for a projectile. Have you everpicked up a piece of tinfoil w/ a magnet? That's your problem.
Open an introductory physics text and look up the "motor principle". The projectile doesn't have to be magnetic - it has to be conducting.
Current flowing through a wire (or other conductor) in a magnetic field produces a force on the wire proportional to the magnetic field strength and the electric current, in a direction perpendicular to both.
That's why you can build a fountain with this effect in the first place (water certainly isn't magnetic).
The force is also proportional to the length of the wire, which gives interesting scaling effects but isn't direcly relevant.
I never got around to trying to build an MHD fountain that would shoot salt water up in the air past a large magnet and a pair of electrodes. Has anyone tried this kind of a project?
I tried building a railgun once, which worked on exactly the same principles (run current through a metal projectile perpendicular to a magnetic field).
My projectile was a shred of tinfoil. It twitched, but didn't move. Then I did the calculations to find out exactly how much current I'd need for a decent amount of force on the projectile.
Even with a very strong magnetic field (think "one tesla"), you're going to need a silly amount of current to apply enough force to give a nice fountain effect (think "hundreds of amps"). This will heat your water up quite a bit, and give you quite a lot of hydrogen and chlorine gas as a byproduct if you're using saltwater.
It should still be do-able; I'm just warning you that it won't be as easy as you might hope:).
Use a nitrate as the electrolyte and you'll avoid the chlorine gas problem (you should get hydrogen and oxygen).
To reverse engineer and duplicate a processor requires a superior understanding of processor design and construction.
Once you have reverse engineered the processor, why wouldn't you then put your resources into designing a better processor based on what you've learned, rather than wasting time making a clone?
Actually, it turns out that reverse-engineering is better for a couple of reasons.
It's less work, not more.
When designing a chip, you have to make a host of design decisions without knowing for certain how each of them will affect performance (you try to make an intelligent gamble on picking the right approaches). If you have an existing architecture to copy, you know more or less what the tradeoff results actually were. This saves a lot of agonizing and design time.
You need to follow the leader's instruction set.
AMD is big enough *now* to add its own instruction set extensions, but this is a fairly recent development. Anyone else has to make their chip fully compatible with either Intel or AMD (Intel for safety). This counts as "cloning" as far as the average tech article writer is concerned. Whether the microarchitectural approaches are copied as well is up to the clone maker.
I know that Via's not planning to make a P4 clone (yet). However, I believe that reverse-engineering would by far be the less costly approach for anyone attempting to clone the P4.
The good thing with light (photons) are that photons are 'bosons', which amongst other things means that they do not interact with other photons. Good for transporting data, since noise is not a problem.
Electrons, on the other hand are 'fermions', which means that they interact strongly with other electrons.
Actually, the fact that the carriers are fermions or bosons doesn't affect interference. Interference occurs because electric currents in nearby wires couple strongy with each other via EM effects, because of all of the free charges moving around.
Consider a "bus" that involved components poking at each other with sticks. The sticks are composites of many fermions (their subatomic consitutents), but poking one stick doesn't interfere with the status of another stick (assuming vacuum and good shock absorbers).
Communicating with electric currents, on the other hand, is like trying to poke with sticks in jello. Motion of charges generates EM fields, which moves nearby charges.
If you took volunteers and told them they were (for example) staffing a career counseling intranet chat system, and had them interact with a blind mix of real people and machine systems, then I'd be more impressed by machines convincing judges that the machines are people.
AI programs have already passed this test, repeatedly, if anecdotal evidence counts for anything.
Another poster has already mentioned the AOLiza page. My favourite conversation featured the victim remarking aloud that AOLiza's comments were repetitive, AOLiza asking, "and what does this tell you?", and the user still not cluing in...
A former co-worker of mine told me of another example from the early BBS days. A friend had set up a hacked version of Eliza as "Bob, the Assistant Sysop" before chatbots were common on BBSs. He got a few comments along the lines of "Bob's a nice guy, but he keeps asking me if I have any problems...".
All that remains is to decode the video signal for processing by the projector. In a simple mode, you might even be able to simply take the HSYNC and VSYNC signals and, essentially, use them to mark the edges of your scanning motion, then simply vibrate the mirror back and forth within that time frame. (this is hard to describe, but hopefully it'll make sense to some of you).
An easier way to do this is to use two spinning mirrors to do your scanning. The problem with this is that you'd need to buffer and re-send the image data, because your "blanking intervals" will be much larger than your display time under this scheme. If you don't mind hacking CRTC settings and are using a computer instead of a TV, you might be able to get your video card to drive its monitor port with this kind of signal instead (had a lot of fun making video cards do things they were never intended to a couple of years back).
You'll also need to have the spinning mirrors fairly far from your projection screen or wall to avoid distortion (you're scanning at constant angular frequency, not constant linear speed on the wall). This makes sych problems worse (blanking interval is that much larger, because you're using that much narrower a wedge of the circle the beam is scanned through).
Electronics to synch the mirror rotation to the synch pulses is easy to build. Use a classical control system with extra damping. $2 worth of electronics to clean up the input signals and $1 worth of electronics to control the speed of the mirror-spinning motors.
Now, the big problem (as others have pointed out) is that you must deliver enough power to your LEDs to brightly illuminate a large patch of wall (or screen, if you prefer). This means shelling out tens of thousands of dollars for a high-power krypton laser (so you get R/G/B from one laser), some decent optics (gratings to separate out the colours, mirrors, etc), and "three accousto-optic modulators" (devices that modulate a signal on to a laser beam). This will probably be cheaper than your laser, but that's only because the laser is bloody expensive.
How much distortion do you get using a second lens?
I never did get around to doing this. I had a glass lens from an old slide projector, but grew tired of the project.
The way I'd do it would be to use the Fresnel lens to focus the tv picture down to a very _small_ image, and use a second lens to blow that up on to the screen (image size much smaller than the lens's focal length means a closer approximation to an ideal lens). OTOH, I'd still have curved-surface distortion focusing down the TV image.
If you try it, please let me know how well it works:).
I can't get to the linked site right now (I'm presuming it was slashdotted allready), but the way it worked was to basically use a magnifing glass. The screen emmits through a box of a certain size (the screen size), If you put a lense over that, in theory, you could magnify that light, so that it would be large enough to fill a "100 inch" screen, but it would look horrible!
I would think it would be very blurred, very hard to see (they don't give off THAT much light), and the colours would wash out.
I'd be curious to hear of anyone's actual experiences in building one of these.
I built a setup like this as a kid using a fresnel lens and a bed sheet. I even rigged a translation stage for the lens for precise focusing.
Problems were as follows, in order of severity:
Your focal plane isn't a plane.
Because nothing really acts like an ideal lens, the image focused on to a curved surface. I was using a flat sheet as my screen. This meant that either the center was in focus, or a ring around it was in focus, but not both.
You can reduce this by using a longer focal length, an aperture, or both, but this is trickier and loses light.
My TV distorts colour when turned upside-down.
I was using one lens. This turned the image upside-down. This meant I had to turn the TV upside-down to get a usable picture. This made the TV image turn funny colours. I have no idea if this happens to most TVs or not. A well-made TV *shouldn't* have this problem - it _should_ only be gravity-sensitive if some of the focusing coils are loose inside it. The electron beam certainly doesn't care about gravity. YMMV.
You can get around this by using two lenses instead of one, or by turning the image upside-down with two mirrors before projecting it. This adds complexity and takes up space.
An alternate solution - that I used the first year I did this - is to put the TV flat on the floor and project on to a sheet on the cieling.
Fresnel lenses are crappy.
You get some colour spreading, but not that much. The main problem is that the image will be at least a little blurry no matter what you do. Especially if your lens is like mine and is scratched up from handling.
The sheet has to be very thin, or you have to be looking at the TV-side of it.
Projecting through a sheet degrades resolution, because the sheet scatters light within itself. You can either look at the image from the back (either getting a mirror-image or needing a mirror to flip the image), or use a very thin sheet and view it from the front.
The projection is very dim.
I solved this by hosting my video parties in the basement and covering the windows. YMMV. Real projection TVs have CRTs designed to operate more brightly than normal TV screens.
These aren't insurmountable problems; just very annoying ones to solve.
I don't see how the plate can be welded to the shaft. Don't forget about the stationary vanes! That means that the wobble plate cannot be spinning about the axis, right?
The vanes are inside the cones, and so don't interfere with the plate's spin. The animation has a reasonably clear picture of this (the "vanes" are the radial fins inside the cone on the left).
I still don't see how i'ts supposed to be possible to run the thing dry. There's extensive friction involved here, both in the plate rubbing against the vane, but more importantly along the ridge or groove you'd need in the ball to transfer motion from the plate to he shaft. all the power has to go through this continuously sliding contact surface.
The plate is welded to the shaft, if I understand correctly. It would either slide against or just pass very close to the surfaces of the conical end-caps and the outer wall of the combustion chamber.
I can see building a setup like this where the disc doesn't actually contact anything (just passes close to relevant surfaces). It would just lose efficiency from exhaust leakage through the resulting gap.
You'll still need bearings on the shaft, of course.
The problem is ofcourse to generate large amounts of hydrogen.
Given the succes of recent tests with fusion reactors, who knows.
Why wait for fusion?
Hydrogen is just a way of transporting energy that you've generated elsewhere. Use a fission plant or a fossil fuel power plant or a solar array or a hydroelectric dam or any other conventional power plant to generate the power you produce the hydrogen with. This lets you handle pollution and energy-source switchover at a handful of power plants instead of having to re-tool a hundred million cars when you discover the Miracle Fuel (tm).
Slashdot Mirror
If the language you are using doesn't support exceptions (C, Perl, etc), you are going to have problems. Exceptions make sure that if an error occurs, and you aren't aware of it, your program dies, and doesn't go on its merry way, causing a security hole/unstable software.
Unless it's an uninitialized-memory error or a buffer overrun that overwrites some other program variables, in which case a C++ program will still keep going on its merry way without throwing an exception, causing difficult-to-duplicate and hard-to-trace bugs.
If it's possible to check for the error at all, then anything that you can implement with exceptions you can implement without exceptions (though I agree that exceptions are a _neater_ way of doing it).
If your program can't check for the error (as is common for memory errors without extensive and slow wrapping on memory accesses), then exceptions won't be triggered and you're still screwed.
[Aside: You can propagate error codes up between levels either by making error codes bit vectors and masking subcall errors on to the parent call's failure code, or by implementing your own error stack (if you anticipate using deep recursion). Messy, so exceptions are still _preferable_, but it can still be _done_ without exceptions. Almost as cleanly, if you wrap error-handling helper functions nicely.]
Imagine if, instead of being locked down all day, the US prison population was educated. Classes all day, homework all night. Give them job skills. Rehabilitate criminals into functional members of society so that when they get out they know how to do something other than be a pain in the ass!
You are assuming that most criminals *want* to be something other than a pain in the ass.
Some will, certainly.
Many won't.
Problems occur when, as happens every few decades, someone has the bright idea that *all* prisoners should just be "rehabilitated", and then sent out into the world as productive, honest members of society.
Any real scheme should take into account the fact that a large number of people in prison are truly criminal - inclined to committing crimes - and will continue to do so. Help the ones who are interested in being helped, but don't assume they all will be.
The primary purpose of prison, IMO, should be neither punative nor rehabilitative - it should be to keep the prisoners from further harming the rest of society.
So the actual program (let's say Joust) is on a ROM cartridge or something?
The program code and all sprite data is on the ROM cartridge, and stays there (the ROM cartridge just looks like normal memory as far as the system's concerned). RAM is used as scratch space only.
The question going through my mind is - why would the graphics driver care what the name of the executable is? If you had a way of cheating to improve performance, wouldn't you just apply it across the board?
Why would they _not_ implement this speed/quality cheat for everything they could? If they were worried about benchmark programs noticing quality problems, the logical thing to do would be to special-case WinBench, not Quake.
HP is going CMP because SMT is too difficult in terms of writing the compilers.
Actually, I think they're doing it because it means they don't have to design a new processor core.
As far as each thread being executed in an SMT chip is concerned, they're running on a single-thread processor. The same scheduling optimizations that benefit code in a single-thread system will benefit the code running SMT with other threads. SMT actually makes this job a bit easier, by reducing the effective latency of instructions (if neither thread's stalled, each thread will execute every other clock, making a 10-cycle-latency instruction look like a 5-cycle-latency instruction, which in turn makes each thread less _likely_ to stall; nice feedback loop here).
The only extra complexity would be in the operating system's scheduling and context switching routines, and that wouldn't be much more complicated than on a multiprocessor system.
Running Joust on 128 BYTES ram? I think you and Michael are pulling our legs. By way of comparison, this post is 129 bytes long.
The RAM is only used to store game state that changes while you play. This would be the level number, the score, the position and velocity of your character, and the positions and velocities of enemy characters and of the eggs that spawn.
This most certainly would fit in 128 bytes.
The Atari has a very, very bizzare internal architecture. A good page describing it is at:
http://www.alienbill.com/vgames/atari.tech.html
This is very hard. Weird sh*t happens when you try that. You get heavier, shorter and time slows down. IANAP (I am not a Physicist) but we aren't going to get close to the speed of light until we radically change our physics
Actually, we could do it now. It would just be horrifically expensive.
Method number one is to use an external power source to accelerate the ship. The least expensive way to do this is to build a giant laser array in space and use this to propel a solar sail. This would still take something like the US's entire military budget for the last century to implement (out of our price range for now).
Method number two is to use a fuel with a very high energy density, with a nearly-perfect drive. Antimatter works decently for this (antiproton annihilation produces charged particles (mesons) that can be directed with a magnetic field before they decay). However, the entire world production of antiprotons is something like a few nanograms per year. A pure-antimatter-drive ship would need hundreds of tonnes. Other approaches to interstellar craft use various types of fusion drive. The problem is that you need a fusion reaction that leaves most of its energy as kinetic energy of charged particles, which rules out the easiest two or three forms of fusion (which aren't terribly "easy" to produce as it is).
So, we could build an interstellar near-C laser launched sailcraft now, for an insane amount of money, and we'll probably be able to build interstellar-capable fusion craft within the next hundred years or so. Both methods are difficult, but neither is impossible and neither requires new physics.
If a physicist out there is planning on the whole "But it's impossible!" rant, skip it. We WILL find a way.
The universe has its own idea of what its laws are, and doesn't care how much we *want* to find a way. Hard limits exist.
First theres the problem with the propulsion system: we're simply not fast enough in our spaceships. In order to get anywhere we need to approach the speed of light or even exceed it
Getting to another star system would require near-C travel, but getting to other planets certainly doesn't. Chemical rockets can get just about anywhere in the inner solar system in a couple of years, and anywhere in the outer solar system within about five years.
Use an ion drive, and you can get just about anywhere within 1-2 years.
Sure, you won't be commuting to Mars for the weekend, but this is certainly good enough for colonization and trade. Think back to the old days of wooden ships on Earth.
Second humans are really not meant to be put in space. We need to adapt, and we need to adapt in a serious way. Most of our body is made up of this little molecule H2O, and we need lots of it to survive. Water is not easy to get in space! Food is another problem. Another is that the human bonestructure degenerates in space.
Humans aren't going to change their basic structure. We can, however, build contained environments that can support us.
Water isn't a problem. We already have water-reclamation systems that are perfectly efficient (we just don't use them because they're expensive). Your ship is air- and water-tight - you won't lose any mass to space.
If you have a big enough ship, food isn't a problem - grow it the old-fashioned way. Or stockpile a year's worth of army rations (this will take mass, but not an unmanageable amount of mass; it's just probably cheaper to grow food).
Gravity similarly isn't a problem. You can either live with bone degeneration, or you can connect two ship parts with a long cable and spin them to get a wonderful simulation of gravity and avoid all zero-g related health problems.
In summary, I don't think we need any new magical technology for in-system space travel. We have pretty much everything we need already.
Actually 1T-SRAM has been around for awhile. The GameCube uses some for main memory. See the /. article
I checked the article and Mosys's site, but the only detailed descriptions of the technology are behind registration scripts.
Could you give a brief description of the operating principles of single-transistor SRAM, or should I just bite the bullet and register on Mosys's site?
I *thought* the cache density looked a bit high for ordinary SRAM - the article mentions something they're calling "single-transistor SRAM".
Does anyone know how on earth they're managing this? Or is this just some low-leakage variant of DRAM with added marketing spin?
The text book answer is to charge up a realy big capacitor, you can get 1 Farad caps now for car stereos. Once its chargege up the Cap is imploded by an explosive charge to give it a realy big boast and when its compressed enough you just throw the switch. The water shoots up pretty good.
It sounds like you're thinking of the standard EMP current spike generator - that's made by crushing an inductor, not a capacitor. Someone posted a good description of the physics involved a while back, but I'm afraid I don't have the link handy.
[You run a starting current through the inductor, then rig explosives to create a travelling short that moves along the inductor decreasing its inductance. As inductance decreases, current increases to keep the stored energy constant.]
Excuse my ignorance, but isn't passing 100 amps through a bridge rectifier going to be a problem? Do they make diodes with this kind of current capacity?
:). That's where I got the one I used for an electrolysis rig a while back.
Sure they do. You're at U of T; go down to Queen and Spadina and head east to SupremeTronic
The one I bought might only have been rated to 30 amps, but the straightforward solution is to just run three or four in parallel with a big aluminum bar bolted across the cases to keep them at the same temperature (otherwise thermal runaway will cause the hottest one to fail, then the next, and so on).
Dude, F=BLI. There's no squaring at work here. You'll need 100's, if not K and M amps to do anything resembling a railgun.
:).
But, P=I^2R. Your Joule heating will be considerable. You'll need some good engineering so that your toy won't disintegrate itself.
And V=LdI/dT. You'll need city bus size capacitors and hydrogen thyratrons to switch massive currents quickly. For railguns we're talking mega-amps in 20 nanoseconds.
Depends on what you call a "railgun".
If you're trying to make a small water fountain, you can get away with a newton of force or less. You'd also be working in continuous mode, which means a capacitor bank isn't needed (just a DC or approximately DC power supply that can provide the needed current).
One-tesla magnets are easy to buy or build - about one tesla is the saturation point of most ferromagnetic materials, so a chunk of iron will turn a 0.01-T or 0.001-T solenoid into a 1T magnet in short order (depending on the permeability of garden-variety scrap iron).
Similarly, high-strength permanent magnets will be in the Tesla range (probably more like half a tesla, but still strong enough for our purposes).
At one tesla, for a force of 1N, and assuming a water tube 1 cm wide, a current of 100 amps is adequate. A step-down transformer, a bridge rectifier, and a wall plug, and you're there.
For a proof-of-concept tabletop railgun, you can similarly relax constraints. If I'm trying to fling, say, a 10g segment of copper plumbing pipe across a room, I don't need a capacitor bank - I need a marine battery. If I can fire the projectile at 10m/s, that gives me a good 5m or so before it hits the floor from tabletop height (10m if I fire it at an angle instead of level); more than enough for a party trick. At that low a speed, it's in the railgun for tens of milliseconds or longer - I don't need nanosecond discharge circuitry. My hypothetical 10g projectile would have a kinetic energy of about half a joule, which means that if my railgun is about a foot and a half long, I again need only 1N of force. A marine battery can supply the required 100 amps of current without any problems at all (in fact, I'd want to drop a resistor in series with it to make sure it doesn't supply much more than that when I short the railgun across it).
Preventing the slug from spot-welding itself to the rails is left as an exercise for the reader
In summary, while I'd need heftier electronics to build a military-grade weapon, tabletop railguns and similar motor-principle conversation pieces aren't that hard to build.
[Aside: I'd actually build a coilgun instead of a railgun if I wanted a military-grade weapon. Much, much easier to build at high power than an ultra-high-current railgun (it's just a series of high-power RF or IF coils repelling the slug with induced currents). Even here, millisecond-level timing is perfectly adequate.]
Tinfoil is a pretty poor choice for a projectile. Have you everpicked up a piece of tinfoil w/ a magnet? That's your problem.
Open an introductory physics text and look up the "motor principle". The projectile doesn't have to be magnetic - it has to be conducting.
Current flowing through a wire (or other conductor) in a magnetic field produces a force on the wire proportional to the magnetic field strength and the electric current, in a direction perpendicular to both.
That's why you can build a fountain with this effect in the first place (water certainly isn't magnetic).
The force is also proportional to the length of the wire, which gives interesting scaling effects but isn't direcly relevant.
I never got around to trying to build an MHD fountain that would shoot salt water up in the air past a large magnet and a pair of electrodes. Has anyone tried this kind of a project?
:).
I tried building a railgun once, which worked on exactly the same principles (run current through a metal projectile perpendicular to a magnetic field).
My projectile was a shred of tinfoil. It twitched, but didn't move. Then I did the calculations to find out exactly how much current I'd need for a decent amount of force on the projectile.
Even with a very strong magnetic field (think "one tesla"), you're going to need a silly amount of current to apply enough force to give a nice fountain effect (think "hundreds of amps"). This will heat your water up quite a bit, and give you quite a lot of hydrogen and chlorine gas as a byproduct if you're using saltwater.
It should still be do-able; I'm just warning you that it won't be as easy as you might hope
Use a nitrate as the electrolyte and you'll avoid the chlorine gas problem (you should get hydrogen and oxygen).
Once you have reverse engineered the processor, why wouldn't you then put your resources into designing a better processor based on what you've learned, rather than wasting time making a clone?
Actually, it turns out that reverse-engineering is better for a couple of reasons.
When designing a chip, you have to make a host of design decisions without knowing for certain how each of them will affect performance (you try to make an intelligent gamble on picking the right approaches). If you have an existing architecture to copy, you know more or less what the tradeoff results actually were. This saves a lot of agonizing and design time.
AMD is big enough *now* to add its own instruction set extensions, but this is a fairly recent development. Anyone else has to make their chip fully compatible with either Intel or AMD (Intel for safety). This counts as "cloning" as far as the average tech article writer is concerned. Whether the microarchitectural approaches are copied as well is up to the clone maker.
I know that Via's not planning to make a P4 clone (yet). However, I believe that reverse-engineering would by far be the less costly approach for anyone attempting to clone the P4.
The good thing with light (photons) are that photons are 'bosons', which amongst other things means that they do not interact with other photons. Good for transporting data, since noise is not a problem.
Electrons, on the other hand are 'fermions', which means that they interact strongly with other electrons.
Actually, the fact that the carriers are fermions or bosons doesn't affect interference. Interference occurs because electric currents in nearby wires couple strongy with each other via EM effects, because of all of the free charges moving around.
Consider a "bus" that involved components poking at each other with sticks. The sticks are composites of many fermions (their subatomic consitutents), but poking one stick doesn't interfere with the status of another stick (assuming vacuum and good shock absorbers).
Communicating with electric currents, on the other hand, is like trying to poke with sticks in jello. Motion of charges generates EM fields, which moves nearby charges.
If you took volunteers and told them they were (for example) staffing a career counseling intranet chat system, and had them interact with a blind mix of real people and machine systems, then I'd be more impressed by machines convincing judges that the machines are people.
AI programs have already passed this test, repeatedly, if anecdotal evidence counts for anything.
Another poster has already mentioned the AOLiza page. My favourite conversation featured the victim remarking aloud that AOLiza's comments were repetitive, AOLiza asking, "and what does this tell you?", and the user still not cluing in...
A former co-worker of mine told me of another example from the early BBS days. A friend had set up a hacked version of Eliza as "Bob, the Assistant Sysop" before chatbots were common on BBSs. He got a few comments along the lines of "Bob's a nice guy, but he keeps asking me if I have any problems...".
A skeptical audience is harder to fool.
All that remains is to decode the video signal for processing by the projector. In a simple mode, you might even be able to simply take the HSYNC and VSYNC signals and, essentially, use them to mark the edges of your scanning motion, then simply vibrate the mirror back and forth within that time frame. (this is hard to describe, but hopefully it'll make sense to some of you).
:).
An easier way to do this is to use two spinning mirrors to do your scanning. The problem with this is that you'd need to buffer and re-send the image data, because your "blanking intervals" will be much larger than your display time under this scheme. If you don't mind hacking CRTC settings and are using a computer instead of a TV, you might be able to get your video card to drive its monitor port with this kind of signal instead (had a lot of fun making video cards do things they were never intended to a couple of years back).
You'll also need to have the spinning mirrors fairly far from your projection screen or wall to avoid distortion (you're scanning at constant angular frequency, not constant linear speed on the wall). This makes sych problems worse (blanking interval is that much larger, because you're using that much narrower a wedge of the circle the beam is scanned through).
Electronics to synch the mirror rotation to the synch pulses is easy to build. Use a classical control system with extra damping. $2 worth of electronics to clean up the input signals and $1 worth of electronics to control the speed of the mirror-spinning motors.
Now, the big problem (as others have pointed out) is that you must deliver enough power to your LEDs to brightly illuminate a large patch of wall (or screen, if you prefer). This means shelling out tens of thousands of dollars for a high-power krypton laser (so you get R/G/B from one laser), some decent optics (gratings to separate out the colours, mirrors, etc), and "three accousto-optic modulators" (devices that modulate a signal on to a laser beam). This will probably be cheaper than your laser, but that's only because the laser is bloody expensive.
Still a very fun project; just not a cheap one
How much distortion do you get using a second lens?
:).
I never did get around to doing this. I had a glass lens from an old slide projector, but grew tired of the project.
The way I'd do it would be to use the Fresnel lens to focus the tv picture down to a very _small_ image, and use a second lens to blow that up on to the screen (image size much smaller than the lens's focal length means a closer approximation to an ideal lens). OTOH, I'd still have curved-surface distortion focusing down the TV image.
If you try it, please let me know how well it works
I would think it would be very blurred, very hard to see (they don't give off THAT much light), and the colours would wash out.
I'd be curious to hear of anyone's actual experiences in building one of these.
I built a setup like this as a kid using a fresnel lens and a bed sheet. I even rigged a translation stage for the lens for precise focusing.
Problems were as follows, in order of severity:
Because nothing really acts like an ideal lens, the image focused on to a curved surface. I was using a flat sheet as my screen. This meant that either the center was in focus, or a ring around it was in focus, but not both.
You can reduce this by using a longer focal length, an aperture, or both, but this is trickier and loses light.
I was using one lens. This turned the image upside-down. This meant I had to turn the TV upside-down to get a usable picture. This made the TV image turn funny colours. I have no idea if this happens to most TVs or not. A well-made TV *shouldn't* have this problem - it _should_ only be gravity-sensitive if some of the focusing coils are loose inside it. The electron beam certainly doesn't care about gravity. YMMV.
You can get around this by using two lenses instead of one, or by turning the image upside-down with two mirrors before projecting it. This adds complexity and takes up space.
An alternate solution - that I used the first year I did this - is to put the TV flat on the floor and project on to a sheet on the cieling.
You get some colour spreading, but not that much. The main problem is that the image will be at least a little blurry no matter what you do. Especially if your lens is like mine and is scratched up from handling.
Projecting through a sheet degrades resolution, because the sheet scatters light within itself. You can either look at the image from the back (either getting a mirror-image or needing a mirror to flip the image), or use a very thin sheet and view it from the front.
I solved this by hosting my video parties in the basement and covering the windows. YMMV. Real projection TVs have CRTs designed to operate more brightly than normal TV screens.
These aren't insurmountable problems; just very annoying ones to solve.
No list of esoteric programming languages would be complete without a link to the Beer Page:
http://core.federated.com/~jim/99/ (mirror)
This is a collection of programs written in over 200 languages designed to print the canonical "99 bottles of beer on the wall" song.
I don't see how the plate can be welded to the shaft. Don't forget about the stationary vanes! That means that the wobble plate cannot be spinning about the axis, right?
The vanes are inside the cones, and so don't interfere with the plate's spin. The animation has a reasonably clear picture of this (the "vanes" are the radial fins inside the cone on the left).
I still don't see how i'ts supposed to be possible to run the thing dry. There's extensive friction involved here, both in the plate rubbing against the vane, but more importantly along the ridge or groove you'd need in the ball to transfer motion from the plate to he shaft. all the power has to go through this continuously sliding contact surface.
The plate is welded to the shaft, if I understand correctly. It would either slide against or just pass very close to the surfaces of the conical end-caps and the outer wall of the combustion chamber.
I can see building a setup like this where the disc doesn't actually contact anything (just passes close to relevant surfaces). It would just lose efficiency from exhaust leakage through the resulting gap.
You'll still need bearings on the shaft, of course.
The problem is ofcourse to generate large amounts of hydrogen.
Given the succes of recent tests with fusion reactors, who knows.
Why wait for fusion?
Hydrogen is just a way of transporting energy that you've generated elsewhere. Use a fission plant or a fossil fuel power plant or a solar array or a hydroelectric dam or any other conventional power plant to generate the power you produce the hydrogen with. This lets you handle pollution and energy-source switchover at a handful of power plants instead of having to re-tool a hundred million cars when you discover the Miracle Fuel (tm).