Trying to initialize my seq2seq-model. I am using the GRU Cells, but cannot figure out Xavier-Initialization. The code in rnn_cell.py doesnt seem to allow that. Any ideas? Need to do this manually?
thx
The cell's weights are created using tf.get_variable() without specifying an initializer parameter. From https://www.tensorflow.org/versions/r0.10/api_docs/python/state_ops.html#get_variable:
If initializer is None (the default), the default initializer passed in the variable scope will be used.
Therefore, something like the following should work:
cell = tf.nn.rnn_cell.GRUCell(256)
with tf.variable_scope('RNN', initializer=tf.contrib.layers.xavier_initializer()):
outputs, state = tf.nn.dynamic_rnn(cell, ...)
Related
I have my own function which I want to use via scifunc_block_m block. The function is defined in an .sci file, as suggested in this answer. Running the script from the scilab console before starting the simulation works fine. However, if I call exec() of this very .sci under xcos Simulation -> Set Context instead, the function seem to remain unknown in xcos. Am I missing something about the context setting?
It began with a function typed into scifunc_block_m or expression block. However,
I didn't want to make the block big and was unable to use .. to split the function definition over multiple lines to prevent the text spilling over the block boundaries.
The function will be used several times, I wanted a single definition vs copy&paste.
For the Set Context part:
I guess that you must specify the absolute path of fader_func.sci, either directly in the set Context box, or through a variable defined in the console:
--> fader_PATH = "C:\the\path\fader_func.sci"
// Then in the Context box;
exec(fader_PATH,-1);
Or directly in the Context box (far less portable solution):
exec("C:\the\path\fader_func.sci", -1);
about scifunc_block_m input
Continuation dots are unlikely supported. Instead, have you tried to explicitly split any long instruction in several shorter ones?
tmp = tanh((u3-u1+u2/2)/0.25/abs(u2))
y1 = 0.5 + sign(u2)*tmp/2
In an ExplicitComponent class, within the definition of the setup function is there a way to give the value of an output during its declaration based on the value of an input created just before in that setup function ?
For instance to do something like :
class Discipline_1(ExplicitComponent):
def setup(self):
self.add_input('Input_1', val=5.0)
self.add_output('Output_1',val = 0.07*inputs['Input_1'])
The idea is, as the 'NonlinearBlockGS' solver in a cycle use the 'val' information to initialize a fixed point method, I would like to give an appropriate initialization to minimize the number of 'NonlinearBlockGS' iterations.
If you really wanted to initialize the output based on the input value, just define the input value as a local variable:
class Discipline_1(ExplicitComponent):
def setup(self):
inp_val = 5.0
self.add_input('Input_1', val=inp_val)
self.add_output('Output_1',val = 0.07*inp_val)
That would only work if you had a fixed value known at setup time. You could pass that value into the class constructor via metadata to make it a little more general. However this may not be the most general approach.
Your group has a certain run sequence, which you could set manually if you liked. the GaussSeidel solver will execute the loop on that sequence, so you only need to initialize the value that is the the input to the first component in the loop. All the others will get their values passed to them by their upstream component source as the GS solver runs. This initial value could be set manually after setup is called by setting the value using the problem interface:
prob['Input_1'] = 5.0
As a side note in openmdao 2.0.2 we have a guess_nonlinear method defined on ImplicitComponents that you can use to initialize implicit output variables, but that is not applicable here
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.
Now I'm making an endless runner where objects are spawned in front on me randomly.
I was told to make a spawnController and globalController object, so I did. Then this code should be put in the controller under step event
if(tick = 32)
{
tick = 0;
instance_create(room_width,room_height,random(spike,groundBlock));
instance_create(room_width,irandom_range(0,room_height-32));
}
tick += 1;
Is there anything wrong with it because i get an error, which is:
In object spawnController, event Step, action 1 at line 4: Wrong number of arguments to function or script.
instance_create(room_width,irandom_range(0,room_height-32));
The error messages in GM can sometimes be a bit unclear.. But in this case it was pretty clear. It goes about this line. And one of the scripts has too few arguments. Either irandom_range or instance_create you forgot an argument.
irandom_range takes two arguments to make a random number, so that is correct.
instance_create however takes 3 arguments: x,y position and the object from which you wish to create an instance. You're simply missing that argument (and the error tells you that). I think that is a typo as you do it correctly in the creation above.
Manual about instance_create
You have a syntax error here:
instance_create(room_width,irandom_range(0,room_height-32);
There's no closing parentheses or a 3rd argument.
One thing that stood out to me is that you used random instead of choose. Im not sure there is a difference in this situation, but choose allows you to list as many arguments you want.
But the other thing as was pointed out, was that your missing the object you want the 4th life to create. You need to specify what object you want it to make.
instance_create(room_width, irandom_range(0,room_height-32), OBJECT);
I'm a bit confused on global variable assignments after reading quite a lot of stack overflow questions. I have gone through
Global variables in R and other similar questions
I have the following situation. I have 2 global variables current_idx and previous_idx. These 2 global variables are being set by a method in a reference class.
Essentially, using <<- assignment operator should work right ? But, I get this warning
Non-local assignment to non-field names (possibly misspelled?)
Where am I going wrong ?
EDIT
Using assign(current_idx, index, envir = .GlobalEnv) works i.e. I do not get the warning. Can some one shed some light on this.
You are confusing "global variables" and Reference Classes which are a type of environment. Executing <<- will assign to a variable with that name in the parent.frame of the function. If you are only one level down from the .GlobalEnv, it will do the same thing as your assign statement.
If you have a Reference Class item you can assign items inside it by name with:
ref_item$varname <- value
Easier said than done, though. First you need to set up the ReferenceClass properly:
http://www.inside-r.org/r-doc/methods/ReferenceClasses
This is happening because the default method for modifying fields of a reference class from within a reference class method is to use <<-. For example, in:
setRefClass(
"myClass",
fields=list(a="integer"),
methods=list(setA=function(x) a <<- x)
)
You can modify the a field of your reference class via the setA method. Because this is the canonical way of setting fields via methods in reference classes, R assumes that any other use of <<- within a reference method is a mistake. So if you try to assign to a variable that exists in an environment other than the reference class, R "helpfully" warns you that maybe you have a typo since it thinks the only probably use of <<- in a reference method is to modify a reference field.
You can still just assign to global objects with <<-. The warning is just a warning that maybe you are doing something you didn't intend to do. If you intended to write to an object in the global environment, then the warning doesn't apply.
By using assign you are bypassing the check that reference methods carry out to make sure you are not accidentally typoing a field name in an assignment within the reference method, so you don't get the warning. Also, note that assign actually targets the environment you supply, whereas <<- will just find the first object of that name in the lexical search path.
All this said, there are really rare instances where you actually want a reference method do be writing directly to the global environment. You may need to rethink what you are doing. You should ask yourself why those two variables are not just fields in the reference class instead of global variables.