[julia-users] ReadOnlyMemoryError() after Pkg.init()??

[Tony Kelman]

Was this by any chance a source build in the same git clone where you had 
previously compiled the master 0.6-dev branch of julia?

[julia-users] Re: Cannot find why Stack Overflow problem appears

[Aleksandr Mikheev]

I used debug tools, found out that something doesn't work when I try to 
insert a point into the node which already contains a point, and they both 
should go to the same subnode. For instance,


particles[1] = particle([0.1, 0.1, 0.1], 1.0, [0.0,0.0,0.0], [0.0,0.0,0.0])

tree = InsertParticle(1,1,tree,particles)

particles[2] = particle([0.13, 0.2, 0.15], 1.0, [0.0,0.0,0.0], [0.0,0.0,0.0
])

tree = InsertParticle(2,1,tree,particles)



leads to infinite loop. However, I cannot see the reason. 

Re: [julia-users] Handling non-convergence in roots.jl

[Joaquim Masset Lacombe Dias Garcia]

Thanks!

On Thu, Nov 10, 2016 at 6:03 PM, Mauro  wrote:

>
> On Thu, 2016-11-10 at 20:07, Mauro  wrote:
> > On Thu, 2016-11-10 at 18:54, Joaquim Masset Lacombe Dias Garcia <
> joaquimdgar...@gmail.com> wrote:
> >> I am running a sequence of root finding functions in a loop.
> >> For my problem the basic fzero always work.
> >>
> >> However, using Newtons method is very useful because it is very fast
> when
> >> it converges.
> >> The problem is that when it does not converge it throws an error
> instead of
> >> a non-convergence flag.
> >>
> >> That way I cant use the fzero when newton fails (actually try/catch
> works
> >> but its very slow).
> >>
> >> Any suggestions?
> >
> > Just modify the Roots.jl package.
>
> To be a bit more informative:  The error gets thrown here:
> https://github.com/JuliaMath/Roots.jl/blob/943cf897e9ea6b31ab3ec70238ac49
> 31065d365a/src/derivative_free.jl#L45
>
> In that function, modify all occurrences of
>   throw(ConvergenceFailed("some message"))
> with
>   ( warn("some message"); return true)
>
> Restart the REPL
>
> Then it should not throw but warn and return the best value it found.
>

Re: [julia-users] Handling non-convergence in roots.jl

[Mauro]

On Thu, 2016-11-10 at 18:54, Joaquim Masset Lacombe Dias Garcia 
 wrote:
> I am running a sequence of root finding functions in a loop.
> For my problem the basic fzero always work.
>
> However, using Newtons method is very useful because it is very fast when
> it converges.
> The problem is that when it does not converge it throws an error instead of
> a non-convergence flag.
>
> That way I cant use the fzero when newton fails (actually try/catch works
> but its very slow).
>
> Any suggestions?

Just modify the Roots.jl package.

[julia-users] Handling non-convergence in roots.jl

[Joaquim Masset Lacombe Dias Garcia]

I am running a sequence of root finding functions in a loop.
For my problem the basic fzero always work.

However, using Newtons method is very useful because it is very fast when 
it converges.
The problem is that when it does not converge it throws an error instead of 
a non-convergence flag.

That way I cant use the fzero when newton fails (actually try/catch works 
but its very slow).

Any suggestions?

[julia-users] Cannot find why Stack Overflow problem appears

[Aleksandr Mikheev]

I am trying to make an octree for randomly distributed set of particles 
. I have been trying to find where 
Stack Overflow Error appears whole day, but it was in vain. Could you 
please help me? The problem should be somewhere in (c == [0]) && (a > 0) part, 
however, I have no idea where. Thank you in advance!

type particle
  R::Vector{Float64}  # coordinates of the particle
  m::Float64  # mass of the particle
  a_tree::Float64 # acceleration of particle calculated from 
tree
  a_exact::Float64# acceleration of particle calculated by 
exact summation
end

type node
  parent::Int64   # node's parent number
  children::Vector{Int64} # set of childrens' numbers
  l::Float64  # size of the node
  R::Vector{Float64}  # radius of geometric center
  m::Float64  # total mass of the node
  ptcl::Int64 # pointer to the particle in it
end

function problem3_2(N::Int64)
particles = Vector{particle}(N) # Basically, our system
tree = Vector{node}(1)  # Initial tree (root)
tree[1] = node(0,[0],1.0,[0.0,0.0,0.0],0.0,0)

for i in eachindex(particles)
  particles[i] = particle([rand() - 1/2, rand() - 1/2, rand() - 1/2], 1.0, 
0.0, 0.0)
  tree = InsertParticle(i,1,tree,particles)
end

return tree
end

function InsertParticle(i::Int64,k::Int64,tree,particles)
  c = tree[k].children
  a = tree[k].ptcl
  if (c == [0]) && (a == 0)
tree[k].ptcl = i
  elseif (c == [0]) && (a > 0)
j_1 = length(tree) + DetermOctant(particles[tree[k].ptcl],tree[k])
j_2 = length(tree) + DetermOctant(particles[i],tree[k])
tree[k].children = [x for x in length(tree)+1:length(tree)+8]
  for p = 1:8
push!(tree,node(k,[0],tree[k].l/2,[0.0,0.0,0.0],0.0,0))
if (p == 1) || (p == 4) || (p == 5) || (p == 8)
  tree[k+p].R[1] = tree[k].R[1] + tree[k+p].l/2
else
  tree[k+p].R[1] = tree[k].R[1] - tree[k+p].l/2
end
if (p == 1) || (p == 2) || (p == 5) || (p == 6)
  tree[k+p].R[2] = tree[k].R[2] + tree[k+p].l/2
else
  tree[k+p].R[2] = tree[k].R[2] - tree[k+p].l/2
end
if (p == 1) || (p == 2) || (p == 3) || (p == 4)
  tree[k+p].R[3] = tree[k].R[3] + tree[k+p].l/2
else
  tree[k+p].R[3] = tree[k].R[3] - tree[k+p].l/2
end

end

InsertParticle(tree[k].ptcl,j_1,tree,particles)
InsertParticle(i,j_2,tree,particles)
tree[k].ptcl = 0
  elseif (c != [0])
  j = DetermOctant(particles[i],tree[k])
  InsertParticle(i,tree[k].children[j],tree,particles)
  end
return tree
end


function DetermOctant(x::particle,y::node)
  c1 = y.R[1]; c2 = y.R[2]; c3 = y.R[3]
  x1 = sign(x.R[1] - c1); x2 = sign(x.R[2] - c2); x3 = sign(x.R[3] - c3)
  if (x1 > 0) && (x2 > 0) && (x3 > 0)
n = 1
  elseif (x1 < 0) && (x2 > 0) && (x3 > 0)
n = 2
  elseif (x1 < 0) && (x2 < 0) && (x3 > 0)
n = 3
  elseif (x1 > 0) && (x2 < 0) && (x3 > 0)
n = 4
  elseif (x1 > 0) && (x2 > 0) && (x3 < 0)
n = 5
  elseif (x1 < 0) && (x2 > 0) && (x3 < 0)
n = 6
  elseif (x1 < 0) && (x2 < 0) && (x3 < 0)
n = 7
  else
n = 8
  end
return n
end

[julia-users] Re: Linear convolution

[Vincent Picaud]

Hi All,
I have a blog post
https://pixorblog.wordpress.com/2016/07/17/direct-convolution/
that presents a detailed implementation of direct convolution in Julia.
Maybe it can help,
Vincent

Le mardi 4 mars 2014 12:38:15 UTC+1, Oliver Lylloff a écrit :
>
> Hello all,
>
> Is anyone aware of a linear convolution implementation? 
> The Base.conv and Base.conv2 functions are implemented with fft which 
> makes them circular convolution functions (as far as I know).
>
> I'm looking for something alike Matlabs conv2 or SciPys signal.convolve2d.
>
> Should be straightforward to implement though.
>
> Best,
> Oliver
>

[julia-users] Re: Value assignment of compound expression

[David P. Sanders]

El jueves, 10 de noviembre de 2016, 0:43:19 (UTC-5), 
wan...@terpmail.umd.edu escribió:
>
>
>
> Hi guys,
>
> I am new to Julia and learning from scratch. I ran into the compound 
> expression like this:
>
>
> tri=base=5;height=10;1/2*base*height
>
>
> This is to calculate the triangle area. The result is right. But I am 
> concerned about the value of "tri". What is it after the calculation. 
> Shouldn't it be 25? Julia told me it is 5!!
>
> Can anybody help me with this?
>

If you actually want the result assigned to tri, you can do it by adding 
parentheses to what you wrote:

julia> tri1 = (base = 5; height = 10; 0.5 * base * height)
25.0

julia> tri1
25.0

(Note that the code is more readable with more space.)

However, what you are really trying to do is make something that, given a 
base and a height, calculates the area,
i.e. a function. So it is more natural (and reusable) to do something like 
this:


julia> triangle_area(base, height) = 0.5 * base * height
tri (generic function with 1 method)

julia> base, height = 5, 10
(5,10)

julia> triangle_area(base, height)
25.0

This has the advantage that you can also reuse the variables base and 
height later. 

(Note also that `base` is a function defined in the Julia standard library 
(which itself is called `Base`!)
and this code overwrites it when run in global scope.)
 

[julia-users] ReadOnlyMemoryError() after Pkg.init()??

[Angel de Vicente]

Hi,

I just did a fresh installation of Julia from source files and
apparently all went well, but I get the following error when trying to
call Pkg.init()

Any idea what could be happening?

,
| [angelv@duna ~]$ julia
|_  
|_   _ _(_)_ |  A fresh approach to technical computing 
|   (_) | (_) (_)|  Documentation: http://docs.julialang.org
|_ _   _| |_  __ _   |  Type "?help" for help.
|   | | | | | | |/ _` |  | 
|   | | |_| | | | (_| |  |  Version 0.5.1-pre+27 (2016-11-04 08:41 UTC) 
|  _/ |\__'_|_|_|\__'_|  |  Commit 25f7066* (6 days old release-0.5) 
| |__/   |  x86_64-redhat-linux 
| 
| julia> Pkg.init()
| INFO: Initializing package repository /home/angelv/.julia/v0.5
| INFO: Cloning METADATA from https://github.com/JuliaLang/METADATA.jl 
| ERROR: ReadOnlyMemoryError()  


  
| julia>   
`

Thanks,
-- 
Ángel de Vicente
http://www.iac.es/galeria/angelv/  

Re: [julia-users] Re: [Announcement] Moving to Discourse (Statement of Intent)

[Patrick Kofod Mogensen]

My take: make the move or don't.

Stuff like forwarding posts only creates confusion, and people start 
answering things that aren't seen by the person asking, because of the 
one-way-street-thing.

On Wednesday, November 9, 2016 at 2:24:18 AM UTC+1, Valentin Churavy wrote:
>
> `julia-dev` has now moved to discourse. 
>
> One possibility would be to start forwarding posts for `julia-users` from 
> Google Groups to Discourse, but that is a one way street. So before I 
> enable that I would like to hear what everybody thinks about it.
>
> On Wed, 9 Nov 2016 at 02:01 Tom Breloff  
> wrote:
>
>> +1... can we move already?  Discourse is a huge improvement.  I 
>> specifically don't answer some questions here because of the difficulty in 
>> writing answers with code.
>>
>> On Sun, Nov 6, 2016 at 3:16 PM, Stefan Karpinski > > wrote:
>>
>>> - Selectively subscribe to certain topics/categories of discussion and 
>>> not others.
>>> - Selectively see threads that reach certain quality/interest thresholds.
>>> - Take links directly from where one reads messages
>>> (I really dislike the Google groups interface, so I use Gmail for 
>>> reading messages, but then getting a link to a post is a real pain; the 
>>> Discourse interface is much better).
>>> - Real tools for moderation, management and administration.
>>> - Active, open development
>>> Google Groups is not only proprietary, but it's also effectively 
>>> abandonware.
>>>
>>> On Sun, Nov 6, 2016 at 8:33 AM, Simon Byrne >> > wrote:
>>>
 Personally, I find the following an improvement over google groups:
 - code blocks (copying and pasting code into the google groups 
 interface always tends to look bad)
 - the ability to edit posts
 - the ability to move threads to different categories (i.e. posts to 
 julia-dev which should have gone to julia-users, etc)


 On Sunday, 6 November 2016 10:33:20 UTC, Milan Bouchet-Valat wrote:
>
> Le dimanche 06 novembre 2016 à 01:49 -0800, Andreas Lobinger a écrit : 
> > Hello colleague, 
> > 
> > > The Julia community has been growing rapidly over the last few 
> > > years and discussions are happening at many different places: 
> there 
> > > are several Google Groups (julia-users, julia-dev, ...), IRC, 
> > > Gitter, and a few other places. Sometimes packages or 
> organisations 
> > > also have their own forums and chat rooms. 
> > > 
> > > In the past, Discourse has been brought up as an alternative 
> > > platform that we could use instead of Google Groups and that would 
> > > allow us to invite the entire Julia community into one space. 
> > > 
> > 
> > What problem with the julia-users mailing-list and the google groups 
> > web interface is solved by using discourse? 
> You can have a look at the previous thread about this: 
> https://groups.google.com/d/msg/julia-users/4oDqW-QxyVA/lw71uqNGBQAJ 
>
> I also encourage you to give a try to Discourse (this can be done 
> without even creating an account on their test instance). 
>
> > Why do you think (can you prove?) more centralisation will happen 
> > with discourse? 
> Centralization will be made possible by allowing for sub-forums 
> dedicated to each topic (stats, optimization, data...) inside 
> Discourse 
> itself, instead of creating totally separate mailing lists as is 
> currently done. Of course people will still be free to use something 
> else, but that's quite unlikely. 
>
> > > We would like to solicit feedback from the broader Julia community 
> > > about moving julia-users to Discourse as well, and potentially 
> > > other mailing lists like julia-stats. 
> > > 
> > 
> > Please define 'We'.  
> "We" meant "Julia core developers". 
>
> > > If you have feedback or comments, please post them 
> > > at http://discourse.julialang.org/t/migration-of-google-groups-to- 
> > > discourse or in this thread. 
> > > 
> > 
> > In some parts of the world, asking for feedback on a topic via a 
> > different medium is seen as unfriendly act ... but still there is 
> > this thread. 
> The idea was that we would like to see how well it works by having 
> people use Discourse for this discussion. But as you noted there's 
> this 
> thread for people who don't want to to that. 
>
>
> Regards 
>
> > Wishing a happy day, 
> >  Andreas 
>

 On Sunday, 6 November 2016 10:33:20 UTC, Milan Bouchet-Valat wrote:
>
> Le dimanche 06 novembre 2016 à 01:49 -0800, Andreas Lobinger a écrit : 
> > Hello colleague, 
> > 
> > > The Julia community has been growing rapidly over the last few 
> > > years and discussions are happening at many different places: 
> there 
> > > are several Google