[julia-users] Reshape that shares the same data?

[Kirill Ignatiev]

The documentation for Base.reshape says

> Create an array with the same data as the given array, but with different 
dimensions. An implementation for a particular type of array may choose 
whether the data is copied or shared.

So if I want to guarantee that the reshaped array shares the same data, and 
that modifying the new array modifies the old array, what should I use?

Re: [julia-users] Re: [ANN] Jumos: a package for molecular simulations in Julia

[Amuthan]

Hey Viral: sure, I'll keep you posted on how it spans out.

On Wed, Jan 28, 2015 at 8:29 PM, Viral Shah  wrote:

> Amuthan,
>
> Off-topic, but do let us know any issues you face in parallelization. Any
> inputs on API design, performance, documentation, etc. will be greatly
> useful.
>
> -viral
>
>
> On Wednesday, January 28, 2015 at 8:12:19 PM UTC+5:30, Amuthan A.
> Ramabathiran wrote:
>>
>> Hi Guillaume:
>>
>> This looks good -- thanks for the package! I have a basic question
>> regarding the force computation: I had a quick look at the code and it
>> appears to me that the current code uses an O(N^2) algorithm (direct sum)
>> for this. Is my understanding correct? Software like LAMMPS use very
>> efficient algorithms for short and long range potentials and this might
>> possibly account for the fact that the benchmark is 80x slower.
>>
>> I had developed a serial MD code using neighbor lists last year and I'm
>> currently in the process of parallelizing it to study the suitability of
>> Julia for developing (reasonably) parallel research codes. Is
>> parallelization something you're looking into? I would be very interested
>> in hearing about this. Thanks!
>>
>> Cheers,
>> Amuthan
>>
>> On Tuesday, January 27, 2015 at 2:46:59 PM UTC-8, Luthaf wrote:
>>>
>>>  Hi julians !
>>>
>>> I am very happy to announce the release of Jumos, a Julia package for
>>> molecular simulations.
>>>
>>> You can find the code here: https://github.com/Luthaf/Jumos.jl, and the
>>> documentation is hosted by readthedocs : http://jumos.readthedocs.org/
>>> en/latest/.
>>>
>>> This package aims at being as extensible as possible. Every algorithm is
>>> a type that can be subtyped and changed at runtime, during the simulation.
>>>  This makes it easy to write new algorithms, experiment with them, and
>>> combine algorithms in all the fancy ways you can imagine.
>>>
>>>  Presently, only molecular dynamic is implemented, but I am planning to
>>> add energy minimisation, and trajectory replay from files (maybe
>>> monte-carlo simulations if I find some time). A handful of tools are
>>> already implemented :
>>>  - Velocity-Verlet and Verlet integrator;
>>>  - Lennard-Jones and Harmonic potential;
>>>  - User-defined potentials;
>>>  - RDF and density profile analysis;
>>>  - Berendsen thermostat;
>>>  - Velocity-rescale thermostat;
>>>  - Temperature and energy computations.
>>>
>>>  And a lot more are planned: https://github.com/Luthaf/Jumos.jl/issues.
>>>  If you want to help, contributions are very welcome ! Just pick up an
>>> issue or create a new one as a feature request.
>>>  The first benchmark (against LAMMPS) gives me a speed 80 times slower
>>> than LAMMPS. This is already great for a dynamic language, but there is
>>> still room for improvement !
>>>
>>>  Any feedback on the implementation is also very welcome.
>>>
>>>  Regards
>>>  Guillaume
>>>
>>>  PS: What does the ANN in the title mean ? It seems to be everywhere,
>>> but I don't have any clue about its meaning
>>>
>>>
>>

[julia-users] Re: [ANN] Jumos: a package for molecular simulations in Julia

[Viral Shah]

Amuthan,

Off-topic, but do let us know any issues you face in parallelization. Any 
inputs on API design, performance, documentation, etc. will be greatly 
useful.

-viral

On Wednesday, January 28, 2015 at 8:12:19 PM UTC+5:30, Amuthan A. 
Ramabathiran wrote:
>
> Hi Guillaume: 
>
> This looks good -- thanks for the package! I have a basic question 
> regarding the force computation: I had a quick look at the code and it 
> appears to me that the current code uses an O(N^2) algorithm (direct sum) 
> for this. Is my understanding correct? Software like LAMMPS use very 
> efficient algorithms for short and long range potentials and this might 
> possibly account for the fact that the benchmark is 80x slower. 
>
> I had developed a serial MD code using neighbor lists last year and I'm 
> currently in the process of parallelizing it to study the suitability of 
> Julia for developing (reasonably) parallel research codes. Is 
> parallelization something you're looking into? I would be very interested 
> in hearing about this. Thanks!
>
> Cheers,
> Amuthan
>
> On Tuesday, January 27, 2015 at 2:46:59 PM UTC-8, Luthaf wrote:
>>
>>  Hi julians !
>>
>> I am very happy to announce the release of Jumos, a Julia package for 
>> molecular simulations.
>>
>> You can find the code here: https://github.com/Luthaf/Jumos.jl, and the 
>> documentation is hosted by readthedocs : 
>> http://jumos.readthedocs.org/en/latest/.
>>
>> This package aims at being as extensible as possible. Every algorithm is 
>> a type that can be subtyped and changed at runtime, during the simulation.
>>  This makes it easy to write new algorithms, experiment with them, and 
>> combine algorithms in all the fancy ways you can imagine.
>>
>>  Presently, only molecular dynamic is implemented, but I am planning to 
>> add energy minimisation, and trajectory replay from files (maybe 
>> monte-carlo simulations if I find some time). A handful of tools are 
>> already implemented :
>>  - Velocity-Verlet and Verlet integrator;
>>  - Lennard-Jones and Harmonic potential;
>>  - User-defined potentials;
>>  - RDF and density profile analysis;
>>  - Berendsen thermostat;
>>  - Velocity-rescale thermostat;
>>  - Temperature and energy computations.
>>  
>>  And a lot more are planned: https://github.com/Luthaf/Jumos.jl/issues. 
>>  If you want to help, contributions are very welcome ! Just pick up an 
>> issue or create a new one as a feature request.
>>  The first benchmark (against LAMMPS) gives me a speed 80 times slower 
>> than LAMMPS. This is already great for a dynamic language, but there is 
>> still room for improvement !
>>  
>>  Any feedback on the implementation is also very welcome.
>>
>>  Regards
>>  Guillaume
>>  
>>  PS: What does the ANN in the title mean ? It seems to be everywhere, 
>> but I don't have any clue about its meaning
>>   
>>  
>

[julia-users] include() file in not nested directory

[Rodrigo L.C.]

I think it's really basic stuff, but I would like to have a "functions" 
directory and a "workspace" directory. In "workspace" I would have 
"file.jl" that says

include("../functions/some_functions.jl")

but this seems to be doing something similar to importing a module because 
it takes very long and I get the

INFO: Loading help data...

message. It works the way I want ir if "functions" is located under 
"workspace", but this seems unpractical since I want to be able to create a 
"workspace2" directory and still have access to the same files. 

What am I not getting of how include() is supposed to work?

[julia-users] Re: Writing a configuration file through templating

[j verzani]

The GoogleCharts.jl package does some of what you seem to have in mind 
though for a different plotting backend. Something similar in scope for 
C3.js should be relatively straightforward.

On Wednesday, January 28, 2015 at 11:55:16 AM UTC-5, Martin Somers wrote:
>
> Hi Andreas
> Most of the plotting packages are fine if you want to do basic stuff time 
> series, bar charts ex but once you start adding complexity things start to 
> get scary very quickly :)
>
> I would like to use some features of 0.4 but it seems I can’t if I want to 
> use IJulia and Gadfly all together
>
> I spent a bit of time trying to get this to work until I saw a post that 
> the backend has moved from D3 and moving towards a more generic approach of 
> snapsvg which isn’t a problem – I would like to see snap being used more in 
> fact
>
> My needs are different to others - I want to have an svg output for my 
> charts similar to plot.ly but I want to have control on the output and 
> the data Im putting into it. I love the Julia syntax but charting is some 
> what mixed at the moment when looking for svg output
>
> Gadfly are 'pretty' charts but there are issues when it comes to clarity 
> of data being overlaid (layers) on top of one another eg a scatter chart – 
> ordering is implemented but there isn’t any docs for this that I can see 
> pointing to how to correctly order a layer 
>
> Personally I don’t think reinventing the wheel for a Julia charting 
> package is a great use of time(my julia skills arent to that level that I 
> can add to extending existing packages) and it would be easier to lean on 
> some existing charting solution out there at the moment – if there is a 
> better solution Im all ears -- leveraging different html5 charting 
> libraries provide greater scope to what can be achieved using Jypter in the 
> future.
>
> Tks
>
> M
>

[julia-users] Re: poly2mask in Julia?

[Patrick O'Leary]

On Wednesday, January 28, 2015 at 4:05:07 PM UTC-6, Andrew McLean wrote:
>
> [Apologies if you see this post twice, it's been a number of hours since 
> my original post and it hasn't appeared.]
>

Sorry about that--I have no idea how it sat in the queue for so long. I 
discarded the original post and kept only the repost. Further posts should 
appear immediately.

Patrick 

[julia-users] Re: poly2mask in Julia?

[Andrew McLean]

On Wednesday, 28 January 2015 02:50:19 UTC, Steven G. Johnson wrote:
>
> In Julia for this problem, I would just write a nested loop: loop over 
> points in the mask, and for each point loop over the (ordered) polygon 
> edges to check whether the point is in the polygon via the usual algorithm 
> (for an edge v1->v2 and a point p, check whether the cross product 
> (p-v1)x(v2-v1) has a consistent sign for all the edges).   Probably you 
> should also start by computing the bounding box of the polygon and restrict 
> yourself to looking at mask points inside this bounding box.  Should take 
> about 30 lines of code, tops.
>

Checking each pixel to see whether it is in the polygon is very 
inefficient, as you basically do a test involving each edge for each pixel. 
There is a more efficient approach that involves looking at lines of pixels 
(rows or columns), this only requires a test involving each edge once for 
each line of pixels. You can see details here:

http://alienryderflex.com/polygon_fill/

[Apologies if you see this post twice, it's been a number of hours since my 
original post and it hasn't appeared.]

- Andrew

[julia-users] Re: set DPI of output figure

[Avik Sengupta]

I believe you can do it this way: 

draw(PNG("hi_res.png", 1inch, 1inch, dpi=300), p)

See here for more:  https://github.com/dcjones/Compose.jl/pull/94

You might have to run the latest master of Gadfly.. not sure this is in a 
released version of Gadfly yet. 
Run Pkg.checkout("Gadfly") to get the latest master. Pkg.free("Gadfly") to set 
it back to the released version. 



On Wednesday, 28 January 2015 23:35:01 UTC, Li Zhang wrote:
>
> Hi fellows,
>
> I just encounter a scenario that i want to set the DPI of PNG output of 
> gadfly plot.
>
> There seems no direct way to control what i want
>
> ```
> draw(PNG(path, width, height))
> ```
>
> Any one have experience or way to do this?
>

[julia-users] set DPI of output figure

[Li Zhang]

Hi fellows,

I just encounter a scenario that i want to set the DPI of PNG output of 
gadfly plot.

There seems no direct way to control what i want

```
draw(PNG(path, width, height))
```

Any one have experience or way to do this?

Re: [julia-users] poly2mask in Julia?

[Andrei Zh]

Thanks, René, seems like it's the most simple and intuitive approach. In 
fact, it looks very similar to what I've got after porting SciKit Image 
version. Here's my code:

function inpolygon{T<:Number}(x:: T, y:: T, vx:: Vector{T}, vy:: Vector{T})
@assert length(vx) == length(vy)
c = false
j = length(vx)
@inbounds for i=1:length(vx)
if (((vy[i] <= y && y < vy[j]) ||
(vy[j] <= y && y < vy[i])) &&
(x < (vx[j] - vx[i]) * (y - vy[i]) / (vy[j] - vy[i]) + vx[i]))
c = !c
end
j = i
end
return c
end


function poly2mask{T<:Number}(vx::Vector{T}, vy::Vector{T}, m::Int, n::Int)
mask = zeros(Int, m, n)
@inbounds for j=1:m, i=1:n
mask[i, j] = int(inpolygon(j, i, vx, vy))
end
return mask
end


And it works pretty fast - for 10x10 matrix it takes only 2.5 microseconds 
on my machine. 


On Wednesday, January 28, 2015 at 11:42:29 AM UTC+3, René Donner wrote:
>
> Perhaps the following is what you need. P should be 2 x nPoints. try e.g. 
> inpolygon([10 20 20 10; 10 10 20 20],1:50,1:40) 
>
>
> function inpolygon(P,m::Int,n::Int) 
> j = size(P,2) 
> oddnodes = false 
> M = P[1,:] 
> N = P[2,:] 
>
> for i in 1:size(P,2) 
> if M[i] < m && M[j] >= m || M[j] < m && M[i] >= m 
> if N[i] + (m-M[i]) / (M[j]-M[i]) * (N[j]-N[i]) < n 
> oddnodes = !oddnodes 
> end 
> end 
> j = i 
> end 
>
> oddnodes 
> end 
> inpolygon{T}(P,img::Array{T,2}) = inpolygon(P, 1:size(img,1), 
> 1:size(img,2)) 
> inpolygon(P,M::AbstractArray,N::AbstractArray) = Float32[inpolygon(P, m,n) 
> for m in M, n in N] 
>
>
>
> Am 28.01.2015 um 03:50 schrieb Steven G. Johnson  >: 
>
> > 
> > 
> > On Sunday, January 25, 2015 at 11:03:30 AM UTC-5, Andrei Zh wrote: 
> > In Matlab, `poly2mask` transforms polygon (given by arrays of `x` and 
> `y` coordinates) into a binary mask, where all values inside polygon get 
> value 1 and all others get value 0. I found Octave implementation [1] that 
> I can translate into Julia, but it's GPL-licensed, and I'd like to avoid 
> copyleft to make my library more flexible for users. Are there any better 
> options or components in Julia that I can reuse for this task? 
> > 
> > You wouldn't want to base a Julia version on an Octave or Matlab version 
> anyway.  Those languages force you to jump through lots of hoop in order to 
> vectorize your code, resulting in rather convoluted implementations of 
> simple algorithms. 
> > 
> > In Julia for this problem, I would just write a nested loop: loop over 
> points in the mask, and for each point loop over the (ordered) polygon 
> edges to check whether the point is in the polygon via the usual algorithm 
> (for an edge v1->v2 and a point p, check whether the cross product 
> (p-v1)x(v2-v1) has a consistent sign for all the edges).   Probably you 
> should also start by computing the bounding box of the polygon and restrict 
> yourself to looking at mask points inside this bounding box.  Should take 
> about 30 lines of code, tops. 
>
>

Re: [julia-users] Re: ANN: Symbolic computation with Julia

[lapeyre . math122a]

Francesco, I just realized that Mathics is actually aiming to implement the 
Mma language. For some reason I thought it was only using the same syntax. 
So, this is indeed similar to what I am trying to do. Except that I 
consider the code that I have now to be an experiment.

On Wednesday, January 28, 2015 at 10:20:08 AM UTC+1, Francesco Bonazzi 
wrote:
>
>
>
> On Tuesday, January 27, 2015 at 12:34:43 PM UTC+1, John Lapeyre wrote:
>>
>>  > I read that the next version of Rubi will feature a decision tree, no 
>> longer pattern matching.
>>
>> Interesting. I don't see it, do you have a link? 
>>
>
> https://github.com/sympy/sympy/issues/7749#issuecomment-54830230 
>
> By the way, I was thinking about the syntax, what about instead of
>
> @ex f(x_, y_Integer, z) := ...
>
> to use a more Julia-friendly one like
>
> @ex f(x, y::Integer, :z) := ...
>
> This does not need any string processing for underscore signs, colon 
> prepended to the symbol (e.g. :z) to mark that *z* is not a wildcard 
> pattern.
>
> Anyways, it looks like on your patterns you are implicitly introducing an 
> Mxpr <-> type correspondence, i.e. if in *x_A* the expression *A* were 
> considered both as the head of an Mxpr and as a Julia type.
>
> Any thoughts about interpolation of Julia variables in the *@ex* macro? I 
> tried to call *a=3; @ex f($a)* but it doesn't work.
>
>
>

[julia-users] 2º Julia Meetup, México D.F.

[Ismael VC]

If you live in Mexico City, the metropolitan area or just plan to visit us 
this weekend,
 you are wellcome next Saturday February 7 from 10:00 to 13:00 at *KMMX*!

Details: http://www.meetup.com/julialang-mx

Re: [julia-users] Re: [ANN] Jumos: a package for molecular simulations in Julia

[Amuthan]

Hi Guillaume: Sure, give me a day or two. I'll put it up online somewhere
with some data on your benchmark.

Cheers,
Amuthan
On Jan 28, 2015 7:49 AM, "Luthaf"  wrote:

> Hi Amuthan,
>
> The current code uses the direct sum because this was the easiest
> algorithm to implement, and your understanding is totally correct.
>
> Adding other algorithms is a piece of cake: it is as easy as subtyping
> `BaseForceComputer` (I could not came with a better name), and providing a
> `call` method.
> So I am planning to add at least (serial) Verlet neighbor lists for the
> forces computations, and maybe some parallel code.
>
> But I don't know a lot about parallel methods in MD, and I still have a
> lot to learn about it. It would definitively be very nice to have it !
> I think that only a few changes are needed to use julia parallel framework
> in the package. All the data are stored in objects of type Array3D, which
> could be modified to use DArray instead.
> I am open to change the internal data structure if this can improve the
> performances.
>
> Is your neighbor list code available somewhere ? I am interested in
> reading it.
>
> Cheers,
> Guillaume
>
> Amuthan A. Ramabathiran a écrit :
>
> Hi Guillaume:
>
> This looks good -- thanks for the package! I have a basic question
> regarding the force computation: I had a quick look at the code and it
> appears to me that the current code uses an O(N^2) algorithm (direct sum)
> for this. Is my understanding correct? Software like LAMMPS use very
> efficient algorithms for short and long range potentials and this might
> possibly account for the fact that the benchmark is 80x slower.
>
> I had developed a serial MD code using neighbor lists last year and I'm
> currently in the process of parallelizing it to study the suitability of
> Julia for developing (reasonably) parallel research codes. Is
> parallelization something you're looking into? I would be very interested
> in hearing about this. Thanks!
>
> Cheers,
> Amuthan
>
> On Tuesday, January 27, 2015 at 2:46:59 PM UTC-8, Luthaf wrote:
>>
>> Hi julians !
>>
>> I am very happy to announce the release of Jumos, a Julia package for
>> molecular simulations.
>>
>> You can find the code here: https://github.com/Luthaf/Jumos.jl, and the
>> documentation is hosted by readthedocs : http://jumos.readthedocs.org/
>> en/latest/.
>>
>> This package aims at being as extensible as possible. Every algorithm is
>> a type that can be subtyped and changed at runtime, during the simulation.
>>  This makes it easy to write new algorithms, experiment with them, and
>> combine algorithms in all the fancy ways you can imagine.
>>
>>  Presently, only molecular dynamic is implemented, but I am planning to
>> add energy minimisation, and trajectory replay from files (maybe
>> monte-carlo simulations if I find some time). A handful of tools are
>> already implemented :
>>  - Velocity-Verlet and Verlet integrator;
>>  - Lennard-Jones and Harmonic potential;
>>  - User-defined potentials;
>>  - RDF and density profile analysis;
>>  - Berendsen thermostat;
>>  - Velocity-rescale thermostat;
>>  - Temperature and energy computations.
>>
>>  And a lot more are planned: https://github.com/Luthaf/Jumos.jl/issues.
>>  If you want to help, contributions are very welcome ! Just pick up an
>> issue or create a new one as a feature request.
>>  The first benchmark (against LAMMPS) gives me a speed 80 times slower
>> than LAMMPS. This is already great for a dynamic language, but there is
>> still room for improvement !
>>
>>  Any feedback on the implementation is also very welcome.
>>
>>  Regards
>>  Guillaume
>>
>>  PS: What does the ANN in the title mean ? It seems to be everywhere,
>> but I don't have any clue about its meaning
>>
>>
>

[julia-users] Re: Writing a configuration file through templating

[Martin Somers]

Hi Andreas
Most of the plotting packages are fine if you want to do basic stuff time 
series, bar charts ex but once you start adding complexity things start to 
get scary very quickly :)

I would like to use some features of 0.4 but it seems I can’t if I want to 
use IJulia and Gadfly all together

I spent a bit of time trying to get this to work until I saw a post that 
the backend has moved from D3 and moving towards a more generic approach of 
snapsvg which isn’t a problem – I would like to see snap being used more in 
fact

My needs are different to others - I want to have an svg output for my 
charts similar to plot.ly but I want to have control on the output and the 
data Im putting into it. I love the Julia syntax but charting is some what 
mixed at the moment when looking for svg output

Gadfly are 'pretty' charts but there are issues when it comes to clarity of 
data being overlaid (layers) on top of one another eg a scatter chart – 
ordering is implemented but there isn’t any docs for this that I can see 
pointing to how to correctly order a layer 

Personally I don’t think reinventing the wheel for a Julia charting package 
is a great use of time(my julia skills arent to that level that I can add 
to extending existing packages) and it would be easier to lean on some 
existing charting solution out there at the moment – if there is a better 
solution Im all ears -- leveraging different html5 charting libraries 
provide greater scope to what can be achieved using Jypter in the future.

Tks

M

Re: [julia-users] Re: ANN: Symbolic computation with Julia

[lapeyre . math122a]

On Wednesday, January 28, 2015 at 10:20:08 AM UTC+1, Francesco Bonazzi 
wrote:
>
>
>
> On Tuesday, January 27, 2015 at 12:34:43 PM UTC+1, John Lapeyre wrote:
>>
>>  > I read that the next version of Rubi will feature a decision tree, no 
>> longer pattern matching.
>>
>> Interesting. I don't see it, do you have a link? 
>>
>
> https://github.com/sympy/sympy/issues/7749#issuecomment-54830230 
>
>   
   This looks great (at least based on the linked post) It no longer relies 
on the sophisticated part of the core Mma language, so it greatly broadens 
number of languages able to run Rubi. (Its only one now: Mma itself)  I 
guess it's not too much trouble to emit sympy code. I'm pretty sure this 
could be easily adapted to Maxima. In fact I wrote an Mma to Maxima 
translator a while ago (Hmm I should put it on github) so it might work 
immediately.  It uses RJF's  CL  Mma parser (uhh. too many acronyms). The 
translator can't handle Mma patterns (maybe just a liitle, I don't 
remember)  My translator could translate and pass tests for a fair size 
quantum information package. It also translated and correctly ran some 
symbolic quantum mechanics code used in research that was written by a 
colleague. But, it was unacceptably slow, because Maxima uses linked lists 
for expressions, which require fundamentally different algorithms, not just 
translation... I'm digressing.

 I guess Albert Rich still maintains the data in some other form ? Or is he 
editing these big nested conditional statements ...

 

> By the way, I was thinking about the syntax, what about instead of
>
> @ex f(x_, y_Integer, z) := ...
>
> Well, I kind of tried different things, including :: at one point. I 
gradually moved away from a Julia extension to really another language: I 
just wanted the patterns, but they need support from expressions, but that 
requires a consistent evaluation sequence, etc. But, because I am relying 
on Julia's parser, the options are limited: the parser has to believe it's 
valid Julia code (although it won't eval). So, if I disallow underscores in 
identifiers and interpret them instead as signifying patterns, I don't 
consume any of the limited available Julia syntax. In Mma  you can have 
one, two, or three underscores before and/or after an identifier, each 
combination of which means something different. All of that has to be 
encoded in Julia syntax. By disallowing underscores, the whole problem is 
solved. I started to implement the Mma "Condition", which is yet another 
essential feature of the pattern matching. I tried :: for *that*, but it 
has high precedence, so you need to use parens, which I don't like. For 
now, I decided on just Condition(a,b). Furthermore, I stopped implementing 
Condition because it is relatively easy to do. AC matching is a b$&%h.  For 
me, there's no sense in continuing the experiment unless I'm convinced the 
harder stuff can be done.  Of course if you, or someone else want a 
particular feature to play with, I'd gladly consider implementing it. At 
present, I consider using the stock Julia parser a stopgap. I did spend 
some time with the RJF parser and even found a minor bug or two. I also 
looked at the Julia parser.  For me, it looks like a big job. But, if 
someone else wants to do it, great!

> Anyways, it looks like on your patterns you are implicitly introducing an 
Mxpr <-> type correspondence, i.e. if in *x_A* the expression *A* were 
considered both as the head of an Mxpr and as a Julia type.

Yeah, thats kinda it. Mma tries to maintain a fiction that non-expression 
types are really expressions with a particular head and zero length. So in 
your example, A might be a type or the head of an expression. I make the 
symbol 'Integer' Protected (except, I don't think I have yet put it on that 
list in the code), then under certain circumstances, it is evaled to get a 
DataType. 

>  Any thoughts about interpolation of Julia variables in the *@ex* macro? 
I tried to call *a=3; @ex f($a)* but it doesn't work.

Yes, this works:

a = 3;  @ex f(JVar(a))

Not pretty, but I don't want to introduce new syntax/language features at 
this point. JVar is done very easily in the standard Mma way.

 apprules(mx::Mxpr{:JVar}) = eval(symname(mx.args[1]))

That's it. Note that this evaluates a, then evals the result, etc. until it 
stops at an SJulia symbol that evaluates to itself. This is the Mma 
behvavior, which
I am sticking with for now. If the attribute 'HoldAll' is set for 'JVar', 
then JVar(a) always evaluates the Julia symbol :a.  Both would be useful, I 
just didn't implement that yet.  I'll document this . Please ask any other 
questions you may have.
Note that I pollute the Julia side, by setting undefined Julia vars to 
true, so that the repl completes them in SJulia. You can
turn this off by commenting out a line in mxpr_type.jl . 

--John

[julia-users] Re: [ANN] Jumos: a package for molecular simulations in Julia

[Luthaf]

Hi Amuthan,

The current code uses the direct sum because this was the easiest 
algorithm to implement, and your understanding is totally correct.


Adding other algorithms is a piece of cake: it is as easy as subtyping 
`BaseForceComputer` (I could not came with a better name), and providing 
a `call` method.
So I am planning to add at least (serial) Verlet neighbor lists for the 
forces computations, and maybe some parallel code.


But I don't know a lot about parallel methods in MD, and I still have a 
lot to learn about it. It would definitively be very nice to have it !
I think that only a few changes are needed to use julia parallel 
framework in the package. All the data are stored in objects of type 
Array3D, which could be modified to use DArray instead.
I am open to change the internal data structure if this can improve the 
performances.


Is your neighbor list code available somewhere ? I am interested in 
reading it.


Cheers,
Guillaume

Amuthan A. Ramabathiran a écrit :

Hi Guillaume:

This looks good -- thanks for the package! I have a basic question 
regarding the force computation: I had a quick look at the code and it 
appears to me that the current code uses an O(N^2) algorithm (direct 
sum) for this. Is my understanding correct? Software like LAMMPS use 
very efficient algorithms for short and long range potentials and this 
might possibly account for the fact that the benchmark is 80x slower.


I had developed a serial MD code using neighbor lists last year and 
I'm currently in the process of parallelizing it to study the 
suitability of Julia for developing (reasonably) parallel research 
codes. Is parallelization something you're looking into? I would be 
very interested in hearing about this. Thanks!


Cheers,
Amuthan

On Tuesday, January 27, 2015 at 2:46:59 PM UTC-8, Luthaf wrote:

Hi julians !

I am very happy to announce the release of Jumos, a Julia package
for molecular simulations.

You can find the code here: https://github.com/Luthaf/Jumos.jl
, and the documentation is
hosted by readthedocs : http://jumos.readthedocs.org/en/latest/
.

This package aims at being as extensible as possible. Every
algorithm is a type that can be subtyped and changed at runtime,
during the simulation.
This makesit easy to write new algorithms, experiment with them,
and combine algorithms in all the fancy waysyou can imagine.

Presently, only molecular dynamic is implemented, but I am
planning to add energy minimisation, and trajectory replay from
files (maybe monte-carlo simulations if I find some time). A
handful of tools are alreadyimplemented :
- Velocity-Verlet and Verlet integrator;
- Lennard-Jones and Harmonic potential;
- User-defined potentials;
- RDF and density profile analysis;
- Berendsen thermostat;
- Velocity-rescale thermostat;
- Temperature and energy computations.

And a lot more are planned:
https://github.com/Luthaf/Jumos.jl/issues
.
If you want to help, contributions are very welcome ! Just pick up
an issue or create a new one as a feature request.
The first benchmark (against LAMMPS) givesme a speed 80 times
slower than LAMMPS. This is already great for a dynamic language,
but there is still room for improvement !

Any feedback on the implementation is also very welcome.

Regards
Guillaume

PS: Whatdoes the ANNin the titlemean ? It seems to be everywhere,
but I don't have any clue about its meaning

Re: [julia-users] Re: Almost at 500 packages!

[Iain Dunning]

I think our equivalent of CRAN Task Views are the various organizations,
e.g. juliaopt.org. I'd like to incorporate them into the official package
listing in a more obvious way, especially as their popularity is growing
(saw JuliaGeo pop up recently, for example)
On Jan 28, 2015 4:58 AM, "Tamas Papp"  wrote:

> I don't think Steven's view is unfriendly per
> se. Documentation/organization is hard, and saying that some other
> projects did not do it perfectly either is not a slur on anyone's work.
>
> I tend to agree with Steven's opinion: very few R packages have
> vignettes (although the good quality ones do), and merely dumping the
> docstrings in a PDF/HTML file in alphabetical order is not that
> helpful. Also, selecting a good package from alternatives is sometimes
> tricky --- I tend to rely on the quality of documentation.
>
> I am glad to see that many Julia packages have an intro on the github
> main page, which can serve as a tutorial/introduction. I think that this
> is good practice.
>
> Best,
>
> Tamas
>
> On Wed, Jan 28 2015, Hans W Borchers  wrote:
>
> > You think the documentation of R packages is very spartan? ... Well,
> there
> > you go.
> > (I thought this mailing list strived to be super-friendly. Recently, I
> felt
> > a tendency here to diminish the work of other open source projects. Could
> > we stop this?)
> >
> > To find packages on CRAN, the normal procedure is not to look into the
> > package list, but into one or two of the Task Views encompassing your
> field
> > of interest. I'd be glad if something similar exists for Julia packages
> --
> > those in METADATA and those not yet registered. I wanted to do this for
> > numerical mathematics, now waiting for version 0.4 before continuing.
> >
> > On Wednesday, January 28, 2015 at 10:17:01 AM UTC+1, Steven Sagaert
> wrote:
> >>
> >> I couldn't agree more. Personally I find CRAN to be a mess. There's no
> >> organization to it. You can only find something in there by googling.
> Also
> >> the documentation of R packages is very spartan...
> >>
> >> >
> >>>
> >>
>

[julia-users] Re: [ANN] Jumos: a package for molecular simulations in Julia

[Amuthan A. Ramabathiran]

Hi Guillaume: 

This looks good -- thanks for the package! I have a basic question 
regarding the force computation: I had a quick look at the code and it 
appears to me that the current code uses an O(N^2) algorithm (direct sum) 
for this. Is my understanding correct? Software like LAMMPS use very 
efficient algorithms for short and long range potentials and this might 
possibly account for the fact that the benchmark is 80x slower. 

I had developed a serial MD code using neighbor lists last year and I'm 
currently in the process of parallelizing it to study the suitability of 
Julia for developing (reasonably) parallel research codes. Is 
parallelization something you're looking into? I would be very interested 
in hearing about this. Thanks!

Cheers,
Amuthan

On Tuesday, January 27, 2015 at 2:46:59 PM UTC-8, Luthaf wrote:
>
>  Hi julians !
>
> I am very happy to announce the release of Jumos, a Julia package for 
> molecular simulations.
>
> You can find the code here: https://github.com/Luthaf/Jumos.jl, and the 
> documentation is hosted by readthedocs : 
> http://jumos.readthedocs.org/en/latest/.
>
> This package aims at being as extensible as possible. Every algorithm is a 
> type that can be subtyped and changed at runtime, during the simulation.
>  This makes it easy to write new algorithms, experiment with them, and 
> combine algorithms in all the fancy ways you can imagine.
>
>  Presently, only molecular dynamic is implemented, but I am planning to 
> add energy minimisation, and trajectory replay from files (maybe 
> monte-carlo simulations if I find some time). A handful of tools are 
> already implemented :
>  - Velocity-Verlet and Verlet integrator;
>  - Lennard-Jones and Harmonic potential;
>  - User-defined potentials;
>  - RDF and density profile analysis;
>  - Berendsen thermostat;
>  - Velocity-rescale thermostat;
>  - Temperature and energy computations.
>  
>  And a lot more are planned: https://github.com/Luthaf/Jumos.jl/issues. 
>  If you want to help, contributions are very welcome ! Just pick up an 
> issue or create a new one as a feature request.
>  The first benchmark (against LAMMPS) gives me a speed 80 times slower 
> than LAMMPS. This is already great for a dynamic language, but there is 
> still room for improvement !
>  
>  Any feedback on the implementation is also very welcome.
>
>  Regards
>  Guillaume
>  
>  PS: What does the ANN in the title mean ? It seems to be everywhere, but I 
> don't have any clue about its meaning
>   
>  

[julia-users] Re: Writing a configuration file through templating

[Andreas Lobinger]

Hello colleague,

it would be interesting to hear, what you miss from what plotting package. 
And why you decided to spend time/code for interfacing, rather than 
contributing to available packages. 

If thinking now for some time about plotting with julia and apart from the 
obvious usability and 'nice' output i'm wondering if we can do something 
about developability (i'm not an english native speaker...): so make it 
easy for people to extend plotting.

Wishing a happy day,
Andreas

Re: [julia-users] Re: Please help, simple double while

[Paul Analyst]

Big thx Gunnar,
 "zip" is excelent,
Paul

W dniu 2015-01-27 o 11:57, Gunnar Farnebäck pisze:
Syntactically you're still missing a comma between the loop variables. 
Semantically that's not how the double for loop works.


Try either

julia> for i = 1:length(x)
   println(x[i], y[i])
   end

or

julia> for (i, j) in zip(x, y)
   println(i, j)
   end


Den tisdag 27 januari 2015 kl. 11:46:03 UTC+1 skrev paul analyst:

;) it is 100 steps.

I need 10 steps driven by 2 vectors x and y

julia> l=193
193

julia> x=int(rand(10)*l)
10-element Array{Int64,1}:
 126
  70
 132
  51
  77
 138
  94
 150
 142
  93

julia> y=int(rand(10)*l)
10-element Array{Int64,1}:
 170
 111
  93
 126
  77
 135
  24
 182
  45
 179

julia> for i in [x] j in [y]
   println(x,y)
   end
ERROR: j not defined
 in anonymous at no file:1

What wrong here ?
Pau;

[julia-users] Writing a configuration file through templating

[Martin Somers]

 

I’ve been looking at a handful of plotting packages over the last few days 
and a lot are falling short for one reason or another

So I was thinking of writing a wrapper for one of popular JS charting 
libraries i.e. C3 - http://c3js.org/

I’m looking at this one because if seems easy enough to create a single JS 
file that can be loaded into a webpage and the script can be injected in 
one location. The api is documented and can be injected all at once.

My question is how can I go about using Julia to generated the js file…. my 
idea is to take a dataframe and pass it to function which generates said 
file. Im thinking of using templating language like 
https://github.com/jverzani/Mustache.jl any examples of people using Julia 
to generate a configuration file?


tks

M

Re: [julia-users] Re: Almost at 500 packages!

[Tamas Papp]

I don't think Steven's view is unfriendly per
se. Documentation/organization is hard, and saying that some other
projects did not do it perfectly either is not a slur on anyone's work.

I tend to agree with Steven's opinion: very few R packages have
vignettes (although the good quality ones do), and merely dumping the
docstrings in a PDF/HTML file in alphabetical order is not that
helpful. Also, selecting a good package from alternatives is sometimes
tricky --- I tend to rely on the quality of documentation.

I am glad to see that many Julia packages have an intro on the github
main page, which can serve as a tutorial/introduction. I think that this
is good practice.

Best,

Tamas

On Wed, Jan 28 2015, Hans W Borchers  wrote:

> You think the documentation of R packages is very spartan? ... Well, there
> you go.
> (I thought this mailing list strived to be super-friendly. Recently, I felt
> a tendency here to diminish the work of other open source projects. Could
> we stop this?)
>
> To find packages on CRAN, the normal procedure is not to look into the
> package list, but into one or two of the Task Views encompassing your field
> of interest. I'd be glad if something similar exists for Julia packages --
> those in METADATA and those not yet registered. I wanted to do this for
> numerical mathematics, now waiting for version 0.4 before continuing.
>
> On Wednesday, January 28, 2015 at 10:17:01 AM UTC+1, Steven Sagaert wrote:
>>
>> I couldn't agree more. Personally I find CRAN to be a mess. There's no
>> organization to it. You can only find something in there by googling. Also
>> the documentation of R packages is very spartan...
>>
>> >
>>>
>>

Re: [julia-users] Re: Almost at 500 packages!

[Hans W Borchers]

You think the documentation of R packages is very spartan? ... Well, there 
you go.
(I thought this mailing list strived to be super-friendly. Recently, I felt 
a tendency here to diminish the work of other open source projects. Could 
we stop this?)

To find packages on CRAN, the normal procedure is not to look into the 
package list, but into one or two of the Task Views encompassing your field 
of interest. I'd be glad if something similar exists for Julia packages -- 
those in METADATA and those not yet registered. I wanted to do this for 
numerical mathematics, now waiting for version 0.4 before continuing.

On Wednesday, January 28, 2015 at 10:17:01 AM UTC+1, Steven Sagaert wrote:
>
> I couldn't agree more. Personally I find CRAN to be a mess. There's no 
> organization to it. You can only find something in there by googling. Also 
> the documentation of R packages is very spartan...
>
> > 
>>
>

Re: [julia-users] Re: ANN: Symbolic computation with Julia

[Francesco Bonazzi]

On Tuesday, January 27, 2015 at 12:34:43 PM UTC+1, John Lapeyre wrote:
>
>  > I read that the next version of Rubi will feature a decision tree, no 
> longer pattern matching.
>
> Interesting. I don't see it, do you have a link? 
>

https://github.com/sympy/sympy/issues/7749#issuecomment-54830230 

By the way, I was thinking about the syntax, what about instead of

@ex f(x_, y_Integer, z) := ...

to use a more Julia-friendly one like

@ex f(x, y::Integer, :z) := ...

This does not need any string processing for underscore signs, colon 
prepended to the symbol (e.g. :z) to mark that *z* is not a wildcard 
pattern.

Anyways, it looks like on your patterns you are implicitly introducing an 
Mxpr <-> type correspondence, i.e. if in *x_A* the expression *A* were 
considered both as the head of an Mxpr and as a Julia type.

Any thoughts about interpolation of Julia variables in the *@ex* macro? I 
tried to call *a=3; @ex f($a)* but it doesn't work.

Re: [julia-users] Re: Almost at 500 packages!

[Steven Sagaert]

I couldn't agree more. Personally I find CRAN to be a mess. There's no 
organization to it. You can only find something in there by googling. Also 
the documentation of R packages is very spartan...

On Thursday, January 22, 2015 at 7:49:40 PM UTC+1, Ista Zahn wrote:
>
> As an R user I'm surprised to see CRAN held up as a model to aspire 
> to. There is a _lot_ of overlapping functionality among those 6k 
> packages, making it hard to figure out which one is "best" for a 
> particular purpose. There are also a lot of unfocused packages 
> providing miscellaneous collections of functions, which makes it 
> difficult to understand exactly what the package offers you as a user. 
> As a user things are easier if a) each package has a clearly defined 
> scope (i.e., "does one thing well"), and b) there are not too many 
> similar packages to choose from for any particular task. None of this 
> is to say that julia isn't on the right track in terms of packages, 
> just that I question the wisdom of emulating CRAN in this regard. 
>
> Best, 
> Ista 
>
> On Wed, Jan 21, 2015 at 7:46 PM, Iain Dunning  > wrote: 
> > Yes indeed Christoph, a package that doesn't work is a package that 
> might as 
> > well not exist. Fortunately, and fairly uniquely I think, we can 
> quantify to 
> > some extent how many of our packages are working, and the degree to 
> which 
> > they are. 
> > 
> > In my mind the goal now is "grow fast and don't break too many things", 
> and 
> > I think our pace over the last month or so of around 1 package per day 
> is 
> > fantastic, with good stability of packages (i.e. they pass tests). I've 
> also 
> > noticed that packages being registered now are often of a higher quality 
> > than they used to be, in terms of tests and documentation. I talked 
> about 
> > this a bit at JuliaCon, but in some sense NPM and CRAN represent 
> different 
> > ends of a spectrum of possibilities, and it seems like the consensus is 
> more 
> > towards CRAN. So, we're doing good I think. 
> > 
> > 
> > On Wed, Jan 21, 2015 at 7:02 PM, Kevin Squire  > 
> > wrote: 
> >> 
> >> Additional references: PyPI lists 54212 packages, currently (roughly 
> half 
> >> as many as node) but, CRAN only has 6214. 
> >> 
> >> Cheers, 
> >>Kevin 
> >> 
> >> On Wed, Jan 21, 2015 at 3:37 PM, Sean Garborg  > 
> >> wrote: 
> >>> 
> >>> You wouldn't like node ;) 
> >>> 
> >>> On Wednesday, January 21, 2015 at 4:29:53 PM UTC-7, Christoph Ortner 
> >>> wrote: 
>  
>  Great that so many are contributing to Julia, but I would question 
>  whether such a large number of packages will be healthy in the long 
> run. It 
>  will make it very difficult for new users to use Julia effectively. 
> >> 
> >> 
> > 
> > 
> > 
> > -- 
> > Iain Dunning 
> > PhD Candidate / MIT Operations Research Center 
> > http://iaindunning.com  /  http://juliaopt.org 
>

[julia-users] Re: [ANN] Jumos: a package for molecular simulations in Julia

[Luthaf]

The two main area of use for this code are
- Teaching molecular simulation, as one have to give the set of 
algorithm they want to use, and can run MD from the REPL.

- Research code, for development of new molecular simulation methods.

It is also fast enough to run post-processing analysis, but not to run 
big simulations on HPC clusters. It would needs parallelisation for this.


Guillaume

Christoph Ortner a écrit :


What are your short-term and long-term aims with this package? A user 
code, teaching code or research code? Do you have specific 
applications in mind?


Christoph

Re: [julia-users] poly2mask in Julia?

[René Donner]

Perhaps the following is what you need. P should be 2 x nPoints. try e.g. 
inpolygon([10 20 20 10; 10 10 20 20],1:50,1:40)


function inpolygon(P,m::Int,n::Int)
j = size(P,2)
oddnodes = false
M = P[1,:]
N = P[2,:]

for i in 1:size(P,2)
if M[i] < m && M[j] >= m || M[j] < m && M[i] >= m
if N[i] + (m-M[i]) / (M[j]-M[i]) * (N[j]-N[i]) < n
oddnodes = !oddnodes
end
end
j = i
end

oddnodes
end
inpolygon{T}(P,img::Array{T,2}) = inpolygon(P, 1:size(img,1), 1:size(img,2))
inpolygon(P,M::AbstractArray,N::AbstractArray) = Float32[inpolygon(P, m,n) for 
m in M, n in N]



Am 28.01.2015 um 03:50 schrieb Steven G. Johnson :

> 
> 
> On Sunday, January 25, 2015 at 11:03:30 AM UTC-5, Andrei Zh wrote:
> In Matlab, `poly2mask` transforms polygon (given by arrays of `x` and `y` 
> coordinates) into a binary mask, where all values inside polygon get value 1 
> and all others get value 0. I found Octave implementation [1] that I can 
> translate into Julia, but it's GPL-licensed, and I'd like to avoid copyleft 
> to make my library more flexible for users. Are there any better options or 
> components in Julia that I can reuse for this task?
> 
> You wouldn't want to base a Julia version on an Octave or Matlab version 
> anyway.  Those languages force you to jump through lots of hoop in order to 
> vectorize your code, resulting in rather convoluted implementations of simple 
> algorithms.
> 
> In Julia for this problem, I would just write a nested loop: loop over points 
> in the mask, and for each point loop over the (ordered) polygon edges to 
> check whether the point is in the polygon via the usual algorithm (for an 
> edge v1->v2 and a point p, check whether the cross product (p-v1)x(v2-v1) has 
> a consistent sign for all the edges).   Probably you should also start by 
> computing the bounding box of the polygon and restrict yourself to looking at 
> mask points inside this bounding box.  Should take about 30 lines of code, 
> tops.

[julia-users] Re: [ANN] Jumos: a package for molecular simulations in Julia

[Christoph Ortner]

What are your short-term and long-term aims with this package? A user code, 
teaching code or research code? Do you have specific applications in mind?

Christoph