VSIPL++ Avatar
  1. OMG Specification

VSIPL++ — Closed Issues

  • Acronym: VSIPL++
  • Issues Count: 14
  • Description: Issues resolved by a task force and approved by Board
Open Closed All
Issues resolved by a task force and approved by Board

Issues Descriptions

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

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