SYNOPSIS

#include "matrix.h" BAND *bd_resize(BAND *A, int new_lb, int new_ub, int new_n) IVEC *iv_resize(IVEC *iv, int new_dim) MAT *m_resize (MAT *A, int new_m, int new_n) PERM *px_resize(PERM *px, int new_size) VEC *v_resize (VEC *x, int new_dim) int *iv_resize_vars(unsigned new_dim, IVEC **x1, IVEC **x2, ..., NULL) int *m_resize_vars (unsigned new_m, unsigned new_n, MAT **A1, MAT **A2, ..., NULL) int *px_resize_vars(unsigned new_size, PERM **px1, PERM **px2, ..., NULL) int *v_resize_vars (unsigned new_dim, VEC **x1, VEC **x2, ..., NULL)

#include "zmatrix.h" ZMAT *zm_resize(ZMAT *A, int new_m, int new_n) ZVEC *zv_resize(ZVEC *x, int new_dim) int *zm_resize_vars(unsigned new_m, unsigned new_n, ZMAT **A1, ZMAT **A2, ..., NULL) int *zv_resize_vars(unsigned new_dim, ZVEC **x1, ZVEC **x2, ..., NULL)

DESCRIPTION

Each of these routines sets the (apparent) size of data structure to be
identical to that obtained by using `.._get(new_...)`.
Thus the `VEC *` returned by \newline`v_resize(x,new_dim)` has
`x->dim` equal to `new_dim`.
The `MAT *` returned by \hfill\break`m_resize(A,new_m,new_n)` is a
`new_m`${}\times{}$`new_n` matrix.
The following rules hold for all of the above functions except
for `px_resize()`.
Whenever there is overlap between the object passed and the re-sized data
structure, the entries of the new data structure are identical, and
elsewhere the entries are zero.
So if `A` is a $5\times 2$ matrix and `new_A = m_resize(A,2,5)`,
then `new_A->me[1][0]` is identical to the old `A->me[1][0]`.
However, `new_A->me[1][3]` is zero.
For `px_resize()` the rules are somewhat different because
permutations do not remain permutations under such arbitrary operations.
Instead, if the `size` is *reduced*, then the returned permutation
is an identity permutation.
If `size` is *increased*, then `new_px->pe[i] == i` for
`i` greater than or equal to the old `size`.
Allocation or reallocation and copying of data structure entries is avoided
if possible (except, to some extent, in `m_resize()`).
There is a ``high-water mark'' field contained within each data structure;
for the `VEC` and `IVEC` data structures it is `max_dim`,
which contains the actual amount of memory that has been allocated (at some
time) for this data structure.
Thus {\bf resizing does not deallocate memory}!
To actually free up memory, use one of the `.._free()` routines or the
`.._FREE()` macros.
You should not rely on the values of entries outside the apparent size of
the data structures but inside the maximum allocated area.
These areas may be zeroed or overwritten, especially by the
`m_resize()` routine.
The `.._resize_vars()` routines resize a NULL-terminated
list of pointers to variables, all of the same type.
The new sizes of the all variables in the list are the same.
Calling

.._resize_vars([m,]n,&x1,&x2,...,&xN,NULL)is equivalent to

x1 = .._resize(x1,[m,]n); x2 = .._resize(x2,[m,]n); ...... xN = .._resize(xN,[m,]n);(Note that ``

EXAMPLE

/* an alternative to workspace arrays */ ... my_function(...) { static VEC *x = VNULL; ...... x = v_resize(x,new_size); MEM_STAT_REG(x,TYPE_VEC); ...... v_copy(..., x); ...... }

BUGS

Note the above comment: {\bf resizing does not deallocate memory}!
To free up the actual memory allocated you will need to use the
`.._FREE()` macros or the `.._free()` function calls.

SEE ALSO:
`.._get()` routines; `MEM_STAT_REG()`.
\sourcefile{memory.c, zmemory.c, bdfactor.c{\rm\ and }ivecop.c}