Why use clone() of ReLU in torch's inception net? - clone

I'm reading https://github.com/Element-Research/dpnn/blob/master/Inception.lua
You can see tons of clone()'s in this source. like
mlp:add(self.transfer:clone())
self.transfer is nothing more than nn.ReLU().
Then,
Why does this code call activation functions using clone()? Does this only concern memory issues?
I thought that the clone shares parameters. Is this right? If it's right, it means all activations of this inception module share parameters. It looks like nonsense. Do I misunderstand Inception-Net?

If you don't clone the module self.transfer then all modules transfer in your net mlp will have the same state variables output and gradInput.
Look for example at this toy code
require 'nn'
module = nn.ReLU()
net = nn.Sequential():add(nn.Linear(2,2)):add(module):add(nn.Linear(2,1)):add(module)
input = torch.Tensor(2,2):random()
net:forward(input)
print(net:get(2).output)
print(net:get(4).output)
Both print statements will return the same value. Modifying one of the module outputs will modify the other one. Since we do not want this behavior we have to clone the module. (However in your case, cloning a simple nn.ReLU() is not that useful.)
The documentation says
If arguments are provided to the clone(...) function it also calls share(...) with those arguments on the cloned module after creating it, hence making a deep copy of this module with some shared parameters.
Therefore if you don't provide any arguments the parameters won't be shared.

Related

How to Test/Debug Jekyll Plugins?

For a blog, I put together an inline tag that pulls header information from a specified webpage. It works, but I need to add caching, so that I'm not making redundant network calls.
I'd like a tighter debugging cycle than restarting the server and waiting for a rebuild, but running the plugin as Ruby code reports uninitialized constant Liquid (NameError). That makes sense, since it isn't required, and wouldn't run, since the plugin is just a class definition.
So, I tried creating some scaffolding to run the code, or what I thought would be scaffolding, anyway.
require 'liquid'
require_relative '../_plugins/header.rb'
ht = HeaderInlineTag.new
ht.initialize 'header', 'some path'
puts ht.render()
This produces...
_test/header.rb:4:in `<main>': private method `new' called for HeaderInlineTag:Class (NoMethodError)
Considering the possibility that initialize() might be run to create objects, I combined the first two lines of code, but that didn't work, either. Same error, different function name. The plugin doesn't mark anything as private, and declaring the methods public doesn't change anything.
What more is needed to test the plugin without carrying around the entire blog?
The solution was beyond my Ruby knowledge, but mostly straightforward, once I connected the pieces of information floating around.
First, this existing answer is about a specific issue dealing with Rails, but incidentally shows how to deal with private new methods: Call them through send, as in HeaderInlineTag.send :new.
Then, this indirect call to .new() now (of course) calls .initialize(), meaning that it needs the three parameters that are required by any plugin. Two parameters are for the testing itself, so they're easy. The third is a parse context. Documentation on writing Jekyll plugins is never clear on what the parse context actually is, since it gets sent automatically as part of the build process. However, some research and testing turns up Liquid::ParseContext as the culprit.
Finally, .render() also takes the ParseContext value.
Therefore, the the test scaffold should look something like this.
require 'liquid'
require_relative '../_plugins/header.rb'
context = Liquid::ParseContext.new
ht = HeaderInlineTag.send :new, 'header', 'some path...', context
puts ht.render context
I can call this from my blog's root folder with ruby _test/header.rb, and it prints the plugin's output. I can now update this script to pull the parameters from the command line or a CSV file, depending on the tests required.

Trouble with complex routing rule

I have a lookup table called BlockCustomer. I also have an FTP Adapter that picks up files from multiple customers. I need to be able to determine the customer from the source of the file and do a lookup on the table. If BlockCustomer.Customer1 = 0 then it will send it to it's target, otherwise it will do nothing.
If I could use javascript I would do something like this:
WHEN Lookup(BlockCustomer,HL7.Source.split("/incoming/")[1].split("/")[0]),1) = 0
But obviously I can't. I found $ZSTRIP but I'm not sure if or how it will work. Is this possible or am I going to have to create a custom class?
In Cache we use function $piece if needs to get some parts of string by delimiter. For rule you could use the same function called Piece, with the same arguments. So you conditions should looks like:
Lookup(BlockCustomer,Piece(HL7.Source,"/incoming/",2),1)=0
By the way if you think, that you need some specific functions for you, you can do it by developing it. Just extend the class Ens.Rule.FunctionSet and add a method. And function will appear with the same name. As an example you can see at Ens.Util.FunctionSet class, which contains almost all available functions.

Passing command line arguments to classes

When developing large scale command line applications that are composed of multiple classes, which need to use options passed from the command line, how do you construct the code such that you can use those options?
I write code like this:
class DatabaseHandler
def initialize(cmd_options = {})
#cmd_options = cmd_options
end
def some_method
puts #cmd_options[:cmd_parameter]
end
end
which, seems tedious and unnecessary to me. What is the Ruby best practice for using command line option parameters in your project's classes? Help appreciated.
Ruby classes are simply that: classes. Good OOD applies, even if it's a command line application. If you need custom behaviour, use dependency injection or configure it using arguments. You may share the command line options using global variables, but as always, that comes at a price: shadowing, increasing complexity to understand the collaborators of a class, difficulty finding the source of a data, etc.
I'd suggest using factory methods to parse the input and return the correct configuration to be passed to a class. If you want nice examples of dependency injection, watch some Sandi Metz talks, she really knows her stuff.
Command-line options are no different from any other kind of configuration; configuration is configuration, no matter where it came from. So, you deal with them the same way you deal with other configuration, e.g. using
a global singleton
Dependency Injection (which is what you are doing in your example)
the Reader Monad
…
For example, for request parameters (which is probably the closest analog to command-line arguments in a Web context), Rails uses a global method named params which returns a Hash-like object mapping parameter names to arguments. So, that would be an example of a global singleton.

Configure providers from variables, in a generic way

How can I create a recipe that will populate its attributes using the fiels from an instance of an object in a generic way?
As an example, consider the following recipe:
component = $auth_docker
docker_image component.name do
registry component.registry
tag component.tag
action :pull
end
When you have 50s of recipes that look like this, maintaining them really gets overwhelming.
In Python, i would probably implement a solution that would look a bit like this:
docker_image = DockerImage(**$auth_docker)
Or, I would create some sort of helper function to build it for me:
def generate_docker_image_lwrp(attributes):
lwrp = DockerImage()
lwrp.registry = attributes.registry
lwrp.tag = attributes.tag
return lwrp
The goal is to reduce maintenance on the recipes. For instance this morning I wanted to add Chef's "retries" attribute on all recipes that pull an image. I had to edit all of them - I don't want that. I should've been able to a) add the attribute to the stack's JSON b) edit the Ruby wrapper class so that instances of it (i.e.: $auth_docker) get the "retries" field, then c) add the retries attribute to the lwrp-generator. Since all recipes would use the same generator, recipes wouldn't need to be edited at all.
Is this possible using Chef, in a way that 'notifies' still work?
Quoting the Documentation
A definition is code that is reused across recipes, similar to a
compile-time macro. A definition is created using arbitrary code
wrapped around built-in chef-client resources—file, execute, template,
and so on—by declaring those resources into the definition as if they
were declared in a recipe. A definition is then used in one (or more)
recipes as if it were a resource.
Though a definition behaves like a resource, some key differences
exist. A definition:
Is not a resource or a lightweight resource Is defined from within the
/definitions directory of a cookbook Is loaded before resources during
the chef-client run; this ensures the definition is available to all
of the resources that may need it May not notify resources in the
resource collection because a definition is loaded before the resource
collection itself is created; however, a resource in a definition may
notify a resource that exists within the same definition Automatically
supports why-run mode, unlike lightweight resources Use a defintion
when repeating patterns exist across resources and/or when a simple,
direct approach is desired. There is no limit to the number of
resources that may be included in a definition: use as many built-in
chef-client resources as necessary.
I.e: you can create a definition for this in a library cookbook used solely for this.
docker_library/defintions/default.rb
define :my_docker_image, :component => nil do
component = params[:component]
docker_image component.name do
registry component.registry
tag component.tag
action :pull
end
end
in your recipes (need to have a depends on the docker_library cookbook in the metadata.rb):
my_component = $auth_docker
my_docker_image my_component.name do
component my_component
end
A more complete exemple of definition is available in the logrotate cookbook

CodeIgniter: Decision making for creating of library & helper in CodeIgniter

After developing in CodeIgniter for awhile, I find it difficult to make decisions when to create a custom library and when to create a custom helper.
I do understand that both allow having business logic in it and are reusable across the framework (calling from different controller etc.)
But I strongly believe that the fact that CI core developers are separating libraries from helpers, there has to be a reason behind it and I guess, this is the reason waiting for me to discover and get enlightened.
CI developers out there, pls advise.
i think it's better to include an example.
I could have a
class notification_lib {
function set_message() { /*...*/}
function get_message() {/*...*/}
function update_message() {/*...*/}
}
Alternatively, i could also include all the functions into a helper.
In a notification_helper.php file, i will include set_message(), get_message(), update_message()..
Where either way, it still can be reused. So this got me thinking about the decision making point about when exactly do we create a library and a helper particularly in CI.
In a normal (framework-less) php app, the choice is clear as there is no helper, you will just need to create a library in order to reuse codes. But here, in CI, I would like to understand the core developers seperation of libraries and helpers
Well the choice comes down to set of functions or class. The choice is almost the same as a instance class verses a static class.
If you have just a simply group of functions then you only need to make a group of functions. If these group of functions share a lot of data, then you need to make a class that has an instance to store this data in between the method (class function) calls.
Do you have many public or private properties to store relating to your notification messages?
If you use a class, you could set multiple messages through the system then get_messages() could return a private array of messages. That would make it perfect for being a library.
There is a question I ask myself when deciding this that I think will help you as well. The question is: Am I providing a feature to my framework or am I consolidating?
If you have a feature that you are adding to your framework, then you'll want to create a library for that. Form validation, for example, is a feature that you are adding to a framework. Even though you can do form validation without this library, you're creating a standard system for validation which is a feature.
However, there is also a form helper which helps you create the HTML of forms. The big difference from the form validation library is that the form helper isn't creating a new feature, its just a set of related functions that help you write the HTML of forms properly.
Hopefully this differentiation will help you as it has me.
First of all, you should be sure that you understand the difference between CI library and helper class. Helper class is anything that helps any pre-made thing such as array, string, uri, etc; they are there and PHP already provides functions for them but you still create a helper to add more functionality to them.
On the other hand, library can be anything like something you are creating for the first time, any solution which might not be necessarily already out there.
Once you understand this difference fully, taking decision must not be that difficult.
Helper contains a group of functions to help you do a particular task.
Available helpers in CI
Libraries usually contain non-CI specific functionality. Like an image library. Something which is portable between applications.
Available libraries in CI
Source link
If someone ask me what the way you follow when time comes to create Helpers or Libraries.
I think these differences:
Class : In a nutshell, a Class is a blueprint for an object. And an object encapsulates conceptually related State and Responsibility of something in your Application and usually offers an programming interface with which to interact with these. This fosters code reuse and improves maintainability.
Functions : A function is a piece of code which takes one more input in the form of parameter and does some processing and returns a value. You already have seen many functions like fopen() and fread() etc. They are built-in functions but PHP gives you option to create your own functions as well.
So go for Class i.e. libraries if any one point matches
global variable need to use in two or more functions or even one, I hate using Global keyword
default initialization as per each time call or load
some tasks are private to entity not publicly open, think of functions never have public modifiers why?
function to function dependencies i.e. tasks are separated but two or more tasks needs it. Think of validate_email check only for email sending script for to,cc,bcc,etc. all of these needs validate_email.
And Lastly not least all related tasks i.e. functions should be placed in single object or file, it's easier for reference and remembrance.
For Helpers : any point which not matches with libraries
Personally I use libraries for big things, say an FTP-library I built that is a lot faster than CodeIgniters shipped library. This is a class with a lot of methods that share data with each other.
I use helpers for smaller tasks that are not related to a lot of other functionality. Small functions like decorating strings might be an example. Or copying a directory recursively to another location.

Resources