I am submitting an R package to biocondutor, which contains some RcppArmadillo codes. I got some complaints from one platform for the operation between uword and int. In the following, drop_bin(0) is uword and bin_number is an integer. This error happens when I compare the uword with integer. However I don't see errors when I run it in my mac osx at all. Is there any way to get around it? Thanks.
degnormCPP.cpp: In function 'arma::uvec bin_drop(int, int, arma::rowvec)':
degnormCPP.cpp:27:18: warning: comparison of integer expressions of different signedness: 'unsigned int' and 'int' [-Wsign-compare]
if (drop_bin(0)==bin_number-1){...}
~~~~~~~~~~~^~~~~~~~~~~~~~
degnormCPP.cpp: In function 'Rcpp::List optiNMFCPP(arma::mat, arma::vec, int)':
I guess I found the answer by cast.
if ((int) drop_bin(0)==bin_number-1){...}
bioconductor seems not complaining anymore
Related
I am attempting to broadcast the log function in a script I am writing.
It is throwing a domain error
julia> log(100)
4.605170185988092
julia> log(-100)
ERROR: DomainError:
Is there a way around this at all? I have a mix of - , + in my array.
For real input the log function returns real numbers. If the log function were to promote the type of log(-100) automatically (to complex numbers) it would be type unstable.
You can do log(complex(-100)) to get complex output (or log.(complex.(array)) for your array of numbers).
I have a problem assigning a pointer to a structure, to a pointer to a structure.
I use gfortran 4.6.3, and the name of the file is test_pointer_struct.f08 so I am using the Fortran 2008 standard (as supported by gfortran 4.6.3).
Hera comes the code:
PROGRAM test_pointer_struct
type tSmall
integer :: a
double precision :: b
end type tSmall
type tBig
integer :: h
type(tSmall), pointer :: member_small
end type tBig
type(tBig) :: var_big
type(tSmall), pointer :: var_small(:)
! We get an array of pointers to the small structure
allocate(var_small(3))
! Also allocate the member_small strucutre (not an array)
allocate(var_big%member_small)
var_big%member_small%a = 1
var_big%member_small%b = 2.0
! Now we want an element of the var_samall array of pointers, to point to the member_small in member_big
var_small(1) => var_big%member_small ! <- I get a compilation error here
! And dissasociate the member_small (we still maintain access to memory space through var_small(1)
var_big%member_small => NULL()
END PROGRAM test_pointer_struct
When I complie this, I get the following error:
Error: Se esperaba una especificación de límites para 'var_small' en (1)
Which could be translated as
Error: Limit specification expected for 'var_small' at (1)
What does this error mean?. What am I doing wrong?
Thank you very much in advance.
Fortran doesn't really do arrays of pointers. Your declaration
type(tSmall), pointer :: var_small(:)
doesn't define var_small to be an array of pointers to things of type tsmall; rather it defines it to be a pointer to an array of things of type tsmall.
When I compile your code Intel Fortran gives the rather more helpful error message
The syntax of this data pointer assignment is incorrect: either 'bound
spec' or 'bound remapping' is expected in this context.
which takes us to R735 in the Fortran 2003 standard. The compiler tries to parse var_small(1) not, as you wish, as a reference to the first element in an array of pointers but to either a bounds-spec-list or a bounds-remapping-list. The expression does not have the right syntax for either and the parse fails.
So that deals with the question of what the error means. What do you do about it ? That depends on your intentions. The usual suggestion is to define a derived type, along these lines
type myptr
type(tsmall), pointer :: psmall
end type myptr
and then use an array of those
type(myptr), dimension(:), allocatable :: ptrarray
Personally I've never liked that approach and have never needed to use it (I write very simple programs). I expect that with Fortran 2003 there are better approaches too but without knowing your intentions I hesitate to offer advice.
I encountered a problem which I've solved, but why the solution works doesnt make sense to me
I had a function similar to this one
function testB(a::Array{AbstractString})
println(a)
end
running it like so gave me
testB(convert(Array{UTF8String},["a","b"]))
ERROR: MethodError: `testB` has no method matching
testB(::Array{UTF8String,1})
Note that Im not manually converting to UTF8 in reality, its for demonstration, in reality I have an AbstractString array, but when I fetch elements from it, they become UFT8
My solution reads in short
function testA{T <: AbstractString}(a::Array{T})
println(a)
end
running this method gives
testA(convert(Array{UTF8String},["a","b"]))
UTF8String["a","b"]
Can anyone tell me why testA works but testB doesnt?
Also, is there a name for this {T <: SomeDataType} notation?
While UTF8String is a subtype of AbstractString, Array{UTF8String} is not a subtype of Array{AbstractString} (no covariance). Hence your testB does not work. (But testB(convert(Array{AbstractString},["a","b"])) should work.)
Rationale for why it has to be like this: a function f(x::Vector{AbstractString}) could e.g. push! a new FooString into x (assuming FooString is a subtype of AbstractString). Now if x was in fact a Vector{UTF8String}, that would fail.
I am trying to use vectors in my OpenCL code. Prior to this, I was mapping the memory to and fro as
cmDevSrc= clCreateBuffer(cxGPUContext,CL_MEM_READ_WRITE,sizeof(cl_char) * (row_info->width) * bpp,NULL,&ciErr);
cmDevDest=clCreateBuffer(cxGPUContext,CL_MEM_READ_WRITE,sizeof(cl_char) * (row_info->width) * bpp,NULL,&ciErr);
I am using cmDevSrc as my source array of unsigned chars and cmdDevDest as for destination.
When I am trying to implement the same using vectors, I am passing the kernel argument as
clSetKernelArg(ckKernel,1,sizeof(cl_uchar4 )*row_info->rowbytes*bpp,&cmDevDest);
with cmDevDest being cl_uchar4 cmDevDest.
But now, I cannot read back my data using mapping , with the following error,
incompatible type for argument 2 of ‘clEnqueueMapBuffer’
/usr/include/CL/cl.h:1066: note: expected ‘cl_mem’ but argument is of type ‘cl_uchar4’
I don't know any other method for this compile time error at this time and I am searching net but any help will very helpful.
Thanks
Piyush
The clCreateBuffer function returns a cl_mem object, not a cl_uchar4 (or anything else), so cmDevSrc and cmDevDest should be declared as cl_mem variables. This is also what is causing the compiler error for your call to clEnqueueMapBuffer.
Additionally, the arg_size argument of clSetKernelArg should be sizeof(cl_mem) when you are passing memory object arguments, not the size of the buffer:
clSetKernelArg(ckKernel, 1, sizeof(cl_mem), &cmDevDest);
This is regarding compile time argument in openCL.
I have an array of constants of fixed size, and I am passing it as compile-time argument, as follows:
-DCOEFF=0.1f,0.2f,0.5f,0.2f,0.1f
And in the Kernel, I am reading it as,
__kernel void Smoothing(__global const float *in, __global float *out)
{
float chnWeight[] = {COEFF};
}
This way, using intel-SDK, I am getting a considerable amount of performance benefit, compared to passing the Coefficients as another argument to the kernel.
The problem is in AMD, this is not getting compiled. I am getting the following error :
0.2f:
Catastrophic error: cannot open source file "0.2f"
1 catastrophic error detected in the compilation of "0.2f".
Compilation terminated.
I understand that in AMD (comma) is also taken as a separating character for the compile time arguments, and this is causing the error.
Any help to solve this problem will be appreciated. Thanks in advance.
This problem was introduced into AMD OpenCL sometime between versions 937.2 and 1268.1. Here is a work-around:
Replace,
-DCOEFF=0.1f,0.2f,0.5f,0.2f,0.1f
with
-D COEFF=0.1f,0.2f,0.5f,0.2f,0.1f
Try quoting the string to -DCOEFF="0.1f,0.2f,0.5f,0.2f,0.1f"
It looks that the compiler is looking for the file "0.2f" and that is the second element, so after the first element and comma the compiler has already stopped interpreting the input as part of the COEFF define.