Hmm, I just solved two 800x800 systems, one at 6400 bits, and one at 8192 bits. I did a careful analysis of memory usage (both within Windows and within the linux session), and I think I can squeeze about 9% more memory, or about 10% more bits of precision (enough for about 9000 bits, give or take).
However, when I did a comparison of the two solutions, I found something unexpected. Even with this fairly large system, the precision was really good. With 1792 bits of precision difference, we can essentially treat the 8192-bit solution as "exact". By subtracting, I found that the absolute precision in bits was in excess of 5300 bits. That means that out of 6400 bits, only about 1100 bits are "junk". This means I should be able to solve the same system at, e.g., 3200 bits, and hopefully get at least 1600-2000 bits of precision out of my results. More hopefully, I should be able to solve a 1000x1000 system, reduced to perhaps 5120 bits of precision, and still get an answer that's perfectly well suited to analysis of the residue. I'll be trying that tonight, overnight (it took about 500 minutes to calculate the 800x800@8192 system).
In addition to the absolute precision test, I even did a "relative" precision test, by multiplying each coefficient by the radius of convergence to the appropriate power, simulating the error in each term for a point on the radius. Even then, the relative precision is still about 5300 bits in absolute magnitude. The following graph shows the absolute (blue) and relative (red) precisions for each term:
By the way, I hadn't quite expected behavior this good. When I was originally solving my accelerated systems, I was calculating the custom vector with the same RealField, and hence getting horrible results unless I used very high precision. For example, for a 300x300 system, I needed somewhere north of 3000 bits to get non-garbage (e.g., first coefficient was 3234134987.12342 or whatever).
But by calculating the custom vector with a very high precision in a separate step, apparently not very much precision is needed for the system itself. I was surprised by this, as I expected that solving a system this large over a realfield would require ridiculously high precision. I suppose the very nature of the system (rising powers going down, rising bases going to the right) makes it inherently stable for solving?
Anyway, the good news for us is that we should be able to solve very large systems without the need to resort to exact (rational) math, which is both slow and memory intensive. The only drawback is the possibility of systems that evaluate as uninvertible with real math (50x50 does, even for ridiculous precision levels, at least with maxima within SAGE). But if that happens, just add or subtract a few terms and try again, I guess.
However, when I did a comparison of the two solutions, I found something unexpected. Even with this fairly large system, the precision was really good. With 1792 bits of precision difference, we can essentially treat the 8192-bit solution as "exact". By subtracting, I found that the absolute precision in bits was in excess of 5300 bits. That means that out of 6400 bits, only about 1100 bits are "junk". This means I should be able to solve the same system at, e.g., 3200 bits, and hopefully get at least 1600-2000 bits of precision out of my results. More hopefully, I should be able to solve a 1000x1000 system, reduced to perhaps 5120 bits of precision, and still get an answer that's perfectly well suited to analysis of the residue. I'll be trying that tonight, overnight (it took about 500 minutes to calculate the 800x800@8192 system).
In addition to the absolute precision test, I even did a "relative" precision test, by multiplying each coefficient by the radius of convergence to the appropriate power, simulating the error in each term for a point on the radius. Even then, the relative precision is still about 5300 bits in absolute magnitude. The following graph shows the absolute (blue) and relative (red) precisions for each term:
By the way, I hadn't quite expected behavior this good. When I was originally solving my accelerated systems, I was calculating the custom vector with the same RealField, and hence getting horrible results unless I used very high precision. For example, for a 300x300 system, I needed somewhere north of 3000 bits to get non-garbage (e.g., first coefficient was 3234134987.12342 or whatever).
But by calculating the custom vector with a very high precision in a separate step, apparently not very much precision is needed for the system itself. I was surprised by this, as I expected that solving a system this large over a realfield would require ridiculously high precision. I suppose the very nature of the system (rising powers going down, rising bases going to the right) makes it inherently stable for solving?
Anyway, the good news for us is that we should be able to solve very large systems without the need to resort to exact (rational) math, which is both slow and memory intensive. The only drawback is the possibility of systems that evaluate as uninvertible with real math (50x50 does, even for ridiculous precision levels, at least with maxima within SAGE). But if that happens, just add or subtract a few terms and try again, I guess.
~ Jay Daniel Fox