# Tag Info

21

I started with the Julia code you had and also got ~20 seconds, so I think my timings are similar to yours. Let me give a step by step breakdown on how to do this. To start, notice that if you are running code in the REPL that variables defined there are global. This incurs a good performance cost. There are two ways to deal with this: 1) Wrap it all in a ...

6

in your MATLAB code, some unnecessary steps can be skipped. Here's a modification of your doStep function that should improve performance quite a bit. Each modif is explained in the comments within the code. doStep2.m function file: function [ newtv ] = doStep2( tv, fitnessf, mutrate, stdev ) % Function to calculate new offspring trait values from parent ...

6

Try swapping out the three arrays with calling a function iteratively---three Int64 arrays (each element 8 bytes) of ~100M elements is a lot. That is, switch out the body of the sum into a separate function: function foo(u) x = rand() y = rand() z = rand(u) (x^2 + y^2 <= 1) & (z <= x^4 + y^2) ? 1 : 0 end and replace the sum ...

6

Alright so I've done a lot of experimenting and the problem seems to be accessing data internal to a type via another type. Specifically accessing d.source.activation appears to be about 100 times more costly than just accessing d.augmented. If you replace d.source.activation with 1.0 you'll more than double the speed. It's also possible this is because ...

5

What you should be using is a neighboring matrix. The key is graph theory. You represent the graph with a matrix. For example: $\begin{bmatrix} 0 & 1 & 1 & 0 & 2 \\ 1 & 0 & 2 & 0 & 0 \\ 1 & 2 & 0 & 1 & 1 \\ 0 & 0 & 1 & 0 & 1 \\ 2 & 0 & 1 & 1 & 0 \\ \end{bmatrix}$ Here ...

5

I have optimized Feagin solvers in DifferentialEquations.jl. You can find the codes starting here. I know your question was about simplifying the code, but after really optimizing them, I believe that is the wrong direction (except for teaching purposes. For teaching, just put A in a sparse matrix, b,c as vectors, and go with it). The code needs to be ...

5

Regarding the rpois function, I think the preferred way of simulating a single value from a Poisson distribution with mean λ is using Distributions rand(Poisson(λ)) To fill out, a vector of Ints, with Poisson simulated values from a vector of means, p, you can use the mutating version of map. In v0.4 it is best to write a helper function r1(λ) = rand(...

5

The biggest problem with this code is the amount of things in global scope. Rewriting it to make some things const, and passing in the rest from a main function brings the time down to .7 seconds (not including the using plots which takes 3.5 seconds, compared to ~10 seconds before. Here is the updated code, I hope it helps. using Printf using Plots const ...

4

I think this is a good approach. Stylistically I think you've done a good job as well; you've use a descriptive variable name (line), good indentation (4 spaces is standard for Julia), and have made use of a function that returns an iterator, which will be more efficient for this purpose than, say, one that returns an array. The only thing I would do ...

3

I've also commented on the julia slack, but just if anyone else is reading, as I see you've not updated the question according to my comments. You can see Julia's general performance tips here. I suggest you read this. You are falling into at least two of the performance gotchas: You are initializing dUx, dUy and dUz as Ints first, but change their type ...

3

Firstly, practical comments regarding Julia implementation. The line: numberoffspring = [rand(Poisson(theta)) for theta in fitnessfunc(tv, n, k)] consumes a lot of time because fitnessfunc is a user defined function about which not enough is known during compilation. This can be fixed by adding a type assertion to the result thus: numberoffspring = [...

3

In Julia 0.4, the ops initialization causes a warning: WARNING: deprecated syntax "[a=>b, ...]" See below for preferred syntax. I don't remember if it works for Julia 0.3. The use of @eval twice, once to create functions and once to call them, seems circuitous. A dictionary that maps symbols to functions would be more direct. E.g.: ops = Dict( ...

3

In case you don't already know this ... Here is what the line [max(len(y) for y in x) for x in zip(*rp)] is doing. Say that rp = [('a', 'b', 'c', 'd'), ('aa', 'bbb', 'cccc', 'ddddd')] unzipped_rp = zip(*rp) # [('a', 'aa'), ('b', 'bbb'), ('c', 'cccc'), ('d', 'ddddd')] This code does almost the same as what the line above does ... max_lengths = [] for x ...

3

Coding Style "Methods", as in Functions which are part of a type are not Julianic. Instead use Functions with typed parameters Rather than ann.forward(input::Array{Float64,1}) use forward(ann::ANN2, input::Array{Float64,1}) Functions which mutate there inputs should end with a bang (!) So infact: forward!(ann::ANN2, input::Array{Float64,1}) It Vector{T} ...

3

I think the most performant solution here would be to create an iterator: julia> immutable EachRow{T<:AbstractMatrix} A::T end Base.start(::EachRow) = 1 Base.next(itr::EachRow, s) = (itr.A[s,:], s+1) Base.done(itr::EachRow, s) = s > size(itr.A,1) done (generic function with 48 methods) julia> AA = [1 2 3; ...

2

I am a newbee of Julia so cannot comment on good Julian ways of optimization. But when I tried running your code, I noticed that the major part of computational time is spent on the evaluation of exp() and log() rather than array handling etc. Below, I changed the iteration number in demo_LDA.jl to perform the test quickly as #... In demo_LDA.jl ...

2

You are giving very short names and commneting next to them the meaning const nbloci = 100 # length of the genome const N = 100 # Number individuals in the population const nbgenerations = 100 # number of generations const mu = 1/10^5 # mutation rate const s = 0.01 # effect of a given mutation on fitness It would ...

2

This change is predicated on the assumption that your program is currently giving you the correct output. If a BiasNode or InputNode is passed into either clear(...) or propDer(...) these functions will crash because they each access activationPrime, a field which is unique to type Node. If we change the parameter type of obj in each of these functions to ...

2

Ok, so I figured out what I was doing wrong. Basically I was completely misunderstanding the way the work-groups and work-items were supposed to break up. What I have in the code in my original post is 1 thread for each element of the matrix A, and then I broke each row of this matrix up into work-groups of size P. What I was supposed to do instead was ...

2

First, use a docstring instead of a comment: """Recursively walk a directory.""" function [ . . . ] Using a docstring allows Julia's built-in help features to work with your function. Next, I would recommend putting the function argument first: function dirwalk(fn::Function, path::AbstractString) Why? This allows dirwalk to be used with Julia's do block ...

2

The following is internally equivalent to @nybblet's answer, but uses nicer syntax instead of a manual loop: f((x,y,z)) = (x^2 + y^2 <= 1) & (z <= x^4 + y^2) function computeintegral(e, p, variance) N = floor(Int, variance / ((1-p)*((e/2)^2))) + 1 x = (rand() for _ in 1:N) y = (rand() for _ in 1:N) z = (2rand() for _ in 1:N) ...

2

MATLAB I don't have the Statistical Toolbox, so unfortunately I can't do any benchmarking to test this, but I believe the following points will increase the performance of your implementation. It will still be far slower than R though. My guess is that the functions that are part of the toolbox are the slow ones: normrnd, poissrnd (and possibly datasample) ...

2

I think this depends a lot on your motivation for separating these into two methods. One simple option I would consider first is to just have 1 version of each of these functions to avoid the duplication in the first place. The caller can just ignore the max_dist value if they don't need it. If performance is an issue and max_distcalculation could be a ...

2

It looks like you store the board after each movement for each possibility, that's a lot of arrays in memory, no wonder it fills your memory for your second example, your code looks for 157523 positions, which is half of the total possibilities. the number of permutations for 1:16 is enormous, the a-star algorithm is probably not sufficient even if you look ...

1

There's a CircularBuffer type in DataStructures, which does pretty much the same. Have a look at its code for some inspiration. Or reuse it, if it fits your needs and you don't hesitate to add that dependency. Regarding the point before, I'd especially recommend to implement the common interfaces, and probably iterate as well. remember! makes sense ...

1

The below code uses Julia 1.0. Full code as a Pkg3 project is available here. Preliminaries There's enough code for it to get its own module. This also makes testing easier. module Bernstein using Polynomials import Base: convert, promote_rule, show import LinearAlgebra: dot, norm import Polynomials: poly Since we're in a module, we must define the ...

1

I solved the same problem a few months ago, here's the code I used: name_scores_total() = name_scores_total(@__DIR__()*"/022data_names.txt") name_scores_total(names_file::String) = name_scores_total(vec(readdlm(names_file, ',', String))) function name_scores_total(names_list::Array{String}) sort!(names_list) alphabet_order = Dict((c, UInt8(c) - ...

1

the only change I would make is to remove your use of the Dict. Dicts are great when you need mutability, but here there is the much simpler solution Int(letter)-Int('A'). With this change, namescore becomes function namescore(name) return sum(Int(char)-Int('A') for letter in name[2:end-1]) end This, however is not ideal, as we can take out the ...

1

Since this will be used at toplevel anyway, I would just wrap all the parameters in a module. macro param_save(file, blk) modname = gensym() Expr(:toplevel, Expr(:using, :JLD), Expr(:module, false, modname, esc(blk)), quote JLD.save($file, Dict( string(n) => eval($modname, n) for ...

1

As mentioned by @roygvib one thing that helps is reformulating the math equations. I also fixed the memory problem. here is the parts that I changed. function LDA_sample_pp{T1, T2}( bayesian_components::Vector{T1}, xx::T2, nn::Array{Float64, 2}, pp::Vector{Float64}, aa::Float64, jj::Int64) K = length(pp) @inbounds for kk = 1:K ...

Only top voted, non community-wiki answers of a minimum length are eligible