You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To handle matrix sizes directly without extra parameters and with good backwards compatibility, cnt: PAPISize will be adjusted.
Before v0.10, this was a pointer to a single element.
For v0.10, we added a second element used as the capacity of the current buffer, reducing allocations.
For v0.12.1, we can add 2 more elements to represent the matrix shape (num rows, num cols). To keep compatibility, we can add a flag to avoid accessing those elements in DSS C-API. If the flag is not set, we fill the expected matrix shape.
Here, we will have to review the CAPI_* files to pass the matrix shape to the reallocation functions. As a bonus, these files can then be post-processed to extract some information for dss-extensions/dss-extensions#6. The new Obj_* functions could be handled too, if it's not too much work.
On the other projects, support can be added by toggling the behavior and checking the values returned. For the end-user, with the new behavior turned off, plain vectors would still be returned, so compatibility is kept. When enabled, if the last element is non-zero, a matrix can be return instead of a vector.
For Python, MATLAB and Julia, I see no obvious issues with this. For C#, we wouldn't support right now since there is no matrix support at the moment. For C++, some template specializations or if constexprs should do the trick.
The main changes would be restricted to the functions that handle the array types. In Python, looks like it would be a single conditional:
defget_float64_array(self, func, *args):
ptr=self.ffi.new('double**')
cnt=self.ffi.new('int32_t[4]') # CFFI zero-inits thisfunc(ptr, cnt, *args)
res=np.frombuffer(self.ffi.buffer(ptr[0], cnt[0] *8), dtype=np.float64).copy()
self.lib.DSS_Dispose_PDouble(ptr)
ifcnt[3] !=0: # if in compat mode, or it's actually a vector, value would be 0returnres.reshape((cnt[2], cnt[3]))
returnresdefget_float64_gr_array(self):
ptr, cnt=self.gr_float64_pointersifcnt[3] !=0: # if in compat mode, or it's actually a vector, value would be 0returnnp.frombuffer(self.ffi.buffer(ptr[0], cnt[0] *8), dtype=np.float64).copy().reshape((cnt[2], cnt[3]))
returnnp.frombuffer(self.ffi.buffer(ptr[0], cnt[0] *8), dtype=np.float64).copy()
Finally, we could consider some way of passing a custom "allocator" function to wrap a few things. For instance, in non-optimized general code, there is still a potential extra copy right now to setup the final container. If we can use a setup function in DSS C-API to init the final container (NumPy array, MATLAB array, Eigen::Matrix<>...), no extra copies would be required. This could be beneficial.
The text was updated successfully, but these errors were encountered:
To handle matrix sizes directly without extra parameters and with good backwards compatibility,
cnt: PAPISize
will be adjusted.Here, we will have to review the
CAPI_*
files to pass the matrix shape to the reallocation functions. As a bonus, these files can then be post-processed to extract some information for dss-extensions/dss-extensions#6. The newObj_*
functions could be handled too, if it's not too much work.On the other projects, support can be added by toggling the behavior and checking the values returned. For the end-user, with the new behavior turned off, plain vectors would still be returned, so compatibility is kept. When enabled, if the last element is non-zero, a matrix can be return instead of a vector.
For Python, MATLAB and Julia, I see no obvious issues with this. For C#, we wouldn't support right now since there is no matrix support at the moment. For C++, some template specializations or
if constexpr
s should do the trick.The main changes would be restricted to the functions that handle the array types. In Python, looks like it would be a single conditional:
Finally, we could consider some way of passing a custom "allocator" function to wrap a few things. For instance, in non-optimized general code, there is still a potential extra copy right now to setup the final container. If we can use a setup function in DSS C-API to init the final container (NumPy array, MATLAB array, Eigen::Matrix<>...), no extra copies would be required. This could be beneficial.
The text was updated successfully, but these errors were encountered: