July « 2010 « Reenigne blog

Archive for July, 2010

Virtual physical tone matrix

Wednesday, July 28th, 2010

Here's a virtual version of my physical tone matrix, implemented in Flash, so you can play along at home:

Much of the code is a direct translation from the C code in the non-virtual version, so it works in a way very close to the real thing. Even the sample rate and frame rate are close (though they are not synchronized - it's not a cycle-exact simulation).

Click or drag on the screen to turn the lights on and off.

The knobs are (from top left) sustain, tempo, tuning and volume. Above and between the sustain and tempo knobs is the escape switch, which brings up or closes a menu of funcions. These are, from top left:

Sine wave (default)
Square wave
Triangle wave
Sawtooth wave
Random wave
Pattern editor (default)
Coarse waveform editor
Fine waveform editor (not particularly useful or easy to use)
Tuning editor
Miscellaneous editor
Save current pattern/waveform/tuning/settings to EEPROM
Load current pattern/waveform/tuning/settings from EEPROM
Toggle life mode
Toggle random mode
Toggle microtone keyboard mode

The miscellaneous editor shows 6 rectangles. Clockwise from top-right these are:

Patterns per loop (a 5-bit binary number) - if this is not 1, then whenever the pattern reaches the right a new pattern is loaded from EEPROM.
Fixed tuning - just disables the tuning knob. This exists in order to allow the tuning to be set more accurately on the non-virtual version, not really necessary on the virtual version
Update noise continually - when set, the waveform is continually updated with random data, so all frequencies sound the same. This is slightly different to the "random wave" waveform preset, where the 256 waveform components are initialized with random numbers but then don't change, so there are some audible differences between playing them at different frequencies.
Beats per pattern - repeat before the pattern gets all the way to the right, useful for rhythms that don't factor into 16.
Sustain override - overrides the function of the sustain knob so that this parameter can be set digitally.
Tempo override (a 16-bit binary number) - must be greater than 0x200 to work - smaller numbers are faster).

The EEPROM save/load functions load or save the data for the current editing mode (pattern, coarse waveform, fine waveform, tuning or miscellaneous). To use them, press save or load. The screen then shows the current EEPROM contents. Click on a location to choose where to save to or load from. Depending on the editing mode, 2-8 lights will be lit per "saved file".

Fun things to try:

Put the PTM in random mode and light 10-16 lights. Then just sit back and listen to some randomly generated music for a while.
Draw a glider or Lightweight spaceship, put the PTM in life mode and turn the tempo all the way up to maximum.
Make a horizontal line in pattern editor mode, turn the sustain all the way up so that the sound is continuous, then switch to the coarse waveform editor (which was inspired by this). Click and drag around to move the "sliders" and see what sounds you can make.
Make sure the pattern editor is empty and then switch to microtone keyboard mode. The lit lights correspond to the white notes on a piano keyboard - the unlit lights are the frequencies in-between (i.e. it's a 34-TET instrument). Try to play or tune or make some weird music. Trying the different preset waveforms is fun in this mode.
(Advanced) Try to create a different tuning such as major scale or chromatic (instead of the default pentatonic) using the tuning editor. Each line of the tuning editor represents a frequency as a 16-bit binary number (LSB on the left), in units of roughly 0.24Hz (16Mhz / 2²⁶).
(Advanced) Make some patterns and save them in consecutive locations in EEPROM, starting at the top left. Then use the "patterns per loop" setting in the miscellaneous editor to play them back in sequence and make a tune longer than 16 notes.

The copy and paste functions on the right-click menu work and are compatible with the original Tone Matrix applet.

Source code is here.

Posted in computer | 2 Comments »

Map reprojection

Monday, July 26th, 2010

Ever wondered what a standard equirectangular projection map of the world would look like if the poles were in different places? Wonder no more! Just click and drag on the map below to move a piece of the world to somewhere else on the map - the rest will follow.

Flash is the best way to do this sort of thing in terms of market penetration, but Actionscript is surprisingly difficult to get started with. Adobe's tools are great, I'm sure, if you want to make animated vector movies but in trying to learn how to use them to do programmatically generated stuff like this I just got lost. Perhaps I just haven't discovered the right bit of documentation. I eventually found this to be a way in to the maze.

I hope to write some more fun little web toys like this in the coming weeks.

Edit: source code.

Posted in maps | 2 Comments »

Credit card designed for internet shopping

Friday, July 23rd, 2010

It seems like it would be possible to make a great deal of money by creating a payment system better than credit cards. Paypal has come closest to doing this, but has a lot of problems.

How could one make credit cards better? It would be very difficult to get your payment system into as many retailers as Visa and Mastercard, so perhaps aiming for a niche would be a good idea. One such niche might be internet purchases. Develop a payment system/credit card designed specifically for internet purchases and it could be very popular.

One major difference between a payment system designed for the internet and one predating it is that one could authenticate the transaction, not the identity. Whenever you buy something online, you put in your card number as usual but then (unlike with normal credit cards) there is an extra step - you log into the payment system's website and approve the requested transaction. Until you have done that, the merchant doesn't get any money (and won't deliver the goods). This cuts out all "stolen card" type fraud, since the thief would also need to steal your payment system password (which never goes anywhere near the merchant). This would allow this payment system to undercut the existing credit card issuers and become competitive. Fraud caused by loss of the payment system password would be treated the same as fraud caused by the loss of any other online banking password (which I think varies from place to place).

This system would still need a "chargeback" mechanism to combat fraud from merchants (and mechanisms to combat fraudulent chargebacks) but my impression is that the costs of these are small compared to the "stolen card" costs.

With suitable cellphone applications for authorization, the system could even be used for brick-and-mortar stores as well.

Unlike Paypal, this system would actually be able to lend money like a credit card, it wouldn't need to be linked to a bank account or credit card.

Posted in economics, Uncategorized | 2 Comments »

USB device classes and usage pages

Thursday, July 22nd, 2010

The Universal Serial Bus interface specification includes various fields to specify what kind of device is plugged into a computer, and what numbers correspond to what buttons, lights and so on on the device. All these are documented in the Human Interface Device Usage Tables. When I discovered this, it provided me with some amusement as alongside the normal mice, keyboards, scanners there are some more exotic devices. Section 5, which describes "Simulation Controls" (i.e. standardized controllers for operating various simulators). As well as the ones you'd expect like a steering wheel (Usage ID C8) and a flight yoke (Usage ID 24) there are such controls as "Standard spaceship controls" (Usage ID 04).

I had no idea that spaceship controls were standardized. I suppose it makes sense, so that once you learn how to fly one sort of spaceship you could (in principle, in some sort of emergency situation) have some chance of operaing an unfamiliar craft. Of course, if that emergency situation is being kidnapped by aliens you're probably out of luck as I doubt any alien spaceship designers have read the USB specification documents.

What's even funnier is the "Standard magic carpet controls" (Usage ID 0B). Being a magical (not to mention fictional) mode of transportation, it seems quite amazing that magic carpets have standardized control mechanisms. You'd think the interface would be something as indistinguishable-from-sufficiently-advanced-technology as "just think about where you want it to go", but the USB documents go into quite some detail about how to fly a magic carpet:

Allows a device to be generally classified as one that uses the standard control of a magic carpet. This control is a bar, grasped by both hands, that controls the Yaw, Pitch and Roll of the carpet.

The bar, at which the pilot sits, may be pushed forward or pulled back to cause the carpet to dive or rise, respectively. In the zero position, the carpet is in level flight. Pushing forward on the bar causes the carpet to nose down and generates negative values. Pulling back on the bar causes the carpet to nose up and generates positive values.

Turning the bar turns the carpet. In the zero position, the carpet travels straight ahead. Pulling back on the right side turns the carpet to the right and generates positive values. Pulling back on the left side turns the carpet to the left and generates negative values.

Rotating the bar rolls the carpet. In the zero position, the carpet travels level. Rotating the bar in a clockwise direction rolls the carpet to the right and generates positive values. Rotating the bar in the counterclockwise direction rolls the carpet to the left and generates negative values.

So there you go - now if you find yourself in a Persian golden-age fairy tale, you know how to get around.

Posted in computer | No Comments »

Time derivative accounting

Wednesday, July 21st, 2010

Sometimes I think it would make things simpler if, when I logged onto my bank's website, there were two sorts of transactions listed. One would the normal sort: "x dollars paid to y on date z". The other sort would be "x dollars per month paid to y since date z". For example, my monthly mortgage payment would be listed as a single transaction, not a separate one each month.

Certain calculations are much easier when done with time derivative values. For example, interest on my mortgage accumulates daily but the payments are monthly, so to figure out what is actually owed at any time requires a lengthy spreadsheet or complicated program. If the interest accumulated continuously, and the payment also happened continuously, the calculations would be much simpler.

Normally, interest is specified as a percentage by which a debt grows. But to know what that really means, you have to specify how long it takes to grow by that much - this can lead to confusion (deliberate or accidental). It would be much better if interest was specified as a growth constant $f$ (with standard units of Hz, bizarrely enough), such that if you have a debt $x_0$ at time 0 and changes only because of interest (no payments or fees) then after time $t$ the debt will have grown to $xe^{tf}$ . If you are also making payments at the rate of $r$ per unit time, then the debt $x$ is given by the differential equation $\displaystyle \frac{dx}{dt} = xf - r$ which has the solution

$\displaystyle x = \frac{r}{f} + (x_0 - \frac{r}{f})e^{ft}$

Hence one can easily solve for the time it takes to repay the loan:

$\displaystyle t = \frac{log(-\frac{r}{x_0f - r})}{f}$

Or you can solve for the repayment rate if you want to repay the loan in a specific amount of time:

$\displaystyle r = \frac{x_0fe^{ft}}{e^{ft} - 1}$

Similarly, one can do calculations around retirement savings. Suppose you have $x_0$ in retirement savings today and the inflation growth constant is $i$ . If you are saving at a rate of $r e^{it}$ and investing in something with a growth rate of $f$ , and you want to retire when you can maintain an income of $y e^{it}$ .

The amount you need in savings at retirement is $x$ in:

$\displaystyle \frac{dx}{dt} = xf - ye^{it} = xi$

Plugging this into the equation for the savings rate while working:

$\displaystyle \frac{dx}{dt} = xf + re^{it}$

Gives:

$\displaystyle y = r+(x_0(f-i)-r)e^{(f-i)t}$

Solving for retirement time:

$\displaystyle t = \frac{\log(\frac{-r}{x_0(f-i)-r})}{f-i}$

Or savings rate:

$\displaystyle r = \frac{e^{ft}x_0(f-i)}{-e^{it}+e^{ft}}$

Of course, all that assumes you can get a fixed rate of return and that inflation stays constant. In reality, these variables are constantly changing. There's also the matter of risk to consider - trading off means for variances, but you get the idea.

The current inflation rate is about 300 picoHertz. The highest recorded hyperinflation is about 6000000 picoHertz (6 microHertz).

How should payment rates be specified in user interfaces? "Dollars per month" is probably the most meaningful multiplier - to make it consistent we should use a standard average month length of 2629746 seconds. Current balance would be updated continuously supposing that the paying of salary and recurring bills could also be paid continuously. One would want to take care to set limits on the payment rate for bills (just as one does with direct debits) so that a mistake at the gas company doesn't instantly wipe out your savings.

Further derivatives could be taken into account so that one could pay exponentially increasing bills like the retirement savings above without making any adjustments. The ultimate outcome of this would be to link everything to inflation and display/specify amounts in "year 2000 dollars" (for example) - in other words, the Inflation-linked currency I've written about before.

Posted in economics | No Comments »

Musical toy design

Tuesday, July 20th, 2010

I've been thinking about how to create the interval bars instrument/toy as a sort of sequel to the physical tone matrix. Here's some of the design space I've explored.

First I wondered how we could sense the relative position of each bar in space. I fairly quickly decided that putting a tiny microcontroller in each of the bars would probably be the best way. The root box queries the bar it's connected to, which then sends back its length, orientation (i.e. which of the 4 connectors it is being queried through) whether its switch is being touched or not. This bar then performs the same query on the bars connected to its three other connectors, sends this information back to the root and so on, walking the tree. A program to transmit a few bits of data, walk one node of a ternary tree and then pass back another string of bits sounds very simple, but as we'll see there are a lot of complications.

The first microcontroller I looked at was the cheapest one I could find, the PIC10F200. This thing is seriously cheap and seriously tiny (both physically and software-wise). It has 16 *bytes* of memory (same as a single SSE register), runs at 4MHz and can run programs that are up to 256 instructions long. It also costs just 30 cents in large quantities. I thought it would be an fun programming challenge to fit such a simple program into such a tiny space.

Unfortunately, I failed in this endeavour because the PIC10F200 only has 4 IO pins (6 pins altogether - the other two are power and ground). Only 3 of them can be used for output. I needed at least 5 pins - one for each directional connector and one for the switch. I tried to figure out some way of addressing each direction with a unique pair of IO pins but couldn't figure out a scheme that would actually work.

So then I decided to go for the next PIC up, the PIC12F508. This has 6 IO pins (perfect), 512 instructions, 25 bytes of RAM and costs $0.41 in large quantities. I bought a pile of them. The PIC16F54 is even cheaper ($0.39), has 12 IO pins and runs up to 20MHz but has no internal oscillator.

I originally figured that I would drive all the PICs with a single external clock to make it easy to keep them in sync. However, I discovered a major problem with this approach - these microcontrollers don't have a external clock oscillator mode. You can use the internal oscillator, an external crystal or an external RC timebase. It might be possible to use an external clock in EXTRC or XT mode but it's out of spec, might damage the microcontroller, might be unstable, might degrade the clock signal and might cause one of the other IO pins to be unavailable. Also, even with cycle exact code there is complexity in the timing because each instruction takes 4 or 8 clock cycles, and you can't control which of the 4 phases you get.

So I decided to use the internal oscillator. It's factory calibrated to +/- 1% so I should be able to synchronize two PICs just by adding appropriate delay loops, making sure that signal pulses are long enough to cover all the possible times when they might be read, and that the reader waits until the pulse is certain to have started before attempting the read. Programming in cycle-exact assembler is difficult enough when there's only one CPU to worry about, but when you're writing code that's going to run in sync on two CPUs and all timing is done by cycle counting and the CPUs have slightly different clock rates it's a nightmare!

The first version of my program took too much space (everything was unrolled and I had different code paths for each orientation). I got it to fit by moving some of the code into subroutines (you have to choose which code you put in subroutines carefully, since the stack only has two levels) but didn't have much space for delay loops.

So I rewrote it to avoid storing the "which port is the parent" and "which port is the child" information in the program counter. Now it only checks this information when reading from or writing to a pin, or checking all the pins to see which direction a signal will come from first. Takes less than half of the available space - brilliant.

The next problem is that only two microcontrollers can be communicating at once (one talking, one listening). If three are trying to communicate at once, eventually the middle one is going to face a time when it has to talk to both of the other two within a certain amount of time, and won't be able to satisfy the conflicting demands. So when a microcontroller is getting a bit of data from a child, it has to tell the parent to wait and we can't have a "bucket brigade" of bits. This means that we get quadratically slower as we get further from the root. Counting the cycles, I realized that (even before all the delay loops had been added) we were outside of our cycle budget to get a reasonably small latency.

To get the "bucket brigade" back, I realized that we had to have a way to synchronize all the microcontrollers at once. We can't use an external cycle clock for this but what about a much slower "heartbeat" signal shared between all the microcontrollers, coming in on the spare pin?

The idea is this: each microcontroller has a state variable. On each heartbeat, each microcontroller jumps to a subroutine corresponding to its state. This subroutine reads the pins set in the previous cycle, sets output pins for the next cycle and updates the state variable for the next cycle before going back to waiting for the next heartbeat. All the waiting is done at once, and we no longer have the precise timing difficulties we have before - as long as we have rules like "how late you can read the inputs", "how early you can set the outputs" and "how long the heartbeat can take" everything should work out just right. I think we can get much better performance with this system.

The musical toy is really about melody and harmony, but under the covers it's rhythm that makes it work.

Posted in hardware | 2 Comments »

Liquid democracy

Monday, July 19th, 2010

Another political idea I really like is that of electronic liquid democracy. The idea is this - instead of trying to choose which of a very small number of representatives will best represent your interests, you can instead vote directly on every measure that your representative would vote on.

Most of the time, you might not care or might not have enough background knowledge to know what's best, so you appoint a proxy to choose your vote on your behalf. You can even choose different proxies for different areas - one for health-related legislation, another for trade-related and so on. You can choose multiple ranked proxies so that if one proxy fails to vote on one issue, the vote will go to your second choice and so on. Proxies can also delegate to other proxies. All this is done electronically (with appropriate security safeguards to avoid elections getting hacked) so you can change your proxies and votes whenever you like.

It's somewhat surprising to me that this hasn't taken off already, given how often voters seem to be dissatisfied with the decisions of their elected representatives. It seems like it would be relatively easy to get going - somebody just needs to run on a platform of no policy except voting in accordance with the result of the system. Such a representative could get votes from both sides of the political spectrum and grants voters much more power and control - it seems to be the best of all worlds. Unfortunately when it was tried in Australia, the Senator On-Line failed miserably to get elected. There are several reasons why this might have happened:

People avoiding voting for a candidate they feel is unlikely to win in order to avoid the wrong mainstream candidate getting elected.
People not trusting this newfangled internet stuff.

The second problem should go away as the generations that haven't grown up in the internet age die out. The first problem is ever present for third parties in first-past-the-post systems. Given that politicians won't generally reform the systems that elected them, it seems like the only chances are for the third parties to sneak in at times when a majority of people have an unpopular view of both mainstream parties (which may happen more often as internet-savvy voters get better informed about what their representatives are actually doing).

Posted in economics | 1 Comment »

Seasteading

Sunday, July 18th, 2010

I find the idea of Seasteading fascinating - it could certainly be a great thing for humanity if it accelerates the evolution of government systems and gets them to solve the Hotelling's law problem and the irrational voter problem . However, I have serious doubts that a seastead would be a good place to live in the long term. Assuming it gets off the ground, here is how I think the experiment would play out.

The first problem is that seastead "land" is extremely expensive - hundreds of dollars per square foot, on par with living space in a major US city but (initially) without the network effects that make US cities valuable places to live/work/do stuff. The "land" also has ongoing maintainance costs much greater than old-fashioned land - making sure it stays afloat, de-barnacling, ensuring a supply of fresh water and food, removing waste and so on.

This means that (at least initially) a seastead is going to be importing much more than it exports. In order to be practical, it's going to have to ramp up to being a net exporter as quickly as possible to pay back the initial costs, keep itself running and generate net wealth. But there are far fewer options for a seastead to make money than for a landstead. Farming is going to be particularly difficult as it requires a lot of space. So the seasteads will have to concentrate on producing wealth in ways that don't require a lot of space, and trade with land states for food.

The things which seasteads will be able to do cheaper than landsteads are things which are made more expensive by government interference, such as manufacturing (no government to impose a minimum wage or environmentally friendly disposal practices) software and other IP-intensive activities (no copyrights or patents to worry about) and scientific research (particularly biological - no ethics laws to get in the way). Drugs, prostitution and gambling will be common as sin taxes can be avoided. Seasteads which don't do these things just won't be able to compete with the land states, so by a simple survival-of-the-fittest process, this is what the successful seasteads will end up doing - a classic race to the bottom.

By design, it's supposed to be very easy to leave a seastead and join another if you disagree with how your current seastead is being run - you just pack up your house onto a ship and go to another seastead. But this very mobility will introduce its own set of problems. Crime, for example - if someone commits a serious crime aboard a seastead, there's little stopping them from leaving before the police start breathing down their necks. To avoid having a serious crime problem, the seasteads are going to have to sacrifice freedom for security in one of a number of ways:

Make it more difficult to move (you'll need a check to make sure you aren't under suspicion of a crime before you'll be allowed to get on the boat).
Have a justice system and uniform baseline of laws covering a large union of seasteads - allow free travel between these seasteads but you'll still be under the same criminal jurisdiction - similar to how US states operate. By agreeing to be a part of the union, your seastead gets some additional security but you have to play by the union's rules to keep your police protection.

Another problem is that it's going to be difficult to institute any form of social welfare - if you tax the rich to feed the poor, those who are getting a net tax will just leave for a seastead which doesn't do that. So there is likely to be a great poverty problem - a big divide between wealthy seastates and poor ones. The poor ones will just die out and their "land" will be taken over by other seasteads, accelerating the Darwinism to the delight of libertarians and the dismay of humanitarians.

If lots of people end up on seasteads, I forsee large environmental problems since it's going to be very difficult for seasteads to enact (let alone enforce) anti-pollution laws. Seasteads which take pains to avoid dumping their toxic waste in the ocean just won't be able to compete with those that don't.

There are certain economies of scale in many of the wealth-generating activities that seasteads will perform, so it seems likely that reasonably successful seasteads will merge into larger conglomerates the way corporations do in the western world (particularly in the US). These corporate sea-states will be the ones which are nicest to live on - since they are major producers of wealth they'll be able to afford the best living conditions and attract the brightest and hardest-working people. They won't be the most free seasteads though - only those who can (or have) contributed to the seastead's economy will be allowed to live there - customers, employees and their families, retired employees, employees of partner corporations and so on. As an employee, you'll have to play by the company rules and not engage in any activities which might be deleterious to the company's profit margin - don't expect to be able to take recreational drugs, for example - they might affect your job performance and add costs to the company healthcare plan.

Some seasteads might have constitutions which prevent this sort of thing. They might not be as big, as pleasant to live on or quite as good at making money, but their small size and consequent agility might allow them to survive and become viable in certain niche areas of the seasteading economy. They may have to make some compromises to stay viable, but as different seasteads will make different compromises, there will be plenty of choice.

The outcome of the seasteading experiment is really important because when humankind inevitably starts colonizing space, similar economic forces will be at work.

Posted in economics | No Comments »

I am a monad

Saturday, July 17th, 2010

In the programming language Haskell, it is normal to work with functions that depend only on their input values, and which do nothing except return an output value. Functional programming is generally much easier to reason about, because there's no chance of one piece of a program making a change to global state that affects an apparently unrelated part of the program.

This does leave the problem of how a function program can communicate with the outside world. Various approaches have been tried, and the one Haskell chooses is particularly elegant. Functions that need to accept input or produce output take an IO object as a parameter and produce a (generally different) IO object as the result. The IO object "encapsulates" the entire world outside the program. To actually run a Haskell program, the machine performs a sequence of IO transformations - taking one IO object, evaluating the program as much as necessary to determine the next IO object, and then actually performing the corresponding input or output operation before restarting the loop.

So there's a sort of inversion between how we normally think about function evaluation and how the evaluation actually happens. One can't really pass around the entire state of the universe as a parameter the way a C programmer would pass an int, so one must fake it by moving the "state of the universe" to the outside of the program and rearranging everything else so that it works the same way as it would if you could.

I can't prove it, but I think there's a very deep idea here with implications for how we understand the universe and our place in it. Much like pure functions can't describe IO, it seems like physics as we understand it can't describe human consciousness (in particular, subjective experience). Some suggest that this means consciousness is an illusion, but this has never been a satisfying answer to me.

Physics is done by describing the universe objectively - there are these particles at these positions and such and such a field had value x over here at this time (somewhat like values in a Haskell program). There are rules describing how the state of the universe evolves through time (somewhat like pure functions). But none of these things really seem to be able to describe what it is like to "feel" seeing the colour red (for example). Physics can describe a stream of 700nm wavelength photons hitting a retina, causing neurons to fire in particular patterns, some of which resemble the patterns that have occurred when the same retina received 700nm photons previously. These patterns then provoke other patterns which previously occurred in conjunction with the "700nm" patterns, and cause the release of small amounts of hormones. Understanding this system completely (which admittedly we don't) would allow one to (in principle) predict exactly which previous experiences would be recalled by any given stimulus, and might even allow one to predict exactly how the stimulated individual would react. But none of this seems to be able to tell us what experiencing red is actually like because we have no way to describe subjective experiences objectively.

We experience the universe entirely from a subjective point of view - through our senses. The objective model is useful because it allows us to reason, communicate and simulate but I suspect that in saying that objective reality is the real thing and subjective reality is just an illusion, we would be making a mistake and not seeing the forest for the trees.

Instead, I would like to suggest that we perform the same inversion that the Haskell compiler does. Instead of thinking of human beings as unexplained (possibly unexplainable) things within an objective universe, think of them as the IO hooks of the universe: input from free will (assuming that it exists) and output to subjective experience. This IO doesn't (necessarily) go to "another universe" - it's just a primitive, axiomatic thing that may have no more relevance to our objective universe than the implementation details of the IO monad do to a pure functional Haskell program. Experiencing life is running the program.

One important difference between the universe and a Haskell program is that a Haskell program only has one IO monad, but the universe seems to have many subjective observers in it. Having multiple IO monads would be a problem for a Haskell program because the IO monad defines how the program is actually evaluated - there's only one "real universe" for it to run in. But there's no problem having multiple non-IO monads - if the monads can't communicate with each other through the outside world (only through the program) you can have as many of them as you like. Since people can't communicate with each other except through the physical universe, there's no problem here.

Does this mean that one observer in the universe is priviliged to be the "IO monad" whilst everyone else is a p-zombie? From the point of view of that observer, it certainly seems like that is a possible way of thinking about it, but since there's no objective difference between an IO monad and a non-IO monad (as long as the monads only communicate objectively), I'm not sure the distinction is meaningful.

Posted in computer, philosophy | 1 Comment »

The physics of a toroidal planet

Friday, July 16th, 2010

I love the idea of futuristic or alien civilizations using advanced technology to create planetary scale art.

I wonder if such an advanced civilization would be able to create a toroidal planet. It would have to be spinning pretty fast for it not to fall into the central hole - fast enough that the effective gravitational field at the outermost ring of the surface would be quite weak and the gravitational field at the innermost ring would be quite strong. The gravitational "down" direction would vary across the surface of the planet and wouldn't be normal to the average surface except on those two rings. I think if you slipped you probably wouldn't fall off (unless the effective gravity was very low) but you would generally fall towards the outermost ring. Any oceans and atmosphere would also be concentrated at the outermost ring. It would be as if there was a planet-sized mountain with its top at the innermost ring and its bottom at the outermost. It would therefore have to be made of something very strong if the minor radius was reasonably large - rock (and probably even diamond) tends to act as a liquid at distance scales much larger than mountains.

I need to try to remember to google my ideas before writing about them. Having written this, I've just discovered that lots of people have thought about this before.

Posted in physics | No Comments »

Reenigne blog