Search All of the Math Forum:
Views expressed in these public forums are not endorsed by
Drexel University or The Math Forum.



Symbolic Prgramming and Large Objects
Posted:
Jul 24, 1996 5:17 PM


Symbolic Programming and Large Objects
I am designing a perfect reconstruction filter bank that is adaptable to multiwavelets. The project involves writing symbolic code that produces several transfer functions with three given structures: Space Design, Cascade Design, Roesser's Design. For the Cascade Design, the symbolic code involves constructing a general 4x4 orthogonal matrix, R, using Givens rotation matrices, reindexing its entries 35 times to produce 35 general orthogonal matrices, Ri, and multiplying all of these matrices together to produce a single matrix, PolyH. Then, the entrees of PolyH will be combined to form a 4x2 matrix, H. Each entree of H will be integrated over one of two intervals to form the objective functions that will be minimized using the optimization package CFSQP. I am runing the maple code on a HP K200 with 1Gb of RAM. When I run cascadeNP1L.txt I get normal results; however, when I run cascadeNP2L.txt or cascadeNP35L.txt I get the following error message:
Error, (in expand/bigprod) object too large
1, 2 and 35 represent the largest value the iteration index, deg, achieves in each of the programs, and deg is the McMillan degree of the filters. I have corresponded with a maple technical supporter and his response is that my programs generate objects that have more than 2^16 terms. I have tried to partition the code to get around this technicality. The problem is that even without the integration section(cascade2LNOINT.txt, cascade35LNOINT.txt), which is the only part of the code that can be partitioned, I still get the error message:
Error, (in expand/bigprod) object too large
I have set up a web site at http://gauss.math.ucdavis.edu/~dellaera which contains the maple code for the Cascade Design. Any suggestion on how to get around these technicalitys or knowledge of a different language that would solve this problem will be much appreciated. Thank you for your time. John Dell'Aera dellaera@math.ucdavis.edu PS. I will summarize and post all suggestions.



