“Instructions” for using the sample files

Run sage from a directory where you are willing to write various files. Some of the files will be object files to store precalculated results, while some of the files will be images.

Non-Accelerated Solver

First, load sage, then type the following and press enter:

This will take a few seconds, depending on your processor. You can check the results by typing, e.g., any of the following:

Note that these coefficients will be saved out to the following file:

The 100 is the number of terms, and the 512 is the precision. Note that we could have used rational math for exact precision, but this is fairly slow, and even a bit unnecessary. This system is far too small to be accurate to more than a few dozen bits of precision.

For floating point arithmetic, there is a certain minimum precision level, below which the solver will return garbage. From there, we can add a few hundred bits of precision and be assured that the result is more than accurate enough for our purposes. In this case, the minimum precision is somewhere around 100 bits, give or take, so we can get by with, e.g., 256 bits of precision. For a larger system, say 300x300, we need about 512-768 bits to get decent precision.

For this example, I've opted for 768 bits of precision, far more than we need. This is mainly for the next phase, where precision is a bit harder to guage because our custom vector is floating point, so we can't solve with rationals.

Accelerated Solver

Next, we will compute the accelerated version. It will seem like a pretty big hassle, but it's worth it. For a 100x100 system, the extra time is quite significant, but when you get up to a larger system, e.g., 500x500 or even 800x800, then the extra time is fairly insignificant, and the gains in accuracy are more than worth it.

1. The first prep file computes the fixed point and saves it out.
2. The second prep file is run once for each "chunk" of the custom vector we're calculating. A global variable "num" must be set to the chunk number to be solved for. See the instructions below.
   
   Note that the second (and first) prep uses much higher precision than the final solver. This is because--at certain intermediate steps--the chunks can grow hundreds of orders of magnitude larger than the values they finally settle on, which means that we'll lose hundreds of orders of magnitude of precision. So we use more precision during this phase. I probably overdid it in my samples (for a 100x100, an extra 256-512 bits would probably have sufficed).
3. The third prep file sums the chunks and saves the vector at the desired precision for the solver.

Once the preparation has been done, we can run the solver, which will save out the results.

Example:

Note that these coefficients will be saved out to the following file:

Screenshots

Here are a few screenshots I took, using (hopefully) the exact sequence shown above:

Note that I'm running SAGE in a VMWare window, using only the shell interface. I can't get the notebook server running, and it hasn't bothered me enough to try to fix it. (Perhaps I just don't know what I'm missing?)

Future Versions

In future versions, I have a few plans. First, I plan to create a shell script that will automate the chunking. Rather than running one command and exiting, the script will simply run one command at a time through sage, with the results saved out at each step, of course.

Note: Just in case you're wondering why I'm exiting after each command, I should explain that with very large systems, memory requirements can easily run more than a GB of RAM. And unfortunately, I haven't found a way to free memory in SAGE. So I write out my partial results to disk, exit, and start with a fresh memory layout. For an 800x800 system, my chunks are 800x500, which already uses more than 1 GB of RAM. I have to do quite a few of these, each taking a little under 2 minutes to calculate at the precision I'm using. With less precision, I think I can do 1000x500 chunks and try to solve a 1000x1000 system, but I haven't yet fully investigated how much precision is needed at various system sizes.

Second, I plan to add a few more graphing options, as well as more examples. The new examples will serve two purposes. First, they will allow for comparison of solutions for systems of various sizes. They will also allow for comparison of accelerated and unaccelerated solutions, to help substantiate my claims about how much improvement we get by using the accelerated versions. Finally, I want to have examples to help show that we can investigate the accuracy of the results, based on the precision of the solving matrix, or the number of columns in our chunks. For example, a 100x2000 solution is very accurate, but a 100x200 solution gives far worse results than the 100x100 solution. The reason is simple to understand, but difficult to explain here, so I'll have to explain elsewhere.

Finally, I plan to document the code a little bit better, and make it a little more user-friendly to read. For a math library like this, the source code should be easy enough to read so that it's obvious what the code is doing. No obfuscation!