[julia-users] fatal: 'XCB' does not appear to be a git repository, i tend to disagree...
Hello colleagues, might be a glitch somewhere, a missing file, a missing information... lobi@orange4:~/juliarepo$ ../julia04/julia _ _ _ _(_)_ | A fresh approach to technical computing (_) | (_) (_)| Documentation: http://docs.julialang.org _ _ _| |_ __ _ | Type help() for help. | | | | | | |/ _` | | | | |_| | | | (_| | | Version 0.4.0-dev+4829 (2015-05-14 14:22 UTC) _/ |\__'_|_|_|\__'_| | Commit 9a47c3b (9 days old master) |__/ | x86_64-linux-gnu julia Pkg.update() INFO: Updating METADATA... fatal: 'XCB' does not appear to be a git repository fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. ERROR: failed process: Process(`git pull --rebase -q`, ProcessExited(1)) [1] in pipeline_error at ./process.jl:512 in run at ./process.jl:486 in anonymous at ./pkg/entry.jl:252 in withenv at ./env.jl:179 in anonymous at ./pkg/entry.jl:251 in cd at ./file.jl:22 in update at ./pkg/entry.jl:255 in anonymous at ./pkg/dir.jl:31 in cd at ./file.jl:22 in cd at ./pkg/dir.jl:31 in update at ./pkg.jl:45 julia Pkg.dir() /home/lobi/.julia/v0.4 and there lobi@orange4:~/.julia/v0.4/XCB$ git status On branch master nothing to commit, working directory clean Everything else works and worked (afaics the previous day...). A good idea, what is wrong? Wishing a happy day, Andreas
[julia-users] Documentation system
Hi everyone, I'm just wondering, why markdown is being used for the built-in documentation as opposed to rst? I guess emergent convention? Since sphinx is used to build the manual, I would have preferred to have the same formatting at least as an option. I was able to successfully reuse inline rst documentation in python projects to build parts of the manual, saving myself to rewrite good chunks of text. But I admit I'm partial to rst because of that (I use it everywhere I can). Is md maybe slightly shorter or has some advantage I don't immediately see? Easier/faster to parse?
[julia-users] Re: fatal: 'XCB' does not appear to be a git repository, i tend to disagree...
Not a julia problem, git config and connection problems... Still, i wonder if Pkg.update() should stop in this case.
Re: [julia-users] Re: Question about modules and overloaded functions
On Sun, 2015-05-24 at 03:44, Cedric St-Jean cedric.stj...@gmail.com wrote: I'm not a big Julia user yet, but if it's anything like Common Lisp (and I think it is), then your problem is not with overloading - it's with symbols. A::f and B::f are two different symbols. To solve that, you want to have a module C that exports f (without necessarily defining anything there), and have using C at the top of both A and B. This will make sure that the *symbol* f referenced in A and B are the same. It's kinda like abstract-base-class inheritance. This was discussed here https://groups.google.com/forum/#!searchin/julia-dev/symbol$20lisp|sort:date/julia-dev/oLAQJTBL4sc/fpPL1J-SA_YJ I think Julia differs from Lisp that symbols do not have a module associated with them. Cedric On Saturday, May 23, 2015 at 5:35:37 PM UTC-4, Gabriel Goh wrote: Thanks for the help guys! The pointer to the discussion helped! It seems the most Juilesque way to do this is to drop the modules altogether. All the solutions suggested didn't feel very appealing. Gabe
Re: [julia-users] Documentation system
I'm just wondering, why markdown is being used for the built-in documentation as opposed to rst? I guess emergent convention? For documenting packages the standard is Lexicon/Docile.jl which do use Markdown. Since sphinx is used to build the manual, I would have preferred to have the same formatting at least as an option. I was able to successfully reuse inline rst documentation in python projects to build parts of the manual, saving myself to rewrite good chunks of text. But I admit I'm partial to rst because of that (I use it everywhere I can). Is md maybe slightly shorter or has some advantage I don't immediately see? Easier/faster to parse?
[julia-users] Re: fatal: 'XCB' does not appear to be a git repository, i tend to disagree...
Drop my previous comment... lobi@orange4:~/juliarepo$ ../julia04/julia _ _ _ _(_)_ | A fresh approach to technical computing (_) | (_) (_)| Documentation: http://docs.julialang.org _ _ _| |_ __ _ | Type help() for help. | | | | | | |/ _` | | | | |_| | | | (_| | | Version 0.4.0-dev+4829 (2015-05-14 14:22 UTC) _/ |\__'_|_|_|\__'_| | Commit 9a47c3b (9 days old master) |__/ | x86_64-linux-gnu julia Pkg.update() INFO: Updating METADATA... fatal: 'XCB' does not appear to be a git repository fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. ERROR: failed process: Process(`git pull --rebase -q`, ProcessExited(1)) [1] in pipeline_error at ./process.jl:512 in run at ./process.jl:486 in anonymous at ./pkg/entry.jl:252 in withenv at ./env.jl:179 in anonymous at ./pkg/entry.jl:251 in cd at ./file.jl:22 in update at ./pkg/entry.jl:255 in anonymous at ./pkg/dir.jl:31 in cd at ./file.jl:22 in cd at ./pkg/dir.jl:31 in update at ./pkg.jl:45 julia whilelobi@orange4:~/.julia/v0.4/XCB$ ls deps LICENSE LICENSE.md README.md src test lobi@orange4:~/.julia/v0.4/XCB$ git status On branch master Your branch is up-to-date with 'origin/master'. nothing to commit, working directory clean lobi@orange4:~/.julia/v0.4/XCB$ git pull --rebase -q lobi@orange4:~/.julia/v0.4/XCB$
[julia-users] Re: Julia Summer of Code
I'm interested in applying. I hope to contribute to the machine learning roadmap posted here: https://github.com/JuliaStats/Roadmap.jl/issues/11. I'm looking for a mentor. To apply, am i supposed to prepare a proposal similar to GSoC? On Friday, May 15, 2015 at 11:27:24 PM UTC+5:30, Viral Shah wrote: Folks, The Moore Foundation is generously funding us to allow for 6-8 Julia Summer of Code projects. Details will be published soon, but if you are interested, please mark your calendars and plan your projects. -viral
[julia-users] Re: Question about modules and overloaded functions
I'm not a big Julia user yet, but if it's anything like Common Lisp (and I think it is), then your problem is not with overloading - it's with symbols. A::f and B::f are two different symbols. To solve that, you want to have a module C that exports f (without necessarily defining anything there), and have using C at the top of both A and B. This will make sure that the *symbol* f referenced in A and B are the same. It's kinda like abstract-base-class inheritance. Cedric On Saturday, May 23, 2015 at 5:35:37 PM UTC-4, Gabriel Goh wrote: Thanks for the help guys! The pointer to the discussion helped! It seems the most Juilesque way to do this is to drop the modules altogether. All the solutions suggested didn't feel very appealing. Gabe
Re: [julia-users] Documentation system
Ease of reading and writing are definitely the most important factors (for humans more so than computers). Doc strings are often read in the source file or in a terminal, for example, so they need to be readable as-is, and writing them shouldn't be a burden. Actually though, Markdown is just the default – you can use anything you want for docs, including RST. Just create an rstblah string macro that builds an RST(blah) object, or similar, and you're halfway there. Of course, you'll miss out on tooling we build for Markdown (e.g. formatting in the repl, text searches etc.) unless you implement it yourself. But you could make an RSTDoc package that does all of that stuff, if you really want it. On 24 May 2015 at 14:54, Yuri D'Elia wav...@thregr.org wrote: Hi everyone, I'm just wondering, why markdown is being used for the built-in documentation as opposed to rst? I guess emergent convention? Since sphinx is used to build the manual, I would have preferred to have the same formatting at least as an option. I was able to successfully reuse inline rst documentation in python projects to build parts of the manual, saving myself to rewrite good chunks of text. But I admit I'm partial to rst because of that (I use it everywhere I can). Is md maybe slightly shorter or has some advantage I don't immediately see? Easier/faster to parse?
[julia-users] Re: Documentation system
On 05/24/2015 04:29 PM, Mike Innes wrote: Ease of reading and writing are definitely the most important factors (for humans more so than computers). Doc strings are often read in the source file or in a terminal, for example, so they need to be readable as-is, and writing them shouldn't be a burden. I never felt a significant difference in readability of md compared to rst. rst might be slightly harder to write due some extra specialized syntax, but then again md tends to be slightly more verbose because of that so there's never a clean winner. But overall the resulting source text is very similar. What I really appreciate with rst is that you can basically write a book out of the box (inline math!) and there's exactly one spec, while md has always a different subset of features which trips me every time. Actually though, Markdown is just the default – you can use anything you want for docs, including RST. Just create an rstblah string macro that builds an RST(blah) object, or similar, and you're halfway there. Of course, you'll miss out on tooling we build for Markdown (e.g. formatting in the repl, text searches etc.) unless you implement it yourself. But you could make an RSTDoc package that does all of that stuff, if you really want it. It was mostly a curiosity. But I keep thinking about that nicely formatted inline-math in ijulia while browsing documentation ;)
[julia-users] size of a Tuple type in 0.4
Is there a simple way, in 0.4, given the type of a tuple, to know how many entries it has? When types of tuples were themselves tuples you could just use length, but that no longer works. (I don't have a desperately important use case, it's just the hacky way I wrote some tests in some code I am bringing up-to-date) Thanks, Andrew
[julia-users] Re: fatal: 'XCB' does not appear to be a git repository, i tend to disagree...
there's the file REQUIRE in ~/.julia/vVERSION if that is ok try Pkg.resolve() On Sunday, 24 May 2015 14:53:21 UTC-3, Andreas Lobinger wrote: Or too much information. On Sunday, May 24, 2015 at 10:43:29 AM UTC+2, Andreas Lobinger wrote: Hello colleagues, might be a glitch somewhere, a missing file, a missing information... I deleted the XCB package from my .v0.4 package directory and still get the same error - which is partially correct, as XCB is in this sense not a valid git repository anymore. Does pkg have some information stored?
Re: [julia-users] Avoid memory allocations when reading from matrices
Loop code
# TODO: figure out memory issuefunction train!(m::Model, s::Adagrad; xmax=100,
alpha=0.75)J = 0.0shuffle!(m.covec)vecsize = size(m.W_main, 1)
eltype = typeof(m.b_main[1])vm = zeros(eltype, vecsize)vc =
zeros(eltype, vecsize)grad_main = zeros(eltype, vecsize)grad_ctx =
zeros(eltype, vecsize)for n=1:s.niter# shuffle indicesfor i
= 1:length(m.covec)@inbounds l1 = m.covec[i].i # main index
@inbounds l2 = m.covec[i].j # context index@inbounds v =
m.covec[i].v#= vm[:] = m.W_main[:, l1] =##= vc[:] =
m.W_ctx[:, l2] =#@inbounds for j = 1:vecsizevm[j] =
m.W_main[j, l1]vc[j] = m.W_ctx[j, l2]end
diff = dot(vec(vm), vec(vc)) + m.b_main[l1] + m.b_ctx[l2] - log(v)
fdiff = ifelse(v xmax, (v / xmax) ^ alpha, 1.0) * diffJ += 0.5 *
fdiff * difffdiff *= s.lrate# inc memory by ~200 MB
running time by 2x#= grad_main[:] = fdiff * m.W_ctx[:, l2] =#
#= grad_ctx[:] = fdiff * m.W_main[:, l1] =#@inbounds for j =
1:vecsizegrad_main[j] = fdiff * m.W_ctx[j, l2]
grad_ctx[j] = fdiff * m.W_main[j, l1]end# Adaptive
learning# inc ~ 600MB + 0.75s#= m.W_main[:, l1] -=
grad_main ./ sqrt(m.W_main_grad[:, l1]) =##= m.W_ctx[:, l2] -=
grad_ctx ./ sqrt(m.W_ctx_grad[:, l2]) =##= m.b_main[l1] -= fdiff ./
sqrt(m.b_main_grad[l1]) =##= m.b_ctx[l2] -= fdiff ./
sqrt(m.b_ctx_grad[l2]) =#@inbounds for j = 1:vecsize
m.W_main[j, l1] -= grad_main[j] / sqrt(m.W_main_grad[j, l1])
m.W_ctx[j, l2] -= grad_ctx[j] / sqrt(m.W_ctx_grad[j, l2])end
m.b_main[l1] -= fdiff ./ sqrt(m.b_main_grad[l1])m.b_ctx[l2] -=
fdiff ./ sqrt(m.b_ctx_grad[l2])# Gradientsfdiff *=
fdiff#= m.W_main_grad[:, l1] += grad_main .^ 2 =##=
m.W_ctx_grad[:, l2] += grad_ctx .^ 2 =##= m.b_main_grad[l1] +=
fdiff =##= m.b_ctx_grad[l2] += fdiff =#@inbounds for j
= 1:vecsizem.W_main_grad[j, l1] += grad_main[j] ^ 2
m.W_ctx_grad[j, l2] += grad_ctx[j] ^ 2end
m.b_main_grad[l1] += fdiffm.b_ctx_grad[l2] += fdiffend
#= if n % 10 == 0 =##= println(iteration $n, cost $J) =#
#= end =#endend
Mixmax [https://emailapps.mixmax.com/img/badge_mixmax.png]
[https://mixmax.com/r/YQkS9vBkBR3wSpESz] Not using Mixmax yet?
[https://mixmax.com/r/YQkS9vBkBR3wSpESz]
And the respective timings
@time GloVe.train!(model, GloVe.Adagrad(500)) 7.097 seconds (96237 k
allocations: 1468 MB, 7.01% gc time)
Slower and more memory.
On Sun, May 24, 2015 at 4:21 AM, Mauro mauro...@runbox.com
[mauro...@runbox.com] wrote:
Loops should run without allocations. Can you post your loop-code?
A[i, :] = 0.5 * B[i, :]
To state the obvious, as loop:
for j=1:size(A,2)
A[i,j] = 0.5 * B[i,j]
end
this shouldn't allocate, if i is an integer. Unless A and B have
different type, then allocation might happen.
On Sun, 2015-05-24 at 05:00, Dom Luna dluna...@gmail.com [dluna...@gmail.com]
wrote:
Reposting this from Gitter chat since it seems this is more active.
I'm writing a GloVe module to learn Julia.
How can I avoid memory allocations? My main function deals with a lot of
random indexing in Matrices.
A[i, :] = 0.5 * B[i, :]
In this case* i* isn't from a linear sequence. I'm not sure that matters.
Anyway, I’ve done analysis and I know B[i, :] is the issue here since it’s
creating a copy.
https://github.com/JuliaLang/ julia/blob/master/base/array. jl#L309
[https://github.com/JuliaLang/julia/blob/master/base/array.jl#L309] makes the
copy
I tried to do it via loop but it looks like that doesn’t help either. In
fact, it seems to allocate slight more memory which seems really odd.
Here’s some of the code, it’s a little messy since I’m commenting different
approaches I’m trying out.
type Model{T}
W_main::Matrix{T}
W_ctx::Matrix{T}
b_main::Vector{T}
b_ctx::Vector{T}
W_main_grad::Matrix{T}
W_ctx_grad::Matrix{T}
b_main_grad::Vector{T}
b_ctx_grad::Vector{T}
covec::Vector{Cooccurence}
end
# Each vocab word in associated with a main vector and a context vector.
# The paper initializes the to values [-0.5, 0.5] / vecsize+1 and
# the gradients to 1.0.
#
# The +1 term is for the bias.
function Model(comatrix; vecsize=100)
vs = size(comatrix, 1)
Model(
(rand(vecsize, vs) - 0.5) / (vecsize + 1),
(rand(vecsize, vs) - 0.5) / (vecsize + 1),
(rand(vs) - 0.5) / (vecsize + 1),
(rand(vs) - 0.5) / (vecsize + 1),
ones(vecsize, vs),
ones(vecsize, vs),
ones(vs),
ones(vs),
CoVector(comatrix), # not required in 0.4
)
end
# TODO: figure out memory issue
Re: [julia-users] supporting multiple julia releases ina single source file
There is this issue, which I think would do what you want:
https://github.com/JuliaLang/julia/issues/7449
On Sun, 2015-05-24 at 19:26, andrew cooke and...@acooke.org wrote:
Julia 0.4 has changed the rand! api (in a good way - the generator is now
explicit) and I am wondering whether I can support both in a single code
base.
What I'd really like, being old fashioned and simple, is something like
cpp's macros that let me switch between two different sets of code:
#ifdef 0.4
rand!{...}(...) = ...
#else
rand!{...}(...) = ...
#endif
That seems like it would be simple and easy for me to understand and read
and maintain in the future.
It also seems like it should be possible with macros, so I wondered if
anyone had done so?
(I did look at the Compat package, but it doesn't seem to support this
particular issue).
Does anything like this exist?
Thanks,
Andrew
[julia-users] Re: supporting multiple julia releases ina single source file
Here is an example:
if VERSION v0.4-
typealias AbstractString String
endif
On Sunday, May 24, 2015 at 1:26:19 PM UTC-4, andrew cooke wrote:
Julia 0.4 has changed the rand! api (in a good way - the generator is now
explicit) and I am wondering whether I can support both in a single code
base.
What I'd really like, being old fashioned and simple, is something like
cpp's macros that let me switch between two different sets of code:
#ifdef 0.4
rand!{...}(...) = ...
#else
rand!{...}(...) = ...
#endif
That seems like it would be simple and easy for me to understand and read
and maintain in the future.
It also seems like it should be possible with macros, so I wondered if
anyone had done so?
(I did look at the Compat package, but it doesn't seem to support this
particular issue).
Does anything like this exist?
Thanks,
Andrew
[julia-users] Re: fatal: 'XCB' does not appear to be a git repository, i tend to disagree...
Or too much information. On Sunday, May 24, 2015 at 10:43:29 AM UTC+2, Andreas Lobinger wrote: Hello colleagues, might be a glitch somewhere, a missing file, a missing information... I deleted the XCB package from my .v0.4 package directory and still get the same error - which is partially correct, as XCB is in this sense not a valid git repository anymore. Does pkg have some information stored?
Re: [julia-users] Avoid memory allocations when reading from matrices
The problem is in:
type Model{T}
W_main::Matrix{T}
W_ctx::Matrix{T}
b_main::Vector{T}
b_ctx::Vector{T}
W_main_grad::Matrix{T}
W_ctx_grad::Matrix{T}
b_main_grad::Vector{T}
b_ctx_grad::Vector{T}
covec::Vector{Cooccurence} # - needs to be concrete type
end
Instead use
covec::Vector{Cooccurence{Int,Int,T}}
or some more complicated parameterisation.
Then, when testing timings you usually do one warm-up to exclude
compilation time:
GloVe.train!(model, solver) # warm up
@time 1 # @time needs a warm up too
@time GloVe.train!(model, solver)
Timings I get:
stock clone from github:
elapsed time: 0.001617218 seconds (2419024 bytes allocated)
with improvements mentioned above:
elapsed time: 0.001344645 seconds (2335552 bytes allocated)
with improvements mentioned above and your loop-version:
elapsed time: 0.00030488 seconds (3632 bytes allocated)
Hope that helps.
On Sun, 2015-05-24 at 19:21, Dominique Luna dluna...@gmail.com wrote:
Loop code
# TODO: figure out memory issue
function train!(m::Model, s::Adagrad; xmax=100, alpha=0.75)
J = 0.0
shuffle!(m.covec)
vecsize = size(m.W_main, 1)
eltype = typeof(m.b_main[1])
vm = zeros(eltype, vecsize)
vc = zeros(eltype, vecsize)
grad_main = zeros(eltype, vecsize)
grad_ctx = zeros(eltype, vecsize)
for n=1:s.niter
# shuffle indices
for i = 1:length(m.covec)
@inbounds l1 = m.covec[i].i # main index
@inbounds l2 = m.covec[i].j # context index
@inbounds v = m.covec[i].v
#= vm[:] = m.W_main[:, l1] =#
#= vc[:] = m.W_ctx[:, l2] =#
@inbounds for j = 1:vecsize
vm[j] = m.W_main[j, l1]
vc[j] = m.W_ctx[j, l2]
end
diff = dot(vec(vm), vec(vc)) + m.b_main[l1] + m.b_ctx[l2] - log(v)
fdiff = ifelse(v xmax, (v / xmax) ^ alpha, 1.0) * diff
J += 0.5 * fdiff * diff
fdiff *= s.lrate
# inc memory by ~200 MB running time by 2x
#= grad_main[:] = fdiff * m.W_ctx[:, l2] =#
#= grad_ctx[:] = fdiff * m.W_main[:, l1] =#
@inbounds for j = 1:vecsize
grad_main[j] = fdiff * m.W_ctx[j, l2]
grad_ctx[j] = fdiff * m.W_main[j, l1]
end
# Adaptive learning
# inc ~ 600MB + 0.75s
#= m.W_main[:, l1] -= grad_main ./ sqrt(m.W_main_grad[:, l1]) =#
#= m.W_ctx[:, l2] -= grad_ctx ./ sqrt(m.W_ctx_grad[:, l2]) =#
#= m.b_main[l1] -= fdiff ./ sqrt(m.b_main_grad[l1]) =#
#= m.b_ctx[l2] -= fdiff ./ sqrt(m.b_ctx_grad[l2]) =#
@inbounds for j = 1:vecsize
m.W_main[j, l1] -= grad_main[j] / sqrt(m.W_main_grad[j, l1])
m.W_ctx[j, l2] -= grad_ctx[j] / sqrt(m.W_ctx_grad[j, l2])
end
m.b_main[l1] -= fdiff ./ sqrt(m.b_main_grad[l1])
m.b_ctx[l2] -= fdiff ./ sqrt(m.b_ctx_grad[l2])
# Gradients
fdiff *= fdiff
#= m.W_main_grad[:, l1] += grad_main .^ 2 =#
#= m.W_ctx_grad[:, l2] += grad_ctx .^ 2 =#
#= m.b_main_grad[l1] += fdiff =#
#= m.b_ctx_grad[l2] += fdiff =#
@inbounds for j = 1:vecsize
m.W_main_grad[j, l1] += grad_main[j] ^ 2
m.W_ctx_grad[j, l2] += grad_ctx[j] ^ 2
end
m.b_main_grad[l1] += fdiff
m.b_ctx_grad[l2] += fdiff
end
#= if n % 10 == 0 =#
#= println(iteration $n, cost $J) =#
#= end =#
end
end
Mixmax Not using Mixmax yet?
And the respective timings
@time GloVe.train!(model, GloVe.Adagrad(500))
7.097 seconds (96237 k allocations: 1468 MB, 7.01% gc time)
Slower and more memory.
On Sun, May 24, 2015 at 4:21 AM, Mauro mauro...@runbox.com wrote:
Loops should run without allocations. Can you post your loop-code?
A[i, :] = 0.5 * B[i, :]
To state the obvious, as loop:
for j=1:size(A,2)
A[i,j] = 0.5 * B[i,j]
end
this shouldn't allocate, if i is an integer. Unless A and B have
different type, then allocation might happen.
On Sun, 2015-05-24 at 05:00, Dom Luna dluna...@gmail.com wrote:
Reposting this from Gitter chat since it seems this is more active.
I'm writing a GloVe module to learn Julia.
How can I avoid memory allocations? My main function deals with a lot of
random indexing in Matrices.
A[i, :] = 0.5 * B[i, :]
In this case* i* isn't from a linear sequence. I'm not sure that
matters.
Anyway, I’ve done analysis and I know B[i, :] is the issue here since
it’s
creating a copy.
https://github.com/JuliaLang/julia/blob/master/base/array.jl#L309 makes
the
copy
I tried to do it via
[julia-users] supporting multiple julia releases ina single source file
Julia 0.4 has changed the rand! api (in a good way - the generator is now
explicit) and I am wondering whether I can support both in a single code
base.
What I'd really like, being old fashioned and simple, is something like
cpp's macros that let me switch between two different sets of code:
#ifdef 0.4
rand!{...}(...) = ...
#else
rand!{...}(...) = ...
#endif
That seems like it would be simple and easy for me to understand and read
and maintain in the future.
It also seems like it should be possible with macros, so I wondered if
anyone had done so?
(I did look at the Compat package, but it doesn't seem to support this
particular issue).
Does anything like this exist?
Thanks,
Andrew
Re: [julia-users] size of a Tuple type in 0.4
On Sun, May 24, 2015 at 3:13 PM, andrew cooke and...@acooke.org wrote:
Is there a simple way, in 0.4, given the type of a tuple, to know how many
entries it has?
When types of tuples were themselves tuples you could just use length, but
that no longer works.
```
julia typeof((1, 2, 3))
Tuple{Int64,Int64,Int64}
julia typeof((1, 2, 3)).parameters
svec(Int64,Int64,Int64)
julia length(typeof((1, 2, 3)).parameters)
3
```
works for other parametrized types as well.
(I don't have a desperately important use case, it's just the hacky way I
wrote some tests in some code I am bringing up-to-date)
Thanks,
Andrew
[julia-users] Re: supporting multiple julia releases ina single source file
you're right. i was worrying too much. this is all i need. thanks, andrew
On Sunday, 24 May 2015 14:49:54 UTC-3, Scott Jones wrote:
Here is an example:
if VERSION v0.4-
typealias AbstractString String
endif
On Sunday, May 24, 2015 at 1:26:19 PM UTC-4, andrew cooke wrote:
Julia 0.4 has changed the rand! api (in a good way - the generator is now
explicit) and I am wondering whether I can support both in a single code
base.
What I'd really like, being old fashioned and simple, is something like
cpp's macros that let me switch between two different sets of code:
#ifdef 0.4
rand!{...}(...) = ...
#else
rand!{...}(...) = ...
#endif
That seems like it would be simple and easy for me to understand and read
and maintain in the future.
It also seems like it should be possible with macros, so I wondered if
anyone had done so?
(I did look at the Compat package, but it doesn't seem to support this
particular issue).
Does anything like this exist?
Thanks,
Andrew
Re: [julia-users] supporting multiple julia releases ina single source file
that's interesting, and what i was looking for, but as they say there, you
don't need this unless there's a change to syntax that fuddles the parser.
so i can just use if. duh! cheers, andrew
On Sunday, 24 May 2015 14:50:22 UTC-3, Mauro wrote:
There is this issue, which I think would do what you want:
https://github.com/JuliaLang/julia/issues/7449
On Sun, 2015-05-24 at 19:26, andrew cooke and...@acooke.org javascript:
wrote:
Julia 0.4 has changed the rand! api (in a good way - the generator is
now
explicit) and I am wondering whether I can support both in a single code
base.
What I'd really like, being old fashioned and simple, is something like
cpp's macros that let me switch between two different sets of code:
#ifdef 0.4
rand!{...}(...) = ...
#else
rand!{...}(...) = ...
#endif
That seems like it would be simple and easy for me to understand and
read
and maintain in the future.
It also seems like it should be possible with macros, so I wondered if
anyone had done so?
(I did look at the Compat package, but it doesn't seem to support this
particular issue).
Does anything like this exist?
Thanks,
Andrew
[julia-users] Reduction of multiple variables in parallel for-loop
Is it possible to perform reduction on more than one variable in the case where the loop is computing more than one quantity? I tried doing something like this: var1=zeros(Float64,10,4) var2=zeros(Complex128,10,1) @parallel (+) for m=1:10 var1[m,:] = [m,2*m,3*m,4*m] var2[m] = m (var1, var2) end but the addition method cannot add that type... The goal here is to fill two arrays where each loop computes a specific element. I figured that simply adding each end of loop array (which would not overlap since all non-modified entries are zeroes) would be more simple than using a shared array. Thanks, Jeremy
[julia-users] Re: Julia Summer of Code
I'm willing to participate in JSoC on the reverse-mode AD. I'm looking for a mentor. If you know someone that could oversee this, don't hesitate to get in touch! With some experience in Julia as well as in optimization and MCMC, I believe I can move this project forward. Cheers, Ken Bastiaensen On Thursday, 21 May 2015 22:50:04 UTC+2, Miles Lubin wrote: Agreed. There's a lot to be done with reverse-mode AD, though the full scale of the work is beyond that of a summer project. FYI, Theodore and I will be working with Jarrett Revels on the project we proposed around DualNumbers and extensions. Hoping to share the results at the end of the summer! On Thursday, May 21, 2015 at 4:27:27 PM UTC-4, Zenna Tavares wrote: Echoing Miles, I vote for working to extend automatic differentiation (especially reverse mode) to all of Julia. The work done in the current AD packages is great, but Julia has sufficiently powerful introspection and metaprogramming capabilities that we shouldn't, in principle, be limited to small subsets of Julia. I'm not sure I am the one to work on it though. Zenna On Tuesday, May 19, 2015 at 2:52:00 PM UTC-4, Jeff Waller wrote: Is this the part where I say Julia-Spark again? I think this is pretty doable in time. It will likely be more or less a port of PySpark https://github.com/apache/spark/tree/master/python/pyspark since Julia and Python are similar in capability. I think I counted about 6K lines (including comments). According to the pyspark presentation https://www.youtube.com/watch?v=xc7Lc8RA8wE, they relied on a 3rd party to containerize a Python program for transmission -- I think I'm remembering this right. That might be a problem to overcome.
[julia-users] How does Julia's @spawnat initialize variables on remote worker process?
Hi, Below is some output; that I can't completely understand. Specifically, where are variables d,e,f after they are initialized? Are they created and destroyed dynamically on worker 2? julia a,b,c (10,20,30) julia whos() Base Module Core Module Main Module a Int64 ans (Int64,Int64,Int64) b Int64 c Int64 julia fetch(@spawnat 2 whos()) From worker 2: Base Module From worker 2: Core Module From worker 2: Main Module julia fetch(@spawnat 2 d,e,f = (a,b,c)) (10,20,30) julia fetch(@spawnat 2 whos()) From worker 2: Base Module From worker 2: Core Module From worker 2: Main Module julia whos() Base Module Core Module Main Module a Int64 ans Nothing b Int64 c Int64 My full post on StackOverFlow is http://stackoverflow.com/questions/30407724/how-does-julias-spawnat-initialize-variables-on-remote-worker-process Thanks, GS
Re: [julia-users] Julia Summer of Code
Viral -- Given the clear interest in it, I'll work toward fleshing it out more fully. However, if anyone is interested in contributing I'd gladly take the help. On Fri, May 22, 2015 at 9:02 PM, Viral Shah vi...@mayin.org wrote: Jey - just checking if you are listing what the project needs - or if you would be able to participate to build these? -viral On 23-May-2015, at 7:54 am, Jey Kottalam j...@cs.berkeley.edu wrote: The core functionality is there, but there's also more to be implemented to have a complete interface to spark-core: - distributed I/O - broadcast vars - accumulator vars - custom partitioners - persistence (caching) - missing transforms and actions -Jey On Fri, May 22, 2015 at 12:46 AM, Jeff Waller truth...@gmail.com wrote: On Thursday, May 21, 2015 at 4:55:16 PM UTC-4, Jey Kottalam wrote: Hi Jeff, they relied on a 3rd party to containerize a Pythonprogram for transmission That is due to the pecularities of Python's serialization module than anything intrinsic to creating a Spark binding. (E.g. Python's pickle format doesn't have support for serializing code and closures, so some extra code was required.) This isn't an issue in Julia since Base.serialize() already has the needed functionality. An initial implementation of a Spark binding done in the same style as PySpark is available at http://github.com/jey/Spock.jl -Jey Hey awesome. Initial you say, what's missing?
[julia-users] Re: Julia Summer of Code
Am applying with the Equations package along with a ongoing project to develop a course and offer bounties to contributors in the developing world. Sort of already have a mentor, the director of the information technology institute at Vietnam national university Aiviet Nguyen who invited the development of the Equations package to be part of his research, however he is not a Julia expert. Is there someone who would like to attach to the project as a mentor in areas not covered by Dr Nguyen? If the project is accepted for JSoC all compensation will be pledged for expanding the project and you will be given power of veto over any suggested expenses.
Re: [julia-users] Avoid memory allocations when reading from matrices
Loops should run without allocations. Can you post your loop-code?
A[i, :] = 0.5 * B[i, :]
To state the obvious, as loop:
for j=1:size(A,2)
A[i,j] = 0.5 * B[i,j]
end
this shouldn't allocate, if i is an integer. Unless A and B have
different type, then allocation might happen.
On Sun, 2015-05-24 at 05:00, Dom Luna dluna...@gmail.com wrote:
Reposting this from Gitter chat since it seems this is more active.
I'm writing a GloVe module to learn Julia.
How can I avoid memory allocations? My main function deals with a lot of
random indexing in Matrices.
A[i, :] = 0.5 * B[i, :]
In this case* i* isn't from a linear sequence. I'm not sure that matters.
Anyway, I've done analysis and I know B[i, :] is the issue here since it's
creating a copy.
https://github.com/JuliaLang/julia/blob/master/base/array.jl#L309 makes the
copy
I tried to do it via loop but it looks like that doesn't help either. In
fact, it seems to allocate slight more memory which seems really odd.
Here's some of the code, it's a little messy since I'm commenting different
approaches I'm trying out.
type Model{T}
W_main::Matrix{T}
W_ctx::Matrix{T}
b_main::Vector{T}
b_ctx::Vector{T}
W_main_grad::Matrix{T}
W_ctx_grad::Matrix{T}
b_main_grad::Vector{T}
b_ctx_grad::Vector{T}
covec::Vector{Cooccurence}
end
# Each vocab word in associated with a main vector and a context vector.
# The paper initializes the to values [-0.5, 0.5] / vecsize+1 and
# the gradients to 1.0.
#
# The +1 term is for the bias.
function Model(comatrix; vecsize=100)
vs = size(comatrix, 1)
Model(
(rand(vecsize, vs) - 0.5) / (vecsize + 1),
(rand(vecsize, vs) - 0.5) / (vecsize + 1),
(rand(vs) - 0.5) / (vecsize + 1),
(rand(vs) - 0.5) / (vecsize + 1),
ones(vecsize, vs),
ones(vecsize, vs),
ones(vs),
ones(vs),
CoVector(comatrix), # not required in 0.4
)
end
# TODO: figure out memory issue
# the memory comments are from 500 loop test with vecsize=100
function train!(m::Model, s::Adagrad; xmax=100, alpha=0.75)
J = 0.0
shuffle!(m.covec)
vecsize = size(m.W_main, 1)
eltype = typeof(m.b_main[1])
vm = zeros(eltype, vecsize)
vc = zeros(eltype, vecsize)
grad_main = zeros(eltype, vecsize)
grad_ctx = zeros(eltype, vecsize)
for n=1:s.niter
# shuffle indices
for i = 1:length(m.covec)
@inbounds l1 = m.covec[i].i # main index
@inbounds l2 = m.covec[i].j # context index
@inbounds v = m.covec[i].v
vm[:] = m.W_main[:, l1]
vc[:] = m.W_ctx[:, l2]
diff = dot(vec(vm), vec(vc)) + m.b_main[l1] + m.b_ctx[l2] -
log(v)
fdiff = ifelse(v xmax, (v / xmax) ^ alpha, 1.0) * diff
J += 0.5 * fdiff * diff
fdiff *= s.lrate
# inc memory by ~200 MB running time by 2x
grad_main[:] = fdiff * m.W_ctx[:, l2]
grad_ctx[:] = fdiff * m.W_main[:, l1]
# Adaptive learning
# inc ~ 600MB + 0.75s
#= @inbounds for ii = 1:vecsize =#
#= m.W_main[ii, l1] -= grad_main[ii] /
sqrt(m.W_main_grad[ii, l1]) =#
#= m.W_ctx[ii, l2] -= grad_ctx[ii] / sqrt(m.W_ctx_grad[ii,
l2]) =#
#= m.b_main[l1] -= fdiff ./ sqrt(m.b_main_grad[l1]) =#
#= m.b_ctx[l2] -= fdiff ./ sqrt(m.b_ctx_grad[l2]) =#
#= end =#
m.W_main[:, l1] -= grad_main ./ sqrt(m.W_main_grad[:, l1])
m.W_ctx[:, l2] -= grad_ctx ./ sqrt(m.W_ctx_grad[:, l2])
m.b_main[l1] -= fdiff ./ sqrt(m.b_main_grad[l1])
m.b_ctx[l2] -= fdiff ./ sqrt(m.b_ctx_grad[l2])
# Gradients
fdiff *= fdiff
m.W_main_grad[:, l1] += grad_main .^ 2
m.W_ctx_grad[:, l2] += grad_ctx .^ 2
m.b_main_grad[l1] += fdiff
m.b_ctx_grad[l2] += fdiff
end
#= if n % 10 == 0 =#
#= println(iteration $n, cost $J) =#
#= end =#
end
end
Here's the entire repo https://github.com/domluna/GloVe.jl. Might be
helpful.
I tried doing some loops but it allocates more memory (oddly enough) and
gets slower.
You'll notice the word vectors are indexed by column, I changed the
representation to that
seeing if it would make a difference during the loop. It didn't seem to.
The memory analysis showed
Julia Version 0.4.0-dev+4893
Commit eb5da26* (2015-05-19 11:51 UTC)
Platform Info:
System: Darwin (x86_64-apple-darwin14.4.0)
CPU: Intel(R) Core(TM) i5-2557M CPU @ 1.70GHz
WORD_SIZE: 64
BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Sandybridge)
LAPACK: libopenblas
LIBM: libopenlibm
LLVM: libLLVM-3.3
Here model consists of 100x19 Matrices and 100 element vectors, 19 words in
the vocab, 100 element word vector.
