In prototypes:
int vsip_iir_destroy_f(vsip_fir_f *filt);
'vsip_fir_f' should be 'vsip_iir_f'

In arguments:
Arguments filt Pointer to a FIR filter object
'FIR' should be 'IIR'

Direct Data Access (DDA) provides the means to access block data via raw pointers, independent of how the block holds the data, and regardless of whether or not the block is bound to user-specified data or VSIPL data. This functionality provides for a more extensible math library by enabling the use of external library calls on user-specified blocks without releasing them, and on VSIPL blocks in general. This API is already incorporated into the VSIPL++ specification and should be incorporated into the VSIPL specification as well in order to bring the two specifications closer together.

Please note that this issue is similarly being tracked on the specification repository: https://github.com/vsip/specs/issues/8

Added a new DDA API to VSIPL (VSIPL, sections 2.5, 4)

I VSIPL before OMG (VSIPL 1.3) some items were highlighted with yellow in the document to indicate implementation dependent values. For instance the vector index (_vi) must be unsigned but need not be long int. Also names used for structures used in incomplete typedefs need not be as shown in the manual although the VSIPL type name is required. The highlight is not in the new manual but the paragraph at the head of the section indicates it. Need to clarify this for the new specification

Substituted highlighted text with "implementation-dependent" (throughout section 2.1 and 2.2)

The dda::Data template allows accessing a block with particular layout
requirements, and the user may leave some of those requirements
unspecified – which means that the implementation may decide which to
use based on the block's layout.

Right now there is no way to query the specific layout parameters that
resulted from the combination of the block's layout with the layout
requirements.

We should add a new Data::layout_type member type to address that.

Added the new (nested) type (VSIPL++, section 7.3.2).

In the SVD section, the minor section numbers start over with each new
function, such that there are multiple "8.7.1.1 Functionality" sections.

The same problem affects the QR section, and possibly others.

I trust that this will be fixed when the document is reformatted in
Docbook, but wanted to explicitly note it so that there's a record of
why the numbers will have changed.

This issue was addressed during the OMG transition (VSIPL 1.3). The issue was accidentally left open.
Disposition: Closed, no change