SIDL `normal' arrays are implemented in the Babel runtime, with bindings in all Babel supported languages. SIDL normal arrays provided a more flexible array representation, with the ability to directly access the underlying array memory in languages that support this capability (C, C++, F90, and F77). In Python, there are situations where arrays must be copied when passing in and out, but direct access is used wherever the Numerical Python package will allow. In Java, arrays are accessed using the Java Native Interface. More information on SIDL normal arrays appears in the Babel User Guide .
In this exercise, the method addVec uses SIDL normal arrays (sda1, and sda2). The SIDL specification of the addVec method designates sda1 as an input argument, therefore it needs to be created (more specifically, associated with memory) on the caller side before the call is made. The Babel runtime provides array manipulation bindings in Babel supported languages (except Python, which uses NumPy arrays). The one-dimensional, SIDL double array sda1 is created using the following code
sda1 = sidl_double__array_create1d(m);
if (!sda1){
fprintf(stderr, "Error:: %s:%d: Error creating sda1.\n",
__FILE__, __LINE__);
return(-1);
}
The Babel runtime C binding contains macros that allow direct access
to underlying SIDL array memory and properties (dimensions, strides,
etc.), without having to go through the standard
set() and get() methods. One
such macro is used in this example to access the underlying memory of
SIDL array sda1
sda1_data = sidlArrayAddr1(sda1, 0);
for (value =0.0, i = 0; i <= m; i++){
sda1_data[i] = (double) i + 3.0 ;
}
Other macros are used in the loop that prints the result returned in the SIDL out array sda2, after the call to addVec.
printf("Result2 = ");
for ( i = sidlLower(sda2, 0); i <= sidlUpper(sda2, 0); i++){
printf("%.2f ", sidlArrayElem1(sda2,i));
}
printf("\n");
Direct access to underlying SIDL array memory is also available in the
Babel SIDL array binding in F77, F90, and C++. Example of such use is
available in the discussion in Section 6.3.
David E. Bernholdt [bek] 574-3147 2009-08-21