Recently I started using Armadillo C++ library. Given my C++ coding skills are not that great, I found this very friendly for linear algebra. I am also using that along with my matlab to speed things up for many of reconstruction algorithm.
I do need to create a vector of boolean and I would prefer using this library rather than . However, I could not figure out how to do it. I tried using uvec; but, documentation seems to indicate that it can not be used with boolean.
Any help would be appreciated.
Regards,
Dushyant
Consider using a matrix uchar_mat which is a typdef for Mat<unsigned char>, it should consume the same amount of memory as a matrix of boolean values.
The Armadillo documentation of version 7.8 states that a matrix Mat<type>, can be of the following types:
float, double, std::complex<float>, std::complex<double>, short, int, long, and unsigned versions of short, int, and long. The code on GitHub however contains typedef Mat <unsigned char> uchar_mat; in the file include/armadillo_bits/typedef_mat.hpp so you should also be able to use uchar_mat.
You will not save any memory by creating a matrix of bool values compared to a matrix of unsigned char values (a bool type consumes 8 bits). This is because in C++ every data type must be addressable; it must be at least 1 byte long so that it is possible to create a pointer pointing to it.
Related
I will need 64 bits integer in my package in a close future. I'm studying the feasibility based on the bit64 package. Basically I plan to have one or more columns in a data.table with an interger64 S3 class and I plan to pass this table to C++ functions using Rcpp.
The following nanotime example from Rcpp gallery explains clearly how a vector of 64 bits int is built upon a vector of double and explain how to create an integer64 object from C++ to R.
I'm now wondering how to deal with an interger64 from R to C++. I guess I can invert the principle.
void useInt64(NumericVector v)
{
double len = v.size();
std::vector<int64_t> n(len);
// transfers values 'keeping bits' but changing type
// using reinterpret_cast would get us a warning
std::memcpy(&(n[0]), &(v[0]), len * sizeof(double));
// use n in further computations
}
Is that correct? Is there another way to do that? Can we use a wrapper as<std::vector<int64_t>>(v)? For this last question I guess the conversion is not based on a bit to bit copy.
I'm trying to pass a three-dimensional data structure to Stan (in RStan) where the entries must be integers, because a function down-stream requires that. However I'm having trouble declaring it.
I tried the straight-forward approach:
int x[n,n,k];
But that gave me the error
mismatch in number dimensions declared and found in context; ... dims declared=(n,n,k); dims found=(n*n*k)
meaning, clearly, the input array is getting flattened, for some reason (that I don't understand). I'm giving it a simple 3d array, no NAs, the dimensions look right before I pass it. And in fact, the same things is happening for 2d arrays, as well, meaning I can't even declare a set of 2d matrices, as a workaround.
Then I tried
row_vector[K] x[N,N];
but that gives back real, not int. And when I do something like
int row_vector[K] x[N,N];
that's just not proper syntax.
I also tried passing logical values, hoping they'd be re-cast as ints, but no. I passed arrays, I passed them cast with as.matrix, I checked their dimension both before and after being put into the data list.
This is with R version 3.4.1 on OSX 10.11.6, using the most recent version of stan, that was just compiled from source, today.
What am I missing? OR, how might I cast a single real to an integer, so that the integer-requiring function doesn't break?
(And, WHERE is the documentation? The best I can find is long-dead comment threads.)
How can I convert a Julia Int/Bool Array/Vector to a Fortran LOGICAL array for use within Julia's ccall?
I tried passing it as Array{Bool} in https://gist.github.com/axsk/28f297e2207365a7f4e8/, but the code is not working correctly and I am quite confident the problem is the Bool-Logical conversion.
I don't know too much about calling Fortran code, but according to this
The Fortran standard does not specify how variables of LOGICAL type
are represented, beyond requiring that LOGICAL variables of default
kind have the same storage size as default INTEGER and REAL variables.
The GNU Fortran internal representation is as follows.
A LOGICAL(KIND=N) variable is represented as an INTEGER(KIND=N)
variable, however, with only two permissible values: 1 for .TRUE. and
0 for .FALSE.. Any other integer value results in undefined behavior.
So I'd do something like the following
julia_array = rand(Bool, 1:10)
fort_array = Int[x?1:0 for x in julia_array]
Then use fort_array as the input. Which Fortran compiler are you using?
EDIT: It turns out the Julia developers already define a type that will work with the linked BLAS/LAPACK, Base.BLAS.BlasInt, that will use the correct Int variant for the system.
As iaindunning posted before, Fortran represents Logical variables as Integers.
Unfortunately the representation of the type Integer varies from platform to platform.
While I had success using Int on Windows and Cint on Linux/MacOS, in the end I used BlasInt, which adopts depending on the platform.
I am doing some image processing on an embedded system (BeagleBone Black) using OpenCV and need to write some code to take advantage of NEON optimization. Specifically, I would like to write a NEON optimized thresholding function and then a NEON optimized erosion/dilation function.
This is my first time writing NEON code and I don't have experience writing assmbly code, so I have been looking at examples and resources for the C-style NEON intrinsics. I believe that I can put some working code together, but am not sure how I should structure the vectors. According to page 2 of the "ARM NEON support in the ARM compiler" white paper:
"These registers can hold "vectors" of items which are 8, 16, 32 or 64
bits. The traditional advice when optimizing or porting algorithms
written in C/C++ is to use the natural type of the machine for data
handling (in the case of ARM 32 bits). The unwanted bits can then be
discarded by casting and/or shifting before storing to memory."
What exactly does this mean? Do I need to to restrict my NEON code to using uint32x4_t vectors rather than uint8x16_t? How would I go about loading the registers? Or does this mean than I need to take some special steps when using vst1q_u8 to store the data to memory?
I did find this example, which is untested but uses the uint8x16_t type. Does it adhere to the "32-bit" advice given above?
I would really appreciate it if someone could please elaborate on the above quotation and maybe provide a very simple working example.
The next sentence from the document you linked gives your answer.
The ability of NEON to specify the data width in the instruction and
hence use the whole register width for useful information means
keeping the natural type for the algorithm is both possible and
preferable.
Note, the document is distinguishing between the natural type of the machine (32-bit) and the natural type of the algorithm (in your case uint8_t).
The document is saying that in the past you would have written your code in such a way that it used 32-bit integers so that it could use the efficient machine instructions suited for 32-bit operations.
With Neon, this is not necessary. It is more useful to use the data type you actually want to use, as Neon can efficiently operate on those data types.
It will depend on your algorithm as to the optimal choice of register width (uint8x8_t or uint8x16_t).
To give a simple example of using the Neon intrinsics to add two sets of uint8_t:
#include <arm_neon.h>
void
foo (uint8_t a, uint8_t *b, uint8_t *c)
{
uint8x16_t t1 = vld1q_u8 (a);
uint8x16_t t2 = vld1q_u8 (b);
uint8x16_t t3 = vaddq_u8 (a, b);
vst1q_u8 (c, t3);
}
My team has been given HDF5 files to read. They contain structured data with unsigned variables. I and my team were overjoyed to find the NetCDF library, which allows pure-Java reading of HDF5 files, albeit using the NetCDF data model.
No problem---we thought we'd just translate from the NetCDF data model to whatever model we wanted. As long as we get the data out. Then we tried to read an unsigned 32-bit integer from the HDF5 file. We can load up HDFView 2.9 and see that the variable is an unsigned 32-bit integer. But... it turns out that NetCDF-3 doesn't support unsigned values!
To add insult to injury, NetCDF-3 recommends that you "widen the data type" or use an _Unsigned = "true" attribute (I am not making this up) to indicate that the 32 bits should be treated as an unsigned value.
Well, maybe those kludges would be effective if I were creating NetCDF data from scratch, but how can I detect using NetCDF that a 32-bit value in an existing HDF5 file should be interpreted as unsigned?
Update: Apparently NetCDF-4 does support unsigned data types. So this begs the question: How can I determine whether a value is signed or unsigned from the NetCDF Java library?" I don't see any unsigned types in ucar.ma2.DataType.
Yes, you can look for _Unsigned = "true" attribute, or you can call Variable.isUnsigned().
Because Java doesnt support unsigned types, it was a difficult design decision. Ultimately we decided not to automatically widen the type, for efficiency. So the application must check and do the right thing. Look at ucar.nc2.DataType.unsignedXXX() helper methods.
When you read the data, you get an Array object. you can call Array.isUnsigned(). Also the extractors like Array.getDouble() will convert correctly.
The netCDF-Java library supports an extended data model called the "Common data Model" to abstract out differences in file formats. So we are not stuck with the limits of the netCDF-3 file format or data model. But we are in Java
John
Given the fact that Java doesnt have unsigned types, I think the only options are to 1) automatically widen unsigned data (turn bytes into shorts, shorts into ins, ints into longs), or 2) represent both signed and unsigned integers with the available Java data types, and let the user decide if/when it should be widened.
Arguably the main use for unsigned data is to represent bits, and in that case conversion would be a waste, since you will just mask and test the bits.
The other main use is for eg satellite data which often uses unsigned bytes, and there again I think not automatically widening is the right choice. What you end up doing is just widening right at the point you use it.
It seems that when the CDM data types are mapped to Java, NetCDF will automatically add the attribute _Unsigned = "true" to the variable. So I assume that if I check for that attribute, it will indicate if the value is unsigned or not. This may be exactly what I was looking for; I'll verify tomorrow that it works.
Update: I tried this and it works; moreover, as John Caron indicated in the accepted answer, a NetCDF array has an isUnsigned() method which checks for the _Unsigned attribute.