When i read some torch codes, i was confused with the "nn" and "dp" model. I see in many codes which requires only dp (no nn), but why it can use nn.methodA? why it can use nn without require it ? besides, the method is defined in the dpnn! Should it be used as dpnn.methodA? the codes do like this:
require 'dp'
...
nn.methodA() [the methodA is defined in 'dpnn']
'dp' has 'nn' as a dependency, and requires 'nn'. More specifically when calling require 'dp' the init script of 'dp' is run. This calls require 'dpnn' (see). Subsequently the init script of 'dpnn' is run and calls require 'nn' (see).
Additionally, modules share the same global namespace. This means modules can set abc or nn or whatever. Many modules extend the namespace of 'nn' to include extra functionality.
Related
I know this question has been asked and answered before, but none of the many answers work for me as described.
What is the procedure for reloading a module that I'm working on in Julia (1.6)?
For example, I have
module MyModule
export letters
const letters = String('A':'Z')
end
and I want the be able to load the module, make changes to letters in the module's file, and then reload the module and have those changes reflected in subsequent uses of letters. This seems simple enough, but I can't get it to work.
I've tried
include("src/MyModule.jl")
using .MyModule
but if I change the definition of letters in MyModule.jl and then
include("src/MyModule.jl")
letters doesn't change, unless I fully qualify its use each time with Main.MyModule.letters: using Main.MyModule; letters refers, for example, to the old definition.
How do I reload a module under development so that I can refer to its definitions without fully qualifying them (and without having an unqualified shadow definition always lying around)?
I would just use Revise.jl and wrap everything in functions:
module MyModule
export letters
letters(char_start, char_end) = char_start:char_end |> String
end
julia> using Revise
julia> includet("src/MyModule.jl")
julia> using .MyModule
julia> letters('l', 'p')
"lmnop"
module MyModule
export letters
letters(char_start, char_end) = char_start:char_start |> String
end
julia> letters('l', 'p')
"l"
const is for defining things that you do not want to modify, so I would not expect your original version to work as expected. Revise.jl should also throw a redefinition error if you try to change it
In general though, it's usually much nicer (and easier too!) to just put everything in a package and use the usual using/import syntax. PkgTemplates.jl is great for this
If you would like to redefine consts though, I would definitely recommend checking out Pluto.jl
I have been trying to modify the cifer example code of Chainer so that it works with multiple optimizers.
As written in page 946 of Chainer Documentation (Release 7.0.0b3), I thought that the function, training.updaters.ParallelUpdater, can take not only an optimizer object but also a dictionary that maps strings to optimizers.
So, I put three optimizer objects in a dictionary, setup them with a model, and put the dictionary into the ParallelUpdate function as an argument. (see the code below)
optimizers = {}
optimizers['SGD'] = chainer.optimizers.SGD(args.learnrate)
optimizers['Adam'] = chainer.optimizers.Adam()
optimizers['RMSProp'] = chainer.optimizers.RMSprop()
.
.
for key in optimizers.keys() :
optimizers[key].setup(model)
.
.
updater = training.updaters.ParallelUpdater(
train_iter, optimizer=optimizers, devices = devices
)
However, the program gives an error message as follows.
File "C:\WPy64-3720\python-3.7.2.amd64\lib\site-packages\chainer\training\updaters\parallel_updater.py", line 82, in __init__
models = {'main': optimizer.target}
AttributeError: 'dict' object has no attribute 'target'
I understand that 'dict' object is not an optimizer object, but I thought that the description in the document implies that the optimizers are automatically exracted from the dictionary.
Does anybody know what is wrong with my code or how to make the updater work with multiple optimizers?
To use multiple optimizers, you need to override the update_core method and provide custom logic to update with these optimizers. The feature of accepting a dict of optimizers is designed for optimizing multiple different objectives with separate optimizers (e.g. GANs) rather than applying different update rules for parameters of a single objective.
Note that it means you eventually need to implement the parallel update by yourself because ParallelUpdater.update_core, which you need to override, actually implement parallelization. I strongly recommend ChainerMN, which cleanly decouple the optimization logic and parallel training.
Is there a way to avoid Google Performance Tools listing files as "??:?", that is, failing to locate which file contains the function it is reporting on? How can I work out which library contains the function being called?
$ env LD_PRELOAD="/usr/lib/libprofiler.so.0" \
CPUPROFILE=output.prof python script.py
$ google-pprof --text --files /usr/bin/python output.prof
Using local file /usr/bin/python.
Using local file output.prof.
Removing _L_unlock_13 from all stack traces.
Total: 433 samples
362 83.6% 83.6% 362 83.6% dtrsm_ ??:?
58 13.4% 97.0% 58 13.4% dgemm_ ??:?
1 0.2% 97.2% 1 0.2% PyDict_GetItem /.../Objects/dictobject.c
1 0.2% 97.5% 1 0.2% PyParser_AddToken /.../Parser/parser.c
...
I am aiming to be able to profile the C code in a python package that has many compiled C extension modules. In the toy example above, what would I do to track down where "dtrsm_" is defined? If there are multiple loaded libraries that contain functions with that same name, is there any way to tell which version is being called?
C/C++ won't compile if the same pre-processed sourcefile (e.g. with #includes expanded) contains duplicate definitions for the same symbol. (Note that in the case of C++, symbols are mangled, according to compiler-specific schemes, to incorporate the argument signature so as to facilitate overloaded functions, which could not otherwise be differentiated.)
The linker is only concerned with unresolved symbols (so there ought be nothings preventing multiple libraries concurrently calling their own respective internally-defined functions with coincident names). If a file invokes a declared but undefined function, and multiple available libraries implement that symbol, then the linker is free to choose (say by precedence in a search-path) which version gets substituted in. (Incidentally, this is the same mechanism by which profilers such as gperftools or hpctoolkit are able to inject themselves and alter the normal behaviour of another application.)
Since different libraries are mapped to separate pages of memory, it ought to be possible to identify (from memory addresses) which library contains the executing version of a function. Indeed, the GNU debugger can identify the library that code is contained by, even when it fails to name a function.
$ gdb python
(gdb) run -c "from numpy import *; linalg.inv(random.random((1000,1000)))"
CTRL-C
(gdb) backtrace
#0 0x00007ffff5ba9df8 in dtrsm_ () from /usr/lib/libblas.so.3
...
#3 0x00007ffff420df83 in ?? () from /.../numpy/linalg/_umath_linalg.so
Linux (or rather the GNU C library) provides the "backtrace" call (for getting a list of pointers from the call stack), and the "backtrace_symbols" call for automatically converting each of those pointers to a descriptive string such as:
"/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5) [0x7fc429929ec5]"
Gperftools can (judging from a query on the github mirror) call the generic "backtrace", but instead of "backtrace_symbols" it "forks out to pprof to do the actual symbolizing". This is a fairly-epic perl script, and looks likely where the "??" comes from.
Crucially, google-pprof is trying to report on the source-file (and line-number) which defines the function, not the binary-file containing the machine-code (that is typically quoted in stack traces). It invokes the "nm" utility. On my system it appears (by running "nm -l -D") that libblas, unlike libc and the python binary, has been stripped of such debugging symbols (presumably for optimisation), explaining the result.
To answer the original question: the call-stack samples should definitively and explicitly specify which version is being called. These can probably be dumped using an option which was added in google-pprof several months ago, or (for time-intensive functions) can be roughly ascertained by manual resampling using gdb. (It's even conceivable that g-pprof can be adjusted to explicitly identify the binaries paths in its output summaries.) Alternatively one can run "nm" (and grep) on the candidate binaries/libraries (of which a short-list can be obtained by running "strings" on the profiler's raw output, among other methods). If the source is accessible (to grep) or the libraries are popular (on the web) then of course (and per Mike Dunlavey) it may be easiest to just query for the function name. In theory the "??:?" may be addressed by carefully recompiling the offending objects.
Just Google the offending function names. The ones you show above are defined in LAPACK. dtrsm is for solving a matrix equation. dgemm is for multiplying matrices.
What you need to know is 1) why they are being called, and 2) how big the matrices are.
To find out why they are being called, what I do is just examine individual stack samples, as here.
The reason matrix size matters is if they are small, these LAPACK routines can actually spend a relatively large fraction of their time just classifying their inputs, such as by calling a function LSAME.
I am new to Julia, so this might be trivial.
I have a function definition within a module that looks like (using URIParser):
function add!(graph::Graph,
subject::URI,
predicate::URI,
object::URI)
...
end
Outside of the module, I call:
add!(g, URIParser.URI("http://test.org/1"), URIParser.URI("http://test.org/2"), URIParser.URI("http://test.org/1"))
Which gives me this error:
ERROR: no method add!(Graph,URI,URI,URI)
in include at boot.jl:238
in include_from_node1 at loading.jl:114
at /Users/jbaran/src/RDF/src/RDF.jl:79
Weird. Because when I can see a matching signature:
julia> methods(RDF.add!)
# 4 methods for generic function "add!":
add!(graph::Graph,subject::URI,predicate::URI,object::Number) at /Users/jbaran/src/RDF/src/RDF.jl:29
add!(graph::Graph,subject::URI,predicate::URI,object::String) at /Users/jbaran/src/RDF/src/RDF.jl:36
add!(graph::Graph,subject::URI,predicate::URI,object::URI) at /Users/jbaran/src/RDF/src/RDF.jl:43
add!(graph::Graph,statement::Statement) at /Users/jbaran/src/RDF/src/RDF.jl:68
At first I thought it was my use of object::Union(...), but even when I define three functions with Number, String, and URI, I get this error.
Is there something obvious that I am missing? I am using Julia 0.2.1 x86_64-apple-darwin12.5.0, by the way.
Thanks,
Kim
This looks like you may be getting bit by the very slight difference between method extension and function shadowing.
Here's the short of it. When you write function add!(::Graph, ...); …; end;, Julia looks at just your local scope and sees if add! is defined. If it is, then it will extend that function with this new method signature. But if it's not already defined locally, then Julia creates a new local variable add! for that function.
As JMW's comment suggests, I bet that you have two independent add! functions. Base.add! and RDF.add!. In your RDF module, you're shadowing the definition of Base.add!. This is similar to how you can name a local variable pi = 3 without affecting the real Base.pi in other scopes. But in this case, you want to merge your methods with the Base.add! function and let multiple dispatch take care of the resolution.
There are two ways to get the method extension behavior:
Within your module RDF scope, say import Base: add!. This explicitly brings Base.add! into your local scope as add!, allowing method extension.
Explicitly define your methods as function Base.add!(graph::Graph, …). I like this form as it more explicitly documents your intentions to extend the Base function at the definition site.
This could definitely be better documented. There's a short reference to this in the Modules section, and there's currently a pull request that should be merged soon that will help.
I have a program that draws shapes on an image. I have a separate namespace for each shape, and they are in separate files.
com/name/box.clj --> has com.name.box namespace.
com/name/triangle.clj --> has com.name.triangle namespace.
They all share a common function called generate that draws them on screen, so if I use use, function names clash.
For now, I load them with load-file. Is there a better way of doing this? Looking through the Clojure API, it seems there are multiple ways of including files. Which one is a better option for a project with lots of files?
I too started by using load-file. According to the Clojure documentation on libs,
Clojure defines conventions for naming and structuring libs:
* A lib name is a symbol that will typically contain two or more parts separated by periods.
* A lib's container is a Java resource whose classpath-relative path is derived from the lib name:
o The path is a string
o Periods in the lib name are replaced by slashes in the path
o Hyphens in the lib name are replaced by underscores in the path
o The path ends with ".clj"
* A lib begins with an "ns" form that
o creates the Clojure namespace that shares its name, and
o declares its dependencies on Java classes, Clojure's core facilities, and/or other libs
The Clojure documentation further provides the following example namespace declaration (which I'm sure you already know, but I'm providing it here for completeness):
(ns com.my-company.clojure.examples.my-utils
(:import java.util.Date)
(:use [clojure.contrib.def :only (defvar-)])
(:require [clojure.contrib.shell-out :as shell]))
So, my answer would be to use libs for your project -- it'll help simplify all of those folders. To "include" a lib, you'll use require, like this:
(require 'clojure.contrib.def 'clojure.contrib.except 'clojure.contrib.sql)
(require '(clojure.contrib def except sql))
As long as the documentation is correct and your project is classpath-relative, everything should happily load. Hope that answers your question. :D
Along with using namespace libs as already has been suggested perhaps your common 'generate' function is a candidate for a multimethod? http://clojure.org/multimethods
This would help avoid the function name clash and add a common abstraction to your 'shapes', I guess it depends on whether an appropriate dispatch function can be found.