I have a program that runs through R but uses the BLAS routines. It runs through correctly about 8 times but then throws an error:
BLAS/LAPACK routine 'DGEMV ' gave error code -6
What does this error code mean?
R defines the XERBLA function as
void F77_NAME(xerbla)(const char *srname, int *info)
{
/* srname is not null-terminated. It should be 6 characters. */
char buf[7];
strncpy(buf, srname, 6);
buf[6] = '\0';
error(_("BLAS/LAPACK routine '%6s' gave error code %d"), buf, -(*info));
}
from the src/main/print.c file.
the Netlib version of dgemv.f shows that only the input parameters are checked. A code of 6 shows a problem with either the LDA or M parameter.
*...
ELSE IF (LDA.LT.MAX(1,M)) THEN
INFO = 6
*...
END IF
IF (INFO.NE.0) THEN
CALL XERBLA('DGEMV ',INFO)
RETURN
So it appears that R takes the negative of the BLAS error code, which I think causes lots of confusion. I think this answers my question but not my problem, since it works several times with the same parameters before the error is thrown.
DGEMV does not return any error codes.
This bug implies that the error is coming from R itself.
Perhaps you should file a bug against R.
Related
I am trying t execute ada multi program using batch file but I am getting this errors:
_d_dtof
_d_dmul
For the below line:
long float := long float (int) * long float;
I think he mean to say for variables only for example
long float : a, b, c;
integer : x;
NOW...
a := b(x) * c;
even I got the same errors for that line but the difference is when using IDE (Ada multi 7.2.4 tool) I did not got any errors, but same code when I used using command promt I got errors. Which means a run time library is unable to link those errors.
I got the below errors...
_d_dtof
_d_add
_d_div
_d_ftod
_d_sub
_d_itod
_d_utod
_d_dtou
and the code is in Ada language.
I'm using a variable that is using too large symbol/string in Scilab, which is giving following error:
Too large string. at line 44 of exec file called by :
exec('/proj/shubhamj/shubhamj/scilab/final_add_from_script.sce', -1)
I've already used stacksize('max').
According to this thread on the mailing list for Scilab the error comes from the length of the command. You can get the same error without the exec() if you call a command that is too long even in your current script (where the exec() call currently is).
If we look at the documentation the default stacksize is approx. 76MB (megabytes) and that is a lot of characters which makes this issue 99.9% not related to the size of the stack.
I apologize that I can not tell you what these functions are form the start.
I have a function CheckOutCell. It takes one argument and that is the number 764. So every time I run the function it looks like this in it's entirety: CheckOutCell(764).
Now many times the function will give me an error:
Error in checkInCell(764) :
The function is currently locked; try again in a minute.
Which is a custom error message and the details are not important to this question.
Now this function could be locked from anywhere from 30 seconds to an hour. I want to be able to automatically run CheckOutCell(764) till it goes through, and then stop running it. That is, run it till I do not get an error, then stop.
I think a start would be using
while(capture.output(checkInCell(764)) == "Error in checkInCell(764) :
The function is currently locked; try again in a minute."){
do something}
However this just produces
Error in checkInCell(764) :
The function is currently locked; try again in a minute.
because the function is still locked, so no output can be captured.
How would I test for while(error = T)
Assume the source code of the function cannot be modified.
Even is.error(CheckInCell(764)) will just produce the same error message
So it seems that this code works in a way
wrapcheck <- function(x){
repeatCheck =tryCatch(checkOutCell(764),
error = function(cond)"skip")
SudoCheck = ifelse(repeatCheck=="skip",repeatCheck, checkOutCell(764))
while(SudoCheck == "skip"){
repeatCheck
}
}
wrapcheck(764)
Basically this checks for an error and then keeps running the function till the error is not produced. In fact I am fairly confident that this would work with any funciton you wanted to put in place of CheckOutCell.
The main problem is that when the function is locked, that it not really an error, it is locked. Therefore this above block will not work. This above block will work when errors other than a lock are produced.
I'm trying to get started with OpenCL but came across weird behavior of the OpenCL compiler with respect to white-space and can't seem to find any documentation about that.
C-style single-line comments (// foo) immediately cause a meaningless build error: At end of source: error: expected a "}". Multi-line comments (/* bar */) seem to work fine.
Line breaks seem to get stripped without adding whitespace which can cause errors. This example will not compile because of that:
__kernel
void TestKernel() {}
line 1: error: identifier "__kernelvoid" is undefined
This may totally depend on my machine and/or configuration but can somebody confirm that these things should not be this way?
I am using OpenCL via Cloo from .net/C#. The driver is from AMD OpenCL 2.0 AMD-APP (1642.5)
I think I figured it out. I was doing this:
var program = new ComputeProgram(context, File.ReadAllLines(filename));
File.ReadAllLines() returns an array of strings without the line-break characters which is the root of the errors I was getting.
Using File.ReadAllTest() instead fixed all the problems:
var program = new ComputeProgram(context, File.ReadAllText(filename));
But in my opinion some of the blame goes to either Cloo or the OpenCL API for accepting a string array but just concatenating it together..
I have a bizarre one here with the serial output when trying to write some code for my Arduino Uno.
I have this proto-code:
MyClass myclass;
void setup()
{
Serial.Begin(9600);
Serial.println("Starting...");
}
void loop()
{
int status = myclass.DoWork();
Serial.println("Status: " + status);
}
class MyClass
{
int DoWork()
{
Serial.println("Doing some work...");
return 1;
}
}
Now when this runs I get the following output:
Starting...
Doing some work...
atus: 1
So the strange part is the "Status: 1" missing the first few characters. Is this because I am using serial in an object improperly or something?
I have noticed when I reference another library that also uses serial like MyClass does that I get other strange output behavior... so I assume that I am doing something wrong.
EDIT: In the end this turned out to actually be a memory issue. A library I was including was quite large and it was consuming the available memory. I found this by adding a few more debugging statements and found the corruption shifted around based on the string lengths and positions. By using the F() function I moved the strings to flash memory (e.g. I now run Serial.println(F("Starting...")); and it has corrected the strange output.
You cannot add strings and integers in C++. It would have been better for you if this failed to compile:
Serial.println("Status: " + status);
Instead the compiler guessed at something. It guessed wrong. Use this:
Serial.print("Status :");
Serial.println(status);
or for complete control of outputting numbers and strings learn to use C string formatting, sprintf()
In the end this turned out to actually be a memory issue. A library I was including was quite large and it was consuming the available memory. I found this by adding a few more debugging statements and found the corruption shifted around based on the string lengths and positions. By using the F() function I moved the strings to flash memory (e.g. I now run Serial.println(F("Starting...")); and it has corrected the strange output.
One more possible explanation.
I was running minicom to monitor, and I usually like that it auto-reconnects after resetting my device.
Well I minimized a terminal running minicom last night, and today I started a new instance that somehow also got connected to the same serial port (if that is even possible).
I think the two instances of minicom were each reading ~50% of the serial characters roughly at random, leaving me with quite a mess of text.