these are the exception I am getting:
I am getting the following exception:
Uncaught exception 'Exception' with message 'Cyclic Reference in Formula'
I am dealing with a excel sheet which contain very complex calculations. I can not write them all here. I am using an interface to send the values to specific cells of that excel sheet. and then getting back the calculated value from the output cells.
use of getOldCalculatedValue() gets the correct values first Time I use it (I have no idea how)
The problem with getOldCalculatedValue() is that this is not the solution. also when i update my input values , output value does not change.
now i checked deeply.. these are the formulas which are generating exceptions:
Fatal error: Uncaught exception 'Exception' with message 'STEAM!B30 -> STEAM!E57 -> STEAM!B56 -> STEAM!B38 -> STEAM!B89 -> internal error'
B30:=IF(G32=1,IF(E570,D55<>0),IF(G32=1,IF(E57
E57: ==IF(B44
B56:=B38*SQRT(IF(E44=1,B52,1^(3/4)*B53^(1/4)*B52/E43^(3/4)/E44^(1/4))/E43)
B38: =VLOOKUP(B70,CHART,2)
B89: ==HLOOKUP($E$4,WLC2CV,VLOOKUP($B$4,WLC2CV,15))
and there is warning generated, when i am handling the exception by assigning it old calculated values.
Warning (2): sqrt() expects parameter 1 to be double, string given [APP\vendors\Classes\PHPExcel\Calculation.php, line 3324]
A cyclic formula is one like (for example) cell A1 contains the formula =B1+1 while cell B1 contains =A1+1, ie. where executing the formula results in a chain of calculations that loops back on itself
This can be valid in Excel, though the default behaviour is to generate an error message when it is encountered. However, you can change this behaviour so that Excel will process the formula through a specified number of cycles or iterations.
PHPExcel supports both behaviours: the default is to generate the error message, as Excel does. But if you set the calculations engine's $cyclicFormulaCount property to a value greater than 0, it will emulate the second behaviour that Excel can exhibit.
At it's simplest level
PHPExcel_Calculation::getInstance()->cyclicFormulaCount = 1
will suppress cyclic errors and allow a basic cyclic calculation to be executed, setting $cyclicFormulaCount to higher values will allow the formulae to be calculated through several cycles or iterations (to the value that you specify).
The getOldCalculatedValue() method retrieves the result of a calculation as last executed by MS Excel itself. This may be correct, but is not guaranteed (eg if formula calculation has been suppressed in excel itself).
Related
So when I run this line on Jupyter notebook.
stats.linregress(xdata, data)
The result is
LinregressResult(slope=8.762662815890456, intercept=-583.1060100267368, rvalue=0.9764595396878868, pvalue=0.0, stderr=0.0710610032681328, intercept_stderr=31.20585863555493)
Then if I run this code
slope, intercept, r_value, p_value, std_err,std_err_intercept = stats.linregress(xdata, data)
There is an error:
ValueError: not enough values to unpack (expected 6, got 5)
But if you see there are 6 values to unpack and I need this value for my calculations could someone help, please.
This is a quirk of the evolving API of functions in scipy.stats. Old versions of linregress returned a tuple with length 5; they did not include the intercept_stderr in the result. New versions return an object with 6 attributes. However, for backwards compatibility, if you unpack that object, it will act like a tuple of length 5.
The simplest way to use the code is to write result = linregress(xdata, ydata), and then refer to the attributes as result.slope, result.intercept, etc. Then the standard error of the intercept is available as result.intercept_stderr.
If, for some reason, you must unpack the result, you can still write
slope, intercept, r_value, p_value, std_err = stats.linregress(xdata, data)
but you lose the intercept_stderr part of the result.
This is explained in the Notes section of the docstring.
I am trying to figure out if it is possible, with a sane amount of programming, to create a certain debugging function by using R's metaprogramming features.
Suppose I have a block of code, such that each line uses as all or part of its input the output from thee line before -- the sort of code you might build with pipes (though no pipe is used here).
{
f1(args1) -> out1
f2(out1, args2) -> out2
f3(out2, args3) -> out3
...
fn(out<n-1>, args<n>) -> out<n>
}
Where for example it might be that:
f1 <- function(first_arg, second_arg, ...){my_body_code},
and you call f1 in the block as:
f1(second_arg = 1:5, list(a1 ="A", a2 =1), abc = letters[1:3], fav = foo_foo)
where foo_foo is an object defined in the calling environment of f1.
I would like a function I could wrap around my block that would, for each line of code, create an entry in a list. Each entry would be named (line1, line2) and each line entry would have a sub-entry for each argument and for the function output. the argument entries would consist, first, of the name of the formal, to which the actual argument is matched, second, the expression or name supplied to that argument if there is one (and a placeholder if the argument is just a constant), and third, the value of that expression as if it were immediately forced on entry into the function. (I'd rather have the value as of the moment the promise is first kept, but that seems to me like a much harder problem, and the two values will most often be the same).
All the arguments assigned to the ... (if any) would go in a dots = list() sublist, with entries named if they have names and appropriately labeled (..1, ..2, etc.) if they are assigned positionally. The last element of each line sublist would be the name of the output and its value.
The point of this is to create a fairly complete record of the operation of the block of code. I think of this as analogous to an elaborated version of purrr::safely that is not confined to iteration and keeps a more detailed record of each step, and indeed if a function exits with an error you would want the error message in the list entry as well as as much of the matched arguments as could be had before the error was produced.
It seems to me like this would be very useful in debugging linear code like this. This lets you do things that are difficult using just the RStudio debugger. For instance, it lets you trace code backwards. I may not know that the value in out2 is incorrect until after I have seen some later output. Single-stepping does not keep intermediate values unless you insert a bunch of extra code to do so. In addition, this keeps the information you need to track down matching errors that occur before promises are even created. By the time you see output that results from such errors via single-stepping, the matching information has likely evaporated.
I have actually written code that takes a piped function and eliminates the pipes to put it in this format, just using text manipulation. (Indeed, it was John Mount's "Bizarro pipe" that got me thinking of this). And if I, or we, or you, can figure out how to do this, I would hope to make a serious run on a second version where each function calls the next, supplying it with arguments internally rather than externally -- like a traceback where you get the passed argument values as well as the function name and and formals. Other languages have debugging environments like that (e.g. GDB), and I've been wishing for one for R for at least five years, maybe 10, and this seems like a step toward it.
Just issue the trace shown for each function that you want to trace.
f <- function(x, y) {
z <- x + y
z
}
trace(f, exit = quote(print(returnValue())))
f(1,2)
giving the following which shows the function name, the input and output. (The last 3 is from the function itself.)
Tracing f(1, 2) on exit
[1] 3
[1] 3
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 am using custom LLVM pass where if I encounter a store to
where the compiler converts the value to a Constant; e.g. there is an explicit store:
X[gidx] = 10;
Then LLVM will generate this error:
aoc: ../../../Instructions.cpp:1056: void llvm::StoreInst::AssertOK(): Assertion `getOperand(0)->getType() == cast<PointerType>(getOperand(1)->getType())->getElementType() && "Ptr must be a pointer to Val type!"' failed.
The inheritance order goes as: Value<-User<-Constant, so this shouldn't be an issue, but it is. Using an a cast on the ConstantInt or ConstantFP has no effect on this error.
So I've tried this bloated solution:
Value *new_value;
if(isa<ConstantInt>(old_value) || isa<ConstantFP>(old_value)){
Instruction *allocInst = builder.CreateAlloca(old_value->getType());
builder.CreateStore(old_value, allocInst);
new_value = builder.CreateLoad(allocResultInst);
}
However this solution creates its own register errors when different type are involved, so I'd like to avoid it.
Does anyone know how to convert a Constant to a Value? It must be a simple issue that I'm not seeing. I'm developing on Ubuntu 12.04, LLVM 3, AMD gpu, OpenCL kernels.
Thanks ahead of time.
EDIT:
The original code that produces the first error listed is simply:
builder.CreateStore(old_value, store_addr);
EDIT2:
This old_value is declared as
Value *old_value = current_instruction->getOperand(0);
So I'm grabbing the value to be stored, in this case "10" from the first code line.
You didn't provide the code that caused this first assertion, but its wording is pretty clear: you are trying to create a store where the value operand and the pointer operand do not agree on their types. It would be useful for the question if you'd provide the code that generated that error.
Your second, so-called "bloated" solution, is the correct way to store old_value into the stack and then load it again. You write:
However this solution creates its own register errors when different type are involved
These "register errors" are the real issue you should be addressing.
In any case, the whole premise of "converting a constant to a value" is flawed - as you have correctly observed, all constants are values. There's no point storing a value into the stack with the sole purpose of loading it again, and indeed the standard LLVM pass "mem2reg" will completely remove such a sequence, replacing all uses of the load with the original value.
I have made a progress bar using the winProgressBar method in R. What I want to do is if someone instantiates my program while it is doing all of its processing, I want the current progress bar to close. I tried using a statement that says
if(exists(progressBar)) {
close(progressBar);
}
but I get an error from the console that says
Error in exists(progressBar) : object 'progressBar' not found
I know that it will not exist during the first iteration of my program, but there is no reason that I can find that would make an if statement cause the program to crash.
If you read the help for exists you will see the following under Arguments
x a variable name (given as a character string).
So
exists('progressBar')
will return TRUE or FALSE.