VSIPL Avatar
  1. OMG Specification

VSIPL — All Issues

  • Acronym: VSIPL
  • Issues Count: 48
  • Description: All Issues
Open Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
VSIPLXX13-5 There is a writing problem with prototypes and arguments of vsip_diir_destroy_f VSIPL 1.5 open
VSIPLXX12-12 vsip_dsvd_getattr_p missing VSIPL 1.4 VSIPL 1.5 Resolved closed
VSIPLXX12-11 Integrate addenda into main body of specification VSIPL++ 1.1 VSIPL++ 1.2 Resolved closed
VSIPLXX12-10 Another minor font issue VSIPL++ 1.1 VSIPL++ 1.2 Resolved closed
VSIPLXX12-6 Compliance section needed VSIPL++ 1.1 VSIPL++ 1.2 Resolved closed
VSIPLXX12-5 Default value of Dense map type not described VSIPL++ 1.1 VSIPL++ 1.2 Resolved closed
VSIPLXX12-9 Minor font issue VSIPL++ 1.1 VSIPL++ 1.2 Resolved closed
VSIPLXX12-8 Numbered sections? VSIPL++ 1.1 VSIPL++ 1.2 Resolved closed
VSIPLXX12-7 Code examples in separate machine-readable file? VSIPL++ 1.1 VSIPL++ 1.2 Resolved closed
VSIPLXX12-4 VSIPL reference in VSIPL++ is outdated VSIPL++ 1.1 VSIPL++ 1.2 Resolved closed
VSIPLXX12-3 "this header is usually included" should be excluded VSIPL++ 1.1 VSIPL++ 1.2 Resolved closed
VSIPLXX13-4 Incorporate the VSIPL++ DDA API into the VSIPL Specification VSIPL++ 1.2 VSIPL++ 1.3 Resolved closed
VSIPLXX13-3 No Highlight's for implementation values VSIPL 1.4 VSIPL++ 1.3 Resolved closed
VSIPLXX13-2 Add "layout_type" member type to dda::Data VSIPL++ 1.2 VSIPL++ 1.3 Resolved closed
VSIPLXX13-1 Section numbering is broken in QR, SVD sections VSIPL++ 1.2 VSIPL++ 1.3 Resolved closed
VSIPLXX12-2 Conformance statement VSIPL++ 1.1 VSIPL++ 1.2 Resolved closed
VSIPLXX12-1 Regarding mars/12-03-38 (VSIPL++ RFC Package VSIPL++ 1.1 VSIPL++ 1.2 Resolved closed
VSIPL16-16 Convolution with decimation!=1 accesses outside input VSIPL++ 1.2 open
VSIPL16-15 'Explicit copy' function to clarify view copy semantics VSIPL++ 1.2 open
VSIPL16-18 Dangerous implicit conversions VSIPL++ 1.2 open
VSIPL16-17 Meaning of vsip_symmetry enum values inconsistent VSIPL++ 1.2 open
VSIPL16-20 Block refcounting interface error prone, wrong VSIPL++ 1.2 open
VSIPL16-19 Unclear antecedent in ~Dense() destructor description VSIPL++ 1.2 open
VSIPL16-23 ~Dense() destructor should use "use count". VSIPL++ 1.2 open
VSIPL16-22 View's block reference-counting is inconsistent VSIPL++ 1.2 open
VSIPL16-14 'Explicit alias' to clarify view copy semantics VSIPL++ 1.2 open
VSIPL16-13 Fir<> has duplicate 'symmetry' accessor, member VSIPL++ 1.2 open
VSIPL16-11 Fir<> copy ctor must be allowed to throw std::bad_alloc VSIPL++ 1.2 open
VSIPL16-10 tuple should provide value accessors VSIPL++ 1.2 open
VSIPL16-12 Domain<> is used when unneeded VSIPL++ 1.2 open
VSIPL16-21 Block decrement_count() is problematic in some cases VSIPL++ 1.2 open
VSIPL16-24 Block reference-counting only described in Dense VSIPL++ 1.2 open
VSIPL16-1 wrong type specifiier for SVD output vector VSIPL++ 1.3 open
VSIPL16-8 VSIPL++ spec references nonexistent complex types VSIPL++ 1.2 open
VSIPL16-7 maxmg etc. of complex should return real values VSIPL++ 1.2 open
VSIPL16-5 cmplx function is misplaced VSIPL++ 1.2 open
VSIPL16-4 scatter, gather declarations should use const_View in place of View VSIPL++ 1.2 open
VSIPL16-9 Conv. 'kernel_size()' incorrect for symmetric kernels VSIPL++ 1.2 open
VSIPL16-2 VSIPL and VSIPL++ should define version macros VSIPL++ 1.2 open
VSIPL16-3 scatter, gather should support multidimensional index views VSIPL++ 1.2 open
VSIPL16-6 cscalar_i is required inconsistently VSIPL++ 1.2 open
VSIPL16-31 Sort function VSIPL 1.4 open
VSIPL16-26 Note on Deferred memory allocation VSIPL++ 1.2 open
VSIPL16-25 Vector destructor should call decrement_count VSIPL++ 1.2 open
VSIPL16-28 Distinction between "Restrictions" and "Errors" is unclear VSIPL 1.4 open
VSIPL16-27 Notes to implementors VSIPL++ 1.2 open
VSIPL16-30 Review entire document for typos VSIPL 1.4 open
VSIPL16-29 Implementation Dependent Input and Output should become optional VSIPL 1.4 open

Issues Descriptions

There is a writing problem with prototypes and arguments of vsip_diir_destroy_f

  • Status: open  
  • Source: University of Science and Technology Beijing ( Runchu Zhao)
  • Summary:

    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'

  • Reported: VSIPL 1.5 — Thu, 27 Aug 2020 15:22 GMT
  • Updated: Thu, 3 Sep 2020 19:58 GMT

vsip_dsvd_getattr_p missing

  • Legacy Issue Number: 18543
  • Status: closed  
  • Source: Retired ( Randall Judd)
  • Summary:

    In VSIPL 1.3 (VSIPL before OMG) there is a get attribute function defined for SVD's. The function definition seems to be missing from VSIPL 1.4 (although the function is mentioned throughout the spec). This appears to be an editing omission during translation of 1.3 to 1.4.

  • Reported: VSIPL 1.4 — Tue, 12 Mar 2013 04:00 GMT
  • Disposition: Resolved — VSIPL 1.5
  • Disposition Summary:

    Added the original text from VSIPL 1.3 (VSIPL, section 9.7.4)

  • Updated: Thu, 12 Mar 2015 02:20 GMT

Integrate addenda into main body of specification

  • Legacy Issue Number: 18266
  • Status: closed  
  • Source: Mentor Graphics Corporation ( Stefan Seefeld)
  • Summary:

    Three separate API additions have been added as "Addenda" to the original VSIPL spec:

    1) VSIPL Interpolation API
    2) VSIPL Permute API
    3) VSIPL Sort API

    Integrate all of those into the main structure of the specification.

  • Reported: VSIPL++ 1.1 — Tue, 13 Nov 2012 05:00 GMT
  • Disposition: Resolved — VSIPL++ 1.2
  • Disposition Summary:

    The “Addenda” sections have been fully integrated verbatim into the structure of
    the specification. They have become chapters 9 (“Interpolation”, page 478), 10
    (“Permutation Functions”, page 492), and 11 (“Sort Functions”, page 501).

  • Updated: Fri, 6 Mar 2015 23:16 GMT

Another minor font issue

  • Legacy Issue Number: 18263
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    There are a few places where "VSIPL 1.0 compliance" is mentioned. This should presumably be "VSIPL 1.3 compliance" or "VSIPL 1.x compliance".

  • Reported: VSIPL++ 1.1 — Tue, 13 Nov 2012 05:00 GMT
  • Disposition: Resolved — VSIPL++ 1.2
  • Disposition Summary:

    Page 27, section 3.2.1, item “Functionality”: “VSIPL 1.0” has been changed to
    “VSIPL 1.4”. Likewise in Section 3.2.2, item “Arguments”.

  • Updated: Fri, 6 Mar 2015 23:16 GMT

Compliance section needed

  • Legacy Issue Number: 18257
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    There are three compliance points: the whole VSIPL specification, the Core profile (mars/12-02-07), and the Core lite profile (mars/12-02-08). All the information needed for a compliance section is present on page 1 (PDF page 23) and those two documents. If this specification had been written using the ISO/OMG document template, this is what it should contain. This is only a matter of presentation.

  • Reported: VSIPL++ 1.1 — Tue, 13 Nov 2012 05:00 GMT
  • Disposition: Resolved — VSIPL++ 1.2
  • Disposition Summary:

    On page 2, a new section 1.4 titled “Conformance” has been introduced following
    section 1.3 (“Functionality”), which includes what was previously the last
    paragraph of section 1.3.

  • Updated: Fri, 6 Mar 2015 23:16 GMT

Default value of Dense map type not described

  • Legacy Issue Number: 18214
  • Status: closed  
  • Source: dpdx.net ( Brooks Moses)
  • Summary:

    Although the paragraphs describing the D, T, and O template parameters
    for Dense<> mention the default value, the paragraph for M does not; it
    should do so.

  • Reported: VSIPL++ 1.1 — Tue, 23 Oct 2012 04:00 GMT
  • Disposition: Resolved — VSIPL++ 1.2
  • Disposition Summary:

    Changed item 6.3.2/4 (page 32) to:
    “M must be a map type with a default constructor. Its default value is the
    Local_map type.”

  • Updated: Fri, 6 Mar 2015 23:16 GMT

Minor font issue

  • Legacy Issue Number: 18262
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    p31 (PDF page 53) There's a font formatting error. The words "Solve a covariance linear system" should be in Times not Courier font.

  • Reported: VSIPL++ 1.1 — Tue, 13 Nov 2012 05:00 GMT
  • Disposition: Resolved — VSIPL++ 1.2
  • Disposition Summary:

    Page 22, section 2.9.1.3: The above text has been properly reformatted as inline
    comment (/.../) embedded into (sample) code.

  • Updated: Fri, 6 Mar 2015 23:16 GMT

Numbered sections?

  • Legacy Issue Number: 18260
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    Sections should ideally be numbered. See ISO/OMG specification template

  • Reported: VSIPL++ 1.1 — Tue, 13 Nov 2012 05:00 GMT
  • Disposition: Resolved — VSIPL++ 1.2
  • Disposition Summary:

    The entire document has been reformatted after being transcribed from MS Word
    to DocBook. Sections are now properly numbered

  • Updated: Fri, 6 Mar 2015 23:16 GMT

Code examples in separate machine-readable file?

  • Legacy Issue Number: 18258
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    The code examples could usefully be provided as separate machine-readable files

  • Reported: VSIPL++ 1.1 — Tue, 13 Nov 2012 05:00 GMT
  • Disposition: Resolved — VSIPL++ 1.2
  • Disposition Summary:

    All example code is in fact now provided as separate C source files.

  • Updated: Fri, 6 Mar 2015 23:16 GMT

VSIPL reference in VSIPL++ is outdated

  • Legacy Issue Number: 18200
  • Status: closed  
  • Source: dpdx.net ( Brooks Moses)
  • Summary:

    The "normative references" section states, "References to “VSIPL” or the
    “VSIPL specification” refer to the VSIPL 1.1 API." This needs to be
    updated to 1.4.

  • Reported: VSIPL++ 1.1 — Tue, 23 Oct 2012 04:00 GMT
  • Disposition: Resolved — VSIPL++ 1.2
  • Disposition Summary:

    The references have been updated to refer to the canonical OMG URL.
    Changed item 1.2/3 (page 1) to:
    “References to “VSIPL” or the “VSIPL specification” refer to the VSIPL
    specification at http://www.omg.org/spec/VSIPL/

  • Updated: Fri, 6 Mar 2015 23:16 GMT

"this header is usually included" should be excluded

  • Legacy Issue Number: 18198
  • Status: closed  
  • Source: dpdx.net ( Brooks Moses)
  • Summary:

    These sections contain phrases like, "Note: This header file is usually
    included in other header files so direct inclusion is rarely necessary."

    This is non-normative, and because "usually" means "some implementations
    may not do this", it is not helpful to users in writing
    standard-conformant code. In fact, it encourages users to write
    non-comforming code! These should be removed.

  • Reported: VSIPL++ 1.1 — Tue, 23 Oct 2012 04:00 GMT
  • Disposition: Resolved — VSIPL++ 1.2
  • Disposition Summary:

    The following note has been removed from item 4/1 (page 11):
    “[Note: This header file is usually included in other header files so direct inclusion
    is rarely necessary.]”

  • Updated: Fri, 6 Mar 2015 23:16 GMT

Incorporate the VSIPL++ DDA API into the VSIPL Specification

  • Legacy Issue Number: 19132
  • Status: closed  
  • Source: Northrop Grumman ( Mr. Joseph Dougherty)
  • Summary:

    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

  • Reported: VSIPL++ 1.2 — Thu, 28 Nov 2013 05:00 GMT
  • Disposition: Resolved — VSIPL++ 1.3
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:59 GMT

No Highlight's for implementation values

  • Legacy Issue Number: 18546
  • Status: closed  
  • Source: Retired ( Randall Judd)
  • Summary:

    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

  • Reported: VSIPL 1.4 — Wed, 13 Mar 2013 04:00 GMT
  • Disposition: Resolved — VSIPL++ 1.3
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Add "layout_type" member type to dda::Data

  • Legacy Issue Number: 18215
  • Status: closed  
  • Source: dpdx.net ( Brooks Moses)
  • Summary:

    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.

  • Reported: VSIPL++ 1.2 — Tue, 23 Oct 2012 04:00 GMT
  • Disposition: Resolved — VSIPL++ 1.3
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section numbering is broken in QR, SVD sections

  • Legacy Issue Number: 18213
  • Status: closed  
  • Source: dpdx.net ( Brooks Moses)
  • Summary:

    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.

  • Reported: VSIPL++ 1.2 — Tue, 23 Oct 2012 04:00 GMT
  • Disposition: Resolved — VSIPL++ 1.3
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Conformance statement

  • Legacy Issue Number: 17403
  • Status: closed  
  • Source: Thematix Partners LLC ( Dr. Doug Tolbert)
  • Summary:

    Please collect all conformance information from various locations in mars/12-03-09 into a single conformance statement in section 1.3 as discussed at the March 2012 AB meeting

  • Reported: VSIPL++ 1.1 — Tue, 29 May 2012 04:00 GMT
  • Disposition: Resolved — VSIPL++ 1.2
  • Disposition Summary:

    The specification contains conformance criteria for (almost) each function
    definition. It is therefore not feasible to move them all into a single section.
    Instead, the existing conformance section has been amended with paragraphs
    outlining these criteria generically, to help the reader find those conformance
    points easily.
    New items 1.3/1 and 1.3/2 (page 1):
    1. Most functions in this specification are parametrized for the value-types
    they operate on. The individual function specifications indicate which
    value-types need to be supported in a compliant implementation.
    2. Compliance criteria relating to the VSIPL++ Parallel specification are listed
    in [dpp.oplevel]

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Regarding mars/12-03-38 (VSIPL++ RFC Package

  • Legacy Issue Number: 17402
  • Status: closed  
  • Source: Thematix Partners LLC ( Dr. Doug Tolbert)
  • Summary:

    Please update the inventory document (mars/12-03-12) to follow the URL naming and other conventions outlined in OMG document ab/07-06-01.

  • Reported: VSIPL++ 1.1 — Tue, 29 May 2012 04:00 GMT
  • Disposition: Resolved — VSIPL++ 1.2
  • Disposition Summary:

    A new and conforming inventory document supersedes the original one.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Convolution with decimation!=1 accesses outside input

  • Key: VSIPL16-16
  • Legacy Issue Number: 18211
  • Status: open  
  • Source: dpdx.net ( Brooks Moses)
  • Summary:

    (Copied from an internal Mentor Graphics issue.)

    Introduction
    ------------

    C-VSIPL defines the following equation to compute the values y_n of a
    minimum support 1-D convolution:

    y_n = Sum k from 0 to M-1 of ( h_k * x_(n*D + (M-1) - k) )

    Where:

    N is the input vector length,
    M is the kernel length,
    D is the deimation,
    x_j is the input vector (of size N)
    h_k is the kernel vector (of size M)

    C-VSIPL defines the length of the output vector (i.e. values n for
    which y_n is defined) as:

    floor( (N-1) / D ) - floor( (M-1) / D) + 1

    In some cases, this equation requires the implementation to access
    elements of x outside the x proper.

    Example Illustrating the Problem
    --------------------------------

    To see this, first consider the case (where the equation is correct):

    N = 5, M = 4, D = 1.

    The expected output length is:

    floor((5-1)/1) - floor((4-1)/1) + 1
    = 4 - 3 + 1
    = 2

    Consider a diagram showing how each output is computed:

    x_0 x_1 x_2 x_3 x_4

    y_0 = h_3 h_2 h_1 h_0

    y_1 = h_3 h_2 h_1 h_0

    I.e.
    y_0 = h_0*x_3 + h_1*x_2 + h_2*x_1 + h_3*x_0
    y_1 = h_0*x_4 + h_1*x_3 + h_2*x_2 + h_3*x_1

    In computing y_0 and y_1, only values

    { x_j | 0 <= j < 5 }

    are required.

    Next, consider the case:

    N = 5, M = 4, D = 2.

    The expected output length is:

    floor((5-1)/2) - floor((4-1)/2) + 1
    = floor(4/2) - floor(3/2) + 1
    = 2 - 1 + 1
    = 2

    To compute y_n, we need to multiply h_k by x_(n D + (M-1) - k).
    For n=1, k=0, the index to x is

    n D + (M-1) - k
    = 1 2 + (4-1) - 0
    = 2 + 3 - 0
    = 5

    However, x_5 is not a valid element of x.

    Pictorally:

    x_0 x_1 x_2 x_3 x_4

    y_0 = h_3 h_2 h_1 h_0

    y_1 = h_3 h_2 h_1 h_0

    Finally, consider two more cases:

    N = 5, M = 4, D = 3 -> output length = 1

    N = 5, M = 4, D = 4 -> output length = 2

    (Why should D=3 be any different from the other cases?)

    This does not make sense for several reasons:

    • First, when D=2, a value (x_5) outside the support of x is required
      to compute the result. This might run counter to user's expectations
      of how the minimal output region of support should be defined.
    • Second, changing the decimation

    A New Equation for the Output Length
    ------------------------------------

    What should the output length be?

    Starting from the assumption that the formula for y_n is correct, we
    need to determine the range of indices

    {n}

    for which all indices to x
    are valid.

    In particular, we want to find the largest n such that the following
    holds for all k in 0 <= k <= M-1:

    0 <= n*D + (M-1) - k < N

    The lower bound is true for all n >= 0 since n*D >= 0 and (M-1)-k >= 0.

    The upper bound:

    n*D + (M-1) - k < N

    The largest LHS occurs when k = 0:

    n*D + (M-1) < N

    n*D < N - M + 1

    n < ceil((N-M+1) / D)

    The largest n that we can compute y_n for is

    n = ceil((N-M+1) / D)-1

    Hence the output length is:

    ceil((N-M+1) / D)

    In the case where D=1, this reduces to:

    N-M+1

    (which is what the current equation reduces too when D=1).

    Comparing the new equation with the old one for the previous examples:

    N=5, M=4, D=1 old=2 new=2
    N=5, M=4, D=2 old=2 new=1
    N=5, M=4, D=3 old=1 new=1
    N=5, M=4, D=4 old=2 new=1

    Equation for Full Support Output Length
    ---------------------------------------

    Similarly, the lengths for full support case are also incorrect.

    For full support, the assumption is that each output vector should
    have at least one value from x used to compute it:

    n*D - k < N

    (minimal index occurs when k = M-1)

    n*D - (M-1) < N

    n*D < N + (M-1)

    n < ceil((N+M-1)/D)

    However, here the error is less of an issue because the equation to
    compute y_n is based on < x_k > rather than x_k. <x_k> is defined to
    be 0 if k < 0 of k >= N

  • Reported: VSIPL++ 1.2 — Tue, 23 Oct 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

'Explicit copy' function to clarify view copy semantics

  • Key: VSIPL16-15
  • Legacy Issue Number: 18210
  • Status: open  
  • Source: dpdx.net ( Brooks Moses)
  • Summary:

    The rules for when a copy constructor "View v(w);" will create a view v
    that aliases the view w are somewhat esoteric and likely to lead to
    confusion – the result depends on details of the type of w, which do
    not appear on this line and (with templates) may be in an entirely
    separate section of the code.

    It would be handy to have versions of this statement which are
    predictable with regards to copy or alias, and which make the intent
    explicit. Unfortunately this is not possible with the alias case, but
    we can at least resolve it for the copy case.

    Thus, I propose we add a deep_copy() function (or a method on views)
    which would allow us to write "View v(deep_copy(w));" – with the result
    that v has the same size as w, and the same values, but is guaranteed to
    be a copy rather than an alias.

    (Note that the "deep_copy" name is just a stand-in; there may be better
    names for this functionality.)

  • Reported: VSIPL++ 1.2 — Tue, 23 Oct 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Dangerous implicit conversions

  • Key: VSIPL16-18
  • Legacy Issue Number: 18216
  • Status: open  
  • Source: dpdx.net ( Brooks Moses)
  • Summary:

    This issue is copied from an internally-filed issue at Mentor that dates
    back to the early days of the specification. Since that time, some
    usage patterns have emerged that appear useful – most notably, the
    implicit use of a length_type when a Domain<1> is required. This
    particular case should either be preserved or additional overloads of
    the relevant functions should be added.

    However, in general this complaint is still quite relevant – for
    instance, we should not be implicitly converting a length_type value to
    a LU_solver object.

    Note that I have not edited this to account for any changes to the
    specification (either section numbers or normative changes) since the
    issue was initially submitted in 2005.

    In most cases, the resolution – adding an "explicit" keyword to many of
    these constructors – seems straightforward and obvious. Chances are
    very high that any existing code which is broken thereby was erroneous
    in the first place.


    Many of the constructors specified can take a single argument but are
    not declared "explicit". A complete list:

    Domain<1>(length_type)
    Index<1>(index_type)
    Dense<D>(Domain<D> const&)
    const_Vector(Block&)
    const_Vector(Vector const&)

    • const_Vector<>(Vector const&)
      Vector<>(Block&)
      template <typename T0, typename Block0>
      Vector(Vector<T0, Block0> const&)
      const_Matrix<>(Block&)
    • const_Matrix<>(Matrix const&)
      Matrix(Block&)
      template <typename T0, typename Block0>
      Matrix(Matrix<T0, Block0> const&)
      const_Tensor<>(Block&)
    • const_Tensor<>(Tensor const&)
      Tensor(Block&)
      template <typename T0, typename Block0>
      Tensor(Tensor<T0, Block0> const&)
      lud<>(length_type) or LU_solver<>(length_type), see #29
      Rand<>(index_type)

    Of these, only the starred conversions are defensible, and even
    they will require some design adjustments. All the
    rest are a problem; most are fixable simply by adding "explicit".
    For the case of Domain<1>, this will require redesign of other
    components to restore convenient usage; perhaps similarly for some
    of the conversions from Block&.

    Also, in the requirements list 6.3, the line View(Block &) should be
    annotated to indicate that the conversion should not be implicit.

    To expand on why these implicit conversions are dangerous...

    First, implicit conversions from native numeric types are especially
    problematic because of the promiscuous conversions among those types,
    inherited from C, that occur even before calling the constructor.
    As a result, any numeric type, whether int, float, char, or bool,
    matches the constructor argument, and thus is accepted freely in
    place of the class type by any function that takes an argument of
    that type, regardless of whether it makes sense. These mistakes
    can be very hard to spot; sometimes it results from calling f(a,b)
    when f(b,a) was meant. (Functions declared to take numeric types
    can sometimes be made safer by overloading with another that takes
    a different, but acceptable, numeric type.)

    Second, implicit conversions of any kind provoke annoying compiler
    error messages complaining of ambiguities when more than one
    conversion path is possible. The more implicit conversions that
    are possible, the more frequently such ambiguities occur. The
    workaround for such an ambiguity is to add a cast to the exact
    type, but casts are themselves a source of errors, and besides
    obscuring the logic of the code, they eliminate the convenience
    the implicit conversion was supposed to provide.

    Third, in cases where one conversion path is favored by the compiler
    over another, the compiler may silently choose what the programmer
    would consider the wrong one.

    Fourth, template argument matching ignores conversions, making those
    that do work less conveniently useful than they may seem.

  • Reported: VSIPL++ 1.2 — Tue, 23 Oct 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Meaning of vsip_symmetry enum values inconsistent

  • Key: VSIPL16-17
  • Legacy Issue Number: 18212
  • Status: open  
  • Source: dpdx.net ( Brooks Moses)
  • Summary:

    The vsip_symmetry enumerator is used in a number of places, and in
    general the VSIP_SYM_EVEN_LEN_* values are defined as "(Even) Symmetric,

    {odd,even}

    length".

    However, in the text there are sporadic mentions that imply that
    symmetric here really means conjugate-symmetric; for instance, see the
    bottom of page 567 ("The filter kernel can be even (conjugate) symmetric
    or non-symmetric.") and the definition of the "kernel" argument to
    vsip_*fir_create on page 612. This needs to be much more clearly and
    consistently stated.

    Regardless of whether the kernel is defined as symmetric or
    conjugate-symmetric, the method for constructing the complete kernel
    from the input in the symmetric cases is not defined. Is the input the
    first half of the kernel, or the second half? Is the first half
    conjugated, or the second half? This needs to be clearly specified.

  • Reported: VSIPL++ 1.2 — Tue, 23 Oct 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Block refcounting interface error prone, wrong

  • Key: VSIPL16-20
  • Legacy Issue Number: 18218
  • Status: open  
  • Source: dpdx.net ( Brooks Moses)
  • Summary:

    This issue is copied from an internally-filed issue at Mentor that dates
    back to the early days of the specification, circa 2005. I expect it
    will be marked as "out of scope" for the VSIPL++ 1.2 FTF, but it should
    be considered for a future 2.0 revision of the spec.


    The specification requiring Blocks to implement reference counting
    has several problems. First, it overconstrains implementations;
    they may well have a better way to implement storage management,
    if permitted. Second, as an interface it is clumsy and fails to
    take advantage of C++ language strengths (most particularly,
    destructors) for better safety. Finally, it is far from clear
    that the library should ever dispose of a user block. If the
    user created it, isn't the user's responsibility to dispose of
    it when the user chooses, by whatever means the user chooses?

    If in fact the library should take responsibility for discarding
    a user's block when it is no longer needed, it suffices to provide
    a way for the user to ask that ownership be transferred to the
    library, without going into detail about how the library will
    manage it afterward.

    ...

    Note that this is also an exception-safety issue. In particular,
    with the existing interface block storage could easily leak if an
    exception were thrown before whoever was responsible to decrement
    the count got to it.

    If the spec were to say that all blocks derive from

    template <bool isManaged, bool isConst,
    typename valueT=..., typename mapT=...>
    class vsip::Block_base;

    then that base class and the views could handle all the refcounting
    business invisibly. Besides being exception-safe and less messy,
    it would be incrementally more convenient for users to define their
    own block types. (Cf. std::iterator<>.)

    Of course users could keep the library from deleting a managed block by
    keeping their own view on it, too.

    It is possible to implement the library so that blocks and programs
    written to the old interface would still work as before.

  • Reported: VSIPL++ 1.2 — Tue, 23 Oct 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Unclear antecedent in ~Dense() destructor description

  • Key: VSIPL16-19
  • Legacy Issue Number: 18217
  • Status: open  
  • Source: dpdx.net ( Brooks Moses)
  • Summary:

    The description of the ~Dense() destructor states "It should no longer
    be used." The antecedent of "it" is grammatically unclear – although
    users can guess from context, this should really say "The Dense object
    should no longer be used."

    It may perhaps be worth noting explicitly that any views bound to the
    block should also not be used (although, in that case, what exactly does
    "used" mean? Is it valid to access their size?).

  • Reported: VSIPL++ 1.2 — Tue, 23 Oct 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

~Dense() destructor should use "use count".

  • Key: VSIPL16-23
  • Legacy Issue Number: 18223
  • Status: open  
  • Source: dpdx.net ( Brooks Moses)
  • Summary:

    The description of the ~Dense() destructor refers to the "reference
    count". However, elsewhere the phrase "use count" is used. This should
    be consistent

  • Reported: VSIPL++ 1.2 — Tue, 23 Oct 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

View's block reference-counting is inconsistent

  • Key: VSIPL16-22
  • Legacy Issue Number: 18220
  • Status: open  
  • Source: dpdx.net ( Brooks Moses)
  • Summary:

    The description of how block reference-counting works with
    view-allocated blocks is inconsistent.

    In 6.1.1. [block.alloc], it is stated that "For a block allocated by a
    view constructor, the effect of creation should include the effect of
    invoking increment_count."

    In 8.1 [view.view], however, the contrary requirement is given: "A
    constructor that does allocate its block must not invoke its block's
    increment_count member function."

    These do not appear to be consistent – or, at the very least, are very
    confusing. I suppose that the intended meaning is that, when a view
    allocates a block, the act of creating that block should increment the
    count, but that the view constructor should not otherwise increment the
    count. However, that's not at all clear from the text.

    Further, in 6.1.1, there is this note: "Note: For a block allocated by a
    view constructor, the number of increment_count invocations should meet
    or exceed the number of decrement_count invocations if the block is to
    be used. When the number of decrement_count invocations exceeds, not
    just equals, increment_count invocations, the block should be
    deallocated." This seems at first glance to be inconsistent with the
    definition of decrement_count, which states that the block will be
    deallocated when the value reaches zero, not goes below zero. It is
    only consistent if we assume that the phrase "the effect of invoking
    increment_count" does not include the effect of incrementing the number
    of times we consider increment_count to have been invoked!

    Much of this would be clarified if we simply explicitly stated, in the
    block requirements, that the "use count" should be set to one in the
    block constructor, rather than the "effect of calling increment_count"
    wording. Then we could omit the 6.1.1 paragraph 7 note entirely.

    (That points out a related omission: We do not actually specify the
    initial use-count value for the general case; for blocks that are not
    Dense and not created by a view constructor, a conforming implementation
    could initialize the use-count to infinity. Or three, just for
    perversity. This is probably not desirable.)

  • Reported: VSIPL++ 1.2 — Tue, 23 Oct 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

'Explicit alias' to clarify view copy semantics

  • Key: VSIPL16-14
  • Legacy Issue Number: 18209
  • Status: open  
  • Source: dpdx.net ( Brooks Moses)
  • Summary:

    In my previous issue, I stated with regards to clarifying the semantics
    of a "View v(w)" statement: "Unfortunately this is not possible with the
    alias case, but we can at least resolve it for the copy case.

    This is not actually true. We could define an alias() function (or
    method) on a View which returns a unspecified type, and then a View
    constructor that accepts that type as input and either creates an alias
    to the precursor view or throws a compile error. Thus, you could write

    View v(alias(w));

    and know that, if it compiles, you are guaranteed to get a true alias.

  • Reported: VSIPL++ 1.2 — Tue, 23 Oct 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Fir<> has duplicate 'symmetry' accessor, member

  • Key: VSIPL16-13
  • Legacy Issue Number: 18208
  • Status: open  
  • Source: dpdx.net ( Brooks Moses)
  • Summary:

    The Fir<> class is required to include both "static symmetry_type const
    symmetry" and "symmetry_type symmetry()". This duplication of names is
    illegal, and the duplication of functionality is pointless. (Thus, the
    Mentor Graphics implementation provides only the const member, not the
    method.)

    Less illegally, the continuous_filter member and continuous_filtering()
    method duplicate each other. Similarly, in [signal.convol] we have a
    misspelled symmtry member and a symmetry() method, and in both
    [signal.convol] and [signal.correl] we have a supprt member and
    support() method. These duplicates and misspellings are confusing and
    redundant, and should be removed.

  • Reported: VSIPL++ 1.2 — Tue, 23 Oct 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Fir<> copy ctor must be allowed to throw std::bad_alloc

  • Key: VSIPL16-11
  • Legacy Issue Number: 18206
  • Status: open  
  • Source: dpdx.net ( Brooks Moses)
  • Summary:

    The Fir<> copy constructor is declared "VSIP_NOTHROW". This is
    erroneous and should instead be "VSIP_THROW((std::bad_alloc))", because
    the copied Fir<> object must not share the storage allocated by the
    source instance (in case the source is destroyed).

    The same error applies to Convolution<>, Correlation<>, and potentially
    others.

  • Reported: VSIPL++ 1.2 — Tue, 23 Oct 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

tuple should provide value accessors

  • Key: VSIPL16-10
  • Legacy Issue Number: 18205
  • Status: open  
  • Source: dpdx.net ( Brooks Moses)
  • Summary:

    VSIPL++ implementations are not required to provide any member
    definitions for tuple<>. However, both the old reference implementation
    and the Mentor Graphics implementation define static members with the
    values of the dimension ordering. These are certainly useful within the
    implementations, and are likely to be useful to applications as well.

    Recommendation: Require definition of 'dim0', 'dim1', and 'dim2' tuple
    members, which match the tuple's template arguments.

  • Reported: VSIPL++ 1.2 — Tue, 23 Oct 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Domain<> is used when unneeded

  • Key: VSIPL16-12
  • Legacy Issue Number: 18207
  • Status: open  
  • Source: dpdx.net ( Brooks Moses)
  • Summary:

    There are several places where the VSIPL++ passes Domain<> arguments
    where only the length portions of the domain are used. The Dense()
    constructors are the most egregious cases, but there are others such as
    Fftm(). This is confusing to users – we've noticed this in training
    classes – and leads to unnecessarily initializing and passing around
    the unused fields in the Domain objects.

    It would be better to add a smaller object – e.g., Length<>, equivalent
    to Index<> – that contains only the length values, and to redefine
    these interfaces in terms of it. Implementations can continue to
    support the Domain<> versions of the interfaces for backwards compatibility.

    In most of these cases where N is fixed, it would also be an even
    clearer (and unambiguous) interface to simply accept N length values as
    integer arguments, and I suggest that those interfaces should be added
    as well. We already effectively have them for the N=1 case because of
    the implicit Domain<1>(int) constructor.

  • Reported: VSIPL++ 1.2 — Tue, 23 Oct 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Block decrement_count() is problematic in some cases

  • Key: VSIPL16-21
  • Legacy Issue Number: 18219
  • Status: open  
  • Source: dpdx.net ( Brooks Moses)
  • Summary:

    The effects of the decrement_count() accessor for blocks are described
    as "Decrease the object’s use count. If the count becomes zero, the
    block deallocates itself."

    This is not always possible. Consider, for instance, this simple code:

    Dense<...> block(...);
    block.decrement_count();

    Since block is created on the stack, it cannot deallocate itself.

    Similar issues will occur with blocks created using placement-new into
    existing allocated memory.

    At minimum, this should be addressed by a clause stating that the
    object's use-count shall not be decremented to zero (or allowed to
    become decremented to zero) except for blocks that have been created
    using "new".

  • Reported: VSIPL++ 1.2 — Tue, 23 Oct 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Block reference-counting only described in Dense

  • Key: VSIPL16-24
  • Legacy Issue Number: 18224
  • Status: open  
  • Source: dpdx.net ( Brooks Moses)
  • Summary:

    It is clear from the existence of the increment_count and
    decrement_count functions in the block requirements that the expectation
    is that the reference-counting should apply to all VSIPL++ blocks.

    However, there is no text at all that states this, aside from those two
    function signatures.

    There is no definition of "use count" anywhere. (See also my previous
    issue noting that we need to explicitly state that the block constructor
    initializes it to one.)

    The only definition of the increment_count and decrement_count is in the
    section describing the Dense block, although those definitions ought to
    apply to all blocks.

    This needs to be rearranged.

  • Reported: VSIPL++ 1.2 — Tue, 23 Oct 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

wrong type specifiier for SVD output vector

  • Key: VSIPL16-1
  • Legacy Issue Number: 19695
  • Status: open  
  • Source: Mentor Graphics Corporation ( Stefan Seefeld)
  • Summary:

    The specification for the SVD API is parametrized for the value-types to support real / complex single-precision / double-precision values.

    However, the "decompose" method incorrectly requires the vector of singular values to use single-precision value-types only.

  • Reported: VSIPL++ 1.3 — Fri, 19 Dec 2014 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

VSIPL++ spec references nonexistent complex types

  • Key: VSIPL16-8
  • Legacy Issue Number: 18203
  • Status: open  
  • Source: dpdx.net ( Brooks Moses)
  • Summary:

    The specification defines complex_i as "The implementation shall define
    this type to be complex<short>, complex<int>, or complex<long int> such
    that the choice of underlying type is the same as scalar_i."

    This is problematic, because the C++ spec states that complex<T> is not
    necessarily defined when T is not float or double. In practice, GCC
    provides only incomplete definitions for the int/short/long cases.

    Since cscalar_i is only used in a very few places, I suggest that it
    should simply be removed from the spec.

    (The changelog in the back of the document mentions a change related to
    this, but the actual text does not appear to be changed.)

  • Reported: VSIPL++ 1.2 — Tue, 23 Oct 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

maxmg etc. of complex should return real values

  • Key: VSIPL16-7
  • Legacy Issue Number: 18202
  • Status: open  
  • Source: dpdx.net ( Brooks Moses)
  • Summary:

    The mag() and magsq() elementwise functions are defined to return real
    views from complex views, as one would expect.

    However, the maxmg, maxmgsq, minmg, and minmgsq reduction functions –
    which ought to be simply the maximum/minimum of the mag and magsq
    results, are defined to return complex values. They should likewise
    return real values.

    (Note that the Mentor Graphics implementation already does return real
    values from these functions. The change is unlikely to break user code
    in any case; if the user assigns the result to a complex variable, that
    will still work when the functions return real values.)

  • Reported: VSIPL++ 1.2 — Tue, 23 Oct 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

cmplx function is misplaced

  • Key: VSIPL16-5
  • Legacy Issue Number: 18199
  • Status: open  
  • Source: dpdx.net ( Brooks Moses)
  • Summary:

    The cmplx() function is placed at the end of section 10.3.5, which is
    otherwise about "Scalar functions and their element-wise extensions" –
    but cmplx() is defined only as an element-wise function, not as a scalar
    function. It does not belong in this section.

    In addition, the return value is given as "The element-wise extension of
    the complex(T1, T2) constructor to views." This is not the return value
    – it returns a view, not a constructor! This should be clarified.

  • Reported: VSIPL++ 1.2 — Tue, 23 Oct 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

scatter, gather declarations should use const_View in place of View

  • Key: VSIPL16-4
  • Legacy Issue Number: 18197
  • Status: open  
  • Source: dpdx.net ( Brooks Moses)
  • Summary:

    The gather() and scatter() functions use an "Index<View<T,
    Block0>::dim>" template to describe the dimension of the Indices that
    they accept. However, "View" is not defined anywhere; the actual
    input/output type is given as "const_View".

    Thus, this should be changed to "Index<const_View<T, Block0>::dim>".

  • Reported: VSIPL++ 1.2 — Tue, 23 Oct 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Conv. 'kernel_size()' incorrect for symmetric kernels

  • Key: VSIPL16-9
  • Legacy Issue Number: 18204
  • Status: open  
  • Source: dpdx.net ( Brooks Moses)
  • Summary:

    Copied from an internal bug report:

    PROBLEM: Convolution accessor 'kernel_size()' is defined to return the
    domain having the same length for each dimension as 'filter_coeffs'.
    However, when constructing a convolution with a symmetric kernel
    (sym_even_len_odd or sym_even_len_even), 'filter_coeffs' only holds
    a subset of coefficients. In those cases, the true kernel size is
    larder (For example, in 1D convolutions the true size will either '2 *
    filter_coeffs.size()' or '2 * filter_coeff.size() + 1').

    In contrast, the C-VSIPL spec defines the kernel size as M, and
    specifies the size of 'filter_coeffs' as either M if symmetry =
    non_sym, or 'floor(M/2)' if 'symmetry == sym_even_len_

    {odd,even}

    '.
    Queries to return the kernel size of a convolution return M.

    PROPOSED FIX: Change wording of 'kernel_size()' accessor (and
    Convolution constructor effects) to indicate correct kernel size.

    TODO: Review specification of Correlation, FIR, and IIR for similar
    error.

  • Reported: VSIPL++ 1.2 — Tue, 23 Oct 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

VSIPL and VSIPL++ should define version macros

  • Key: VSIPL16-2
  • Legacy Issue Number: 18188
  • Status: open  
  • Source: dpdx.net ( Brooks Moses)
  • Summary:

    The VSIPL++ (and VSIPL) standards should define version macros, so that application code can be conditionalized on what version of the library they are being compiled with.

    This should be done with numeric macros (i.e., VSIP_VERSION=1 and VSIP_VERSION_MINOR=2) to enable numeric comparisons.

    In addition, there should be separate macros for VSIPL and VSIPL+, and either there should be separate version macros for VSIPL+ and Parallel VSIPL+, or there should be a macro ("VSIP_PARALLEL"?) to indicate whether the Parallel VSIPL+ pieces are supported.

  • Reported: VSIPL++ 1.2 — Fri, 19 Oct 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

scatter, gather should support multidimensional index views

  • Key: VSIPL16-3
  • Legacy Issue Number: 18196
  • Status: open  
  • Source: dpdx.net ( Brooks Moses)
  • Summary:

    The gather() and scatter() functions, as defined, are capable of
    gathering from or scattering to multidimensional arrays, by virtue of
    supporting multidimensional Index variables.

    However, they cannot gather to or scatter from multidimensional
    arrays, because they explicitly specify only Vectors of Index variables.
    The extension to Matrices and Tensors of Index variables, with
    corresponding-type gather() output and scatter() input, is obvious and
    should be included.

  • Reported: VSIPL++ 1.2 — Tue, 23 Oct 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

cscalar_i is required inconsistently

  • Key: VSIPL16-6
  • Legacy Issue Number: 18201
  • Status: open  
  • Source: dpdx.net ( Brooks Moses)
  • Summary:

    There are only two functions in the entire VSIPL++ API that are required
    to support computations on cscalar_i values: sumval and cumsum. This
    seems quite inconsistent, and those requirements should probably be
    removed for consistency.

    (See also previous issue about removing cscalar_i entirely. The only
    other uses of it are in view constructors, gather, and scatter.)

  • Reported: VSIPL++ 1.2 — Tue, 23 Oct 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Sort function

  • Key: VSIPL16-31
  • Legacy Issue Number: 18575
  • Status: open  
  • Source: Anonymous
  • Summary:

    I don't think that Sort is defined the best way in VSIPL.
    Why spec doesn't define create function? Such function will let user to
    allocate additional memory which are required by some sorting methods.
    Why not to define out-of-place sort?
    If I work on 64-bit system, sort array of 32-bit FP values and need index
    vector, I'll get 64-bit indices which are not supposed to be that long.
    This is because last argument of sort function is
    const vsip_vview_vi *index and

    _vi means (unsigned long int) i.e. 64-bit elements.
    In the sort I implemented for AVX I permute data in vector registers and
    apply same permute to the indices which occupy other vector register.
    It's OK if function has to produce 32-bit indices, but it will be wrong
    when I have to shuffle 64-bit values.

    This last comment is applicable to other functions as well - index vector
    on 64-bit systems doesn't have to be 64-bit value because data arrays
    today are not huge yet.

  • Reported: VSIPL 1.4 — Mon, 25 Mar 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Note on Deferred memory allocation

  • Key: VSIPL16-26
  • Legacy Issue Number: 18259
  • Status: open  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    p48 says "Note to Implementors: memory allocation shall not be deferred." Why not? This is clearly an oblique reference to some unspoken semantics of the interface that isn't documented, and perhaps should be.

  • Reported: VSIPL++ 1.2 — Tue, 13 Nov 2012 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Vector destructor should call decrement_count

  • Key: VSIPL16-25
  • Legacy Issue Number: 18225
  • Status: open  
  • Source: dpdx.net ( Brooks Moses)
  • Summary:

    The ~Vector() destructor function is described as "If this object is the
    only one using its block, the block is deleted. Otherwise, its block's
    use count is decremented by one."

    This is a redundant description of the decrement_block functionality,
    and further spreads the description of the block reference-counting
    throughout the standard.

    It would be much better to either (a) explicitly state that "This calls
    the block's decrement_count accessor, which may deallocate the block."

    Or, if we do not want to constrain the implementation to literally call
    the block method, we can alternately add a paragraph to the block
    requirements section describing increment-count and decrement-count
    functionality in general (with the increment_count and decrement_count
    functions being interfaces to it), and the ~Vector description should
    refer to that.

  • Reported: VSIPL++ 1.2 — Tue, 23 Oct 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Distinction between "Restrictions" and "Errors" is unclear

  • Key: VSIPL16-28
  • Legacy Issue Number: 18381
  • Status: open  
  • Source: Mentor Graphics Corporation ( Stefan Seefeld)
  • Summary:

    Throughout the document functions are defined with formal sections for "Restrictions" and "Errors".
    It isn't clear what the purpose of these two items is. In particular, "Errors" should actually spell out what errors (if any) the given function may generate. What it actually does, however, is specify conditions for the function arguments. These really belong into the "Restrictions" section

  • Reported: VSIPL 1.4 — Tue, 22 Jan 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Notes to implementors

  • Key: VSIPL16-27
  • Legacy Issue Number: 18261
  • Status: open  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    There are several oblique references to hidden interface semantics in "Notes to implementors", particularly the expectation that a development mode should keep reference counts on various data structures. However, since providing a development mode is not mandatory, this cannot be a normative part of the specification. This could be made clearer.

  • Reported: VSIPL++ 1.2 — Tue, 13 Nov 2012 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Review entire document for typos

  • Key: VSIPL16-30
  • Legacy Issue Number: 18383
  • Status: open  
  • Source: Mentor Graphics Corporation ( Stefan Seefeld)
  • Summary:

    While working on the translation to DocBook I noticed lots of small typos ("matrix" instead of "vector", "2d" instead of "1d", references to non-existing functions in "see also" sections, etc.)
    While these may all be obvious, i.e. not require any discussion or even semantic changes to the spec, the document needs a careful review to correct these.

  • Reported: VSIPL 1.4 — Tue, 22 Jan 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Implementation Dependent Input and Output should become optional

  • Key: VSIPL16-29
  • Legacy Issue Number: 18382
  • Status: open  
  • Source: Mentor Graphics Corporation ( Stefan Seefeld)
  • Summary:

    VSIPL and VSIPL++ both provide APIs to serialize certain objects. The VSIPL++ API supports serialization of blocks, while the VSIPL API supports serialization of function objects.

    The API for both should be unified and made optional (a "profile"), as it is orthogonal to the rest of the spec.

  • Reported: VSIPL 1.4 — Tue, 22 Jan 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT