#include <cassert>
#include <cmath>
#include <cstdio>
#include <cstdlib>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <map>
#include <string>
#include <blitz/array.h>
#include <cblas.h>
#include "SincResampler.h"
Namespaces | |
namespace | blitz |
Typedefs | |
typedef Array< double, 2 > | ResamplingMatrix |
typedef std::map< DetectorIndex_t, ResamplingMatrix *, std::less< DetectorIndex_t > > | FMatrixCache |
Functions | |
double | sinc (double x) |
BZ_DECLARE_FUNCTION (sinc) static int genFMatrix(ResamplingMatrix &F | |
Variables | |
unsigned | src_npoints |
unsigned double | src_vlaser |
Its reference implementation is David Tobin's resample_gifts.m 20031230, which follows the matrix multiplication approach as defined in the BOMEM technical memo BOM-TECH-XXXX(Draft)-Spectral Resampling(work-02).doc
Dependencies: Blitz++ 0.6 open source matrix template library. BLAS basic linear algebra library, vendor implementation (e.g. Apple veclib), or ATLAS.
Unit test builds (to be moved to makefile): c++ -framework veclib -DTEST=1 -o test1 -I/System/Library/Frameworks/vecLib.framework/Headers -I/sw/include -L/sw/lib Resample0.cc -lstdc++ -lblitz c++ -framework veclib -DTEST=2 -o test2 -I/System/Library/Frameworks/vecLib.framework/Headers -I/sw/include -L/sw/lib Resample0.cc -lstdc++ -lblitz
self-test against fmatrix( N, 1.1, 'sinc' ): for 17, 35, 85, 1025 test cases.
test case for N=17:
Columns 1 through 8
0.1878 -0.0287 -0.0189 0.0423 -0.0555 0.0625 -0.0651 0.0639 1.0599 0.0580 0.0274 -0.0534 0.0647 -0.0690 0.0688 -0.0649 -0.1393 1.0955 -0.0525 0.0759 -0.0810 0.0801 -0.0756 0.0683 0.0759 -0.0525 1.0955 -0.1393 0.1133 -0.0994 0.0872 -0.0747 -0.0534 0.0274 0.0580 1.0599 -0.1998 0.1370 -0.1074 0.0858 0.0423 -0.0189 -0.0287 0.1878 0.9907 -0.2335 0.1461 -0.1048 -0.0361 0.0149 0.0195 -0.0876 0.3312 0.8920 -0.2414 0.1408 0.0324 -0.0126 -0.0152 0.0584 -0.1440 0.4811 0.7694 -0.2262 -0.0303 0.0113 0.0128 -0.0450 0.0940 -0.1920 0.6299 0.6299
Column 9
-0.0590 0.0577 -0.0584 0.0612 -0.0667 0.0761 -0.0923 0.1226 -0.1920
|
F matrix cache We assume for the moment that it is more expensive to load these from disk or network than it is to recompute them. Thus, we build a memory cache and flush when the executable exits. If our upstream control logic is sufficiently clever, it keeps sending us the same group so that we don't spend a lot of time building F matrices. |
|
two-dimensional double precision matrix is our F-matrix type. |
|
F matrix generator. This is an alternative to the zero-fill-linear-interpolate which is currently being tested. The F matrix generator may be subject to later complications of its generation algorithm. The src_vlaser entries vary with the off-axis angle of the pixels. The tgt_vlaser is picked as nominal for the instrument. Caching of these matrices is potentially disk-expensive. This implies that there will be a certain affinity of pixels for given CPUs, in order that the caches of the F-matrices can be kept to a reasonable size per machine. Altenrately, we can dilute the accuracy by reducing the number of distinct src_vlaser values, and/or reducing the F matrix sizes, treating them as sparse or tridiagonal, zeroing out the corners. This reduces the computation load as well as the memory load at the cost of a bite out of any error budget. FIXMEs: use the quality reduction factor MATLAB equivalent code (from DCT) as converted to I/J notation for Blitz++: (refer to fmatrix.m) >> k = (N/2:N)' k = I+(N/2.0); >> k2 = repmat(k,1,N/2+1) >> x = k2'*ratio - k2 k2rp = ratio*(J+N/2.0); k2 = I+(N/2.0) x = k2rp - k2 |
|
sinc function |