DrQue.net has been a little unstable for the last couple of weeks.  I had done some upgrades to the server in anticipation of the next long-term stable Ubuntu release due to come out at the end of the month.  When I had setup the Micro Dragon, I had installed Ubuntu 9.04, but had not done much with it since.  As usual, the server "just ran" and we logged over 160 days of non-stop runtime.  But as 10.04 is set to come out, I wanted the Micro Dragon to be ready by having 9.10.  In order to get the server to run, I had to make a new build of Apache and PHP, so I went with the most up-to-date versions of those.
   Turns out that when I updated PHP, it decided that all warnings and notices should be logged to the Apache error log file.  And, what I didn't know, was that I have some script on my site that has a warning which causes continuous log entries.  In not too much time, it fills the hard drive.
   What made this error hard to track was the symptoms.  At first, MySQL refused to start.  So, I thought it was a permissions problem related to the upgrade.  It was then I noticed the hard drive was full--all 144 GB.  DrQue.net, with all of it's sites, only has a foot print of 19 GB.  Still believing this was related to MySQL, I started to look at it's log file and the databases.  But nothing was out of the ordinary.  I then started looking at every directory on the hard drive to see how much space it was using.  To my surprise, nothing was taking up the space.  So, I flag the disk for a check on start-up and rebooted.  Sure enough, I was back to plenty of free space.  Thinking this was the problem, I left things alone.
   A few days latter, I noticed my hard drive price script not logging new values.  Usually when this happens, it is because the source site changes format.  But after some running around, I found the hard drive was again full.  Again, I rebooted and checked for errors.  After not freeing any hard drive space, I started probing a little deeper.  As part of the probe, I shutdown Apache.  This caused the error log file to close, and become it's proper size--over 100 GB.  Once I found the log file at this size, I removed it and restarted Apache.  Using tail, I watched the log for a bit and saw the problem.  A quick change the the PHP init file, and we seem to be back in business.
   This is one reason I'm not a big fan of doing regular updates.  And being out of state, I haven't kept up the back up server like I use to, so that when the main server has problems, I just let the old server run the show until I get things working.  Looks like I have a new project though.

At work I stumbled on a function for doing a log in base 2. After studying the function, I decided to try a similar approach to the exponential function.

We start with Taylor series. I'm not sure how James Gregory discovered infinite series or how Brook Taylor figured out a general method for constructing them back in the early 1700s, but they sure do come in handy in the age of computers. This topic is infamous amongst calculus 2 students, but although they were a lot of work, I rather enjoyed them. Let's first look at the Taylor series transform function:

The notation denotes the n^th derivative of the function. The variable a is some starting point. Our function is . To preform the Taylor series, we need a list of the function's derivatives. For our function, that's easy: . Fill in the blanks, our our series becomes .

To see why this is useful, let's step back to the Maclaurin series for e^x: . This series will work for any value of x. There's just one problem, which should be easy to see from looking at the function: n!. This value grows very rapidly, and it doesn't take long before we run out of floating point precision. This is why the Taylor series is better. We can speed the process of convergence by starting from some known point closer to x.

In order to implement this in software, we now need a known point. If a general e^x is desired, then we are going to need several known points. I used some known limitation for the implementation. 64-bit double precision floating point has a range from 2^-1024 to 2¹⁰²³. Any value outside of this range is too much to work with. Just blindly judging from a spreadsheet, I could see that useful range from was -50 < x < 708. To keep it simple, I just decided to have a whole number increments in the table. So 758 known entries must be known.

To generate these, I used a program I've been using more and more. It's called PARI/GP and is a computer algebra system. One of the fetchers is arbitrary precision arithmetic (i.e. the ability to calculate big numbers). I used the program to generate my table of known values with 50 digits of accuracy.

And here is the implementation:

Download the tables here.

If you follow the code, you will notice a couple of things. We can take advantage of the fact a summation is a loop. This speeds up two items, (a - x)ⁿ and n!. This is because and . Thus, we can accumulate the results similar just like with the summation—except instead of adding, we multiply. The upper limit on the loop is not infinity. The reality is, we only want as much precision as we can store. So once the loop has produced enough precision that the numbers no longer change, it stops. Also, the summation loop starts at 1, not zero. This is because of the factorial. 0! = 1, and 1! = 1. Rather then deal with this in the loop, I started with the second term and moved the results of the first term out of the loop. Evaluated, the first term of the loop comes out to be e^a. The (-1)ⁿ means this is an alternating series—or that the sign is inverted on even/odd intervals. We can do that better with an if statement.. The loop is really . Note that k is some finite number based on the precision—usually less then 20.

My initial testing shows this function is accurate to about 12 digits.

I now have a really massive space ship. Now lets run the numbers to see what would be required to make it work, and how big it really is. 

The outer ring has 100% gravity and contains 90 spheres for a total of 282 km² (109 sq. miles). All the rings combine give a total of 540 spheres for 1,414 km² (around 545 sq. miles), and with just the 6 sets rendered, 8,482 km² (3,275 sq. miles)—a little less land area then the island of Island of Hawai*i.

The outer ring is for people. Assuming a population density of Beloit, Wisconsin (2,176.6 people/sq. mile), there could comfortably be 237,250 people. Up the density to that of New York City (27,440 people/sq. mile) and a total population of 2,445,960 people could be supported. If I had been able to render the full ship with 100 ring sets, the population could have been as high as 300 million people.

We can hold plenty of people, and there is a 5:1 ratio of auxiliary space to living space. The auxiliary space would be used to grow crops, and may be able to make more efficient use of the total cubic area of the spheres. It would seem we have enough space. So how much energy are we going to need in order to move this ship to the edge of the solar system?

First, we need to mass of this ship. This is going to be a very big number. To make things easier to estimate, lets just assume the mass of each sphere is about that if it were half filled with water. Why? Because we need a place to start, and water is fairly dense. I love the metric system for reasons such as this. The weight of 1 cubic meter of water is exactly 1,000 kg or 1 tonne (metric ton). Each sphere has a volume of around 4.1 billion cubic meters, and would have an estimated mass of 4.1 trillion kg. We have 3240 of these spheres for a grand total of 1.36x10¹⁶ kg—13.6 quadrillion kg. It's hard to comprehend this much mass because of it's scale.

Now that we know mass, we can determine the amount of energy required to keep it at a constant acceleration. Remember we want a constant acceleration of 9.81 m/s² so that Earth's gravity is obtained from the linear acceleration. We need to know how much force is required to obtain this acceleration. The Newton unit is a measurement of force, and it is given in kg·m/s². We have the mass in kg, and the acceleration in m/s², so fill in the two numbers and we get 1.33x10¹⁷ or 133.1 quadrillion Newtons of force.

Now that we know how much force is needed for our constant acceleration, we need to know much much energy will be required to travel to the edge of the solar system. The unit of energy, the Joule, is kg·m²/s². That is, how much force is being applied for the distance travel. We have force, and we know distance—50 AU or 7.5 trillion meters. So we need 995.9 octillion joules of energy. For comparison, a 1 megaton nuclear bomb contains 4.2 quadrillion Joules of energy. This craft requires the equivalent of 238 trillion 1 megaton devices.

So where does one come up with this huge quantity of energy? The common answer in sci-fi is to use the most dense energy form known—antimatter. Using mass-energy equivalence (yes, I'm about to invoke Einstein's famous E=mc²), 1 kg of mater, if converted to pure energy, contains 8.99x10¹⁶ or 89.9 quadrillion Joules of energy. That's the equivalent to the energy of a 21.5 megaton bomb—in just 1 kg. It's easy to see why sci-fi writers like antimatter, and if we could really produce it, we would indeed have an extremely dense form of energy.

Antimatter, however, doesn't convert into 100% usable energy. For those who are not familiar with antimatter, just understand that when mater and antimatter meet, they annihilate each other. The result is energy, transmitted in photons (electromagnetic energy—light, radio waves, ext.) and neutrinos. Neutrinos are useless as energy as they interact so weakly with matter their energy can not be captured. So 50% of the energy in antimatter is automatically lost. In addition, there is an efficiency loss on the engine—presumably some kind of rocket engine. Rocket science is a little difficult—it's rocket science. However, if we use the space shuttle as an example, it is known the rocket engines come out to be about 17% efficient. That is, 17% of the total energy stored in the fuel goes to moving the vehicle. The rest goes into making heat (most of the energy), light and noise. So lets assume our antimatter rockets can obtain 20% efficiency. Between the neutrinos and efficiency, we loss about 90% of of the energy in the fuel. But that's about all the better most cars do. The result is a total of 110.8 trillion kg of antimatter fuel is needed. This comes out to be less then 1% of the overall ship mass. Consider how massive the space shuttle is, and how much of that is just for fuel—this craft is pretty efficient.

To house this much fuel, we need to know how dense the fuel is. Lets assume we can make any kind of antimatter we desire. So anti-Iron would be a good choice. The density of iron is 7,874 kg/m³, and the properties of anti-iron should be similar (if not identical). A storage space of 14.1 billion cubic meters is required. For this, I added the 4 larger inner spheres, each with a radius of 6000 meters. Each would have a volume of 904.8 billion cubic meters—more then enough room for our fuel. Since this is antimatter fuel, some containment system would have to be in place. For how, like many other issues, I am ignoring this.

There we have it. One massive ship. But in theory, we could push it to the edge of the solar system.  Honestly, I love running the numbers.  I now have big spreadsheets full of equations so I can tweak values and see the results.  And this is only one run of "the numbers".

I tried drawing up several versions of the station to get a feel for proportion. To do this, I used Google Sketchup—and I've really taken this program to it's limits with this project. While there is nothing complicated about my design, there are a lot of objects.

Let's start with the outer ring, ring 1. It is 60,000 meters in diameter. In order to keep the devisions simple, I placed 90 spheres on this ring. We can assume these rings, with their accurate gravity, is where people will live. There are 7 inner rings. The outer rings have better gravity. Rings 2, 3, and 4 have 93%, 86% and 80% gravity respectively. Most plant life and life stock shouldn't be severely effected by this lower gravity—or we can assume that if they are, selective breading can be done to find better suited plants and animals. The outer four rings, 5-8 can be used for storage. Gravity at the 8th ring is down to 53%, but still enough to keep things firmly anchored to the floor.

In the center area I planned of large fuel containers. The fuel will have to be something like antimatter in order to contain the energy density necessary to propel the ship. There is no reason to have fuel storage at any kind of gravity, so the fuel is well suited toward the center.

I had originally considered having the center of the ship stationary and just a rotating outer ring. But this has the problem of one massive barring, and some way to transfer linear force from the engines through this barring. It was easier just to have the entire ship rotate.

There will, however, be a need for a static non-rotating part of the ship at the front. This area allow other ships to port.  I was unable to draw this because by this time, Sketchup was on it's knees.  My original design called for a set of 100 ring sets stacked on top of one an other, but this drawing only has 6 sets.  After the drawing was complete, I used the rendering software Kerkythea.  I gave the port an aluminium surface (all the other default textures were shinny) and borrowed a picture from NASA's Hubble Space Telescope for the background.  This rendering doesn't give clues to just how massive this object really is.  Keep in mind the outer ring is 60 km (37 miles) in diameter.

Outer space is big—really big—and almost entirely empty. One thing done in a lot of sci-fi movies is having the characters fly through an asteroid field, dodging asteroids like road hazards. This is silly. You would be lucky to find one asteroid in the Asteroid Belt flying straight through it, yet alone having to worry about dodging such things. Everything in our solar system is separated by distances much larger then anything we can normally work with.

In my story, ships are regularly required to travel to the outer edge of the solar system. Pluto's outer edge of it's orbit is about 50 AU, or 7.3 billion km, or 4.5 billion miles from the sun. So how long would it take to get there?

If you could get a space craft to travel 500,000 mph (not too crazy for space travel), it would take about 1 3/4 years to travel the distance. It you would like to do that in one month, you would have to travel about 10 million miles an hour.

Rocket engines are a source of force. Force in physics is usually measured in Newtons, which is kg·m/s².

Assuming the force exerted by a rocket engine is constant, we can determine it's acceleration (m/s²) on some given mass (kg). Our mass is the space ship, so knowing it's mass, we can determine acceleration.

What's nice about acceleration is that it keeps increasing velocity. The standard physics equation x = x0 + v0 t + 1/2 a t² will determine a position (x) after some time (t) with an initial position (x0) and initial velocity (v0). We we start of position 0 (x0 = 0) at a complete stop (v0=0), the equation simplifies to x = 1/2 a t². And we can solve for t, so t = sqrt( 2 * x / a ). We know x—that is the distance we want to travel. So what is the optimal acceleration? Acceleration due to gravity naturally. This way, we have linear acceleration and perfect gravity. So acceleration is 9.81 m/s². Thus, if you had the ability to provide a constant force with this rocket engine, it would take about 14 days to reach the outer orbit of Pluto from the Sun. That's not bad considering the distance.

But in working this out, I was faced with one obvious problem. The ship I designed is rotating. It already has gravity. The gravity introduced by linear acceleration will be in the wrong direction. If the rotation provides 1 g in one direction, and linear acceleration provides 1 g in an other direction, people are going to be standing sideways just to stay upright. This isn't going to work.

It was in the car ride back to Wisconsin talking this over with Mikala that a solution was presented. Mikala pointed out what should have been obvious: why not just have the spheres rotate? As the ship accelerates, turn the spheres such that the center of gravity at a 90 degree angle to the floor. In fact, one wouldn't even need to turn the spheres. The bottoms are heavier then the tops, because the tops are empty. If allowed to rotate, the spheres would naturally correct for the center of gravity.

So as the ship accelerates, the rotation is slowed. Since the ship is likely to be large, we will have to gradually accelerate to avoid jarring everything. A change in acceleration is known as jerk. So some constant jerk factor would have to be obtained—likely from that rate at which the rotation could be slowed to a stop.

A couple of weeks ago, I started contemplating an idea of a large transport space ship. On occasion I like to write a little sci-fi, but I'm usually far more interested in the technology then the story. I started to wonder about how a large transport vessel might be laid out.

Not much of a fiction reader, most of my exposure to sci-fi is from movies. And most movies don't try all that hard to create images of accurate space traveling vessels. Most somehow assume there is artificial gravity so they never have to address the issue. But how do you get gravity?

There are two methods that are rather easy: rotation and linear acceleration. Rotation works well if the object is stationary, such as with a space station. Linear acceleration can work if you have the ability to accelerate at 9.8 m/s²—the same acceleration as gravity. That's an acceleration of 79,000 mph²—meaning if you start for a dead stop, after 1 hour would be traveling 79,000 mph—so a fairly hefty acceleration. So I started with rotation.

Rotation provides centripetal force. Most of us as a kid have either tried or have seen someone spin a bucket of water over their head. The centripetal force from the rotation causes the water not to spill out even as the bucket is inverted. One can apply the same principals in space.

Again, most movies get a rotation as a means of artificial gravity wrong. Gravity is a function of the radius of the rotating path, and the speed of rotation. g = R( pi r / 30 )²/9.81 where g is gravity with respect to Earth (so 1.0 is Earth's gravity), R is the radius of rotation and r is rounds/minute of rotation. Two things should stand out about this function: a faster rotation means much higher gravity because the RPM is squared, and gravity depends on the radius. If you picture a circle, the one would be standing on the inside edge. One's feet would be touching the inner edge, and one's head would extend toward the center of the circle. The head, being closer to the center of the circle, would experience less gravity then their feet, because the radius has been reduced by their body length. This effect would be significant for small circles. For example, we could use a radius of 10 meters (so 20 meters, or about 66 feet in diameter). To get gravity at the circles edge would require a rotational speed of about 9.5 RPM. A person who is 5'8" (1.7 meters) tall would only have 82% gravity at the top of their head. Someone lifting 10 pounds would to their head would find it weighting only 8 pounds when level with their head. This may not be terrible. However, there is an other problem. Humans experience the Coriolis effect (i.e. knowing that we are spinning) at speeds above 2 RPM. So someone in such a station would get dizzy.

To get the speed down, it is necessary to increase the radius. One concept studies back in 1975 referred to as the "Stanford torus" was a torus (i.e. the doughnut shape) 900 meters in radius (about 1 mile in diameter). This would require about 1 RPM in order to hold gravity. The "O'Neill cylinder - Island Three" had an outer radius of 16 km (about 20 miles) and would rotate at one round ever 4 1/4 minutes.

After a lot of reading (mostly on Wikipedia), I starting thinking about how to create my own living area. The "Island Three" concept was really neat because it is an open cylinder. You could look up and see the other side—a city scape above your head but not falling on top of you. But this concept was designed to be stationary—orbiting Earth for example. They used large mirrors to reflect in sunlight, which was used for lighting and plant life. My vessel had to move, and the further away from the sun, the less light you get.

An other problem I had with this design was the possibility for catastrophic disasters. The entire atmosphere was contained in a single section. One hull breach, and you risk destroying the entire station. I wanted something more compartmentalized—something that worked in sections that were able to be isolated for other sections.

In other stories I've worked on, I thought up a concept using domes to grow crops. A center light source would shine on a reflective ceiling, and fields would be cultivated by a rotating gantry crane. I wondered if this concept couldn't be expanded to the space port. Rather then just use a dome, I tried using a sphere. It was easier to draw, but after some thought, made more sense. A dome is just a sphere cut in half. So the upper half of this sphere would be the dome, and the lower half could be support equipment. The flat disk in the middle is the plane for which people could live. This idea seemed to work pretty well in my head, so I started to come up with numbers—which is really where I have my fun!

My ring would be 30 km in radius (or 37 miles in diameter). At this size, it would rotate once every 5 3/4 minutes (0.17 RPM). Each dome would be 1 km in radius (1 1/4 miles in diameter), providing 776 acres of land (31 km²). The whole ring could fit 90 such domes for a total of almost 70,000 acres—109 sq. miles (2,800 km²). Because of the large size, even a building 100 meters tall (328 feet, or around 32 stories) will still have 99.67% gravity—so a 150 pound person would weight 149.5 pounds on the top floor.

So far, everything was going well for my space port. But then I remember this thing had to move...

   Yesterday I completed my basic bench layout, and for the most part, everything fits.  Part of the reason is that I used Google Sketchup to do a drawing for placement first.
   The sleeping box has been redesigned.  At first I considered cutting the box down to bench height.  Our new place is quite small.  I instead to use the top of the box as a bunk for our roommate James.  So this leaves the box at a height of 4 feet.  The biggest change is the door.  Previously, the box opened by hinges in the front, done mainly to keep from having to make additional cuts when the box was first assembled.  This was not a good design.  It leaked a lot of light, and was quite heavy.  The sliding door of my box at the Garage works much better.  Since Jai sleeps in the box with me, I decided to recycle the sliding door, but add a second one.  We both go to bed at different times, and this allows her to get into the box whenever she likes without having to crawl over me.

   Having owned and operated a domain for over 5 years I'm use to people trying to sell me junk because the idiots shysters at Network Solutions won't keep my e-mail address private unless I pay for that "privilege".  I've received e-mails in the past from people wanting to sell me a domain name similar to mine.  I ignore them by changing my e-mail address.  So when I received an e-mail the other day, I followed standard procedure.  To my surprise, I received a second e-mail hour latter to the updated e-mail address.  Seems the domain squatters have become more aggressive.  To humor myself, I clicked on the "unsubscribe" link.  Naturally, I received an e-mail today, this time from a different company.
   Let's have a look at the e-mails.  The first one is from 2/20/2010 9:19 AM
The next from 2/22/2010 7:13 AM
I received this e-mail at 2/23/2010 7:06 AM
Now I change my e-mail address.  The next e-mail is to the new address at 2/23/2010 6:01 PM
And the last e-mail from 2/26/2010 11:26 AM
    Some interesting things can be learned.  First, the use of various domain names to push their products.  They use initrustdomain.net, bestinitrustdomains.biz, flexmediadomains.com and easydomainrecovery.com.  Both initrustdomain.net and bestinitrustdomains.biz are owned by "Moniker Online Services LLC" who according to "SPAM Trackers" wiki have a long history of criminal activity.  The other two domains are "owned" by "DOMAINBULLIES, LLC" and "ENOM, INC."  There isn't much information about them.
   What gets me is that the Internet is a major source of commerce.  Isn't the FTC suppose to be doing something about this?  Why then do places like SPAM Tracker talk about groups like Moniker Online Services and how they have operated for years?  The more I deal with law and law enforcement, the more less I believe it functions.  It is both incapibal of protecting people, and incapibal keeping law enforcement from harassing the people it aims to protect.

    Everyone once and awhile I want to quick put a 3D drawing together, and I'll use Google Sketchup. Being the math nut that I am, I love it when I need to do a bit of geometry.
   Today, I happened to need to place an octagon (8=sides parallelogram) such that northern, and eastern edges were also the edges of a square, and the start of the north west corner (X), and south east corner (Z) of the octagon began at the these corners on the square. When you draw a polygon in sketchup, you need to have a center point (I) and an end point at one of the angles (such as A). So if I wanted an 8-sided polygon (octagon) to calculate where the center points, and some end point. If you happen to have Sketchup, try and see if you can eyeball this--you'll find it isn't easy. A geometric solution is needed. Luckily, it's easy.
  Every angle in an octagon is 45 degrees, which is 360 / 8. To find the center of an octagon, pick any edge, and measure 67.5 degrees (45 / 1.5) toward the center. An example in this drawing is line AB or BC. Where the angles meet is the center, point I. Note also that when drawing this polygon, it will be done from point I to one of the point A through H.
   In my requirement description, I want this octagon (call it octagon I) to meet up with square WXYZ such that vertex A meets vertex X, and D meets Z. Sides AB to XY, and DE to ZY and parallel, and vertex A and the same as X, D the same as Z. Now that we know the 2 verities, and two edges, we can find the center. Measure an angle starting at X along XY that measure 67.5 degrees clockwise. And 67.5 counter clockwise starting Z lone ZY. This is the center point.
   Draw your octagon starting at this location I, going to either vertex X or Z. That's it! :)

So my last article on prime numbers led me to ask the question "How many prime numbers are there between 2 and 2³²". I know the quick answer to this question is "a lot". 2³² is over four billion—and that's a fair bit of space to check. It would be easy to make a for-loop and brute force the entire number range, but this is the age of multi-core CPUs—and single threaded is so 2000. Besides, my computer hasn't broken a sweat in awhile.

I decided to do a straight C implementation. I've been doing C and C++ at work, and C++ has been irritating me lately because I tried to do a "quick and dirty" implementation without too much thought into the classes I'd need. That's a recipe for disaster, and how you end up with things like microsoft's windows ME. So vanilla C it was.

Threads and semaphores I used the POSIX standards, and I've tried to demonstrate how to make a dispatcher foreground task with one or more worker threads. The key to this is the dispatch semaphore. Normally, semaphores are used to for mutually exclusive lock, or to send signals between threads. However, they can also be used as a count. Think of them like a library that has a set number (say 5) of books. That means 5 people can check that book out, but if a 6th person wants to check that book out, they will have to wait for one of the first 5 to return their copy. The semaphore does this by keeping a count. When that count reaches zero, the next task that tries to pend the semaphore will have to wait. So the dispatcher is a loop that starts by pending the semaphore. When it gets the semaphore, it will create a task. The task will do some work, then post the semaphore. The semaphore count determines how many tasks can run at the same time. If we limit the number of tasks that can run at once to the number of CPU cores, then we can utilize the CPU to 100%.

First, the dispatcher skeleton code:

Then, the skeleton of the worker thread:

Now just launching a thread to check one number is a bit of a waste—it takes some overhead to start and stop the task. So we give each thread some range of numbers to check. A pthread can be passed parameters, and we pass the starting number, along with the amount of numbers to check. The parameter block is also used for storage of the results. So here is the full worker thread:

The dispatcher has to accumulate the results. Our could try using a global variable, but you can run into issues with non-atomic access. Adding 1 might seem a basic operation, but (at least in a RISC system) it takes 3 instructions to add one to a variable in memory: load the data to a register, add the register by 1, and store the register. You can not (without a semaphore) guarantee that those instructions will not be interrupted by an other thread. So, the accumulation happens in just one place—the dispatch loop.

The dispatcher will assign all the work, but it is finished once all the work has been assigned. We still need to wait for the work to finish. So the last part of the process looks like this:

Now we can print the results to the screen, and we're done.

I knew this code would tax the CPU rather hard, so I wanted to measure how long the process would take. "time.h" is a C standard unit. Unfortunately, "time_spec", which has a high-resolution method for checking the time, it's part of the C99 standard. But we can get time in the resolution of seconds, and that's good enough. To do this, we simply mark the time when the process begins, and mark it again at the end. The difference (for which there is a function to compute) is the total number of seconds that has elapsed.

The answer: There are 203,280,221 primes between 2 and 4,294,967,295, and it took 6,054 seconds (1 hour, 41 minutes) on a quad-core clocked at 2.5 GHz.

The full source code is here.