In TensorFlow (Python), when adding to the graph a tf.train.RMSPropOptimizer, are any additional variables added that need initialization? If yes, how can I get access to them and initialize them manually? (I'd rather not use tf.global_variables_initializer). In other words:
(1) How can I decide which initializer to use?
(2) How can I add the initilizer op to the graph, specifically for these variables?
EDIT 1:
I'm referring here to any new tf.Variable that is added to the graph whenever I add the RMSPropOptimizer, and how it is initialized (just like other tf.Variables). I'm not referring to the arguments in constructor of the RMSPropOptimizer, (which are hyper parameters of the model).
In TensorFlow (Python), when adding to the graph a tf.train.RMSPropOptimizer, are any additional variables added that need initialization?
Yes.
If yes, how can I get access to them and initialize them manually? (I'd rather not use tf.global_variables_initializer).
From the docs:
tf.train.RMSPropOptimizer.__init__(learning_rate, decay=0.9, momentum=0.0, epsilon=1e-10, use_locking=False, centered=False, name='RMSProp')
There are at least 3 (decay, momentum, and epsilon).
In other words: (1) How can I decide which initializer to use?
This I don't have a good answer to - I've been told in class "just use Adam". That might be good advice in general, but I imagine there are cases where others work better. This might be worth searching online for blog posts or survey papers or something.
(2) How can I add the initializer op to the graph, specifically for these variables?
You can pass them into the constructor as named parameters.
Related
I'm trying to implement my own MoveListFactory and don't know how to access / create the variable descriptors for the move I want to instantiate. The createMoveList method (from the MoveListFactory interface) takes a single argument of an instance of my Solution class. From this I can access all the planning variables that I need to create a ChainSwapMove. What I'm unsure about is how to create the first argument that the ChainSwapMove constructor requires (e.g. the Collection<GenuineVariableDescriptor>). The example in the documentation doesn't shed any light on this process since the custom move used in the NQueens example doesn't require this Collection of GenuineVariableDescriptors. I've not come across any examples of how someone can access these from only the information contained in a Solution object.
Anything ending with *Descriptor is very internal API, not the kind of classes I want users to be using. The docs presume you build your own move (which is difficult indeed to build a valid move on chained variables that leaves the chain in a valid state).
That being said, here's a clue: InnerScoreDirector.getSolutionDescriptor().getEntityDescripor(MyCustomer.class).getVariableDescriptor("myPreviousStandstill") ...
I learned in another question that BaseUnits must be singletons. This has a number of disadvantages, including making client code a bit harder to work with (you have to store the singleton somewhere and provide access to it), and making it harder to serialize code e.g. via Fuel.
What is the benefit of this constraint? (I'm assuming it's so that users are safe if they load two Aconcagua clients which define e.g. BaseUnit subclass: #Pound differently)
In practice, is it worth it, or would it be better to treat BaseUnits like value objects? Especially in light of the fact that the paper itself uses expressions like 1 dollar, which already precludes units with the same name.
I wrote something about it in the other post.
Units are not really Singletons (as Singleton is defined in the gang of four book), and the idea is not to create a class per unit but to instantiate BaseUnit or DerivedUnit, etc., per unit you need.
So, for example you can create:
meter := BaseUnit named: 'meter'.
centimeter := ProportionalDerivedUnit basedUnit: meter convertionFactor: 1/100
named: 'centimeter'.
And then write:
1*meter = (100*centimeter)
that will return true.
As I post in the other question, equality is defined as the default, therefore identity is used.
So, you can do two things to make equality works:
To have well know objects (using global variables or a global root object to access them as Chalten does)
Modify #= in Unit and make two units equal if the have the same name (or create a subclass with this definition of #=)
The main reason to use the default #= implementation are:
It is the more generic solution
Units (in real life) are unique, so it make sense to be unique in the model
It make sense to have one "meter" object instead of creating one each time you need it.
The main disadvantage is like you see, that the first time you see it could be kind of problematic to understand, but again, you only need to have a way to access to the object and problem solved.
Regarding Fuel, the problem can be solved saving the root object that defined all units (like TimeUnit in Chalten) or implementing option 2) :-)
Hope this help! Let me know if you have more questions!
In Chapter 36.4 of HTDP(How to Design Programs),
I found this warning:
Warning: The state variable is never a parameter of a function.
But as far as I've heard before, in functional programming, functions will be corrupted if they refer state variables. They will not be pure functions anymore. They will be hard to test, do unpredictable works, cannot be memoized ... etc. The state variables also should be passed by as parameters, not just referred as some global constants.
So I wonder
is HTDP is arguing something wrong,
in some of functional programming practices, global state variables are allowed? or
I have wrong idea?
Thanks in advance.
Disclaimer: I like&respect this book very much and learned a lot. Actually I would like to spread good words about this book to my friends(if any). So don't get it wrong.
I don't think there's anything incompatible with what you've heard about functional programming and what is written in the chapter you linked. However, you're conflating two concepts here: the presence of mutable state in functional programs (a purity issue) vs. the order in which things are evaluated, and the restrictions on the syntax you have available to write things down.
Consider: if you're using an eager evaluation strategy, then passing a "state variable" of the kind they describe in that chapter would have the effect of dereferencing it, and you would get the value of the variable as the function argument. Similarly, if the variable was bound as a parameter to the function, you would get a different bit of memory at every call. There are many different options here. The fact that some languages permit you to pass references around as values is not universal.
So they are really just describing global variables (or variables that are accessed from some parent scope), which by their very nature need not be passed to functions as parameters. If the specific language permits pass-by-reference, this might not be such a clear distinction.
As far as I can see there are two main principles how to deal with application-wide role player objects like a root model object (in MVC context):
create the object and pass it through the object tree (e.g. in the constructor)
provide it as a singleton or other global variable technique
The first approach seems to be cleaner because the dependencies are better visible but there is a lot of additional work to do (parameters, class variables,...).
What do you prefer?
Edit: The first technique also uses only one instance but it is provided by passing the object and not by a static function
I prefer run singletons' method getInstance() as constructor parameter - bake two birds with one stone ;)
This is where dependency injection can help out. Having to explicitly pass all the correct dependencies manually to an object whenever you create one can be a pain and perhaps somewhat error prone. A decent dependency injection container can help to automate this process and is actually easier to use than singletons.
The Symfony2 framework is a modern example:
http://symfony.com/doc/current/book/service_container.html
I think passing as parameter is a little more memory-efficient, easier to debug, but need a some additional work.
I prefer to use singletons only when i really need it (like database sessions, write to file etc.).
It really depends on project type, language, budget, size of project etc. There is no "universal" answer.
In my design I am using objects that evaluate a data record. The constructor is called with the data record and type of evaluation as parameters and then the constructor calls all of the object's code necessary to evaluate the record. This includes using the type of evaluation to find additional parameter-like data in a text file.
There are in the neighborhood of 250 unique evaluation types that use the same or similar code and unique parameters coming from the text file.
Some of these evaluations use different code so I benefit a lot from this model because I can use inheritance and polymorphism.
Once the object is created there isn't any need to execute additional code on the object (at least for now) and it is used more like a struct; its kept on a list and 3 properties are used later.
I think this design is the easiest to understand, code, and read.
A logical alternative I guess would be using functions that return score structs, but you can't inherit from methods so it would make it kind of sloppy imo.
I am using vb.net and these classes will be used in an asp.net web app as well as in a distributed app.
thanks for your input
Executing code in a constructor is OK; but having only properties with no methods might be a violation of the tell don't ask principle: perhaps instead those properties should be private, and the code which uses ("asks") those properties should become methods of the class (which you can invoke or "tell").
In general, putting code that does anything significant in the constructor a not such a good idea, because you'll eventually get hamstrung on the rigid constructor execution order when you subclass.
Constructors are best used for getting your object to a consistent state. "Real" work is best handled in instance methods. With the work implemented as a method, you gain:
separation of what you want to evaluate from when you want to evaluate it.
polymorphism (if using virtual methods)
the option to split up the work into logical pieces, implementing each piece as a concrete template method. These template methods can be overridden in subclasses, which provides for "do it mostly like my superclass, but do this bit differently".
In short, I'd use methods to implement the main computation. If you're concerned that an object will be created without it's evaluation method being called, you can use a factory to create the objects, which calls the evaluate method after construction. You get the safety of constructors, with the execution order flexibility of methods.