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:
- renaming function and macro names
- update calls for few functions that changed interface. The interface changes are related to introduction of data types (double, single, int) and to change in memory scheme presented by the custom application to the perClass runtime
- changing the header file and library names in your custom projects
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.
prsd_activate
becomessdactivate
prsd_demo
becomessddemo
prsd_display
becomessddisplay
prsd_feedback
becomessdfeedback
prsd_histid
becomessdhostid
prsdversion
becomessdversion
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:
prsd_GetName
becomessd_GetPipelineName
sd_AttachMemToInput
andsd_AttachMemToOutput
functions take two parameters less and assume different memory ordering of application data buffersd_BufNew
andsd_BufNewReferringTo
requires one new parameter specifying data type (see below). The later function also expects different memory ordering.- to support multiple data types
prsd_BufGetValue
is replaced bysd_BufGetValueDouble
,sd_BufGetValueSingle
andsd_BufGetValueInt
. Analogously forprsd_BufSetValue
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 ↩
- replace prsd.h with perclass.h, update the
#include
statement. - link your application with
perclass
library insted oflibprsd
perclass.dll
for Windows 32-bit and 64-bitperclass.so
for Linux 32-bit and 64-bitperclass.dylib
for Mac OS X 32-bit and 64-bit
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.