I have a work flow that starts with an array. I got this work-flow working, however there was one funny thing that cause it to break and I do not understand why.
For testing I have an IndepVarComp that provides the vector. It only seems to work when it is initialized with a vector from np.zeros(...).
root.add('input', \
IndepVarComp('top'+':'+'twcxVector', \
np.zeros(TWCXDictArraySize(twcxDict))) \ # <- arange breaks here
,promotes=['*'])
I tried to use something like np.arange(...) to verify that things are populated properly. But then nothing happens at that point.
Just so I understand things more, could someone please explain why something like this causes OpenMDAO to break.
For reference this is the rest of the work-flow:
root.add('obj',Array2TWCXDictOpenMDAO(twcxDict,'top'+':') \
,promotes=['*'])
top.setup()
top.root.list_connections()
top.run()
data = top.check_total_derivatives(out_stream=sys.stdout)
top.run()
data = top.check_partial_derivatives(out_stream=sys.stdout)
It seems that OpenMDAO expects numpy arrays of floats. So IndepVarComp needs to be initialized with those types. Some of the methods for creating numpy arrays will create arrays of integers. This is the case when np.arange is passed with just a number. When these arrays are passed to IndepVarComp, then openMDAO assumes that derivatives cannot be taken. Thus check derivatives will not run over these variables. This problem can be fixed by creating arrays with the argument 'dtype=np.float_'
root.add('input', \
IndepVarComp('top'+':'+'twcxVector', \
np.arange(TWCXDictArraySize(twcxDict),dtype=np.float_)) \
,promotes=['*'])
Related
I tried using frama-c-gui and was able to perform impact analysis
But I am not able to figure out how can we pass statment number on which the impact analysis needs to be performed in batch mode of Frama-C.
There is a special annotation //# impact pragma stmt; that you can use to indicate that you are interested in the impact of the statement following the annotation. Then, if said annotation is in function f, you can use the following command line to print the impacted code on the command line:
frama-c -impact-pragma f -impact-slicing impact.c -then-on "impact slicing" -print
-impact-pragma f indicates that you are interested by the statements flagged by a pragma in function f
-impact-slicing indicates that you want to create a project named impact slicing containing the statements impacted by the one(s) you have selected.
-then-on "impact-slicing" let you continue the analysis on project impact slicing (here we only -print the code, but you can put any option you like after -then-on project_name)
Note however that the impact plugin is quite experimental.
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'm trying to set an array in ZSH (configured using oh-my-zsh).
export AR=(localhost:1919 localhost:1918)
but I'm getting an error like such:
zsh: number expected
If I don't add the export command, it's just fine. I'm not typing the above in a *rc file, just in the zsh prompt. What could be the problem?
You can't export an array in zsh.
For more info: http://zsh.sourceforge.net/Guide/zshguide02.html
Note that you can't export arrays. If you export a parameter, then
assign an array to it, nothing will appear in the environment; you can
use the external command printenv VARNAME (again no $ because the
command needs to know the name, not the value) to check. There's a
more subtle problem with arrays, too. The export builtin is just a
special case of the builtin typeset, which defines a variable without
marking it for export to the environment. You might think you could do
typeset array=(this doesn\'t work)
but you can't --- the special
array syntax is only understood when the assignment does not follow a
command, not in normal arguments like the case here, so you have to
put the array assignment on the next line. This is a very easy mistake
to make. More uses of typeset will be described in chapter 3; they
include creating local parameters in functions, and defining special
attributes (of which the export attribute is just one) for
parameters.
In my kernel i have this defined.
#define ACTIVATION_FUNCTION(X) (1.7159f*tanh(2.0f/3.0f*X))
I would like to define it in the clBuildProgram call, such i can alter the kernel at runtime. How can i do this?
You can use the -D argument to the OpenCL compiler, by passing it in the options parameter of the clBuildProgram function. Passing -D x=y, is equivalent to adding #define x y at the top of your kernel file. Similarly, passing -D x is equivalent to adding #define x (for any x and y, of course).
In your case, you probably want to pass something like this:
-D ACTIVATION_FUNCTION(X)=(1.7159f*tanh(2.0f/3.0f*X))
Which you can then change as you see fit, directly from your program, at runtime.
Note you could also open the kernel file and write the define directly into it, as an alternative solution, but this is probably the cleanest way. Just be careful with newlines, I'm not sure how well they are handled.
Ref. this documentation page on clBuildProgram, "Preprocessor Options" section.
I am using the Kernel Density Estimator toolbox form http://www.ics.uci.edu/~ihler/code/kde.html . But I am getting the following error when I try to execute the demo files -
>> demo_kde_3
KDE Example #3 : Product sampling methods (single, anecdotal run)
Attempt to reference field of non-structure array.
Error in double (line 10)
if (npd.N > 0) d = 1; % return 1 if the density exists
Error in repmat (line 49)
nelems = prod(double(siz));
Error in kde (line 39)
if (size(ks,1) == 1) ks = repmat(ks,[size(points,1),1]); end;
Error in demo_kde_3 (line 8)
p = kde([.1,.45,.55,.8],.05); % create a mixture of 4 gaussians for
testing
Can anyone suggest what might be wrong? I am new to Matlab and having a hard time to figure out the problem.
Thank You,
Try changing your current directory away from the #kde folder; you may have to add the #kde folder to your path when you do this. For example run:
cd('c:\');
addpath('full\path\to\the\folder\#kde');
You may also need to add
addpath('full\path\to\the\folder\#kde\examples');
Then see if it works.
It looks like function repmat (a mathworks function) is picking up the #kde class's version of the double function, causing an error. Usually, only objects of the class #kde can invoke that functions which are in the #kde folder.
I rarely use the #folder form of class definitions, so I'm not completely sure of the semantics; I'm curious if this has any effect on the error.
In general, I would not recommend using the #folder class format for any development that you do. The mathworks overhauled their OO paradigm a few versions ago to a much more familiar (and useful) format. Use help classdef to see more. This #kde code seems to predate this upgrade.
MATLAB gives you the code line where the error occurs. As double and repmat belong to MATLAB, the bug probably is in kde.m line 39. Open that file in MATLAB debugger, set a breakpoint on that line (so the execution stops immediately before the execution of that specific line), and then when the code is stopped there, check the situation. Try the entire code line in console (copy-paste or type it, do not single-step, as causing an uncatched error while single-stepping ends the execution of code in debugger), it should give you an error (but doesn't stop execution). Then try pieces of the code of that code line, what works as it should and what not, eg. does the result of size(points, 1) make any sense.
However, debugging unfamiliar code is not an easy task, especially if you're a beginner in MATLAB. But if you learn and understand the essential datatypes of MATLAB (arrays, cell arrays and structs) and the different ways they can be addressed, and apply that knowledge to the situation on the line 39 of kde.m, hopefully you can fix the bug.
Repmat calls double and expects the built-in double to be called.
However I would guess that this is not part of that code:
if (npd.N > 0) d = 1; % return 1 if the density exists
So if all is correct this means that the buil-tin function double has been overloaded, and that this is the reason why the code crashes.
EDIT:
I see that #Pursuit has already addressed the issue but I will leave my answer in place as it describes the method of detection a bit more.