This idea, with tweaks, goes back to Gelernter's book "Mirror Worlds". In the late 80s he imagined that the net's primary purpose would be to sustain a big simulation of society.
He wanted to feed the simulation with as much real, accurate information as possible, so that its results would have a lot of predictive and descriptive power. He was particularly interested in its value as an educational tool and as a tool for crafting wiser social, economic, and political policies.
Sims Online is a step toward what Gelernter imagined. A crude step, but it will plant the idea firmly in the minds of millions of people, and offer some clear preliminary notion of how it could be implemented and how well it might work.
If King had said "I need $10k for the next chapter." he'd have been fine. By saying "x% of you need to pay" he was doomed to failure.
Yup, that is EXACTLY what King did wrong. It made me wonder if he was trying something sneaky and back-handed, to pretend to empower new writers, and then demonstrate to them that "even Stephen King can't make this work". Perhaps he did so in collusion with the very publishers he pretended to spurn.
King is King. Joe B. Hacker is "nobody" so even if he writes great fiction, how will he get people's attention?
IIRC, the original SPP (or one of the variants that was floating around at the time) suggested that Joe Hacker should release the first few chapters into the public domain to convince people that his stuff is worth reading. Then he can ransom subsequent chapters one by one.
I think it would be wise to use something a little more complex than a number.
What I envisioned (and failed to make clear) was that the posting would list the ID followed by the amount donated, where the ID would be the anonymous number. Anonymous ID numbers could then only be aliased for anonymous donors who'd send in exactly the same amount.
Your idea of using the donor's public key is a good one, and gets around the same-donation-alias problem. Or anonymous donors could just invent long random pseudonyms, and the chances of identical nyms would be remote.
There have been a few expressions of concern about vaporware. The
solution to this is simple. What is held for ransom is the source
code, but a working executable could be released, sufficient to
demonstrate that the programmer really has written the program in
question. There would still be an incentive to pay the ransom. An
executable isn't as valuable to the average user as a program whose
source has been released, because with the latter, it's possible to
get peer review, upgrades and modifications, etc.
The server was slashdotted before I could read more than the front
page (see Google
cache), so I missed the "step-by-step process" description.
People have mentioned concerns about sky-high ransoms, but the free
market will vote with its feet so that doesn't worry me. Likewise,
the problem of a programmer who raises the ransom after the initial
announcement will be solved because people will get disgusted and
won't pay.
But there's a problem of fraud. Joe Programmer wrote Foo Program and
I've donated ten bucks to have the source released. But I don't know
if Joe counted my ten bucks toward the ransom, or simply pocketed it.
If I'm patient and trusting, I can wait for market forces and
reputation to filter out the programmers who pocket donations.
But Joe can do better by posting a list of donations. For donors who
prefer to be anonymous, he assigns them a number and emails a copy of
the number to them, so they can verify that their donations have been
counted. Anybody can grab a snapshot of the donation list and throw
it in a spreadsheet to verify the current tally.
Anybody whose donation was ignored can gripe in some suitable forum
(Slashdot, Usenet, wherever) and if there are enough gripes that
don't look like kooks, Joe's reputation will suffer.
they plan to 'heat' the NaOH in order to turn it into solid NaH. How would they heat it? Heating costs energy. Is this possibly a similar scam as to use corn based ethanol to power engines?...corn needs an abundance of nitrate rich fertilizer, which in turn requires a lot of energy
It's not a scam. Think of hydrogen as an energy storage medium, not a fuel to be drilled from the ground.
When we use petroleum fuels, we're spending (in just a couple of centuries) energy that was stored over many millions of years. We may think of renewable energy as a rip-off because we need to collect it (from sunlight or wind or tides or whatever) instead of just drilling for existing energy-dense fuel.
But you know we'll run out some day, and renewable energy will be all we'll have. You probably also know that with solar collectors in orbit, we could have a huge annual energy budget by today's standards.
So energy storage, and especially clean energy storage, is going to be very important. Hydrogen is a lot more efficient than corn, because corn uses a lot of that fertilizer energy for metabolism and reproduction. Hydrogen doesn't, so you get almost all your energy back.
A lot of people have thought about making the infrastructure transition easier. One nifty idea is Powerballs. These are ping-pong balls filled with NaH, which float in a tank of water. Above the water the tank is full of H2 gas. When the H2 pressure drops too far, a computer-controlled cutter pops open a ping-pong ball, and NaH + H2O -> NaOH + H2 happens. The H2 bubbles to the top, the NaOH stays in the water.
At the filling station, they pump out the broken shells, water and NaOH from your tank, before putting in new water and powerballs. The broken shells are recyclable. The NaOH is reacted with fresh H2 to produce water and NaH.
There needs to be some regulatory rules to make this process as clean as it promises to be. NaOH is nasty stuff, though no more toxic than gasoline. But overall, it's a cool idea.
Forget about HWR. Graffiti is the best I've seen, and it's still a PITA. Give me a chicklet keyboard like the Zaurus. Or give me speech recognition, if it can be made to work well.
Long battery life. A bright colorful display is worth much less to me than being able to go for weeks on one set of batteries. If I _do_ need to charge it N times per week, don't make me take the batteries out to recharge them.
My biggest problem with PDAs is that I pay big bucks for a small breakable object, and invariably I drop it on a hard surface. Give it a chain, like a pocket watch. Put a snaphook on the end of the chain - some people will prefer to allow their PDAs to hit the floor.
It's good to see this discussion informed by some knowledge of orbital mechanics (a lot more than I have, obviously). For those of us playing catch-up here, some links:
123.
This is obviously a richly researched topic with lots of published papers. Some of them talk about new algorithms for tackling the complex dynamics you're talking about. And of course there's always Moore's Law; the computers used for Apollo missions were about as powerful as (or maybe much less than?) Palm Pilots.
It's probably quite feasible to give the L1 station a radio link to an orbital mechanics cluster on the ground, which can be as big as is needed, and could run equations of motion for a couple dozen nearby orbits in faster-than-real-time.
Most of what was in the article was audio/video systems, and computer networking. Everybody has that, these people just have the more expensive versions. I was hoping for more qualitatively novel stuff.
The vacuum-cleaner robot from a couple days ago is novel, plus it's useful. Popular-Mechanics-style home automation (dimming the windows, opening and closing drapes in response to weather or sun position) would be interesting.
In the early 70s there was a magazine article about a guy whose two dogs couldn't stand each other. He built a system that automatically opened and closed doors in the house, keeping track of where the dogs were, and never allowing them into the same room simultaneously. No microprocessors back then.
Reading the MSNBC article would lead you to think that the only thing accomplished by folding@home has been a feasibility test with a toy (non-biological) protein. The results page (see Google cache) shows dozens of simulation runs, including some of clinical significance.
The big win with the toy protein is that it allows for experimental verification of the validity of data produced by FAH clients. That's a good thing, because biochemists are very suspicious of simulations and tend to ignore them until there's compelling correlation with results from a real lab.
Hopefully this will substantiate a large number of already-done simulations, or at least put them in a position where they suggest some very small amount of lab work to verify an interesting result.
To the folks complaining that only the big pharmas will benefit: This stuff is being done in academia. Would you prefer the big pharmas did it internally and there was NO CHANCE AT ALL for the results to make it into the public knowledge base? Be realistic - you KNOW the big pharmas will be the big winners on anything like this - that's the business they're in. For the rest of us, the best hope is to hasten the day when cheap generics of the resulting drugs are available for low-income patients.
I question the thinking that much would be gained by fighting the big pharmas (quite aside from the complete ineffectiveness of a typical/.er in doing so). They are bearing the research costs for the drugs, as well as the expense of pushing them thru the FDA pipeline. Open-source bazaar-style development will not work for new drugs, no matter how much we wish it would.
completely fit the stereotype, as far as I could see. I don't expect SW movies to grapple with social issues, even trivial ones, but it would have been interesting to see Lucas fire another three neurons and come up with an idea there.
The lack of multiple inheritance bugs me, but it's less of a problem than I'd expected, and it also presents an interesting challenge.
Before you write your preprocessor, you might want to look at how Java handles this challenge. The Java language also permits only single inheritance but there's an additional idea called an interface. The interface is an API which a class can implement; it's not inheritance because the interface doesn't offer any implementations for the methods, it simply requires that all its methods be implemented.
Interfaces still give you polymorphism. It's pretty common where I work to write an interface specifying, say, some kind of event listener, and any class implementing that interface can be an
argument to somebody's addEventListener method.
You mention that you want a thorough plan before you write any code.
As another poster pointed out, it's easier to change a plan than it is
to change code; a plan involving a dead-end approach can be scrapped
with a smaller loss than a large body of code involving the same
dead-end approach.
So the first reason for "plan first, then code" is that coding is
expensive. That expense represents a risk if you're pursuing an
approach that doesn't work out. Throwing away a plan is quicker and
less expensive.
The second reason for "plan first, then code" is that a written plan
is a clear expression of the ideas in the plan. Code is often not
very readable or very obvious, and a large body of code may require
weeks or months of study to get all the nuances at work.
There is a hidden disadvantage to "plan first, then code". Remember
that we're trying to manage the risk of choosing a dead-end approach,
so we want to minimize the investment before the discovery that the
approach is bogus. A non-executable plan won't catch all the design
bugs. It will only catch the design bugs that you can recognize on
inspection of a written plan; the screening process is limited by
your own human cognitive faculties.
What if we could write an executable plan, in a language that is clear
and expressive, and in which writing the plan is inexpensive? This
would be the best of all possible worlds! Luckily you're not the first
person to face a daunting software design challenge, and people have
been designing languages for exactly these constraints for many years
(Python, Perl, Scheme, Ruby, Smalltalk, andothers. These
languages vary in the expressiveness of their syntax. If you're
concerned about the mental expense of coding, you probably will want
to avoid Perl (which looks a lot like C) and Scheme (which requires a
mental paradigm shift). My off-the-cuff recommendation among these
would be Python.
Why not write your final product in one of these easy, inexpensive,
readable, expressive languages? Alas, many of them don't
have the performance of C or C++. If you're doing something
computation-intensive, that matters. But wait! There is another
saving grace, called SWIG, a
program that lets you glue small bits of C or C++ code into your
larger program written in one of the easy languages.
In most computer programs, the performance is gated by a small
number of small pieces of the code. Usually, the majority of the code
does not have a big impact on performance. If you can identify those
small performance-expensive bits, and translate them to C or C++ and
glue them back into your program, you get the speed you want, and 95%
of your code is still readable and expressive, and easy to change
later. The trick to finding these performance-limiting bits is
called profiling (see
1,
2,
3).
So here's the advice (assuming Python):
1. Spend a day learning Python, two days if you're busy. Python
has lots of great libraries, skim the list of libraries as
somebody may have contributed something you'll need.
2. Write your entire program readably in Python. Don't worry about
speed yet. Rewrite as required until you're sure you've got a good
design.
3. Use profiling to locate the few small pieces that slow down your
program.
4. Use SWIG and C/C++ to rewrite those pieces and connect them back
into your program.
I like this idea a lot. But
as others have pointed out, $10K is nothing to a large corporation, and a very big deal to the basement inventor.
The application deposit should be a fixed percentage of the financial "size" of the entity (market cap for corp, last year's declared income for individual). For a typical lone inventor it would cost maybe $2K, where it might cost hundreds of millions for a big corporation. Shareholders would dump the stock of any big corp that sought lots of frivolous patents.
There would be a thriving legal business in appealing rejections, so there would need to be a way to make those variably expensive too.
Off-topic: protocol for animated 3D
on
Open Source TV
·
· Score: 2
There ought to be a protocol for doing 3D animations over networks. It
would work like this: you make up a bunch of computational models for
the objects in the scene. You have a rather large scene header where
you transmit theses models to the receiver. Then you ship down
parameters for each model for each animation frame.
The receiver gets to decide his own camera angle, or if he has the
MIPS and the inclination, he can render five different camera angles
simultaneously. Or maybe if he's a radiologist he might enjoy watching
a real-time CAT scan view of the scene.
With all the video-game hardware floating around these days, this
certainly must be feasible. Surely it could be done with crude
low-bandwidth animations like the music video for "Money for Nothing",
where every object is only made of a few dozens polygons.
ObCringely
Some posters have complained that he hasn't formalized the
open-source-ness of the show by using the GFDL. But this is (IIRC) the
first time anybody has done anything at all along these lines, so I
think we can cut him a little slack. It may turn out that legally it
makes sense to invent a new license, like a GNU Free Video License or
GNU Free Media License, to cover streamable media.
The world of TV hasn't had to deal with open source yet. This could
be a highly entertaining bee to put in the *AA's bonnet.
There are two cool things here. One is the use of a molding technology
to replace photolithography. AFAIK this technique was pioneered by George
Whitesides.
The second is the memory element, described only as "an organic
synthetic molecule" acting as a non-volatile memory. Non-volatile is
good; that means instant-on laptops. As for what it is, they don't
say, but their recent work has involved rotaxane and catenane (see Figure
2). Bit flips in those molecules are reversible, another good thing,
since you don't want memory that gets tired over time.
This is all cool fun stuff, and I'm glad for it, but I had really been
hoping for a follow-up of HP and UCLA's brilliant work on molecular
combinatorial logic in January. If they could add an active gain
stage to that stuff, they'd really have something amazing.
After poking around the Intersil website for quite a while, I learned that these chips have new part numbers, ISL5216 and ISL5217. They do look very cool. I've done ISA bus interfacing but never PCI. One of those things I never got around to, but it would be a good thing some day.
Note to self: Intersil has an office on Route 9 near Shopper's World, and uses Arrow and Newark as distributors.
It turns out there's a name for this, IQ modulation, where "I"
means "in phase" and "Q" means "quadrature". There is a quite elegant
Java simulation that shows what's going on.
You can limit the 10.7 IF to 60 kHz bandwidth and then sample it at
120 kHz just fine - this is called subsampling.
You're right, that would work for a receiver. You couldn't use that
idea for a transmitter, though.
A cool thing would be to have two carrier-frequency oscillators running
at 90 degrees representing the cosine and sine. If you multiply them
both by coefficients and add them, and the coefficients are band-limited
signals, you've got a very flexible modulator. It's also pretty easy to
build a demodulator that works the same way. And you don't need an IF
stage.
If FSF is going to build a radio PCI board, I'm hoping they'll do the
cosine-sine-modulator version.
No matter what station you listen to, it gets shifted down to the same intermediate frequency, so that once it's there, it can go thru exactly the same frequency.
Brain spazz, sorry. That should say "circuitry". Once you're in the IF domain, the circuitry is carefully tuned for 10.7 MHz. For instance filters can have fixed-value components, which is cheaper and more reliable than trying to make them adjustable.
Now that generating waves becomes a software problem...
It has always been possible to generate waves in software. What's
novel here is that it's being done in real time in the IF range of
frequencies. Computers are still not quite fast enough to do this in
the frequency range of the carrier signal.
When you tune your FM radio, your receiver accepts a signal centered
at around 90-100 MHz and downshifts it to 10.7 MHz. The 90-100 MHz is
called "radio frequency", the 10.7 MHz is called "intermediate
frequency". No matter what station you listen to, it gets shifted down
to the same intermediate frequency, so that once it's there, it can go
thru exactly the same frequency.
The conversion from RF to IF is a pretty simple process that ignores
the actual audio content of the signal. Once it's in IF, an FM
demodulator picks off the audio that was modulated onto the carrier at
the transmitter. AM radio also uses an intermediate frequency, but
it's 455 kHz instead of 10.7 MHz.
GNU Radio depends upon commodity computers to sample and process the
signal in real time. The Nyquist sampling theorem says you must sample
at twice the frequency of interest as a theoretical minimum; in
practice you'd like to sample more like threee or four times the
frequency. So when you run GNU Radio, samples are whipping through
your computer at 30 or 40 megasamples per second, at least for the IF
processing. The audio processing can be done at a much more leisurely
pace.
Since the computer can't hope to keep up with the 90-100 MHz raw
carrier (yet, anyway) there must still be some external circuitry to
perform the RF->IF downshift. But that's the relatively simple
circuitry - by specifying everything else in software you get a hugely
flexible radio. I've drooled with envy watching people use all-mode
radios to talk to satellites in orbit, but those suckers are
expensive! You need to be able to do AM modulation on the 2 meter band
(144-148 MHz). Now maybe I can try it one of these days.
we are building a robotic sea anemone-like creature... The fundamental questions explored by this work are:
What interaction skills must a robot have for people to feel they are in communication with it?
Do these skills allow people to anthropomorphize it and in what way?
How do these skills influence a person's opinion of how intelligent the robot is, how alive it is, and what other abilities it might have?
This is Wiezenbaum's Eliza experiment. The researchers are hoping people will overestimate its intelligence. The measure of success here will be how well they mislead people. How much new insight can we expect from this version?
These guys will build a comlpex widget with sensors and motors that works underwater for extended periods. Why not make it do something clever, useful, unexpected? I know, I know, that's AI, and we don't do no stinkin AI no more. But it would impress me a lot more.
we need a moderation that roughly sums up this: "these exact arguements, and the common rebuttals of them, have been posted... a million times before, and the discussions that inevitably come from them are both predictable and pointless."
Slashdot Mirror
It wouldn't. Why is that a problem? Better you making zillions of dollars than the spammers.
He wanted to feed the simulation with as much real, accurate information as possible, so that its results would have a lot of predictive and descriptive power. He was particularly interested in its value as an educational tool and as a tool for crafting wiser social, economic, and political policies.
Sims Online is a step toward what Gelernter imagined. A crude step, but it will plant the idea firmly in the minds of millions of people, and offer some clear preliminary notion of how it could be implemented and how well it might work.
Yup, that is EXACTLY what King did wrong. It made me wonder if he was trying something sneaky and back-handed, to pretend to empower new writers, and then demonstrate to them that "even Stephen King can't make this work". Perhaps he did so in collusion with the very publishers he pretended to spurn.
King is King. Joe B. Hacker is "nobody" so even if he writes great fiction, how will he get people's attention?
IIRC, the original SPP (or one of the variants that was floating around at the time) suggested that Joe Hacker should release the first few chapters into the public domain to convince people that his stuff is worth reading. Then he can ransom subsequent chapters one by one.
What I envisioned (and failed to make clear) was that the posting would list the ID followed by the amount donated, where the ID would be the anonymous number. Anonymous ID numbers could then only be aliased for anonymous donors who'd send in exactly the same amount.
Your idea of using the donor's public key is a good one, and gets around the same-donation-alias problem. Or anonymous donors could just invent long random pseudonyms, and the chances of identical nyms would be remote.
The server was slashdotted before I could read more than the front page (see Google cache), so I missed the "step-by-step process" description.
People have mentioned concerns about sky-high ransoms, but the free market will vote with its feet so that doesn't worry me. Likewise, the problem of a programmer who raises the ransom after the initial announcement will be solved because people will get disgusted and won't pay.
But there's a problem of fraud. Joe Programmer wrote Foo Program and I've donated ten bucks to have the source released. But I don't know if Joe counted my ten bucks toward the ransom, or simply pocketed it. If I'm patient and trusting, I can wait for market forces and reputation to filter out the programmers who pocket donations.
But Joe can do better by posting a list of donations. For donors who prefer to be anonymous, he assigns them a number and emails a copy of the number to them, so they can verify that their donations have been counted. Anybody can grab a snapshot of the donation list and throw it in a spreadsheet to verify the current tally.
Anybody whose donation was ignored can gripe in some suitable forum (Slashdot, Usenet, wherever) and if there are enough gripes that don't look like kooks, Joe's reputation will suffer.
It's not a scam. Think of hydrogen as an energy storage medium, not a fuel to be drilled from the ground.
When we use petroleum fuels, we're spending (in just a couple of centuries) energy that was stored over many millions of years. We may think of renewable energy as a rip-off because we need to collect it (from sunlight or wind or tides or whatever) instead of just drilling for existing energy-dense fuel.
But you know we'll run out some day, and renewable energy will be all we'll have. You probably also know that with solar collectors in orbit, we could have a huge annual energy budget by today's standards.
So energy storage, and especially clean energy storage, is going to be very important. Hydrogen is a lot more efficient than corn, because corn uses a lot of that fertilizer energy for metabolism and reproduction. Hydrogen doesn't, so you get almost all your energy back.
At the filling station, they pump out the broken shells, water and NaOH from your tank, before putting in new water and powerballs. The broken shells are recyclable. The NaOH is reacted with fresh H2 to produce water and NaH.
There needs to be some regulatory rules to make this process as clean as it promises to be. NaOH is nasty stuff, though no more toxic than gasoline. But overall, it's a cool idea.
After all, 4.4585 yAz equals one square micron. It's a much more sensible unit. The sorter is around 900 micro-yAz.
This is obviously a richly researched topic with lots of published papers. Some of them talk about new algorithms for tackling the complex dynamics you're talking about. And of course there's always Moore's Law; the computers used for Apollo missions were about as powerful as (or maybe much less than?) Palm Pilots.
It's probably quite feasible to give the L1 station a radio link to an orbital mechanics cluster on the ground, which can be as big as is needed, and could run equations of motion for a couple dozen nearby orbits in faster-than-real-time.
The vacuum-cleaner robot from a couple days ago is novel, plus it's useful. Popular-Mechanics-style home automation (dimming the windows, opening and closing drapes in response to weather or sun position) would be interesting.
In the early 70s there was a magazine article about a guy whose two dogs couldn't stand each other. He built a system that automatically opened and closed doors in the house, keeping track of where the dogs were, and never allowing them into the same room simultaneously. No microprocessors back then.
The big win with the toy protein is that it allows for experimental verification of the validity of data produced by FAH clients. That's a good thing, because biochemists are very suspicious of simulations and tend to ignore them until there's compelling correlation with results from a real lab.
Hopefully this will substantiate a large number of already-done simulations, or at least put them in a position where they suggest some very small amount of lab work to verify an interesting result.
To the folks complaining that only the big pharmas will benefit: This stuff is being done in academia. Would you prefer the big pharmas did it internally and there was NO CHANCE AT ALL for the results to make it into the public knowledge base? Be realistic - you KNOW the big pharmas will be the big winners on anything like this - that's the business they're in. For the rest of us, the best hope is to hasten the day when cheap generics of the resulting drugs are available for low-income patients.
I question the thinking that much would be gained by fighting the big pharmas (quite aside from the complete ineffectiveness of a typical /.er in doing so). They are bearing the research costs for the drugs, as well as the expense of pushing them thru the FDA pipeline. Open-source bazaar-style development will not work for new drugs, no matter how much we wish it would.
completely fit the stereotype, as far as I could see. I don't expect SW movies to grapple with social issues, even trivial ones, but it would have been interesting to see Lucas fire another three neurons and come up with an idea there.
Before you write your preprocessor, you might want to look at how Java handles this challenge. The Java language also permits only single inheritance but there's an additional idea called an interface. The interface is an API which a class can implement; it's not inheritance because the interface doesn't offer any implementations for the methods, it simply requires that all its methods be implemented.
Interfaces still give you polymorphism. It's pretty common where I work to write an interface specifying, say, some kind of event listener, and any class implementing that interface can be an argument to somebody's addEventListener method.
So the first reason for "plan first, then code" is that coding is expensive. That expense represents a risk if you're pursuing an approach that doesn't work out. Throwing away a plan is quicker and less expensive.
The second reason for "plan first, then code" is that a written plan is a clear expression of the ideas in the plan. Code is often not very readable or very obvious, and a large body of code may require weeks or months of study to get all the nuances at work.
There is a hidden disadvantage to "plan first, then code". Remember that we're trying to manage the risk of choosing a dead-end approach, so we want to minimize the investment before the discovery that the approach is bogus. A non-executable plan won't catch all the design bugs. It will only catch the design bugs that you can recognize on inspection of a written plan; the screening process is limited by your own human cognitive faculties.
What if we could write an executable plan, in a language that is clear and expressive, and in which writing the plan is inexpensive? This would be the best of all possible worlds! Luckily you're not the first person to face a daunting software design challenge, and people have been designing languages for exactly these constraints for many years (Python, Perl, Scheme, Ruby, Smalltalk, and others. These languages vary in the expressiveness of their syntax. If you're concerned about the mental expense of coding, you probably will want to avoid Perl (which looks a lot like C) and Scheme (which requires a mental paradigm shift). My off-the-cuff recommendation among these would be Python.
Why not write your final product in one of these easy, inexpensive, readable, expressive languages? Alas, many of them don't have the performance of C or C++. If you're doing something computation-intensive, that matters. But wait! There is another saving grace, called SWIG, a program that lets you glue small bits of C or C++ code into your larger program written in one of the easy languages.
In most computer programs, the performance is gated by a small number of small pieces of the code. Usually, the majority of the code does not have a big impact on performance. If you can identify those small performance-expensive bits, and translate them to C or C++ and glue them back into your program, you get the speed you want, and 95% of your code is still readable and expressive, and easy to change later. The trick to finding these performance-limiting bits is called profiling (see 1, 2, 3).
So here's the advice (assuming Python):
1. Spend a day learning Python, two days if you're busy. Python has lots of great libraries, skim the list of libraries as somebody may have contributed something you'll need.
2. Write your entire program readably in Python. Don't worry about speed yet. Rewrite as required until you're sure you've got a good design.
3. Use profiling to locate the few small pieces that slow down your program.
4. Use SWIG and C/C++ to rewrite those pieces and connect them back into your program.
The application deposit should be a fixed percentage of the financial "size" of the entity (market cap for corp, last year's declared income for individual). For a typical lone inventor it would cost maybe $2K, where it might cost hundreds of millions for a big corporation. Shareholders would dump the stock of any big corp that sought lots of frivolous patents.
There would be a thriving legal business in appealing rejections, so there would need to be a way to make those variably expensive too.
The receiver gets to decide his own camera angle, or if he has the MIPS and the inclination, he can render five different camera angles simultaneously. Or maybe if he's a radiologist he might enjoy watching a real-time CAT scan view of the scene.
With all the video-game hardware floating around these days, this certainly must be feasible. Surely it could be done with crude low-bandwidth animations like the music video for "Money for Nothing", where every object is only made of a few dozens polygons.
ObCringely
Some posters have complained that he hasn't formalized the open-source-ness of the show by using the GFDL. But this is (IIRC) the first time anybody has done anything at all along these lines, so I think we can cut him a little slack. It may turn out that legally it makes sense to invent a new license, like a GNU Free Video License or GNU Free Media License, to cover streamable media.
The world of TV hasn't had to deal with open source yet. This could be a highly entertaining bee to put in the *AA's bonnet.
The second is the memory element, described only as "an organic synthetic molecule" acting as a non-volatile memory. Non-volatile is good; that means instant-on laptops. As for what it is, they don't say, but their recent work has involved rotaxane and catenane (see Figure 2). Bit flips in those molecules are reversible, another good thing, since you don't want memory that gets tired over time.
This is all cool fun stuff, and I'm glad for it, but I had really been hoping for a follow-up of HP and UCLA's brilliant work on molecular combinatorial logic in January. If they could add an active gain stage to that stuff, they'd really have something amazing.
Note to self: Intersil has an office on Route 9 near Shopper's World, and uses Arrow and Newark as distributors.
It turns out there's a name for this, IQ modulation, where "I" means "in phase" and "Q" means "quadrature". There is a quite elegant Java simulation that shows what's going on.
You're right, that would work for a receiver. You couldn't use that idea for a transmitter, though.
A cool thing would be to have two carrier-frequency oscillators running at 90 degrees representing the cosine and sine. If you multiply them both by coefficients and add them, and the coefficients are band-limited signals, you've got a very flexible modulator. It's also pretty easy to build a demodulator that works the same way. And you don't need an IF stage.
If FSF is going to build a radio PCI board, I'm hoping they'll do the cosine-sine-modulator version.
Brain spazz, sorry. That should say "circuitry". Once you're in the IF domain, the circuitry is carefully tuned for 10.7 MHz. For instance filters can have fixed-value components, which is cheaper and more reliable than trying to make them adjustable.
It has always been possible to generate waves in software. What's novel here is that it's being done in real time in the IF range of frequencies. Computers are still not quite fast enough to do this in the frequency range of the carrier signal.
When you tune your FM radio, your receiver accepts a signal centered at around 90-100 MHz and downshifts it to 10.7 MHz. The 90-100 MHz is called "radio frequency", the 10.7 MHz is called "intermediate frequency". No matter what station you listen to, it gets shifted down to the same intermediate frequency, so that once it's there, it can go thru exactly the same frequency.
The conversion from RF to IF is a pretty simple process that ignores the actual audio content of the signal. Once it's in IF, an FM demodulator picks off the audio that was modulated onto the carrier at the transmitter. AM radio also uses an intermediate frequency, but it's 455 kHz instead of 10.7 MHz.
GNU Radio depends upon commodity computers to sample and process the signal in real time. The Nyquist sampling theorem says you must sample at twice the frequency of interest as a theoretical minimum; in practice you'd like to sample more like threee or four times the frequency. So when you run GNU Radio, samples are whipping through your computer at 30 or 40 megasamples per second, at least for the IF processing. The audio processing can be done at a much more leisurely pace.
Since the computer can't hope to keep up with the 90-100 MHz raw carrier (yet, anyway) there must still be some external circuitry to perform the RF->IF downshift. But that's the relatively simple circuitry - by specifying everything else in software you get a hugely flexible radio. I've drooled with envy watching people use all-mode radios to talk to satellites in orbit, but those suckers are expensive! You need to be able to do AM modulation on the 2 meter band (144-148 MHz). Now maybe I can try it one of these days.
These guys will build a comlpex widget with sensors and motors that works underwater for extended periods. Why not make it do something clever, useful, unexpected? I know, I know, that's AI, and we don't do no stinkin AI no more. But it would impress me a lot more.
How about a Usenet rating?