That surprised me too. On the second page, he explains his problem with Python. BASIC has lines that each do one thing, and you have conditional and unconditional jumps to line numbers, no fancy-schmancy control structures. Brin feels that BASIC is much closer to how the microprocessor interprets instructions.
Python compiles to a bytecode that is equally analogous to a processor's instruction set, also with conditional and unconditional jumps to numbered locations in the code, which can be disassembled and studied; see http://docs.python.org/lib/module-dis.html. One could pick nits and say that BASIC's variables are closer to processor registers than Python's stack, but feh. Bytecodes running on the Python VM or the Java VM would be EXACTLY as pedagogically valuable as BASIC, except that BASIC statements are much more human-readable where Python bytecodes.
So what we need is an alternative Python front end that looks like BASIC, which I'll call PYSIC. The PYSIC language has the readability of BASIC (including line numbers and conditional/unconditional GOTOs) and compiles to Python bytecodes. PYSIC runs inside a Python session so you can use everything normally available in Python. It should be possible to mix-and-match bits of PYSIC and standard Python.
What I think would REALLY fulfill Brin's agenda, beyond PYSIC, would be to get Python and PYSIC running on embedded platforms, especially toys, where kids can write programs and make things happen. That's what sucked me into the whole electronics and computers thing when I was a kid.
Without a DRM in place, we are capable of making as many copies of a piece of content as we want and seeding it onto the net. How do you create a market for a product, and make money of a product that has a huge initial creative investment, but then no manufacturing cost, and is in infinite supply?
DRM is a colosally badidea. Think of it like this: today you alone have a piece of content (which you spent lots of time/money creating), the end state is that it's in the public domain, and how did you make money going from here to there? The fairest way to do it is the Ransom model. A similar but more formal arrangement is the Street Performer Protocol.
An idea I like is an incremental ransom model. You spend $100 million making a movie, say 7200 seconds (two hours) long. You chop it into pieces a half-second long, encrypt each with a separate 128-bit key, and publish the 14,400 encrypted tarballs with bittorrent. Now your problem is to make back a few hundred million dollars by selling the 14,400 secret keys. You can ransom them, just as Stephen King did with chapters of The Plant (but without his unnecessary condition that some minimum fraction of consumers be non-defectors). You can auction off others on eBay. You can donate some keys to charity. You can sell some keys to sponsors, e.g. Hershey might want to buy the keys for the sequence where somebody is eating Reese's pieces because Mars/M&M didn't want to invest in your movie.
Of course some keys will represent more interesting parts of the movie than others, and you'll want to think about how to reflect those differences in the prices you try to get for them. A few exciting bits, released for cheap, might make good teasers.
I would be really curious to see how it would work out if a major movie were released this way. It would be really interesting to see how the economics of that would play out.
There's some website now that will help facilitate this -- it holds the money in escrow, and returns it if the minimum is not raised. I can't remember the name of the site though.
This website might be the one you're thinking of. There is a
very cool, very relevant idea called the "dominant assurance contract". It's
explained informally here
and more formally here.
there are things that take a huge investment to create the first copy - i. e. die-cast aluminum, injection-molded plastics, complex forgings... fat Internet pipes, fast servers, maintaining the colo site or your own server facility.
The same with pharmaceuticals. Developing a drug and getting it through clinical trials is an enormous expense, whereas manufacturing thereafter is much cheaper. But as in all these cases, the pharmaceutical company has to depend on sales of the manufactured product to pay back the upfront R&D costs. This leads to wierdness of all sorts, and in the case of new drugs, significant numbers of avoidable deaths.
It would be good to come up with a scheme for ALL these scenarios where compensation for the big upfront cost is decoupled from compensation for the much smaller repeating cost.
I want to live in a society where some public goods are financed that couldn't be supported by a purely free market. I don't mind being forced to pay taxes for public schools or libraries I never use, because I want the secondary benefits of living in a society with those things. I think the financing of public goods is a correct raison d'etre for government.
Here's my economic fantasy of government investment. Choosing an AIDS drug at random, nelfinavir is made by Agouron Pharmaceuticals and has a patent that will expire in 2013. AIDS treatment is a public good, so the government negotiates with Agouron to purchase all rights to nelfinavir. Assuming they can agree on a price, anybody who can safely manufacture the product may now do so. There is still an FDA tasked with protecting consumer safety.
Some of the crazy incentives in the pharma world disappear. Once the rights are sold, Agouron no longer has an incentive to cover up unfavorable test results. Third-party vendors might sell it cheaply enough for use in the developing world. Agouron will retain a big market share, even after selling the rights, as many distributors will want the pill with the Agouron logo on it.
Fat internet pipes are a regional public good, so they'd somehow be financed by the state or local government. They have teeny budgets; maybe there is a federal pool earmarked for state and local purchases. After somebody lays the pipe, the state or local government could buy it from them, and then license bandwidth to whoever. Somebody who wanted private pipes, and who was willing to bear the cost, would simply not sell them to the government.
I'm not sure if it's useful to try to apply this model to the tooling for a plastic product. The idea would be, I guess, that there'd be some way to pay for the tooling separately from the repeating costs of manufacturing, and the guy picking the product off the shelf in the store is somehow not paying the tooling cost. I dunno, I don't think a case like that can be much improved over the current arrangement. Good thought experiment, though.
There needs to be a trustee who administers the fund and makes the purchase, and oversees the open-sourcing of the code... It turns out there is a precedent for this:
After NaN Technologies BV went bankrupt in 2002, the intellectual property rights to Blender went to the newly created NaN Holding BV. The newly created Blender Foundation campaigned for donations to obtain the right to release the software as open source under the GNU GPL. NaN Holding BV set the price tag at 100,000 Euro. More than 1,300 users became members and donated more than 50 Euros each, in addition to anonymous users, non-membership individual donations and companies. On October 13, 2002 Blender was released on the Internet as open source.
And here I thought I'd been clever. Or maybe forgotten my meds.
Anyway, my thought is, there should be lots more of these kinds of foundations being formed. Lots of interesting code is locked up in companies that are circling the drain, and when they go down, they're likely to take that code with them.
People might value the code more highly as a public good than as a proprietary product. As the company gets closer to going out of business, they'll be increasingly eager to cut their losses, and might lower the buy-out price to something affordable.
I got curious about this solution, and tried the following empirical test.
x = y = 2 ** 0.5
for i in range(1000):
print i, y
y = x ** y
This obviously converges toward 2.0. It turns out that the later comment that (2**0.5)**4 == 4 is also true. I'm not sure if there is some kind of paradox there, but I think the bit about the 4th power is a red herring.
Christ, given the number of programmers and CS people and IT people on Slashdot, shouldn't it be possible to offer a "PRE" tag so one can post code??
Disclosure: I have no familiarity with RISC OS and have not been following its histories or any related controversies. With that out of the way, I blunder forward in ignorance.
Obviously Paul Middleton thinks he can make more money on the software by retaining control of it. But there must be some amount of money for which he would sign away the rights and allow it to be open-sourced. As time goes by, and his company continues to circle the drain and the software continues to lose market share, that amount should decrease.
That we're having a discussion at all indicates that some people think it would be a public good for the software to be open-sourced. If those people start contributing to some kind of trust or escrow account, and convincing their friends to contribute, they will eventually have enough money to exceed Middleton's buy-off price at that time.
Open-source software users should plan future buy-outs and figure out how to make them work. This is a good one to start, because it looks like it will be relatively cheap. But we should win one or two of these, and then start targetting more ambitious cases.
I can't see a lot of obstacles to this working. There needs to be a trustee who administers the fund and makes the purchase, and oversees the open-sourcing of the code, and who is deemed trustworthy by all the contributors. The FSF or the EFF might fill that role, or a new 501(c)(3) could be set up.
The key to the micropayment game is aggregation of volume.
There is an alternative to this, which is to use probabilistic micropayments. There are a few different probabilistic ideas around, my favorite is of course my own. Suppose that I agree that some piece of
content is worth a nickel. I'm not willing to use a 37-cent stamp to
send a nickel to the creator of the content, nor are our banks willing
to process a check for five cents, but I might be amenable to a fair
lottery that gives me one chance in 100 of owing five dollars.
Assuming the customer agrees in principle, the next problem is to
arrange a lottery that both vendor and customer agree is fair. Let N
be the multiplier (the 100 in the example above) and P be the amount
of the check (five bucks, above) so that the agreed-upon value of the
content is P/N. Here's my idea for a fair lottery protocol.
Customer and vendor agree to terms (including values of P and N).
Vendor generates a random 128-bit number R1 and computes its
MD5 hash H1. Vendor transmits H1 and content to customer.
Customer generates a random 128-bit number R2 and transmits R2
to vendor.
Vendor transmits R1 to customer. Customer confirms that MD5 hash
of R1 is really H1.
Customer and vendor both compute ((R1+R2) % N). If this number is
zero, then customer owes amount P to vendor. Otherwise customer
gets the content for free.
The guarantee of fairness is that neither vendor nor customer can
manipulate the quantity ((R1+R2)%N), because the vendor doesn't know
R2 when he generates R1, and the customer doesn't know R1 when he
generates R2. The hash value H1 represents the vendor's commitment to
the value of R1: it assures the customer that the vendor did not
change R1 after learning the value of R2.
I picked up that understanding of patents from somewhere, I forget where, and there is some validation for it on Wikipedia. Interestingly, the use of patents to encourage disclosure predates the U.S. Constitution by 300 years. So it's entirely possible that the framers would have had additional/other goals in mind.
While there is an informal notion of a trade secret as you suggest, I think that (in the U.S. at least) there is also a formalized legal concept of a trade secret. That's why people sign non-disclosure agreements. So at least to the extent that the NDA is legally binding, the secret-holder enjoys some protection.
There is no way to "enforce" "novel and useful" both are subjective and there is no a-priori way to determine this.
I think the generally accepted practice is to ask somebody with ordinary skill in the art to which the patent pertains. If it's obvious to such a person, then it's theoretically not patentable. Of course, just as programmers vary wildly in their levels of skill and productivity, similar variations occur in other fields, so a standard of "ordinary skill" is still very shakey.
The patent system was supposed to originally protect the individual inventor. Those days are LONG past!
Nope, that was never the idea behind patents. Inventors were doing fine before patents came along. All inventions were trade secrets. Your competitors would try to figure out your secrets (as they do today). If they succeeded, you had no legal recourse for the "theft" of your idea, and they went into business.
Patents are a bargain between the inventor and the government. The inventor agrees to disclose the invention. The government agrees to grant the inventor a temporary monopoly. When the monopoly ends, the invention theoretically passes into the public domain. As other posts have pointed out, there are lots of tricks to extend a patent's term.
Patents aren't an intrinsically bad idea. But it probably makes sense to adjust the patent's term to reflect reality. Patents in, say, consumer electronics should probably not have a term of more than maybe five years.
It also makes sense to enforce the criterion of "novel and useful" so that fewer frivolous patents get granted.
Google has a policy of giving people a percentage of their work hours to fiddle around with personal interests. At worst, it raises morale. At best it produces new business opportunities.
But ignoring that, even Google as a company probably does more research than you might think. Of course profit will be a big motivator for it, but I bet there's a lot of very cool stuff going on inside that hasn't yet been publicized, and some may never be until somebody writes a book in fifteen years.
So far I've mostly seen mention of the Hohmann transfer and the interplanetary superhighway. These are two particular classes of solutions to the problem of getting to Mars. But they optimize different things: Hohmann keeps the math simple at the expense of bursty violent accelerations (and wasted rocket fuel), the IPS conserves fuel but can take centuries to get anywhere.
Computers are bigger now so we no longer need the simplicity of Hohmann. There is a large class of optimization algorithms (genetic algorithms, gradient descent, simulated annealing), any of which could be thrown at this problem. And there are, dare I say it, several Beowulf clusters sitting around that could implement these algorithms.
This would allow us to choose the parameters to be optimized. Maybe there is a safe, quick trajectory involving a steady low-level burn (not the impulse used for Hohmann). A specially optimized trajectory like this wouldn't be as analytically tractable as Hohmann, but with cheap computers, analytic tractability is not the precious commodity it was in the slide rule days.
Once I got curious about space elevators and momentum transfer tethers, and wrote some code in Java and Python. It does not specifically address a trip to Mars, but it has a reasonable class hierarchies for doing the math. Applying it to Mars is left as an exercise for the reader.
It uses Verlet integration. It seemed adequate for the kinds of orbits involved in a tether, where the time span of interest is only a few hours. A trip to Mars will take months unless you go powered the whole way, which you probably can't afford to do (although a solar sail might help).
It would be best to come up with analytical solutions. If you never need to solve the 3-body problem these will be ellipses. A cheesy semi-solution to the 3-body problem could be piecewise-elliptical. Again, details are left as an exercise for the reader.
definitely belongs on the list. That was the best PDA I ever had. A perfectly-sized chicklet keyboard, tremendous battery life, a C compiler, a sane OS. I hoped they would be around long enough for a Linux port but it wasn't to be. I know there have been follow-up HP products but they prioritized the wrong things, e.g. a color screen adds little while shortening battery life.
They showed that thing just once, but it really has stuck in my mind too.
Mine also. When you look at the unfunny crap that they repeat endlessly, it's a real mystery that one genuinely funny thing gets so quickly discarded. But if they realized how funny it was, they'd beat it to death and it would be ruined.
I wonder if there's some kind of limit on how funny the show is allowed to be. Maybe they all want to save the really funny material for their individual stand-up acts, or for their post-SNL movie careers.
Is there any reason not to compress and decompress air instead of Freon? You take air from inside the car, compress it thereby heating it up, then you run it (under pressure) through a long radiator outside the car. Once it reaches the temperature of the outside air, you decompress it (cooling it) and dump it back inside the car. This is the same principle that makes bicycle pumps heat up (and I'm guessing the same principle used with freon).
I know I'm not a genius, so somebody has already thought of using air, especially since air is so readily available. The fact we're not using air already means there is some problem with it. Is air inefficient for heat transfer?
There is a way to do this that avoids the overflow problem, using XOR instead of addition.
A = A xor B
B = A xor B
A = A xor B
This will work for any values of A and B as long as the two registers have the same number of bits.
There have been a few posts complaining (accurately) that the majority
of the response to this story has been all jokes and no thinking. The
reason for the Beowulf clusters we all joke about is to do big math
problems, including simulations of proteins and other big molecules,
weather and climate, cosmology stuff like supernovae, etc. FLOPS are
our friends, and we should make better use of them, especially cheap
ones like the FLOPS in graphics cards (see
http://www.eet.com/showArticle.jhtml?articleID=553 00904). Discussions
on the beowulf.org mailing list
(http://www.beowulf.org/archive/2001-March/thread. html#2579) indicate
those guys think the overhead of communication between CPU and GPU is
too expensive, and graphics hardware becomes obsolete too quickly.
The people in TFA are part of a larger group (see http://www.gpgpu.org/)
that thinks about how to use graphics cards for a wide variety of math
problems. Here's an abstract from one of their papers:
In our experiments we compare the execution on a midclass GPU (NVIDIA
GeForce FX 5700LE) with a high-end CPU (Pentium 4 3.2GHz). The results
show that to achieve high speedup with the GPU you need to: (1) format
the vectors into two-dimensional arrays; (2) process large data
arrays; and (3) perform a considerable amount of operations per data
element.
Apparently GPU architecture is so quirky that it's hard to write a
general-purpose API to exploit it. Consequently there tend to be
entirely seperate efforts for different classes of computational
problems. If graphics cards weren't such a commodity, this kind of
bad engineering practice would be unacceptable.
I'll repeat a cool link posted by somebody else:
http://www.cs.unc.edu/~ibr/projects/paranoia/ - this is a program,
originally written in the 80s, to characterize the performance and
idiosyncracies of a floating-point processor. Recent work at UNC
Chapel Hill has been done on Windows platforms. (Twenty years ago, UNC
Chapel Hill was one of the hotbeds of computer graphics development
that eventually gave us Shrek and The Incredibles.)
Slashdot Mirror
That surprised me too. On the second page, he explains his problem with Python. BASIC has lines that each do one thing, and you have conditional and unconditional jumps to line numbers, no fancy-schmancy control structures. Brin feels that BASIC is much closer to how the microprocessor interprets instructions. Python compiles to a bytecode that is equally analogous to a processor's instruction set, also with conditional and unconditional jumps to numbered locations in the code, which can be disassembled and studied; see http://docs.python.org/lib/module-dis.html. One could pick nits and say that BASIC's variables are closer to processor registers than Python's stack, but feh. Bytecodes running on the Python VM or the Java VM would be EXACTLY as pedagogically valuable as BASIC, except that BASIC statements are much more human-readable where Python bytecodes. So what we need is an alternative Python front end that looks like BASIC, which I'll call PYSIC. The PYSIC language has the readability of BASIC (including line numbers and conditional/unconditional GOTOs) and compiles to Python bytecodes. PYSIC runs inside a Python session so you can use everything normally available in Python. It should be possible to mix-and-match bits of PYSIC and standard Python. What I think would REALLY fulfill Brin's agenda, beyond PYSIC, would be to get Python and PYSIC running on embedded platforms, especially toys, where kids can write programs and make things happen. That's what sucked me into the whole electronics and computers thing when I was a kid.
DRM is a colosally bad idea. Think of it like this: today you alone have a piece of content (which you spent lots of time/money creating), the end state is that it's in the public domain, and how did you make money going from here to there? The fairest way to do it is the Ransom model. A similar but more formal arrangement is the Street Performer Protocol.
An idea I like is an incremental ransom model. You spend $100 million making a movie, say 7200 seconds (two hours) long. You chop it into pieces a half-second long, encrypt each with a separate 128-bit key, and publish the 14,400 encrypted tarballs with bittorrent. Now your problem is to make back a few hundred million dollars by selling the 14,400 secret keys. You can ransom them, just as Stephen King did with chapters of The Plant (but without his unnecessary condition that some minimum fraction of consumers be non-defectors). You can auction off others on eBay. You can donate some keys to charity. You can sell some keys to sponsors, e.g. Hershey might want to buy the keys for the sequence where somebody is eating Reese's pieces because Mars/M&M didn't want to invest in your movie.
Of course some keys will represent more interesting parts of the movie than others, and you'll want to think about how to reflect those differences in the prices you try to get for them. A few exciting bits, released for cheap, might make good teasers.
I would be really curious to see how it would work out if a major movie were released this way. It would be really interesting to see how the economics of that would play out.
This website might be the one you're thinking of. There is a very cool, very relevant idea called the "dominant assurance contract". It's explained informally here and more formally here.
The same with pharmaceuticals. Developing a drug and getting it through clinical trials is an enormous expense, whereas manufacturing thereafter is much cheaper. But as in all these cases, the pharmaceutical company has to depend on sales of the manufactured product to pay back the upfront R&D costs. This leads to wierdness of all sorts, and in the case of new drugs, significant numbers of avoidable deaths.
It would be good to come up with a scheme for ALL these scenarios where compensation for the big upfront cost is decoupled from compensation for the much smaller repeating cost.
I want to live in a society where some public goods are financed that couldn't be supported by a purely free market. I don't mind being forced to pay taxes for public schools or libraries I never use, because I want the secondary benefits of living in a society with those things. I think the financing of public goods is a correct raison d'etre for government.
Here's my economic fantasy of government investment. Choosing an AIDS drug at random, nelfinavir is made by Agouron Pharmaceuticals and has a patent that will expire in 2013. AIDS treatment is a public good, so the government negotiates with Agouron to purchase all rights to nelfinavir. Assuming they can agree on a price, anybody who can safely manufacture the product may now do so. There is still an FDA tasked with protecting consumer safety.
Some of the crazy incentives in the pharma world disappear. Once the rights are sold, Agouron no longer has an incentive to cover up unfavorable test results. Third-party vendors might sell it cheaply enough for use in the developing world. Agouron will retain a big market share, even after selling the rights, as many distributors will want the pill with the Agouron logo on it.
Fat internet pipes are a regional public good, so they'd somehow be financed by the state or local government. They have teeny budgets; maybe there is a federal pool earmarked for state and local purchases. After somebody lays the pipe, the state or local government could buy it from them, and then license bandwidth to whoever. Somebody who wanted private pipes, and who was willing to bear the cost, would simply not sell them to the government.
I'm not sure if it's useful to try to apply this model to the tooling for a plastic product. The idea would be, I guess, that there'd be some way to pay for the tooling separately from the repeating costs of manufacturing, and the guy picking the product off the shelf in the store is somehow not paying the tooling cost. I dunno, I don't think a case like that can be much improved over the current arrangement. Good thought experiment, though.
Anyway, my thought is, there should be lots more of these kinds of foundations being formed. Lots of interesting code is locked up in companies that are circling the drain, and when they go down, they're likely to take that code with them.
People might value the code more highly as a public good than as a proprietary product. As the company gets closer to going out of business, they'll be increasingly eager to cut their losses, and might lower the buy-out price to something affordable.
x = y = 2 ** 0.5
for i in range(1000):
This obviously converges toward 2.0. It turns out that the later comment that (2**0.5)**4 == 4 is also true. I'm not sure if there is some kind of paradox there, but I think the bit about the 4th power is a red herring.
Christ, given the number of programmers and CS people and IT people on Slashdot, shouldn't it be possible to offer a "PRE" tag so one can post code??
Obviously Paul Middleton thinks he can make more money on the software by retaining control of it. But there must be some amount of money for which he would sign away the rights and allow it to be open-sourced. As time goes by, and his company continues to circle the drain and the software continues to lose market share, that amount should decrease.
That we're having a discussion at all indicates that some people think it would be a public good for the software to be open-sourced. If those people start contributing to some kind of trust or escrow account, and convincing their friends to contribute, they will eventually have enough money to exceed Middleton's buy-off price at that time.
Open-source software users should plan future buy-outs and figure out how to make them work. This is a good one to start, because it looks like it will be relatively cheap. But we should win one or two of these, and then start targetting more ambitious cases.
I can't see a lot of obstacles to this working. There needs to be a trustee who administers the fund and makes the purchase, and oversees the open-sourcing of the code, and who is deemed trustworthy by all the contributors. The FSF or the EFF might fill that role, or a new 501(c)(3) could be set up.
But the world's oldest beanbag chair and the world's oldest lava lamp ought to have been safe.
Go ahead, take the plunge. It will be one of the more rewarding half-hours of your computing career.
There is an alternative to this, which is to use probabilistic micropayments. There are a few different probabilistic ideas around, my favorite is of course my own. Suppose that I agree that some piece of content is worth a nickel. I'm not willing to use a 37-cent stamp to send a nickel to the creator of the content, nor are our banks willing to process a check for five cents, but I might be amenable to a fair lottery that gives me one chance in 100 of owing five dollars.
Assuming the customer agrees in principle, the next problem is to arrange a lottery that both vendor and customer agree is fair. Let N be the multiplier (the 100 in the example above) and P be the amount of the check (five bucks, above) so that the agreed-upon value of the content is P/N. Here's my idea for a fair lottery protocol.
The guarantee of fairness is that neither vendor nor customer can manipulate the quantity ((R1+R2)%N), because the vendor doesn't know R2 when he generates R1, and the customer doesn't know R1 when he generates R2. The hash value H1 represents the vendor's commitment to the value of R1: it assures the customer that the vendor did not change R1 after learning the value of R2.
While there is an informal notion of a trade secret as you suggest, I think that (in the U.S. at least) there is also a formalized legal concept of a trade secret. That's why people sign non-disclosure agreements. So at least to the extent that the NDA is legally binding, the secret-holder enjoys some protection.
There is no way to "enforce" "novel and useful" both are subjective and there is no a-priori way to determine this.
I think the generally accepted practice is to ask somebody with ordinary skill in the art to which the patent pertains. If it's obvious to such a person, then it's theoretically not patentable. Of course, just as programmers vary wildly in their levels of skill and productivity, similar variations occur in other fields, so a standard of "ordinary skill" is still very shakey.
Nope, that was never the idea behind patents. Inventors were doing fine before patents came along. All inventions were trade secrets. Your competitors would try to figure out your secrets (as they do today). If they succeeded, you had no legal recourse for the "theft" of your idea, and they went into business.
Patents are a bargain between the inventor and the government. The inventor agrees to disclose the invention. The government agrees to grant the inventor a temporary monopoly. When the monopoly ends, the invention theoretically passes into the public domain. As other posts have pointed out, there are lots of tricks to extend a patent's term.
Patents aren't an intrinsically bad idea. But it probably makes sense to adjust the patent's term to reflect reality. Patents in, say, consumer electronics should probably not have a term of more than maybe five years.
It also makes sense to enforce the criterion of "novel and useful" so that fewer frivolous patents get granted.
Google has a policy of giving people a percentage of their work hours to fiddle around with personal interests. At worst, it raises morale. At best it produces new business opportunities.
But ignoring that, even Google as a company probably does more research than you might think. Of course profit will be a big motivator for it, but I bet there's a lot of very cool stuff going on inside that hasn't yet been publicized, and some may never be until somebody writes a book in fifteen years.
Computers are bigger now so we no longer need the simplicity of Hohmann. There is a large class of optimization algorithms (genetic algorithms, gradient descent, simulated annealing), any of which could be thrown at this problem. And there are, dare I say it, several Beowulf clusters sitting around that could implement these algorithms.
This would allow us to choose the parameters to be optimized. Maybe there is a safe, quick trajectory involving a steady low-level burn (not the impulse used for Hohmann). A specially optimized trajectory like this wouldn't be as analytically tractable as Hohmann, but with cheap computers, analytic tractability is not the precious commodity it was in the slide rule days.
It uses Verlet integration. It seemed adequate for the kinds of orbits involved in a tether, where the time span of interest is only a few hours. A trip to Mars will take months unless you go powered the whole way, which you probably can't afford to do (although a solar sail might help).
It would be best to come up with analytical solutions. If you never need to solve the 3-body problem these will be ellipses. A cheesy semi-solution to the 3-body problem could be piecewise-elliptical. Again, details are left as an exercise for the reader.
We have found that regular chairs work fine for this.
definitely belongs on the list. That was the best PDA I ever had. A perfectly-sized chicklet keyboard, tremendous battery life, a C compiler, a sane OS. I hoped they would be around long enough for a Linux port but it wasn't to be. I know there have been follow-up HP products but they prioritized the wrong things, e.g. a color screen adds little while shortening battery life.
No, this is by contrast to those oceans that are left out on land, and get all dried out and dessicated. It's a huge waste of water.
It looks like you're trying to identify one or more examples of Microsoft ingenuity and creativity! Would you like some suggestions?
Mine also. When you look at the unfunny crap that they repeat endlessly, it's a real mystery that one genuinely funny thing gets so quickly discarded. But if they realized how funny it was, they'd beat it to death and it would be ruined.
I wonder if there's some kind of limit on how funny the show is allowed to be. Maybe they all want to save the really funny material for their individual stand-up acts, or for their post-SNL movie careers.
I know I'm not a genius, so somebody has already thought of using air, especially since air is so readily available. The fact we're not using air already means there is some problem with it. Is air inefficient for heat transfer?
A = A xor B
B = A xor B
A = A xor B
This will work for any values of A and B as long as the two registers have the same number of bits.
There is a way to do this that avoids the overflow problem, using XOR instead of addition. A = A xor B B = A xor B A = A xor B This will work for any values of A and B as long as the two registers have the same number of bits.
The people in TFA are part of a larger group (see http://www.gpgpu.org/) that thinks about how to use graphics cards for a wide variety of math problems. Here's an abstract from one of their papers:
Apparently GPU architecture is so quirky that it's hard to write a general-purpose API to exploit it. Consequently there tend to be entirely seperate efforts for different classes of computational problems. If graphics cards weren't such a commodity, this kind of bad engineering practice would be unacceptable.I'll repeat a cool link posted by somebody else: http://www.cs.unc.edu/~ibr/projects/paranoia/ - this is a program, originally written in the 80s, to characterize the performance and idiosyncracies of a floating-point processor. Recent work at UNC Chapel Hill has been done on Windows platforms. (Twenty years ago, UNC Chapel Hill was one of the hotbeds of computer graphics development that eventually gave us Shrek and The Incredibles.)