perClass Documentation
version 5.0 (21-sep-2016)

kb20: PRSD Studio to perClass transition

Problem: How can I transition from PRSD Studio to perClass?

Solution: Move to new naming convention for C API and update your code with few API changes.

20.1. Introduction ↩

With 3.0 release, PRSD Studio was renamed to perClass. Due to major upgrade of the execution runtime, the 3.0 release brings some C API changes and interface polishing. Most of the Matlab API remains unchanged so almost all existing 2.x user scripts will keep running. Moving from PRSD Studio 2.x to perClass 3.x is a matter of minutes.

It consists of three steps:

Optionally, get familiar with the new functionality available in the perClass runtime.

As a convention, perclass (small letters) is consistently used everywhere in the programing API and file names. In this way, we avoid ambiguity as some operating systems require, some preserve and others don't preserve the case.

The mixed case perClass is only used as a name of the software in writing.

20.1.1. Renaming function and macro names ↩

In the Matlab toolbox, the functions starting with prsd or prsd_ prefix were renamed using the sd prefix. All renamed functions are only auxiliary providing seldom used functionality like demo examples of license activation. The most of PRSD Studio 2.x user-scripts do not need to be updated to transfer to perClass 3.0. The sd prefix stands for "system design" and is used avoid clashes in Matlab namespace.

In the C API, prsd_ prefixes are replaced by sd_. This includes both function names and macros. For example, prsd_InitKernel becomes sd_InitKernel. Simple search and replace is sufficient.

20.1.2. Update function calls ↩

Quick list:

Detailed explanation:

Memory scheme, assumed by the perClass runtime, was changed to reflect the most common situation where all features of one measurement are stored in memory together. When attaching perClass runtime to application memory, the assumption is that the memory block contains all features of the first sample, then of the second sample etc. In other words, the offset to next feature is 1 and offset to next sample is equal to the number of features.

Therefore, the perClass 3.0 functions attaching the memory to pipeline sd_AttachMemToInput and sd_AttachMemToOutput now require less parameters. Apart of the kernel and pipeline, only the data pointer, sample size and feature size is needed. The two additional parameters, used in PRSD Studio 2.x API, namely the sample and feature offsets are removed. Please note that, strictly speaking, feature size could be also inferred. perClass API requires that user provides both sample and feature size of the application buffer being attached. In this way, the feature size is provided explicitly and potential mismatch with pipeline dimensionality may be easily found.

20.1.3. Update header and library names ↩

20.1.4. New functionality ↩

perClass 3.x pipelines support use of different data types. By default double precision is used for data and integer for decisions. Data type is represented by macros SD_DOUBLE, SD_SINGLE and SD_INT. Input and output data type of a pipeline is returned by the sd_GetInputType and sd_GetOutputType calls, respectively. Data type is also included in the buffer constructor functions sd_BufNew and sd_BufNewReferringTo.

perClass runtime now provides cross-platform implementation of high-precision timers accessible through sd_Tic and sd_Toc functions. sd_Toc returns the time in seconds elapsed from the previous sd_Tic call. The functions cannot be nested.