[julia-users] Re: Arrayfire and Julia

[Zahirul ALAM]

Thanks Viral and everyone else. I will play with this later this week. :)

On Friday, 18 September 2015 04:14:25 UTC-4, Viral Shah wrote:
>
> We at Julia Computing have done some exploratory work on ArrayFire.jl, 
> which is now available here. This is not a supported package at the moment, 
> but that could change in the future. For now, we are putting out what we 
> have done.
>
> https://github.com/JuliaComputing/ArrayFire.jl
>
> -viral
>
> On Tuesday, November 18, 2014 at 10:17:45 AM UTC+5:30, Zahirul ALAM wrote:
>>
>> I second this.
>>
>> On Monday, 17 November 2014 12:27:43 UTC-5, Test This wrote:
>>>
>>> Happy to see thus reaction from a core julia developer. Hope julia makes 
>>> parallel programming on CPUs and GPUs easier. 
>>>
>>

[julia-users] escher examples

[Yakir Gagnon]

I'm about to delve into the Escher and Reactive docs, but are there a bunch 
of *simple* examples for how to use the widgets etc (other than 
https://shashi.github.io/Escher.jl/widgets-api.html)? Something like 
"here's a .jl file that has a button that runs some function"...

Thanks!!!  

[julia-users] ANN: Julia v0.4.0-rc3 released

[Tony Kelman]

The third release candidate of Julia 0.4.0 is available for download from the 
usual place . Please test extensively, 
report issues to the issue tracker 
 for base Julia problems, and 
report issues with packages to their respective issue trackers.

Bugfix backports are continuing on release-0.4 branch while new breaking 
development for 0.5-dev will occur on master. We will hopefully only need 
one last RC after this one if no release-blocking issues are identified, 
which we can then promote to final with no substantial changes after a few 
days.

-Tony

[julia-users] How to create an array of a given type?

[Dongning Guo]

I'd like to create an array of a certain type.  The basic code looks as 
follows:

Type T
  x::Float64
  y::Float64
end
b = Array{T}(3)

Basically I wish  b[1], b[2], b[3] to be of the same type T.

I'm using Julia within the Atom editor.  The last line of code causes Julia 
to hang and produces the following error "Julia Client – Internal Error
UndefRefError: access to undefined reference
in yieldto at 
/Applications/Julia-0.4.0-rc2.app/Contents/Resources/julia/lib/julia/sys.dylib
in wait at 
/Applications/Julia-0.4.0-rc2.app/Contents/Resources/julia/lib/julia/sys.dylib 
(repeats 3 times)
[inlined code] from /Users/me/.julia/v0.4/Lazy/src/dynamic.jl:69
in anonymous at /Users/me/.julia/v0.4/Atom/src/eval.jl:44
[inlined code] from /Users/me/.julia/v0.4/Atom/src/comm.jl:23
in anonymous at task.jl:63


The same code works just fine under command line Julia (0.4.0-rc2).

Any help will be appreciated, including how to have a clean slate 
reinstallation (either Juno or Atom) that just works.

I'm relatively new to Julia.  I was using Julia under Juno until Juno broke 
down with no fix after I tried.  Reinstallation didn't help (several other 
people had similar problems, see 
https://groups.google.com/d/topic/julia-users/ntOb9HNm0ac/discussion).  I 
then switched to Atom and still has problems.

Re: [julia-users] Re: Hyper-Dual numbers

[Rob Goedman]

Hi Nitin,

Thanks for the note and references. The recent upgrade of ForwardDiff.jl 
certainly shows the value of these methods.

Did you (re-)implement MultiComplexNumbers from the 2nd reference, or used one 
of the two (Fortran and Matlab) prototype modules? Did you use it from within 
Julia? Do you know the license that comes with the implementation you used? 

Sorry for all the questions!

Regards,
Rob


> On Sep 28, 2015, at 18:11, Nitin Arora  wrote:
> 
> There is another method to calculate any order derivatives, very similar to 
> this one, known as Multi-complex differentiation. This method can calculate 
> derivatives up-to any order.
> 
> http://www.autodiff.org/Docs/euroad/13rd%20EuroAd%20Workshop%20-%20Thierry%20Dargent%20-%20Using%20Multicomplex%20Variables%20for%20Automatic%20Computation%20of%20High-Order%20Derivatives.pdf
> 
> http://delivery.acm.org/10.1145/217/2168774/a16-lantoine.pdf?ip=207.151.221.1=2168774=ACTIVE%20SERVICE=6405B83BDA580DC2%2E4D4702B0C3E38B35%2E4D4702B0C3E38B35%2E4D4702B0C3E38B35=717380051=25446753&__acm__=1443489222_ee3f3d4c7ee41030aaba536e14d6a6ab
> 
> I have used this in my field and it seems to work nicely.
> 
> thanks,
> Nitin
> 
>> On Saturday, March 29, 2014 at 5:43:05 PM UTC-7, Rob J Goedman wrote:
>> Hi,
>> 
>> As a first 'jump into the fray' exercise I've attempted to translate Jeffrey 
>> Fike's hyper-dual numbers code from c++ to Julia, more or less following the 
>> DualNumbers package.
>> 
>> The c++ code can be found at http://adl.stanford.edu/hyperdual/hyperdual.h . 
>> The paper itself at http://adl.stanford.edu/hyperdual/Fike_AIAA-2011-886.pdf 
>> .
>> 
>> The Julia package can be found at: 
>> https://github.com/goedman/HyperDualNumbers.jl.git .
>> 
>> Of course, I'm pretty new at this so I'm sure there will be errors and poor 
>> practices. So any feedback is appreciated.
>> 
>> Also, I'm wondering if the type should be called Hyper or a better name 
>> would be HyperDual.
>> 
>> This work was triggered by the interesting threads around openPP, 
>> TaylorSeries.jl, Calculus2, PowerSeries.jl (and at some time I hope MCMC.jl).
>> 
>> Rob J. Goedman
>> goe...@icloud.com
>> 
>> 
>> 
>> 

[julia-users] Re: Passing data through Optim

[Christopher Fisher]

Thanks for your willingness to investigate the matter more closely. I 
cannot post the exact code I am using (besides its rather long). However, I 
posted a toy example that follows the same basic operations. Essentially, 
my code involves an outer function (SubLoop) that loops through a data set 
with multiple subjects. The model is fit to each subject's data. The other 
function (LogLike) computes the log likelihood and is called by optimize. 
The first set of code corresponds to the closure method and the second set 
of code corresponds to the global variable method. In both cases, the code 
executed in about .85 seconds over several runs on my computer and has 
about 1.9% gc time. I'm also aware that my code is probably not optimized 
in other regards. So I would be receptive to any other advice you might 
have. 


 

using Distributions,Optim

function SubLoop1(data1)

function LogLike1(parms) 

L = pdf(Normal(parms[1],exp(parms[2])),SubData)

LL = -sum(log(L))

end

#Number of Subjects

Nsub = size(unique(data1[:,1],1),1)

#Initialize per subject Data

SubData = []

for i = 1:Nsub

idx = data1[:,1] .== i

SubData = data1[idx,2]

parms0 = [1.0;1.0]

optimize(LogLike1,parms0,method=:nelder_mead)

end

end

 

N = 10^5

#Column 1 subject index, column 2 value

Data = zeros(N*2,2)

for sub = 1:2

Data[(N*(sub-1)+1):(N*sub),:] = [sub*ones(N) rand(Normal(10,2),N)]

end

@time SubLoop1(Data)











Using Distributions, Optim

function SubLoop2(data1)

global SubData

#Number of subjects

Nsub = size(unique(data1[:,1],1),1)

#Initialize per subject data

SubData = []

for i = 1:Nsub

idx = data1[:,1] .== i

SubData = data1[idx,2]

parms0 = [1.0;1.0]

optimize(LogLike2,parms0,method=:nelder_mead)

end

end

 

function LogLike2(parms) 

L = pdf(Normal(parms[1],exp(parms[2])),SubData)

LL = -sum(log(L))

end

 

N = 10^5

#Column 1 subject index, column 2 value

Data = zeros(N*2,2)

for sub = 1:2

Data[(N*(sub-1)+1):(N*sub),:] = [sub*ones(N) rand(Normal(10,2),N)]

end

@time SubLoop2(Data)



On Monday, September 28, 2015 at 11:24:13 AM UTC-4, Kristoffer Carlsson 
wrote:
>
> From only that comment alone it is hard to give any further advice. 
>
> What overhead are you seeing?
>
> Posting runnable code is the best way to get help.
>
>

RE: [julia-users] Why is String deprecated in favour of AbstractString?

[David Anthoff]

+1 to having a String type that I can just use and it works if I don’t care 
about any of the encoding subtleties.

 

From: julia-users@googlegroups.com [mailto:julia-users@googlegroups.com] On 
Behalf Of Stefan Karpinski
Sent: Monday, September 28, 2015 8:28 AM
To: Julia Users 
Subject: Re: [julia-users] Why is String deprecated in favour of AbstractString?

 

There's another reason: I am planning to use `String` as the name of a standard 
string type in a future version of Julia (hopefully 0.5). This string type will 
be UTF-8-like but can hold arbitrary data, which will distinguish if from the 
UTF8String type, which will enforce valid UTF-8 encoding.

 

On Mon, Sep 28, 2015 at 9:56 AM, Steven G. Johnson  > wrote:



On Monday, September 28, 2015 at 9:55:27 AM UTC-4, Steven G. Johnson wrote:

The indices passed to strings in Julia are byte offsets,

 

 (Technically, they are codeunit offsets.  In UTF-8, the codeunit is a byte; in 
UTF-16, the codeunit is a 16-bit word.)

 

[julia-users] fixing aspect ratio in Compose.jl

[Michael Borregaard]

Hi,
does anyone know how to fix the aspect ratio in a compose canvas? Gadfly 
can do it with ```coords.Cartesian(fixed = true)```, which uses Compose, 
but how to do it for that?

thanks,
M

Re: [julia-users] Number of loops not known at compile time

[Tim Holy]

If I were doing this, I'd make u a Vector of NTuples, pass it in as an 
argument, and use N in @generating the body of the function. You can use 
Cartesian macros in the body of a generated function (many examples in base).

--Tim

On Monday, September 28, 2015 11:33:46 AM Giuseppe Ragusa wrote:
> @erik thank you. I know of Base.Cartesian, but I was not able to make it
> work for my use case.
> 
> @steven yes, that is what i was afraid of (I was trying to shy away from
> recursion).
> 
> On Monday, September 28, 2015 at 8:23:48 PM UTC+2, Erik Schnetter wrote:
> > Guiseppe
> > 
> > In addition to using recursion, you can also use a macro to generate the
> > code.
> > 
> > However, this functionality is available in the "Cartesian" module which
> > is part of Base Julia. You are probably looking for "@nloops".
> > 
> > -erik
> > 
> > 
> > On Mon, Sep 28, 2015 at 11:24 AM, Giuseppe Ragusa  > 
> > > wrote:
> >> I am having problems (serious problems!) to deal with algorithms that
> >> boil down do nested for loops but whose number of loops is not known at
> >> compile time. As an example consider this:
> >> 
> >> ```
> >> 
> >>  function tmp()
> >>  
> >>  r = 3
> >>  n = 100
> >>  λ = zeros(r)
> >>  u = rand(n, r)
> >>  counter = 0
> >>  Y = Array(Float64, n)
> >>  
> >>  @inbounds for j_1 = 0:k
> >>  
> >>  for i = 1:n
> >>  
> >>  Y[i] = pow(u[i, 1], j_1)
> >>  
> >>  end
> >>  
> >>  λ[1] = j_1
> >>  for j_2 = 0:(k-j_1)
> >>  
> >>  λ[2] = j_2
> >>  for i = 1:n
> >>  
> >>  Y[i] *= pow(u[i, 2], j_2)
> >>  
> >>  end
> >>  
> >>  for j_3 = 0:(k-j_1-j_2)
> >>  
> >>  λ[3] = j_3
> >>  for i = 1:n
> >>  
> >>  Y[i] *= pow(u[i, 3], j_3)
> >>  
> >>  end
> >>  counter += 1
> >>  println(λ, " ", " => ", j_1, j_2, j_3, " counter =>",
> >> 
> >> counter)
> >> 
> >>  end
> >>  
> >>  end
> >>  
> >>  end
> >>  
> >>  end
> >>  ```
> >> 
> >> This is what I want when `r = 3`. For larger `r = 4` there would be an
> >> additional loop. etc. Now, everything is complicated by the fact that `r`
> >> is not know at compile time.
> >> 
> >> I have tried to generate the loops using the macros in  Base.Cartesian
> >> and then using generated functions to accomplish what I want, but I
> >> cannot
> >> get what I want. The main difficulty is that Base.Cartesian I can't get
> >> the
> >> ranges I want).
> >> 
> >> Does anybody have suggestions on how to deal with this?

Re: [julia-users] Why is String deprecated in favour of AbstractString?

[Daniel Carrera]

Sounds interesting. I am very naive when it comes to strings. What re the
advantages of the planned String type that can hold arbitrary data? What
are the problems with UTF8?

Cheers,
Daniel.

On 28 September 2015 at 17:27, Stefan Karpinski 
wrote:

> There's another reason: I am planning to use `String` as the name of a
> standard string type in a future version of Julia (hopefully 0.5). This
> string type will be UTF-8-like but can hold arbitrary data, which will
> distinguish if from the UTF8String type, which will enforce valid UTF-8
> encoding.
>
> On Mon, Sep 28, 2015 at 9:56 AM, Steven G. Johnson 
> wrote:
>
>>
>>
>> On Monday, September 28, 2015 at 9:55:27 AM UTC-4, Steven G. Johnson
>> wrote:
>>>
>>> The indices passed to strings in Julia are byte offsets,
>>>
>>
>>  (Technically, they are codeunit offsets.  In UTF-8, the codeunit is a
>> byte; in UTF-16, the codeunit is a 16-bit word.)
>>
>
>

Re: [julia-users] Why is String deprecated in favour of AbstractString?

[Stefan Karpinski]

Not super interested in getting into it right now. Will make a PR when it's
more ready.

On Mon, Sep 28, 2015 at 4:15 PM, Daniel Carrera  wrote:

> Sounds interesting. I am very naive when it comes to strings. What re the
> advantages of the planned String type that can hold arbitrary data? What
> are the problems with UTF8?
>
> Cheers,
> Daniel.
>
> On 28 September 2015 at 17:27, Stefan Karpinski 
> wrote:
>
>> There's another reason: I am planning to use `String` as the name of a
>> standard string type in a future version of Julia (hopefully 0.5). This
>> string type will be UTF-8-like but can hold arbitrary data, which will
>> distinguish if from the UTF8String type, which will enforce valid UTF-8
>> encoding.
>>
>> On Mon, Sep 28, 2015 at 9:56 AM, Steven G. Johnson > > wrote:
>>
>>>
>>>
>>> On Monday, September 28, 2015 at 9:55:27 AM UTC-4, Steven G. Johnson
>>> wrote:

 The indices passed to strings in Julia are byte offsets,

>>>
>>>  (Technically, they are codeunit offsets.  In UTF-8, the codeunit is a
>>> byte; in UTF-16, the codeunit is a 16-bit word.)
>>>
>>
>>
>

Re: [julia-users] Re: When to use !

[Tom Breloff]

So it seems like there's not an enthusiastic agreement, but that the
slightly better answer is `immerse()` rather than `immerse!()`?   I suppose
I'll make some api changes to remove similar `!` instances, and the next
tag will be a minor version.  Thanks.

On Mon, Sep 28, 2015 at 12:40 PM, Steven G. Johnson 
wrote:

>
>
> On Monday, September 28, 2015 at 12:34:01 PM UTC-4, Tom Breloff wrote:
>>
>> A question regarding the use of `!` came up a few days ago (
>> https://github.com/tbreloff/Plots.jl/issues/30#issuecomment-142995667),
>> and I wanted to quickly poll the users to get opinions.
>>
>> When a module maintains some sort of global state, and a method mutates
>> that global state, is it appropriate to add `!` to the end of the method
>> name?
>>
>> The example referenced asks why I named the method `immerse!()` instead
>> of `immerse()`, even though it doesn't have any arguments to mutate (it
>> changes the default plotting backend, which is part of the module state).
>> Which method name should it be? (and is it better or worse to provide both
>> options which would do the same thing?)
>>
>
> See the discussion in https://github.com/JuliaLang/julia/issues/9262 ...
> and in particular the discussion about rand(), which modifies global state,
> but that is an implementation detail rather than a part of the definition
> of the function.
>

Re: [julia-users] Number of loops not known at compile time

[Erik Schnetter]

Guiseppe

In addition to using recursion, you can also use a macro to generate the
code.

However, this functionality is available in the "Cartesian" module which is
part of Base Julia. You are probably looking for "@nloops".

-erik


On Mon, Sep 28, 2015 at 11:24 AM, Giuseppe Ragusa  wrote:

> I am having problems (serious problems!) to deal with algorithms that boil
> down do nested for loops but whose number of loops is not known at compile
> time. As an example consider this:
>
> ```
>  function tmp()
>  r = 3
>  n = 100
>  λ = zeros(r)
>  u = rand(n, r)
>  counter = 0
>  Y = Array(Float64, n)
>
>  @inbounds for j_1 = 0:k
>
>  for i = 1:n
>  Y[i] = pow(u[i, 1], j_1)
>  end
>
>  λ[1] = j_1
>  for j_2 = 0:(k-j_1)
>  λ[2] = j_2
>  for i = 1:n
>  Y[i] *= pow(u[i, 2], j_2)
>  end
>
>  for j_3 = 0:(k-j_1-j_2)
>  λ[3] = j_3
>  for i = 1:n
>  Y[i] *= pow(u[i, 3], j_3)
>  end
>  counter += 1
>  println(λ, " ", " => ", j_1, j_2, j_3, " counter =>",
> counter)
>  end
>  end
>  end
>  end
>  ```
>
> This is what I want when `r = 3`. For larger `r = 4` there would be an
> additional loop. etc. Now, everything is complicated by the fact that `r`
> is not know at compile time.
>
> I have tried to generate the loops using the macros in  Base.Cartesian and
> then using generated functions to accomplish what I want, but I cannot get
> what I want. The main difficulty is that Base.Cartesian I can't get the
> ranges I want).
>
> Does anybody have suggestions on how to deal with this?
>
>
>


-- 
Erik Schnetter 
http://www.perimeterinstitute.ca/personal/eschnetter/

Re: [julia-users] Number of loops not known at compile time

[Giuseppe Ragusa]

@erik thank you. I know of Base.Cartesian, but I was not able to make it 
work for my use case. 

@steven yes, that is what i was afraid of (I was trying to shy away from 
recursion). 

On Monday, September 28, 2015 at 8:23:48 PM UTC+2, Erik Schnetter wrote:
>
> Guiseppe
>
> In addition to using recursion, you can also use a macro to generate the 
> code.
>
> However, this functionality is available in the "Cartesian" module which 
> is part of Base Julia. You are probably looking for "@nloops".
>
> -erik
>
>
> On Mon, Sep 28, 2015 at 11:24 AM, Giuseppe Ragusa  > wrote:
>
>> I am having problems (serious problems!) to deal with algorithms that 
>> boil down do nested for loops but whose number of loops is not known at 
>> compile time. As an example consider this:
>>
>> ```
>>  function tmp()
>>  r = 3
>>  n = 100
>>  λ = zeros(r)
>>  u = rand(n, r)
>>  counter = 0
>>  Y = Array(Float64, n)
>>
>>  @inbounds for j_1 = 0:k
>>  
>>  for i = 1:n
>>  Y[i] = pow(u[i, 1], j_1)
>>  end
>>  
>>  λ[1] = j_1
>>  for j_2 = 0:(k-j_1)
>>  λ[2] = j_2
>>  for i = 1:n
>>  Y[i] *= pow(u[i, 2], j_2)
>>  end
>>  
>>  for j_3 = 0:(k-j_1-j_2)
>>  λ[3] = j_3
>>  for i = 1:n
>>  Y[i] *= pow(u[i, 3], j_3)
>>  end
>>  counter += 1
>>  println(λ, " ", " => ", j_1, j_2, j_3, " counter =>", 
>> counter)
>>  end
>>  end
>>  end
>>  end
>>  ```
>>
>> This is what I want when `r = 3`. For larger `r = 4` there would be an 
>> additional loop. etc. Now, everything is complicated by the fact that `r` 
>> is not know at compile time. 
>>
>> I have tried to generate the loops using the macros in  Base.Cartesian 
>> and then using generated functions to accomplish what I want, but I cannot 
>> get what I want. The main difficulty is that Base.Cartesian I can't get the 
>> ranges I want). 
>>
>> Does anybody have suggestions on how to deal with this?
>>
>>
>>
>
>
> -- 
> Erik Schnetter  
> http://www.perimeterinstitute.ca/personal/eschnetter/
>

[julia-users] Re: When to use !

[Steven G. Johnson]

On Monday, September 28, 2015 at 12:34:01 PM UTC-4, Tom Breloff wrote:
>
> A question regarding the use of `!` came up a few days ago (
> https://github.com/tbreloff/Plots.jl/issues/30#issuecomment-142995667), 
> and I wanted to quickly poll the users to get opinions.
>
> When a module maintains some sort of global state, and a method mutates 
> that global state, is it appropriate to add `!` to the end of the method 
> name?
>
> The example referenced asks why I named the method `immerse!()` instead of 
> `immerse()`, even though it doesn't have any arguments to mutate (it 
> changes the default plotting backend, which is part of the module state). 
>  Which method name should it be? (and is it better or worse to provide both 
> options which would do the same thing?)
>

See the discussion in https://github.com/JuliaLang/julia/issues/9262 ... 
and in particular the discussion about rand(), which modifies global state, 
but that is an implementation detail rather than a part of the definition 
of the function.

[julia-users] Re: When to use !

[Sisyphuss]

vote for "without !"

On Monday, September 28, 2015 at 6:40:36 PM UTC+2, Steven G. Johnson wrote:
>
>
>
> On Monday, September 28, 2015 at 12:34:01 PM UTC-4, Tom Breloff wrote:
>>
>> A question regarding the use of `!` came up a few days ago (
>> https://github.com/tbreloff/Plots.jl/issues/30#issuecomment-142995667), 
>> and I wanted to quickly poll the users to get opinions.
>>
>> When a module maintains some sort of global state, and a method mutates 
>> that global state, is it appropriate to add `!` to the end of the method 
>> name?
>>
>> The example referenced asks why I named the method `immerse!()` instead 
>> of `immerse()`, even though it doesn't have any arguments to mutate (it 
>> changes the default plotting backend, which is part of the module state). 
>>  Which method name should it be? (and is it better or worse to provide both 
>> options which would do the same thing?)
>>
>
> See the discussion in https://github.com/JuliaLang/julia/issues/9262 ... 
> and in particular the discussion about rand(), which modifies global state, 
> but that is an implementation detail rather than a part of the definition 
> of the function.
>

[julia-users] Re: Optimal Control using Dynamic Programming

[Maxim Egorov]

If you formulate the problem as a Markov decision process, you can use 
POMDPs.jl  which supports value iteration 
. The POMDPs.jl 
framework requires a functional problem definition, and some examples can 
be found in POMDPModels.jl . 

Re: [julia-users] Why is String deprecated in favour of AbstractString?

[Stefan Karpinski]

That's the idea.

On Mon, Sep 28, 2015 at 1:06 PM, David Anthoff  wrote:

> +1 to having a String type that I can just use and it works if I don’t
> care about any of the encoding subtleties.
>
>
>
> *From:* julia-users@googlegroups.com [mailto:julia-users@googlegroups.com]
> *On Behalf Of *Stefan Karpinski
> *Sent:* Monday, September 28, 2015 8:28 AM
> *To:* Julia Users 
> *Subject:* Re: [julia-users] Why is String deprecated in favour of
> AbstractString?
>
>
>
> There's another reason: I am planning to use `String` as the name of a
> standard string type in a future version of Julia (hopefully 0.5). This
> string type will be UTF-8-like but can hold arbitrary data, which will
> distinguish if from the UTF8String type, which will enforce valid UTF-8
> encoding.
>
>
>
> On Mon, Sep 28, 2015 at 9:56 AM, Steven G. Johnson 
> wrote:
>
>
>
> On Monday, September 28, 2015 at 9:55:27 AM UTC-4, Steven G. Johnson wrote:
>
> The indices passed to strings in Julia are byte offsets,
>
>
>
>  (Technically, they are codeunit offsets.  In UTF-8, the codeunit is a
> byte; in UTF-16, the codeunit is a 16-bit word.)
>
>
>

[julia-users] When to use !

[Tom Breloff]

A question regarding the use of `!` came up a few days ago 
(https://github.com/tbreloff/Plots.jl/issues/30#issuecomment-142995667), 
and I wanted to quickly poll the users to get opinions.

When a module maintains some sort of global state, and a method mutates 
that global state, is it appropriate to add `!` to the end of the method 
name?

The example referenced asks why I named the method `immerse!()` instead of 
`immerse()`, even though it doesn't have any arguments to mutate (it 
changes the default plotting backend, which is part of the module state). 
 Which method name should it be? (and is it better or worse to provide both 
options which would do the same thing?)

[julia-users] Re: Number of loops not known at compile time

[Steven G. Johnson]

On Monday, September 28, 2015 at 11:24:40 AM UTC-4, Giuseppe Ragusa wrote:
>
> I am having problems (serious problems!) to deal with algorithms that boil 
> down do nested for loops but whose number of loops is not known at compile 
> time. As an example consider this:
>

In this sort of algorithm, I usually employ recursion (on the dimension 
being looped over), where the base case is 1 or 2 nested loops (big enough 
to amortize the recursion overhead). 

[julia-users] How do I fix this package error?

[Matthias Redies]

I've got a problem with the package Tk. It seems to be a dependency for 
ImageView. I tried to do Pkg.build("Tk"), but it didn't help. This is the 
result of Pkg.test("Tk")

julia> Pkg.test("Tk")
INFO: Computing test dependencies for Tk...
INFO: No packages to install, update or remove
INFO: Testing Tk
ERROR: Tk not properly installed. Please run Pkg.build("Tk")
 in error at ./error.jl:21
 in include at /usr/bin/../lib64/julia/sys.so
 in include_from_node1 at /usr/bin/../lib64/julia/sys.so
 in reload_path at ./loading.jl:152
 in _require at ./loading.jl:67
 in require at ./loading.jl:52
 in include at /usr/bin/../lib64/julia/sys.so
 in include_from_node1 at ./loading.jl:128
 in process_options at /usr/bin/../lib64/julia/sys.so
 in _start at /usr/bin/../lib64/julia/sys.so
while loading /home/matthias/.julia/v0.3/Tk/src/Tk.jl, in expression 
starting on line 24
while loading /home/matthias/.julia/v0.3/Tk/test/runtests.jl, in expression 
starting on line 2
[
 
ERROR: Tk 
]=


failed process: Process(`/usr/bin/julia 
/home/matthias/.julia/v0.3/Tk/test/runtests.jl`, ProcessExited(1)) [1]


==
INFO: No packages to install, update or remove
ERROR: Tk had test errors
 in error at ./error.jl:21
 in test at ./pkg/entry.jl:718
 in anonymous at ./pkg/dir.jl:28
 in cd at /usr/bin/../lib64/julia/sys.so
 in cd at ./pkg/dir.jl:28
 in test at ./pkg.jl:67


I also tried Pkg.build() (without the "Tk"), but the error is quite long so 
I used Pastebin . How do I fix this?

Re: [julia-users] Number of loops not known at compile time

[jonathan . bieler]

If I understand correctly, the trick is to encode the dimension into the 
type of the arguments (using parametric types), then the @generated macro 
allows you to "write" a function just when the type of the arguments is 
known,
so you can create the right numbers of loops on the fly.

http://julia.readthedocs.org/en/latest/manual/metaprogramming/#generated-functions

Maybe this is a good example:

https://github.com/JuliaLang/julia/blob/master/base/multidimensional.jl#L738

Re: [julia-users] How do I pass an event handle via ccall?

[Isaiah Norton]

>
>  What is the difference between an event and a callback function?  I
> think I understand how a callback works.  I thought an event caused a
> callback, but that doesn't look like what's happening here.

A callback is a function that is passed to some other routine, and called
from that routine later. In C, a callback would be a function pointer; in
Julia, a function may be passed either by name or anonymously (see the
docs). A typical example in a GUI application is to associate callback
functions with certain user actions (MouseOver, ButtonClicked, etc.).

The examples in the FTDI manual are "synchronous" (rather than
"asynchronous"), so there are no callbacks involved. In this context,
"event" refers to signalling of an OS-specific synchronization object:
EVENT_HANDLE and HANDLE on *nix and windows respectively (used with the
corresponding `pthread_cond_wait` and `WaitForSingleObject` functions). A
pointer to the sync object is passed as the third argument to
FT_SetEventNotification.
At some point, the appropriate wait function is called, it blocks until a
signal is raised on the synchronization handle, and then the wait function
returns and control flow resumes in the "reader". As indicated in the links
given earlier, it is necessary to run these blocking calls on a separate
async worker thread because the Julia event loop is not thread safe.

Also, beware that there are no guarantees on the timing of async completion
callbacks (due to other queued work, GC pauses blocking the event loop,
etc.).

On Sep 28, 2015 7:34 AM, "Chris Stook"  wrote:

> Thank you.
>>
>
> I have reviewed the suggested material.  I'm probably in way over my head
> with this, but I'd like to learn, so I'm going to ask what is probably a
> novice question.
>
> What is the difference between an event and a callback function?  I think
> I understand how a callback works.  I thought an event caused a callback,
> but that doesn't look like what's happening here.
>
> -Chris
>

[julia-users] Number of loops not known at compile time

[Giuseppe Ragusa]

I am having problems (serious problems!) to deal with algorithms that boil 
down do nested for loops but whose number of loops is not known at compile 
time. As an example consider this:

```
 function tmp()
 r = 3
 n = 100
 λ = zeros(r)
 u = rand(n, r)
 counter = 0
 Y = Array(Float64, n)

 @inbounds for j_1 = 0:k
 
 for i = 1:n
 Y[i] = pow(u[i, 1], j_1)
 end
 
 λ[1] = j_1
 for j_2 = 0:(k-j_1)
 λ[2] = j_2
 for i = 1:n
 Y[i] *= pow(u[i, 2], j_2)
 end
 
 for j_3 = 0:(k-j_1-j_2)
 λ[3] = j_3
 for i = 1:n
 Y[i] *= pow(u[i, 3], j_3)
 end
 counter += 1
 println(λ, " ", " => ", j_1, j_2, j_3, " counter =>", 
counter)
 end
 end
 end
 end
 ```

This is what I want when `r = 3`. For larger `r = 4` there would be an 
additional loop. etc. Now, everything is complicated by the fact that `r` 
is not know at compile time. 

I have tried to generate the loops using the macros in  Base.Cartesian and 
then using generated functions to accomplish what I want, but I cannot get 
what I want. The main difficulty is that Base.Cartesian I can't get the 
ranges I want). 

Does anybody have suggestions on how to deal with this?

[julia-users] Re: Two Modules with same type name

[Kristoffer Carlsson]

Maybe this: https://github.com/simonster/Reexport.jl is useful?

[julia-users] Re: Passing data through Optim

[Christopher Fisher]

Thanks. That worked, but it did not result in the performance increase I 
suspected. 

On Monday, September 28, 2015 at 8:53:25 AM UTC-4, Kristoffer Carlsson 
wrote:
>
> Use closures:
>
> function f(a,b,c)
> # Closure:
> f_closure(a) = a+b+c
>
> #pass f_closure to optimum and it has access to b,c
> println(f_closure(a))
> end
>
> julia> f(3,5,6)
> 14
>
>
>
>
>
> On Monday, September 28, 2015 at 2:46:45 PM UTC+2, Christopher Fisher 
> wrote:
>>
>> I was wondering if there is a way to pass data through the optim function 
>> using the nelder_mead algorithm. As far as I can tell, the only way to fit 
>> a model to data is to declare the data as a global variable. I suspect this 
>> results in poor performance. 
>>
>

[julia-users] Re: Passing data through Optim

[Kristoffer Carlsson]

>From only that comment alone it is hard to give any further advice. 

What overhead are you seeing?

Posting runnable code is the best way to get help.

Re: [julia-users] Why is String deprecated in favour of AbstractString?

[Stefan Karpinski]

There's another reason: I am planning to use `String` as the name of a
standard string type in a future version of Julia (hopefully 0.5). This
string type will be UTF-8-like but can hold arbitrary data, which will
distinguish if from the UTF8String type, which will enforce valid UTF-8
encoding.

On Mon, Sep 28, 2015 at 9:56 AM, Steven G. Johnson 
wrote:

>
>
> On Monday, September 28, 2015 at 9:55:27 AM UTC-4, Steven G. Johnson wrote:
>>
>> The indices passed to strings in Julia are byte offsets,
>>
>
>  (Technically, they are codeunit offsets.  In UTF-8, the codeunit is a
> byte; in UTF-16, the codeunit is a 16-bit word.)
>

Re: [julia-users] How to use variables in subsets of DataFrames ?

[Rob J. Goedman]

Fred,

Would  below example work for you?

julia> dft = readtable("/Users/rob/Desktop/test.csv", separator = '\t')
8x5 DataFrames.DataFrame
| Row | title1 | title2 | title3 | title4 | title5 |
|-||||||
| 1   | 10 | 20 | 30 | 40 | 50 |
| 2   | 11 | 21 | 31 | 41 | 51 |
| 3   | 12 | 22 | 32 | 42 | 52 |
| 4   | 13 | 23 | 33 | 43 | 53 |
| 5   | 14 | 24 | 34 | 44 | 54 |
| 6   | 15 | 25 | 35 | 45 | 55 |
| 7   | 16 | 26 | 36 | 46 | 56 |
| 8   | 17 | 27 | 37 | 47 | 57 |

julia> titles = names(dft)
5-element Array{Symbol,1}:
 :title1
 :title2
 :title3
 :title4
 :title5

julia> dft[[2:6], titles[2:5]]
5x4 DataFrames.DataFrame
| Row | title2 | title3 | title4 | title5 |
|-|||||
| 1   | 21 | 31 | 41 | 51 |
| 2   | 22 | 32 | 42 | 52 |
| 3   | 23 | 33 | 43 | 53 |
| 4   | 24 | 34 | 44 | 54 |
| 5   | 25 | 35 | 45 | 55 |

julia> dft[[2:6], titles[3]]
5-element DataArrays.DataArray{Int64,1}:
 31
 32
 33
 34
 35


If you use list comprehension you will need the extra Symbol[] construct:

julia> dft[:, Symbol[titles[i] for i in 2:3]]
8x2 DataFrames.DataFrame
| Row | title2 | title3 |
|-|||
| 1   | 20 | 30 |
| 2   | 21 | 31 |
| 3   | 22 | 32 |
| 4   | 23 | 33 |
| 5   | 24 | 34 |
| 6   | 25 | 35 |
| 7   | 26 | 36 |
| 8   | 27 | 37 |


Regards,
Rob

> On Sep 28, 2015, at 2:18 AM, Fred  wrote:
> 
> Hi !
> I would like to know how is it possible to use variables in subsets of 
> DataFrames ? I would like to use a syntax like
>  df[:,:titles[1]] and df[:,:titles[1:3]]
> 
> Thanks for your help !
> 
> 
> julia> using DataFrames
> 
> 
> julia> df = readtable("test.csv", separator = '\t')
> 8x5 DataFrame
> | Row | title1 | title2 | title3 | title4 | title5 |
> |-||||||
> | 1   | 10 | 20 | 30 | 40 | 50 |
> | 2   | 11 | 21 | 31 | 41 | 51 |
> | 3   | 12 | 22 | 32 | 42 | 52 |
> | 4   | 13 | 23 | 33 | 43 | 53 |
> | 5   | 14 | 24 | 34 | 44 | 54 |
> | 6   | 15 | 25 | 35 | 45 | 55 |
> | 7   | 16 | 26 | 36 | 46 | 56 |
> | 8   | 17 | 27 | 37 | 47 | 57 |
> 
> 
> julia> titles = readdlm("titles.csv")
> 3x1 Array{Any,2}:
>  "title3"
>  "title1"
>  "title5"
> 
> 
> julia> df[:,:title2]
> 8-element DataArray{Int64,1}: 
> 
>  20   
> 
>  21   
> 
>  22   
> 
>  23   
> 
>  24   
> 
>  25   
> 
>  26   
> 
>  27   
> 
>   
> 
> julia> titles[1]
> "title3"  
> 
>   
> 
> julia> df[:,:titles[1]]
> ERROR: `getindex` has no method matching getindex(::Symbol, ::Int64)   
> 
> julia> df[:,:titles[1:3]]
> ERROR: `getindex` has no method matching getindex(::Symbol, 
> ::UnitRange{Int64})
> 
> 
> 
> 

[julia-users] Re: Two Modules with same type name

[Christoph Ortner]

perfect, thank you both. I will try this approach for now.
Christoph

On Monday, 28 September 2015 16:35:45 UTC+1, Kristoffer Carlsson wrote:
>
> Maybe this: https://github.com/simonster/Reexport.jl is useful?

Re: [julia-users] Why is String deprecated in favour of AbstractString?

[Steven G. Johnson]

On Monday, September 28, 2015 at 9:55:27 AM UTC-4, Steven G. Johnson wrote:
>
> The indices passed to strings in Julia are byte offsets,
>

 (Technically, they are codeunit offsets.  In UTF-8, the codeunit is a 
byte; in UTF-16, the codeunit is a 16-bit word.)

[julia-users] Re: Two Modules with same type name

[Christoph Ortner]

I hadn't thought in terms of 1); it does not fit perfectly, but is the most 
attractive approach so far.

So now I have 3 modules, AbstractM, MA, MB. Is there a way for the user to 
call

using MA

and all functions exported by AbstractM will automatically be exported from 
MA as well?

Thanks,
   Christoph

Re: [julia-users] Nesting Macros passing Expressions

[Tomas Lycken]

What is correct form in this case?

The exact same problem again: you need to *quote* the returned expression 
from the macro, to make sure that the code is run when the macro is called, 
and not when it’s defined.

This will work as intended:

macro tst(i::Int)
quote
tst3(i)
end
end

# or

macro tst(i::Int)
:(tst3(i))
end

This section of the manual 
 might be 
worth reading (again) :)

// T

On Monday, September 28, 2015 at 7:20:03 AM UTC+2, Leonardo wrote:

Many thanks!
>
> I have a similar problem calling a function in following scenario:
> function tst3(i::Int)
> println(i)
> end
>
> macro tst(i::Int)
> tst3(i)
> end
>
> I obtain an error executing code:
> julia> b = 2::Int
> julia> @tst b
> complaining for a problem of type, because tst3 seems to receive a Symbol 
> instead an Integer:
> ERROR: TypeError: anonymous: in typeassert, expected Int64, got Symbol
>
> What is correct form in this case?
>
> Leonardo
>
>
> Il 27/09/2015 18:58, Yichao Yu ha scritto:
>
> On Sun, Sep 27, 2015 at 12:20 PM, Leonardo   
> wrote:
>
> Hi all,
> I need manipulate AST of an expression in a macro, and pass same expression
> in input to another macro, but I experience some problem.
>
> I try to express my doubt with a simplified example:
> macro tst2(e2::Expr)
> println(e2.head)
> end
>
> macro tst(e1::Expr)
> @tst2 esc(e1)
> end
>
> ```
> macro tst(e1::Expr)
> quote
> @tst2 $(esc(e1))
> end
> end
> ```
>
> otherwise, `@tst2` will be run at `tst` definition time.
>
>
> In previous code I want that call to @tst2 behave exact like call to @tst.
>
> E.g. calling @tst2 in REPL I obtain:
> julia> a = 2
> julia> @tst2(a < 3)
> comparison
> but same call to @tst has no effect, and I cannot find an alternative
> working form for @tst
>
> Someone can help me to understand this odd behaviour of Julia's macro?
>
> Many thanks in advance
>
> Leonardo
>
>
>
> ​

Re: [julia-users] Re: UTF16String or UTF8String?

[Jameson Nash]

I find it interesting to note that the wikipedia article points out that if
size compression is the goal (and there is enough text for it to matter),
then SCSU (or other attempts at creating a unicode-specific compression
scheme) is inferior to using a general purpose compression algorithm. Since
the entropy* of the data is independent of its encoding, the size of the
compressed data should also be fairly independent of the encoding.

*entropy is a measure of the amount of "information" contained in a block
of data.

Under optimal compression, the size of the data should equal the entropy.
Using https://en.wikipedia.org/wiki/Entropy_%28information_theory%29 as my
reference, the typical english texts encoded in ASCII can be stored in ~1
bit / character (e.g. utf8 has 700% overhead over the optimal encoding
scheme). At this level of excess over actual compression, there should not
be not much point to the argument over whether 700% or 1500% bloat is
"better".


On Sun, Sep 27, 2015 at 10:47 PM Scott Jones 
wrote:

> The ANSI Latin 1 character set, which is equivalent to the 1st 256
> characters of the Unicode character set,
> supports the following languages: Western Europe and Americas: Afrikaans,
> Basque, Catalan, Danish, Dutch, English, Faeroese, Finnish, French,
> Galician, German, Icelandic, Irish, Italian, Norwegian, Portuguese, Spanish
> and Swedish.
>
> If you store things like Python 3, those will all be stored in 1 byte per
> character.
> In UTF-8, those will use 2 bytes per character for characters between
> 128-255.
>
> Things like Greek, Arabic (most of it, at least), Hebrew, Cyrillic will
> take 2 bytes per character in UTF-8.
>
> Since UTF-8 takes so much space when dealing with text from a large part
> of the world's languages
> (and languages used by > 60% of the world population, by my estimates), in
> the past, I had to come up with packing schemes (that were designed for
> optimizing space, not ease of processing) for efficiently storing Unicode
> text in a database, which other people have also done (see BOCU-1 & SCSU).
>
> Scott
>
>

Re: [julia-users] Implementing printf() and sprintf() in Julia.

[Daniel Carrera]

I just created a pull request. I hope I got it right. This is the first
time I use the pull-request feature at Github.

https://github.com/JuliaLang/Formatting.jl/pull/15

Daniel.

On 28 September 2015 at 07:03, Kevin Squire  wrote:

> How about submitting a patch to Formatting.jl?
>
> On Sunday, September 27, 2015, Michael Hatherly 
> wrote:
>
>> As mentioned in the other thread,
>> https://groups.google.com/d/msg/julia-users/hBbEGEopi0A/OX4ZEhFnBgAJ and
>> https://groups.google.com/d/msg/julia-users/hBbEGEopi0A/fKQcqDEVBgAJ,
>> there are concerns about generating new code for every single formatting
>> string used. I guess generally this won’t be much of an issue, but it could
>> be. Maybe write a package and see how much interest there is first?
>>
>> — Mike
>> ​
>> On Sunday, 27 September 2015 13:02:25 UTC+2, Daniel Carrera wrote:
>>>
>>> Hello,
>>>
>>> I made a trivial change to a some clever code by Tim Holy, and used it
>>> to make printf() and sprintf() function with the familiar syntax that we
>>> know from C/C++ (requires Julia 0.4):
>>>
>>>
>>> immutable FormatString{S} end
>>>
>>> FormatString(str::AbstractString) = FormatString{symbol(str)}
>>>
>>> @generated function Base.print{format}(::Type{FormatString{format}},
>>> args...)
>>> meta = Expr(:meta, :inline)
>>> fmt = string(format)
>>> allargs = [:(args[$d]) for d = 1:length(args)]
>>> quote
>>> @printf($fmt, $(allargs...))
>>> end
>>> end
>>> @generated function Base.sprint{format}(::Type{FormatString{format}},
>>> args...)
>>> meta = Expr(:meta, :inline)
>>> fmt = string(format)
>>> allargs = [:(args[$d]) for d = 1:length(args)]
>>> quote
>>> @sprintf($fmt, $(allargs...))
>>> end
>>> end
>>>
>>> function printf(s::AbstractString, args...)
>>> print(FormatString(s), args...)
>>> end
>>> function sprintf(s::AbstractString, args...)
>>> print(FormatString(s), args...)
>>> end
>>>
>>>
>>> Could (or should) something like this be included in Julia by default?
>>> The first time you call printf() sprintf() with a new format string, the
>>> function call is slower than the @printf and @sprintf macros, but
>>> subsequent calls are just as fast:
>>>
>>> julia> @time @printf("%7d  %7.2f", 220/7, 22/7)
>>>  31 3.14  0.024334 seconds (20.68 k allocations: 912.738 KB)
>>>
>>> julia> @time @printf("%7d  %7.2f", 220/7, 22/7)
>>>  31 3.14  0.000102 seconds (30 allocations: 1.094 KB)
>>>
>>> julia>
>>>
>>> julia> fmt = "%6d  %7.2f"
>>> "%6d  %7.2f"
>>>
>>> julia> @time printf(fmt, 220/7, 22/7)
>>> 31 3.14  0.036154 seconds (36.81 k allocations: 1.675 MB)
>>>
>>> julia> @time printf(fmt, 220/7, 22/7)
>>> 31 3.14  0.95 seconds (37 allocations: 1.250 KB)
>>>
>>>
>>>
>>> Daniel.
>>>
>>

[julia-users] Two Modules with same type name

[Christoph Ortner]

I want to have two modules, say MA, MB both of which define a type  T

module MA
  type T end
end 

module MB
  type T end
end 

Both are different implementations of the same concept, hence the same 
name. Both are exported. Most of the time, I will use either MA or MB, but 
not both. Occasionally, though I will use both to convert between them. 

An easy way to avoid clashes is to just call the first now TA and the 
second one TB, but this creates unnatural and clunky names.

Another way would be to not worry and simply use `import` instead of 
`using` when I need both. 

This situation must have come up many times. How have others dealt with it?

Thank you,
Christoph
 

Re: [julia-users] How do I pass an event handle via ccall?

[Chris Stook]

>
> Thank you.
>

I have reviewed the suggested material.  I'm probably in way over my head 
with this, but I'd like to learn, so I'm going to ask what is probably a 
novice question.

What is the difference between an event and a callback function?  I think I 
understand how a callback works.  I thought an event caused a callback, but 
that doesn't look like what's happening here.

-Chris  

Re: [julia-users] Nesting Macros passing Expressions

[Yichao Yu]

On Mon, Sep 28, 2015 at 2:45 AM, Tomas Lycken  wrote:
> What is correct form in this case?
>
> The exact same problem again: you need to quote the returned expression from
> the macro, to make sure that the code is run when the macro is called, and
> not when it’s defined.
>
> This will work as intended:
>
> macro tst(i::Int)
> quote
> tst3(i)
> end
> end
>
> # or
>
> macro tst(i::Int)
> :(tst3(i))
> end

This won't work either. When you have

The argument to the macro is always the expression and not the value
of it (because for local scope, the macro is executed at compile time
and the symbols doesn't have a value yet). So for `@tst b`, the
argument for `@tst` is always `:b` and `i::Int` won't accept it.

```
macro tst(i)
:(tst3(i))
end
```

Also, as a general note, almost all the `::Int` in your code below are
unnecessary.

> function tst3(i::Int)

This one is fine if you want to define other methods for `tst3` or if
you want to make sure only `Int` can be accepted.

> macro tst(i::Int)

This is bad as mentioned above unless you only want to accept integer
literals i.e. `@tst 2`

Also note that macros cannot be extended. If you want to call
different methods depending on the type of the argument to the macro,
use a helper function. (i.e. `macro tst(i) tst_function(i) end;
tst_function(i::TypeA) = ...; tst_function(i::TypeB) = ...;`). Still
keep in mind that the arguments will be the expression and not the
value.

> julia> b = 2::Int

The `:Int` in this one is useless. The type of a literal is already as
concrete as it could be and adding type assertion on it only add
useless code.

>
> This section of the manual might be worth reading (again) :)
>
> // T
>
> On Monday, September 28, 2015 at 7:20:03 AM UTC+2, Leonardo wrote:
>>
>> Many thanks!
>>
>> I have a similar problem calling a function in following scenario:
>> function tst3(i::Int)
>> println(i)
>> end
>>
>> macro tst(i::Int)
>> tst3(i)
>> end
>>
>> I obtain an error executing code:
>> julia> b = 2::Int
>> julia> @tst b
>> complaining for a problem of type, because tst3 seems to receive a Symbol
>> instead an Integer:
>> ERROR: TypeError: anonymous: in typeassert, expected Int64, got Symbol
>>
>> What is correct form in this case?
>>
>> Leonardo
>>
>>
>> Il 27/09/2015 18:58, Yichao Yu ha scritto:
>>
>> On Sun, Sep 27, 2015 at 12:20 PM, Leonardo  wrote:
>>
>> Hi all,
>> I need manipulate AST of an expression in a macro, and pass same
>> expression
>> in input to another macro, but I experience some problem.
>>
>> I try to express my doubt with a simplified example:
>> macro tst2(e2::Expr)
>> println(e2.head)
>> end
>>
>> macro tst(e1::Expr)
>> @tst2 esc(e1)
>> end
>>
>> ```
>> macro tst(e1::Expr)
>> quote
>> @tst2 $(esc(e1))
>> end
>> end
>> ```
>>
>> otherwise, `@tst2` will be run at `tst` definition time.
>>
>> In previous code I want that call to @tst2 behave exact like call to @tst.
>>
>> E.g. calling @tst2 in REPL I obtain:
>> julia> a = 2
>> julia> @tst2(a < 3)
>> comparison
>> but same call to @tst has no effect, and I cannot find an alternative
>> working form for @tst
>>
>> Someone can help me to understand this odd behaviour of Julia's macro?
>>
>> Many thanks in advance
>>
>> Leonardo
>>
>>
>

Re: [julia-users] How do I pass an event handle via ccall?

[Yichao Yu]

On Mon, Sep 28, 2015 at 7:33 AM, Chris Stook  wrote:
>> Thank you.
>
>
> I have reviewed the suggested material.  I'm probably in way over my head
> with this, but I'd like to learn, so I'm going to ask what is probably a
> novice question.
>
> What is the difference between an event and a callback function?  I think I
> understand how a callback works.  I thought an event caused a callback, but
> that doesn't look like what's happening here.

This seems to be FDTI specific and judging from the reply so far, I
don't think anyone on the list is really familiar with it. The
document seems to have examples in C and it shouldn't be too hard to
translate that to julia.

>
> -Chris

[julia-users] Re: Julia convert BitArray to Integer array

[wildart]

Try `reinterpret(UInt8, x.chunks)`


On Monday, September 28, 2015 at 1:01:47 AM UTC-4, Sweta Yamini wrote:
>
>
>
> Hi,
>
> I am new to Julia. I have an N X N BitArray that I want to pack to Uint8 
> of size N X ceil(N/8)
>
> I tried to reinterpret the array as
>
> packed = reinterpret(Uint8, mybitarray)
>
> but it gives me an error "auto_unbox: unable to determine argument type"
>
> I tried
>
> packed = convert(Array{Uint8}, bitpack(mybitarray))
>
> but it just gives me an N X N Uint8 array with 0 and 1.
>
> Could you help me with this?
>
> Sweta
>

Re: [julia-users] Inset plots with Gadfly?

[Stephan Buchert]

Thanks for the quick reply. I think, this will work.

Am Montag, 28. September 2015 13:43:53 UTC+2 schrieb Tom Breloff:
>
> I don't think it's directly built in, but here's how you would do it: 
>  ("p1.o[2]" and "p2.o[2]" are the Gadfly.Plot objects that are returned 
> from Gadfly.plot commands:
>
> [image: Inline image 1]
>
> On Mon, Sep 28, 2015 at 7:11 AM, Stephan Buchert  > wrote:
>
>> I'm trying out the different options to plot in Julia.
>>
>> Gadfly seems to lack the option to draw a plot at a specified 
>> location/size on the page, like for example as an inset in another plot?
>>
>> Would it be possible to add an interface for doing this? I have  been 
>> staring at the code for hstack/vstack, but this stuff is too abstract for 
>> me.
>>
>> Regards,
>> Stephan
>>
>>
>>
>

[julia-users] Inset plots with Gadfly?

[Stephan Buchert]

I'm trying out the different options to plot in Julia.

Gadfly seems to lack the option to draw a plot at a specified location/size 
on the page, like for example as an inset in another plot?

Would it be possible to add an interface for doing this? I have  been 
staring at the code for hstack/vstack, but this stuff is too abstract for 
me.

Regards,
Stephan

[julia-users] Re: Two Modules with same type name

[Christoph Ortner]

Tomas Lycken: I do this actually, but didn't mention it to not make the 
question overly complicated. How does it solve my problem? My question was 
about co-existence of MA.T and MB.T .
Thanks,
Christoph

[julia-users] RFC: ROOT.jl, wrappers for the ROOT library from CERN

[Joosep Pata]

Hello, 

I’ve compiled a set of wrappers for the ROOT libraries used at CERN for storing 
the data from the Large Hadron Collider.

https://github.com/jpata/ROOT.jl
https://github.com/JuliaLang/METADATA.jl/pull/3550

These are a stop-gap until they can be ported to Keno’s Cxx.jl, but they are 
already useful since a few years, so I’d like to ask for more sets of eyes to 
look at them.

Cheers,
Joosep

[julia-users] How to use variables in subsets of DataFrames ?

[Fred]

Hi !
I would like to know how is it possible to use variables in subsets of 
DataFrames ? I would like to use a syntax like
 df[:,:titles[1]] and df[:,:titles[1:3]] 

Thanks for your help !


julia> using DataFrames


julia> df = readtable("test.csv", separator = '\t')
8x5 DataFrame
| Row | title1 | title2 | title3 | title4 | title5 |
|-||||||
| 1   | 10 | 20 | 30 | 40 | 50 |
| 2   | 11 | 21 | 31 | 41 | 51 |
| 3   | 12 | 22 | 32 | 42 | 52 |
| 4   | 13 | 23 | 33 | 43 | 53 |
| 5   | 14 | 24 | 34 | 44 | 54 |
| 6   | 15 | 25 | 35 | 45 | 55 |
| 7   | 16 | 26 | 36 | 46 | 56 |
| 8   | 17 | 27 | 37 | 47 | 57 |


julia> titles = readdlm("titles.csv")
3x1 Array{Any,2}:
 "title3"
 "title1"
 "title5"


julia> df[:,:title2]
8-element DataArray{Int64,1}:   
  
 20 
  
 21 
  
 22 
  
 23 
  
 24 
  
 25 
  
 26 
  
 27 
  

  
julia> titles[1]
"title3"   
   

  
julia> df[:,:titles[1]]
ERROR: `getindex` has no method matching getindex(::Symbol, ::Int64)   

julia> df[:,:titles[1:3]]
ERROR: `getindex` has no method matching getindex(::Symbol, ::UnitRange{
Int64}) 



title1	title2	title3	title4	title5
10	20	30	40	50
11	21	31	41	51
12	22	32	42	52
13	23	33	43	53
14	24	34	44	54
15	25	35	45	55
16	26	36	46	56
17	27	37	47	57
title3
title1
title5

Re: [julia-users] Re: UTF16String or UTF8String?

[Scott Jones]

On Monday, September 28, 2015 at 3:32:55 AM UTC-4, Jameson wrote:
>
> I find it interesting to note that the wikipedia article points out that 
> if size compression is the goal (and there is enough text for it to 
> matter), then SCSU (or other attempts at creating a unicode-specific 
> compression scheme) is inferior to using a general purpose compression 
> algorithm. Since the entropy* of the data is independent of its encoding, 
> the size of the compressed data should also be fairly independent of the 
> encoding.
>
> *entropy is a measure of the amount of "information" contained in a block 
> of data.
>
> Under optimal compression, the size of the data should equal the entropy. 
> Using https://en.wikipedia.org/wiki/Entropy_%28information_theory%29 
> 
>  
> as my reference, the typical english texts encoded in ASCII can be stored 
> in ~1 bit / character (e.g. utf8 has 700% overhead over the optimal 
> encoding scheme). At this level of excess over actual compression, there 
> should not be not much point to the argument over whether 700% or 1500% 
> bloat is "better".
>

Theory is fine, until you have to do something in the real world.
Even with a very large file (1GB) of highly compressible XML of mostly 
English text, your typical general purpose compression schemes don't 
generally get better than 1/2 to 1/4 the original size, and the 
encoding/decoding can take large amounts of memory for their dictionaries.
(note, if you really think you can do better, there is 50,000 euros of 
prize money waiting for you)
See http://mattmahoney.net/dc/text.html.

A general purpose compression algorithm really doesn't do very well when 
the average length of what you are compressing is less than 16 characters.
If you are interested, please 
read http://www.unicode.org/notes/tn14/UnicodeCompression.pdf, which has a 
good discussion of both Unicode specific compression schemes (such as 
BOCU-1, SCSU) vs. general purpose compression schemes.
In particular, read the last paragraph or two of page 12, and the 
conclusions at the end.
The Unicode specific scheme I came up with back in the '90s (which is 
probably more heavily used than either BOCU-1 or SCSU, but is proprietary), 
uses run-length encoding and packs sequences of digits (think of what you'd 
see in a CSV file, for example), and so achieves higher compression ratios 
than either BOCU-1 or SCSU.

Note, I have nothing against using general purpose compression schemes, 
they work pretty well when compressing whole files, or whole blocks or 
chunks of data (before encryption, of course!), say when moving blocks from 
cache to disk and vice-versa, it just doesn't help at all for compressing 
short Unicode sequences quickly.

RE: [julia-users] Re: How do I fix this package error?

[David Anthoff]

You certainly got the German part right.

 

From: julia-users@googlegroups.com [mailto:julia-users@googlegroups.com] On 
Behalf Of Tony Kelman
Sent: Monday, September 28, 2015 3:36 PM
To: julia-users 
Subject: [julia-users] Re: How do I fix this package error?

 

I don't speak German, but the error looks to be:

 

1.  schwerwiegender Fehler: X11/Xlib.h: Datei oder Verzeichnis nicht gefunden

2. Kompilierung beendet.

 

Which I think is telling you it can't find the X11 headers. There should be a 
development package you can install for that, possibly libx11-dev on ubuntu?



On Monday, September 28, 2015 at 2:36:38 PM UTC-7, Matthias Redies wrote:

I've got a problem with the package Tk. It seems to be a dependency for 
ImageView. I tried to do Pkg.build("Tk"), but it didn't help. This is the 
result of Pkg.test("Tk")

 

julia> Pkg.test("Tk")
INFO: Computing test dependencies for Tk...
INFO: No packages to install, update or remove
INFO: Testing Tk
ERROR: Tk not properly installed. Please run Pkg.build("Tk")
 in error at ./error.jl:21
 in include at /usr/bin/../lib64/julia/sys.so
 in include_from_node1 at /usr/bin/../lib64/julia/sys.so
 in reload_path at ./loading.jl:152
 in _require at ./loading.jl:67
 in require at ./loading.jl:52
 in include at /usr/bin/../lib64/julia/sys.so
 in include_from_node1 at ./loading.jl:128
 in process_options at /usr/bin/../lib64/julia/sys.so
 in _start at /usr/bin/../lib64/julia/sys.so
while loading /home/matthias/.julia/v0.3/Tk/src/Tk.jl, in expression starting 
on line 24
while loading /home/matthias/.julia/v0.3/Tk/test/runtests.jl, in expression 
starting on line 2
[
 ERROR: Tk 
]=


failed process: Process(`/usr/bin/julia 
/home/matthias/.julia/v0.3/Tk/test/runtests.jl`, ProcessExited(1)) [1]


==
INFO: No packages to install, update or remove
ERROR: Tk had test errors
 in error at ./error.jl:21
 in test at ./pkg/entry.jl:718
 in anonymous at ./pkg/dir.jl:28
 in cd at /usr/bin/../lib64/julia/sys.so
 in cd at ./pkg/dir.jl:28
 in test at ./pkg.jl:67


I also tried Pkg.build() (without the "Tk"), but the error is quite long so I 
used Pastebin  . How do I fix this?

 

Re: [julia-users] Re: When to use !

[Scott Jones]

I'd also stick with the convention that ! means modification of one or more 
of the arguments (typically first argument), and definitely not have it for 
anything where there is some external state modification that is just an 
implementation detail.
(if somethings purpose is to set global state, such as set_rounding, I do 
like having the set_ to indicate that).

On Monday, September 28, 2015 at 1:03:52 PM UTC-4, Tom Breloff wrote:
>
> So it seems like there's not an enthusiastic agreement, but that the 
> slightly better answer is `immerse()` rather than `immerse!()`?   I suppose 
> I'll make some api changes to remove similar `!` instances, and the next 
> tag will be a minor version.  Thanks.
>
> On Mon, Sep 28, 2015 at 12:40 PM, Steven G. Johnson  > wrote:
>
>>
>>
>> On Monday, September 28, 2015 at 12:34:01 PM UTC-4, Tom Breloff wrote:
>>>
>>> A question regarding the use of `!` came up a few days ago (
>>> https://github.com/tbreloff/Plots.jl/issues/30#issuecomment-142995667), 
>>> and I wanted to quickly poll the users to get opinions.
>>>
>>> When a module maintains some sort of global state, and a method mutates 
>>> that global state, is it appropriate to add `!` to the end of the method 
>>> name?
>>>
>>> The example referenced asks why I named the method `immerse!()` instead 
>>> of `immerse()`, even though it doesn't have any arguments to mutate (it 
>>> changes the default plotting backend, which is part of the module state).  
>>> Which method name should it be? (and is it better or worse to provide both 
>>> options which would do the same thing?)
>>>
>>
>> See the discussion in https://github.com/JuliaLang/julia/issues/9262 ... 
>> and in particular the discussion about rand(), which modifies global state, 
>> but that is an implementation detail rather than a part of the definition 
>> of the function.
>>
>
>

[julia-users] Re: How do I fix this package error?

[Tony Kelman]

I don't speak German, but the error looks to be:


   1. schwerwiegender Fehler: X11/Xlib.h: Datei oder Verzeichnis nicht 
   gefunden
   2. Kompilierung beendet.
   

Which I think is telling you it can't find the X11 headers. There should be 
a development package you can install for that, possibly libx11-dev on 
ubuntu?


On Monday, September 28, 2015 at 2:36:38 PM UTC-7, Matthias Redies wrote:
>
> I've got a problem with the package Tk. It seems to be a dependency for 
> ImageView. I tried to do Pkg.build("Tk"), but it didn't help. This is the 
> result of Pkg.test("Tk")
>
> julia> Pkg.test("Tk")
> INFO: Computing test dependencies for Tk...
> INFO: No packages to install, update or remove
> INFO: Testing Tk
> ERROR: Tk not properly installed. Please run Pkg.build("Tk")
>  in error at ./error.jl:21
>  in include at /usr/bin/../lib64/julia/sys.so
>  in include_from_node1 at /usr/bin/../lib64/julia/sys.so
>  in reload_path at ./loading.jl:152
>  in _require at ./loading.jl:67
>  in require at ./loading.jl:52
>  in include at /usr/bin/../lib64/julia/sys.so
>  in include_from_node1 at ./loading.jl:128
>  in process_options at /usr/bin/../lib64/julia/sys.so
>  in _start at /usr/bin/../lib64/julia/sys.so
> while loading /home/matthias/.julia/v0.3/Tk/src/Tk.jl, in expression 
> starting on line 24
> while loading /home/matthias/.julia/v0.3/Tk/test/runtests.jl, in 
> expression starting on line 2
>
> [
>  
> ERROR: Tk 
> ]=
>
>
> failed process: Process(`/usr/bin/julia 
> /home/matthias/.julia/v0.3/Tk/test/runtests.jl`, ProcessExited(1)) [1]
>
>
>
> ==
> INFO: No packages to install, update or remove
> ERROR: Tk had test errors
>  in error at ./error.jl:21
>  in test at ./pkg/entry.jl:718
>  in anonymous at ./pkg/dir.jl:28
>  in cd at /usr/bin/../lib64/julia/sys.so
>  in cd at ./pkg/dir.jl:28
>  in test at ./pkg.jl:67
>
>
> I also tried Pkg.build() (without the "Tk"), but the error is quite long 
> so I used Pastebin . How do I fix this?
>
>

Re: [julia-users] Re: How do I fix this package error?

[Matthias Redies]

Am Dienstag, 29. September 2015 00:39:47 UTC+2 schrieb David Anthoff:
>
> You certainly got the German part right.
>
>  
>
> *From:* julia...@googlegroups.com  [mailto:
> julia...@googlegroups.com ] *On Behalf Of *Tony Kelman
> *Sent:* Monday, September 28, 2015 3:36 PM
> *To:* julia-users 
> *Subject:* [julia-users] Re: How do I fix this package error?
>
>  
>
> I don't speak German, but the error looks to be:
>
>  
>
> 1.  schwerwiegender Fehler: X11/Xlib.h: Datei oder Verzeichnis nicht 
> gefunden
>
> 2. Kompilierung beendet.
>
>  
>
> Which I think is telling you it can't find the X11 headers. There should 
> be a development package you can install for that, possibly libx11-dev on 
> ubuntu?
>
>
>
> On Monday, September 28, 2015 at 2:36:38 PM UTC-7, Matthias Redies wrote:
>
> I've got a problem with the package Tk. It seems to be a dependency for 
> ImageView. I tried to do Pkg.build("Tk"), but it didn't help. This is the 
> result of Pkg.test("Tk")
>
>  
>
> julia> Pkg.test("Tk")
> INFO: Computing test dependencies for Tk...
> INFO: No packages to install, update or remove
> INFO: Testing Tk
> ERROR: Tk not properly installed. Please run Pkg.build("Tk")
>  in error at ./error.jl:21
>  in include at /usr/bin/../lib64/julia/sys.so
>  in include_from_node1 at /usr/bin/../lib64/julia/sys.so
>  in reload_path at ./loading.jl:152
>  in _require at ./loading.jl:67
>  in require at ./loading.jl:52
>  in include at /usr/bin/../lib64/julia/sys.so
>  in include_from_node1 at ./loading.jl:128
>  in process_options at /usr/bin/../lib64/julia/sys.so
>  in _start at /usr/bin/../lib64/julia/sys.so
> while loading /home/matthias/.julia/v0.3/Tk/src/Tk.jl, in expression 
> starting on line 24
> while loading /home/matthias/.julia/v0.3/Tk/test/runtests.jl, in 
> expression starting on line 2
>
> [
>  
> ERROR: Tk 
> ]=
>
>
> failed process: Process(`/usr/bin/julia 
> /home/matthias/.julia/v0.3/Tk/test/runtests.jl`, ProcessExited(1)) [1]
>
>
>
> ==
> INFO: No packages to install, update or remove
> ERROR: Tk had test errors
>  in error at ./error.jl:21
>  in test at ./pkg/entry.jl:718
>  in anonymous at ./pkg/dir.jl:28
>  in cd at /usr/bin/../lib64/julia/sys.so
>  in cd at ./pkg/dir.jl:28
>  in test at ./pkg.jl:67
>
>
> I also tried Pkg.build() (without the "Tk"), but the error is quite long 
> so I used Pastebin . How do I fix this?
>
>  
>
>
It worked. I ran "sudo dnf groupinstall "X Software Development" and now 
everything seems to be fine. 

Thanks
 

[julia-users] Proposed change to HttpServer.handle signature

[jock . lawrie]

 

Hi all,


There has been some discussion here 
 about changing the 
signature of HttpHandler.handle from f(req, res) to f(req).

The purpose is to make the functionality of an application clearer. That 
is, an application is a function that takes in a Request and returns a 
Response:


function app(req::Request)
...# do stuff here
res# Response typeend

There is some support for the idea among the web stack devs and no 
objections...so far.


Before making the change I'd like to get a sense of how disruptive this 
might be for users of the Julia web stack. So the two questions are:


1) What problems will this change cause?

2) The proposal is to deprecate the current signature such that both f(req, 
res) and f(req)will work in Julia 0.4, but only f(req) will work in Julia 
0.5.


Nothing is set in stone yet so please speak up if this is a cause for 
concern. 


Cheers,

Jock

[julia-users] Julia release candidates downloading with Ubuntu PPA

[Scott Jones]

Because we needed to use some of the functionality which had been in 0.4, 
we'd been using the nightly builds from 'ppa:staticfloat/julianightlies',
but now we need to switch that to picking up the 0.4.0 release candidates 
until 0.4 becomes the release (because some packages like PEGParser.jl
are failing doing a Pkg.build, complaining about not working with 0.5).

Is there any way of getting the 0.4 RC for Ubuntu?

Thanks, Scott

[julia-users] Plasma Actuator Simulation

[Marius]

Hi everybody,

I wrote a simulation code for Plasma Actuator. This is based on my previous 
code written in Python and uses Suzen model combined with Navier-Stokes 
equations. It's about 5 times faster than Python but still simulation takes 
days to finish. I am new to Julia and I tried to follow the performance 
tips but so far this is how much I could do. Any suggestions for improving 
speed are highly appreciated. This is the code:


using PyPlot
using PyCall

const nx=441
const ny=441
const nt=100
const Length=0.011#11 mm
const dx=Length/(nx-1)
const dy=Length/(ny-1)
x=linspace(-Length/2,Length/2,nx)
y=linspace(-Length/2,Length/2,ny)

phi1 = zeros(ny,nx) #potential
eps=zeros(ny,nx)#permitivity
roc=ones(ny,nx)#charge
ld=ones(ny,nx)#Debye length
### All Electrodes 
# initial boundary conditions
phi1[221:222,49:57]=1400.0
phi1[218:219,57:97]=0.0
#phi1[221:222,97:105]=0.0
phi1[221:222,145:153]=1400.0
phi1[218:219,153:193]=0.0
#phi1[221:222,193:201]=0.0
#phi1[221:222,241:249]=0.0
phi1[218:219,249:289]=0.0
phi1[221:222,289:297]=1400.0
#phi1[221:222,337:345]=0.0
phi1[218:219,345:385]=0.0
phi1[221:222,385:393]=1400.0
eps[1:220,:]=2.7
eps[221:end,:]=1.0
eps[221:221,:]=(eps[222:222,1:end].*eps[220:220,1:end])./(((dx/(2*dx))*eps[222:222,1:end])+
(((dx/(2*dx))*eps[220:220,1:end])))
###
#convergence parameters
to1=1e-8
###Gauss-Seidel solver
max_phi1_diff=1
while max_phi1_diff > to1
  phi1_old=copy(phi1)
  phi1[2:nx-1,2:ny-1]=((eps[2:nx-1,2:ny-1].*((phi1[3:nx,2:ny-1]/(dx^2))+

(phi1[2:nx-1,3:ny]/(dy^2)))+((eps[1:nx-2,2:ny-1].*phi1[1:nx-2,2:ny-1])/(dx^2))+

((eps[2:nx-1,1:ny-2].*phi1[2:nx-1,1:ny-2]/(dy^2)./(((eps[2:nx-1,2:ny-1]+
eps[1:nx-2,2:ny-1])/(dx^2))+
((eps[2:nx-1,2:ny-1]+eps[2:nx-1,1:ny-2])/(dy^2)))
  phi1[end,:]=phi1[end-1,:]
  phi1[1,:]=phi1[2,:]
  phi1[:,end]=phi1[:,end-1]
  phi1[:,1]=phi1[:,2]
  phi1[221:222,49:57]=1400.0
  phi1[218:219,57:97]=0.0
  #phi1[221:222,97:105]=0.0
  phi1[221:222,145:153]=1400.0
  phi1[218:219,153:193]=0.0
  #phi1[221:222,193:201]=0.0
  #phi1[221:222,241:249]=0.0
  phi1[218:219,249:289]=0.0
  phi1[221:222,289:297]=1400.0
  #phi1[221:222,337:345]=0.0
  phi1[218:219,345:385]=0.0
  phi1[221:222,385:393]=1400.0
  eps[1:220,:]=2.7
  eps[221:end,:]=1.0
  phi1_diff = phi1.-phi1_old
  max_phi1_diff=maximum(abs(phi1_diff))
end

fig = plt.figure(figsize = (11,7), dpi=100)
plt.contourf(x*1000,y*1000,phi1,50)
cbar = plt.colorbar()
savefig("wflow1368AC29SeptemberElectricField.png")
 CHARGE  
ld[221:end,:]=0.00017 #Debye lenght
ld[1:220,:]=1.0#Debye lenght
roc[218:219,57:97]=0.00750
roc[218:219,153:193]=0.00750
roc[218:219,249:289]=0.00750
roc[218:219,345:385]=0.00750
eps[1:220,:]=2.7
eps[221:end,:]=1.0
eps[221:221,:]=(eps[222:222,1:end].*eps[220:220,1:end])./(((dx/(2*dx))*eps[222:222,1:end])+
(((dx/(2*dx))*eps[220:220,1:end])))
roc[:,end] =0
roc[end,:] = 0
roc[:,1] =0
roc[1,:] = 0
#convergence parameters
to1=1e-8
###Gauss-Seidel solver
max_roc_diff=1
while max_roc_diff > to1
  roc_old=copy(roc)
  
roc[2:nx-1,2:ny-1]=((eps[2:nx-1,2:ny-1].*((roc[3:nx,2:ny-1]/(dx^2)).+(roc[2:nx-1,3:ny]/dy^2)))+
((eps[1:nx-2,2:ny-1].*roc[1:nx-2,2:ny-1])/dx^2)+

((eps[2:nx-1,1:ny-2].*roc[2:nx-1,1:ny-2])/dy^2))./(((eps[2:nx-1,2:ny-1].+eps[1:nx-2,2:ny-1])/dx^2)+

((eps[2:nx-1,2:ny-1]+eps[2:nx-1,1:ny-2])/dy^2)+(1./(ld[2:nx-1,2:ny-1].^2)))
  ld[221:end,:]=0.00017 #charge
  ld[1:220,:]=1.0#Debye lenght
  roc[218:219,57:97]=0.00750
  roc[218:219,153:193]=0.00750
  roc[218:219,249:289]=0.00750
  roc[218:219,345:385]=0.00750
  roc_diff = roc.-roc_old
  max_roc_diff=maximum(abs(roc_diff))
end

fig = plt.figure(figsize = (11,7), dpi=100)
plt.contourf(x*1000,y*1000,roc,50)
cbar = plt.colorbar()
savefig("wflow1368AC29SeptemberCharge.png")
# BODY FORCE ###
F1=ones(ny,nx)
Fx1=ones(ny,nx)
Fy1=ones(ny,nx)
F1[2:nx-1,2:ny-1]=roc[2:nx-1,2:ny-1].*(-(((phi1[2:nx-1,2:ny-1]-phi1[1:nx-2,2:ny-1])/dx)+((phi1[2:nx-1,2:ny-1]-phi1[2:nx-1,1:ny-2])/dy)))
F1[221:222,49:57]=0.0
F1[218:219,57:97]=0.0
F1[221:222,97:105]=0.0
F1[221:222,145:153]=0.0
F1[218:219,153:193]=0.0
F1[221:222,193:201]=0.0
F1[221:222,241:249]=0.0
F1[218:219,249:289]=0.0
F1[221:222,289:297]=0.0
F1[221:222,337:345]=0.0
F1[218:219,345:385]=0.0
F1[221:222,385:393]=0.0
F1[1:220,:]=0.0
## Body force on x and Y ###
Fx1[2:nx-1,2:ny-1]=roc[2:nx-1,2:ny-1].*(-(((phi1[2:nx-1,2:ny-1]-phi1[1:nx-2,2:ny-1])/dx)))
Fy1[2:nx-1,2:ny-1]=roc[2:nx-1,2:ny-1].*(-((phi1[2:nx-1,2:ny-1]-phi1[2:nx-1,1:ny-2])/dy))

fig = plt.figure(figsize = (11,7), dpi=100)
plt.contourf(x*1000,y*1000,F1,50)
cbar = plt.colorbar()
savefig("wflow1368AC29SeptemberForce.png")
###
#Navier Stokes
const 

[julia-users] Re: Julia release candidates downloading with Ubuntu PPA

[Jeffrey Sarnoff]

I use linuxmint which works well with ubuntu pkgs.  I have had success 
downloading the generic linux binaries and (as root) stuffing the contents 
into /usr/local.

On Monday, September 28, 2015 at 9:57:13 PM UTC-4, Scott Jones wrote:
>
> Because we needed to use some of the functionality which had been in 0.4, 
> we'd been using the nightly builds from 'ppa:staticfloat/julianightlies',
> but now we need to switch that to picking up the 0.4.0 release candidates 
> until 0.4 becomes the release (because some packages like PEGParser.jl
> are failing doing a Pkg.build, complaining about not working with 0.5).
>
> Is there any way of getting the 0.4 RC for Ubuntu?
>
> Thanks, Scott
>
>

[julia-users] Re: Hyper-Dual numbers

[Nitin Arora]

There is another method to calculate any order derivatives, very similar to 
this one, known as Multi-complex differentiation. This method can calculate 
derivatives up-to any order.

http://www.autodiff.org/Docs/euroad/13rd%20EuroAd%20Workshop%20-%20Thierry%20Dargent%20-%20Using%20Multicomplex%20Variables%20for%20Automatic%20Computation%20of%20High-Order%20Derivatives.pdf

http://delivery.acm.org/10.1145/217/2168774/a16-lantoine.pdf?ip=207.151.221.1=2168774=ACTIVE%20SERVICE=6405B83BDA580DC2%2E4D4702B0C3E38B35%2E4D4702B0C3E38B35%2E4D4702B0C3E38B35=717380051=25446753&__acm__=1443489222_ee3f3d4c7ee41030aaba536e14d6a6ab

I have used this in my field and it seems to work nicely.

thanks,
Nitin

On Saturday, March 29, 2014 at 5:43:05 PM UTC-7, Rob J Goedman wrote:
>
> Hi,
>
> As a first 'jump into the fray' exercise I've attempted to translate 
> Jeffrey Fike's hyper-dual numbers code from c++ to Julia, more or less 
> following the DualNumbers package.
>
> The c++ code can be found at http://adl.stanford.edu/hyperdual/hyperdual.h 
> . The paper itself at 
> http://adl.stanford.edu/hyperdual/Fike_AIAA-2011-886.pdf .
>
> The Julia package can be found at: 
> https://github.com/goedman/HyperDualNumbers.jl.git .
>
> Of course, I'm pretty new at this so I'm sure there will be errors and 
> poor practices. So any feedback is appreciated.
>
> Also, I'm wondering if the type should be called Hyper or a better name 
> would be HyperDual.
>
> This work was triggered by the interesting threads around openPP, 
> TaylorSeries.jl, Calculus2, PowerSeries.jl (and at some time I hope 
> MCMC.jl).
>
> Rob J. Goedman
> goe...@icloud.com 
>
>
>
>
>

[julia-users] Re: Two Modules with same type name

[Tomas Lycken]

Oh, I think I might have misread your question a little. Sorry 'bout that.

It's difficult to suggest a perfect solution without knowing more about 
your actual use case, but I would probably go with one of these two 
approaches:

1) If the two types are basically different implementations of the same 
concept, where the abstract type can really capture the concept, I would 
not export either MA.T or MB.T. Rather, I'd export AbstractT, and a bunch 
of methods working on AbstractTs, and have all client code use only that, 
and be agnostic of whether it's really the implementation from MA or MB. 
This works well only if the two concepts MA.T and MB.T are so similar that 
all verbs that are related to them (i.e. all functions you might want to 
apply to them) are the same, so that you can just dispatch on the runtime 
type and get the job done.

2) If the two types are implementations of different concepts with some 
things in common, I'd rename them to make that fact clear; don't call them 
MA.T and MB.T, but rather MA.ThisT and MB.ThatT, For example, don't have 
`module Linear type Model end end` and `model Exponential type Model end 
end`, but rather two types `LinearModel` and `ExponentialModel` and export 
both. You'll avoid naming conflicts, and the actual intent of your code 
will be better communicated to the user (who might not know, or want to 
know, exactly which module the type was defined in).

If neither of these approaches seem viable, can you give some more detail 
on what you're trying to do?

On Monday, September 28, 2015 at 2:36:49 PM UTC+2, Christoph Ortner wrote:
>
> Tomas Lycken: I do this actually, but didn't mention it to not make the 
> question overly complicated. How does it solve my problem? My question was 
> about co-existence of MA.T and MB.T .
> Thanks,
> Christoph
>

[julia-users] Passing data through Optim

[Christopher Fisher]

I was wondering if there is a way to pass data through the optim function 
using the nelder_mead algorithm. As far as I can tell, the only way to fit 
a model to data is to declare the data as a global variable. I suspect this 
results in poor performance. 

[julia-users] Re: Passing data through Optim

[Kristoffer Carlsson]

Use closures:

function f(a,b,c)
# Closure:
f_closure(a) = a+b+c

#pass f_closure to optimum and it has access to b,c
println(f_closure(a))
end

julia> f(3,5,6)
14





On Monday, September 28, 2015 at 2:46:45 PM UTC+2, Christopher Fisher wrote:
>
> I was wondering if there is a way to pass data through the optim function 
> using the nelder_mead algorithm. As far as I can tell, the only way to fit 
> a model to data is to declare the data as a global variable. I suspect this 
> results in poor performance. 
>

[julia-users] Re: Plasma Actuator Simulation

[John Gibson]

Marius: I think you'd be better off in learning to write fast Julia code if 
you presented an straightforward implementation of a classic PDE problem 
and asked for help in optimizing that. Maybe 2D heat equation would be a 
good place to start. The code you've presented is not really intelligible 
without a better description of the equations, the boundary conditions, the 
discretization methods, more detailed comments, explanations of magic 
numbers, etc. And requiring plasma physics expertise makes your audience 
here too small,  probably.

best regards, 

John


On Monday, September 28, 2015 at 10:14:32 PM UTC-4, Marius wrote:
>
> Hi everybody,
>
> I wrote a simulation code for Plasma Actuator. This is based on my 
> previous code written in Python and uses Suzen model combined with 
> Navier-Stokes equations. It's about 5 times faster than Python but still 
> simulation takes days to finish. I am new to Julia and I tried to follow 
> the performance tips but so far this is how much I could do. Any 
> suggestions for improving speed are highly appreciated. This is the code:
>
>
> using PyPlot
> using PyCall
>
> const nx=441
> const ny=441
> const nt=100
> const Length=0.011#11 mm
> const dx=Length/(nx-1)
> const dy=Length/(ny-1)
> x=linspace(-Length/2,Length/2,nx)
> y=linspace(-Length/2,Length/2,ny)
> 
> phi1 = zeros(ny,nx) #potential
> eps=zeros(ny,nx)#permitivity
> roc=ones(ny,nx)#charge
> ld=ones(ny,nx)#Debye length
> ### All Electrodes 
> # initial boundary conditions
> phi1[221:222,49:57]=1400.0
> phi1[218:219,57:97]=0.0
> #phi1[221:222,97:105]=0.0
> phi1[221:222,145:153]=1400.0
> phi1[218:219,153:193]=0.0
> #phi1[221:222,193:201]=0.0
> #phi1[221:222,241:249]=0.0
> phi1[218:219,249:289]=0.0
> phi1[221:222,289:297]=1400.0
> #phi1[221:222,337:345]=0.0
> phi1[218:219,345:385]=0.0
> phi1[221:222,385:393]=1400.0
> eps[1:220,:]=2.7
> eps[221:end,:]=1.0
>
> eps[221:221,:]=(eps[222:222,1:end].*eps[220:220,1:end])./(((dx/(2*dx))*eps[222:222,1:end])+
> (((dx/(2*dx))*eps[220:220,1:end])))
> ###
> #convergence parameters
> to1=1e-8
> ###Gauss-Seidel solver
> max_phi1_diff=1
> while max_phi1_diff > to1
>   phi1_old=copy(phi1)
>   phi1[2:nx-1,2:ny-1]=((eps[2:nx-1,2:ny-1].*((phi1[3:nx,2:ny-1]/(dx^2))+
> 
> (phi1[2:nx-1,3:ny]/(dy^2)))+((eps[1:nx-2,2:ny-1].*phi1[1:nx-2,2:ny-1])/(dx^2))+
> 
> ((eps[2:nx-1,1:ny-2].*phi1[2:nx-1,1:ny-2]/(dy^2)./(((eps[2:nx-1,2:ny-1]+
> eps[1:nx-2,2:ny-1])/(dx^2))+
> ((eps[2:nx-1,2:ny-1]+eps[2:nx-1,1:ny-2])/(dy^2)))
>   phi1[end,:]=phi1[end-1,:]
>   phi1[1,:]=phi1[2,:]
>   phi1[:,end]=phi1[:,end-1]
>   phi1[:,1]=phi1[:,2]
>   phi1[221:222,49:57]=1400.0
>   phi1[218:219,57:97]=0.0
>   #phi1[221:222,97:105]=0.0
>   phi1[221:222,145:153]=1400.0
>   phi1[218:219,153:193]=0.0
>   #phi1[221:222,193:201]=0.0
>   #phi1[221:222,241:249]=0.0
>   phi1[218:219,249:289]=0.0
>   phi1[221:222,289:297]=1400.0
>   #phi1[221:222,337:345]=0.0
>   phi1[218:219,345:385]=0.0
>   phi1[221:222,385:393]=1400.0
>   eps[1:220,:]=2.7
>   eps[221:end,:]=1.0
>   phi1_diff = phi1.-phi1_old
>   max_phi1_diff=maximum(abs(phi1_diff))
> end
>
> fig = plt.figure(figsize = (11,7), dpi=100)
> plt.contourf(x*1000,y*1000,phi1,50)
> cbar = plt.colorbar()
> savefig("wflow1368AC29SeptemberElectricField.png")
>  CHARGE  
> ld[221:end,:]=0.00017 #Debye lenght
> ld[1:220,:]=1.0#Debye lenght
> roc[218:219,57:97]=0.00750
> roc[218:219,153:193]=0.00750
> roc[218:219,249:289]=0.00750
> roc[218:219,345:385]=0.00750
> eps[1:220,:]=2.7
> eps[221:end,:]=1.0
>
> eps[221:221,:]=(eps[222:222,1:end].*eps[220:220,1:end])./(((dx/(2*dx))*eps[222:222,1:end])+
> (((dx/(2*dx))*eps[220:220,1:end])))
> roc[:,end] =0
> roc[end,:] = 0
> roc[:,1] =0
> roc[1,:] = 0
> #convergence parameters
> to1=1e-8
> ###Gauss-Seidel solver
> max_roc_diff=1
> while max_roc_diff > to1
>   roc_old=copy(roc)
>   
> roc[2:nx-1,2:ny-1]=((eps[2:nx-1,2:ny-1].*((roc[3:nx,2:ny-1]/(dx^2)).+(roc[2:nx-1,3:ny]/dy^2)))+
> ((eps[1:nx-2,2:ny-1].*roc[1:nx-2,2:ny-1])/dx^2)+
> 
> ((eps[2:nx-1,1:ny-2].*roc[2:nx-1,1:ny-2])/dy^2))./(((eps[2:nx-1,2:ny-1].+eps[1:nx-2,2:ny-1])/dx^2)+
> 
> ((eps[2:nx-1,2:ny-1]+eps[2:nx-1,1:ny-2])/dy^2)+(1./(ld[2:nx-1,2:ny-1].^2)))
>   ld[221:end,:]=0.00017 #charge
>   ld[1:220,:]=1.0#Debye lenght
>   roc[218:219,57:97]=0.00750
>   roc[218:219,153:193]=0.00750
>   roc[218:219,249:289]=0.00750
>   roc[218:219,345:385]=0.00750
>   roc_diff = roc.-roc_old
>   max_roc_diff=maximum(abs(roc_diff))
> end
>
> fig = plt.figure(figsize = (11,7), dpi=100)
> plt.contourf(x*1000,y*1000,roc,50)
> cbar = plt.colorbar()
> savefig("wflow1368AC29SeptemberCharge.png")
> # BODY FORCE ###
> F1=ones(ny,nx)
> Fx1=ones(ny,nx)
> 

Re: [julia-users] Re: Plasma Actuator Simulation

[Stefan Karpinski]

I don't know anything about plasma physics, but this entire code is in
global scope and uses a bunch of non-const global arrays. This is the very
first thing the performance tips warn against:

http://julia.readthedocs.org/en/latest/manual/performance-tips/

Refactor your code into functions that take arguments and return values
instead of operating on globals.

On Mon, Sep 28, 2015 at 10:54 PM, John Gibson  wrote:

> Marius: I think you'd be better off in learning to write fast Julia code
> if you presented an straightforward implementation of a classic PDE problem
> and asked for help in optimizing that. Maybe 2D heat equation would be a
> good place to start. The code you've presented is not really intelligible
> without a better description of the equations, the boundary conditions, the
> discretization methods, more detailed comments, explanations of magic
> numbers, etc. And requiring plasma physics expertise makes your audience
> here too small,  probably.
>
> best regards,
>
> John
>
>
>
> On Monday, September 28, 2015 at 10:14:32 PM UTC-4, Marius wrote:
>>
>> Hi everybody,
>>
>> I wrote a simulation code for Plasma Actuator. This is based on my
>> previous code written in Python and uses Suzen model combined with
>> Navier-Stokes equations. It's about 5 times faster than Python but still
>> simulation takes days to finish. I am new to Julia and I tried to follow
>> the performance tips but so far this is how much I could do. Any
>> suggestions for improving speed are highly appreciated. This is the code:
>>
>>
>> using PyPlot
>> using PyCall
>>
>> const nx=441
>> const ny=441
>> const nt=100
>> const Length=0.011#11 mm
>> const dx=Length/(nx-1)
>> const dy=Length/(ny-1)
>> x=linspace(-Length/2,Length/2,nx)
>> y=linspace(-Length/2,Length/2,ny)
>> 
>> phi1 = zeros(ny,nx) #potential
>> eps=zeros(ny,nx)#permitivity
>> roc=ones(ny,nx)#charge
>> ld=ones(ny,nx)#Debye length
>> ### All Electrodes 
>> # initial boundary conditions
>> phi1[221:222,49:57]=1400.0
>> phi1[218:219,57:97]=0.0
>> #phi1[221:222,97:105]=0.0
>> phi1[221:222,145:153]=1400.0
>> phi1[218:219,153:193]=0.0
>> #phi1[221:222,193:201]=0.0
>> #phi1[221:222,241:249]=0.0
>> phi1[218:219,249:289]=0.0
>> phi1[221:222,289:297]=1400.0
>> #phi1[221:222,337:345]=0.0
>> phi1[218:219,345:385]=0.0
>> phi1[221:222,385:393]=1400.0
>> eps[1:220,:]=2.7
>> eps[221:end,:]=1.0
>>
>> eps[221:221,:]=(eps[222:222,1:end].*eps[220:220,1:end])./(((dx/(2*dx))*eps[222:222,1:end])+
>> (((dx/(2*dx))*eps[220:220,1:end])))
>> ###
>> #convergence parameters
>> to1=1e-8
>> ###Gauss-Seidel solver
>> max_phi1_diff=1
>> while max_phi1_diff > to1
>>   phi1_old=copy(phi1)
>>   phi1[2:nx-1,2:ny-1]=((eps[2:nx-1,2:ny-1].*((phi1[3:nx,2:ny-1]/(dx^2))+
>>
>> (phi1[2:nx-1,3:ny]/(dy^2)))+((eps[1:nx-2,2:ny-1].*phi1[1:nx-2,2:ny-1])/(dx^2))+
>>
>> ((eps[2:nx-1,1:ny-2].*phi1[2:nx-1,1:ny-2]/(dy^2)./(((eps[2:nx-1,2:ny-1]+
>> eps[1:nx-2,2:ny-1])/(dx^2))+
>> ((eps[2:nx-1,2:ny-1]+eps[2:nx-1,1:ny-2])/(dy^2)))
>>   phi1[end,:]=phi1[end-1,:]
>>   phi1[1,:]=phi1[2,:]
>>   phi1[:,end]=phi1[:,end-1]
>>   phi1[:,1]=phi1[:,2]
>>   phi1[221:222,49:57]=1400.0
>>   phi1[218:219,57:97]=0.0
>>   #phi1[221:222,97:105]=0.0
>>   phi1[221:222,145:153]=1400.0
>>   phi1[218:219,153:193]=0.0
>>   #phi1[221:222,193:201]=0.0
>>   #phi1[221:222,241:249]=0.0
>>   phi1[218:219,249:289]=0.0
>>   phi1[221:222,289:297]=1400.0
>>   #phi1[221:222,337:345]=0.0
>>   phi1[218:219,345:385]=0.0
>>   phi1[221:222,385:393]=1400.0
>>   eps[1:220,:]=2.7
>>   eps[221:end,:]=1.0
>>   phi1_diff = phi1.-phi1_old
>>   max_phi1_diff=maximum(abs(phi1_diff))
>> end
>>
>> fig = plt.figure(figsize = (11,7), dpi=100)
>> plt.contourf(x*1000,y*1000,phi1,50)
>> cbar = plt.colorbar()
>> savefig("wflow1368AC29SeptemberElectricField.png")
>>  CHARGE  
>> ld[221:end,:]=0.00017 #Debye lenght
>> ld[1:220,:]=1.0#Debye lenght
>> roc[218:219,57:97]=0.00750
>> roc[218:219,153:193]=0.00750
>> roc[218:219,249:289]=0.00750
>> roc[218:219,345:385]=0.00750
>> eps[1:220,:]=2.7
>> eps[221:end,:]=1.0
>>
>> eps[221:221,:]=(eps[222:222,1:end].*eps[220:220,1:end])./(((dx/(2*dx))*eps[222:222,1:end])+
>> (((dx/(2*dx))*eps[220:220,1:end])))
>> roc[:,end] =0
>> roc[end,:] = 0
>> roc[:,1] =0
>> roc[1,:] = 0
>> #convergence parameters
>> to1=1e-8
>> ###Gauss-Seidel solver
>> max_roc_diff=1
>> while max_roc_diff > to1
>>   roc_old=copy(roc)
>>
>> roc[2:nx-1,2:ny-1]=((eps[2:nx-1,2:ny-1].*((roc[3:nx,2:ny-1]/(dx^2)).+(roc[2:nx-1,3:ny]/dy^2)))+
>> ((eps[1:nx-2,2:ny-1].*roc[1:nx-2,2:ny-1])/dx^2)+
>>
>> ((eps[2:nx-1,1:ny-2].*roc[2:nx-1,1:ny-2])/dy^2))./(((eps[2:nx-1,2:ny-1].+eps[1:nx-2,2:ny-1])/dx^2)+
>>
>> ((eps[2:nx-1,2:ny-1]+eps[2:nx-1,1:ny-2])/dy^2)+(1./(ld[2:nx-1,2:ny-1].^2)))
>>   

[julia-users] Re: Plasma Actuator Simulation

[Michael Prentiss]

In my experience it is helpful to have a Fortran version to compare speeds 
against when learning Julia.
This would be easy w.r.t. your problem.

It is easy to right functional Julia code that is very slow, but looks 
okay.  The best way for me was to have 
have a basis of comparison.

On Monday, September 28, 2015 at 9:14:32 PM UTC-5, Marius wrote:
>
> Hi everybody,
>
> I wrote a simulation code for Plasma Actuator. This is based on my 
> previous code written in Python and uses Suzen model combined with 
> Navier-Stokes equations. It's about 5 times faster than Python but still 
> simulation takes days to finish. I am new to Julia and I tried to follow 
> the performance tips but so far this is how much I could do. Any 
> suggestions for improving speed are highly appreciated. This is the code:
>
>
> using PyPlot
> using PyCall
>
> const nx=441
> const ny=441
> const nt=100
> const Length=0.011#11 mm
> const dx=Length/(nx-1)
> const dy=Length/(ny-1)
> x=linspace(-Length/2,Length/2,nx)
> y=linspace(-Length/2,Length/2,ny)
> 
> phi1 = zeros(ny,nx) #potential
> eps=zeros(ny,nx)#permitivity
> roc=ones(ny,nx)#charge
> ld=ones(ny,nx)#Debye length
> ### All Electrodes 
> # initial boundary conditions
> phi1[221:222,49:57]=1400.0
> phi1[218:219,57:97]=0.0
> #phi1[221:222,97:105]=0.0
> phi1[221:222,145:153]=1400.0
> phi1[218:219,153:193]=0.0
> #phi1[221:222,193:201]=0.0
> #phi1[221:222,241:249]=0.0
> phi1[218:219,249:289]=0.0
> phi1[221:222,289:297]=1400.0
> #phi1[221:222,337:345]=0.0
> phi1[218:219,345:385]=0.0
> phi1[221:222,385:393]=1400.0
> eps[1:220,:]=2.7
> eps[221:end,:]=1.0
>
> eps[221:221,:]=(eps[222:222,1:end].*eps[220:220,1:end])./(((dx/(2*dx))*eps[222:222,1:end])+
> (((dx/(2*dx))*eps[220:220,1:end])))
> ###
> #convergence parameters
> to1=1e-8
> ###Gauss-Seidel solver
> max_phi1_diff=1
> while max_phi1_diff > to1
>   phi1_old=copy(phi1)
>   phi1[2:nx-1,2:ny-1]=((eps[2:nx-1,2:ny-1].*((phi1[3:nx,2:ny-1]/(dx^2))+
> 
> (phi1[2:nx-1,3:ny]/(dy^2)))+((eps[1:nx-2,2:ny-1].*phi1[1:nx-2,2:ny-1])/(dx^2))+
> 
> ((eps[2:nx-1,1:ny-2].*phi1[2:nx-1,1:ny-2]/(dy^2)./(((eps[2:nx-1,2:ny-1]+
> eps[1:nx-2,2:ny-1])/(dx^2))+
> ((eps[2:nx-1,2:ny-1]+eps[2:nx-1,1:ny-2])/(dy^2)))
>   phi1[end,:]=phi1[end-1,:]
>   phi1[1,:]=phi1[2,:]
>   phi1[:,end]=phi1[:,end-1]
>   phi1[:,1]=phi1[:,2]
>   phi1[221:222,49:57]=1400.0
>   phi1[218:219,57:97]=0.0
>   #phi1[221:222,97:105]=0.0
>   phi1[221:222,145:153]=1400.0
>   phi1[218:219,153:193]=0.0
>   #phi1[221:222,193:201]=0.0
>   #phi1[221:222,241:249]=0.0
>   phi1[218:219,249:289]=0.0
>   phi1[221:222,289:297]=1400.0
>   #phi1[221:222,337:345]=0.0
>   phi1[218:219,345:385]=0.0
>   phi1[221:222,385:393]=1400.0
>   eps[1:220,:]=2.7
>   eps[221:end,:]=1.0
>   phi1_diff = phi1.-phi1_old
>   max_phi1_diff=maximum(abs(phi1_diff))
> end
>
> fig = plt.figure(figsize = (11,7), dpi=100)
> plt.contourf(x*1000,y*1000,phi1,50)
> cbar = plt.colorbar()
> savefig("wflow1368AC29SeptemberElectricField.png")
>  CHARGE  
> ld[221:end,:]=0.00017 #Debye lenght
> ld[1:220,:]=1.0#Debye lenght
> roc[218:219,57:97]=0.00750
> roc[218:219,153:193]=0.00750
> roc[218:219,249:289]=0.00750
> roc[218:219,345:385]=0.00750
> eps[1:220,:]=2.7
> eps[221:end,:]=1.0
>
> eps[221:221,:]=(eps[222:222,1:end].*eps[220:220,1:end])./(((dx/(2*dx))*eps[222:222,1:end])+
> (((dx/(2*dx))*eps[220:220,1:end])))
> roc[:,end] =0
> roc[end,:] = 0
> roc[:,1] =0
> roc[1,:] = 0
> #convergence parameters
> to1=1e-8
> ###Gauss-Seidel solver
> max_roc_diff=1
> while max_roc_diff > to1
>   roc_old=copy(roc)
>   
> roc[2:nx-1,2:ny-1]=((eps[2:nx-1,2:ny-1].*((roc[3:nx,2:ny-1]/(dx^2)).+(roc[2:nx-1,3:ny]/dy^2)))+
> ((eps[1:nx-2,2:ny-1].*roc[1:nx-2,2:ny-1])/dx^2)+
> 
> ((eps[2:nx-1,1:ny-2].*roc[2:nx-1,1:ny-2])/dy^2))./(((eps[2:nx-1,2:ny-1].+eps[1:nx-2,2:ny-1])/dx^2)+
> 
> ((eps[2:nx-1,2:ny-1]+eps[2:nx-1,1:ny-2])/dy^2)+(1./(ld[2:nx-1,2:ny-1].^2)))
>   ld[221:end,:]=0.00017 #charge
>   ld[1:220,:]=1.0#Debye lenght
>   roc[218:219,57:97]=0.00750
>   roc[218:219,153:193]=0.00750
>   roc[218:219,249:289]=0.00750
>   roc[218:219,345:385]=0.00750
>   roc_diff = roc.-roc_old
>   max_roc_diff=maximum(abs(roc_diff))
> end
>
> fig = plt.figure(figsize = (11,7), dpi=100)
> plt.contourf(x*1000,y*1000,roc,50)
> cbar = plt.colorbar()
> savefig("wflow1368AC29SeptemberCharge.png")
> # BODY FORCE ###
> F1=ones(ny,nx)
> Fx1=ones(ny,nx)
> Fy1=ones(ny,nx)
>
> F1[2:nx-1,2:ny-1]=roc[2:nx-1,2:ny-1].*(-(((phi1[2:nx-1,2:ny-1]-phi1[1:nx-2,2:ny-1])/dx)+((phi1[2:nx-1,2:ny-1]-phi1[2:nx-1,1:ny-2])/dy)))
> F1[221:222,49:57]=0.0
> F1[218:219,57:97]=0.0
> F1[221:222,97:105]=0.0
> F1[221:222,145:153]=0.0
> F1[218:219,153:193]=0.0
> 

[julia-users] Re: Plasma Actuator Simulation

[Luke Stagner]

Ok...wow...I am not surprised it is slow. Well here is what you could try. 

1. Wrap everything into a function. Julia has difficulty with globals.
2. You are defining pointless functions in a loop. You can easily change 
the code to exclude them
3. In your loops you are accessing arrays in row major. This will cause 
alot of cache misses in a column major language like Julia
4. I don't think you need to code up your own version of the gauss seidel 
method. There are plenty of built in ways to solve a system of linear 
equations in Julia.

Fix those things and it should run faster

-Luke 
On Monday, September 28, 2015 at 7:14:32 PM UTC-7, Marius wrote:
>
> Hi everybody,
>
> I wrote a simulation code for Plasma Actuator. This is based on my 
> previous code written in Python and uses Suzen model combined with 
> Navier-Stokes equations. It's about 5 times faster than Python but still 
> simulation takes days to finish. I am new to Julia and I tried to follow 
> the performance tips but so far this is how much I could do. Any 
> suggestions for improving speed are highly appreciated. This is the code:
>
>
> using PyPlot
> using PyCall
>
> const nx=441
> const ny=441
> const nt=100
> const Length=0.011#11 mm
> const dx=Length/(nx-1)
> const dy=Length/(ny-1)
> x=linspace(-Length/2,Length/2,nx)
> y=linspace(-Length/2,Length/2,ny)
> 
> phi1 = zeros(ny,nx) #potential
> eps=zeros(ny,nx)#permitivity
> roc=ones(ny,nx)#charge
> ld=ones(ny,nx)#Debye length
> ### All Electrodes 
> # initial boundary conditions
> phi1[221:222,49:57]=1400.0
> phi1[218:219,57:97]=0.0
> #phi1[221:222,97:105]=0.0
> phi1[221:222,145:153]=1400.0
> phi1[218:219,153:193]=0.0
> #phi1[221:222,193:201]=0.0
> #phi1[221:222,241:249]=0.0
> phi1[218:219,249:289]=0.0
> phi1[221:222,289:297]=1400.0
> #phi1[221:222,337:345]=0.0
> phi1[218:219,345:385]=0.0
> phi1[221:222,385:393]=1400.0
> eps[1:220,:]=2.7
> eps[221:end,:]=1.0
>
> eps[221:221,:]=(eps[222:222,1:end].*eps[220:220,1:end])./(((dx/(2*dx))*eps[222:222,1:end])+
> (((dx/(2*dx))*eps[220:220,1:end])))
> ###
> #convergence parameters
> to1=1e-8
> ###Gauss-Seidel solver
> max_phi1_diff=1
> while max_phi1_diff > to1
>   phi1_old=copy(phi1)
>   phi1[2:nx-1,2:ny-1]=((eps[2:nx-1,2:ny-1].*((phi1[3:nx,2:ny-1]/(dx^2))+
> 
> (phi1[2:nx-1,3:ny]/(dy^2)))+((eps[1:nx-2,2:ny-1].*phi1[1:nx-2,2:ny-1])/(dx^2))+
> 
> ((eps[2:nx-1,1:ny-2].*phi1[2:nx-1,1:ny-2]/(dy^2)./(((eps[2:nx-1,2:ny-1]+
> eps[1:nx-2,2:ny-1])/(dx^2))+
> ((eps[2:nx-1,2:ny-1]+eps[2:nx-1,1:ny-2])/(dy^2)))
>   phi1[end,:]=phi1[end-1,:]
>   phi1[1,:]=phi1[2,:]
>   phi1[:,end]=phi1[:,end-1]
>   phi1[:,1]=phi1[:,2]
>   phi1[221:222,49:57]=1400.0
>   phi1[218:219,57:97]=0.0
>   #phi1[221:222,97:105]=0.0
>   phi1[221:222,145:153]=1400.0
>   phi1[218:219,153:193]=0.0
>   #phi1[221:222,193:201]=0.0
>   #phi1[221:222,241:249]=0.0
>   phi1[218:219,249:289]=0.0
>   phi1[221:222,289:297]=1400.0
>   #phi1[221:222,337:345]=0.0
>   phi1[218:219,345:385]=0.0
>   phi1[221:222,385:393]=1400.0
>   eps[1:220,:]=2.7
>   eps[221:end,:]=1.0
>   phi1_diff = phi1.-phi1_old
>   max_phi1_diff=maximum(abs(phi1_diff))
> end
>
> fig = plt.figure(figsize = (11,7), dpi=100)
> plt.contourf(x*1000,y*1000,phi1,50)
> cbar = plt.colorbar()
> savefig("wflow1368AC29SeptemberElectricField.png")
>  CHARGE  
> ld[221:end,:]=0.00017 #Debye lenght
> ld[1:220,:]=1.0#Debye lenght
> roc[218:219,57:97]=0.00750
> roc[218:219,153:193]=0.00750
> roc[218:219,249:289]=0.00750
> roc[218:219,345:385]=0.00750
> eps[1:220,:]=2.7
> eps[221:end,:]=1.0
>
> eps[221:221,:]=(eps[222:222,1:end].*eps[220:220,1:end])./(((dx/(2*dx))*eps[222:222,1:end])+
> (((dx/(2*dx))*eps[220:220,1:end])))
> roc[:,end] =0
> roc[end,:] = 0
> roc[:,1] =0
> roc[1,:] = 0
> #convergence parameters
> to1=1e-8
> ###Gauss-Seidel solver
> max_roc_diff=1
> while max_roc_diff > to1
>   roc_old=copy(roc)
>   
> roc[2:nx-1,2:ny-1]=((eps[2:nx-1,2:ny-1].*((roc[3:nx,2:ny-1]/(dx^2)).+(roc[2:nx-1,3:ny]/dy^2)))+
> ((eps[1:nx-2,2:ny-1].*roc[1:nx-2,2:ny-1])/dx^2)+
> 
> ((eps[2:nx-1,1:ny-2].*roc[2:nx-1,1:ny-2])/dy^2))./(((eps[2:nx-1,2:ny-1].+eps[1:nx-2,2:ny-1])/dx^2)+
> 
> ((eps[2:nx-1,2:ny-1]+eps[2:nx-1,1:ny-2])/dy^2)+(1./(ld[2:nx-1,2:ny-1].^2)))
>   ld[221:end,:]=0.00017 #charge
>   ld[1:220,:]=1.0#Debye lenght
>   roc[218:219,57:97]=0.00750
>   roc[218:219,153:193]=0.00750
>   roc[218:219,249:289]=0.00750
>   roc[218:219,345:385]=0.00750
>   roc_diff = roc.-roc_old
>   max_roc_diff=maximum(abs(roc_diff))
> end
>
> fig = plt.figure(figsize = (11,7), dpi=100)
> plt.contourf(x*1000,y*1000,roc,50)
> cbar = plt.colorbar()
> savefig("wflow1368AC29SeptemberCharge.png")
> # BODY FORCE ###
> 

Re: [julia-users] Q-less QR?

[Jiahao Chen]

Unfortunately Q-less QR on sparse matrices is not possible at this moment
because the C API to SPQR does not provide this functionality. You'd need
to access the C++ API of SPQR to do this calculation.

On Mon, Sep 21, 2015, 15:57 Dominique Orban 
wrote:

> Is it possible to compute the Q-less QR factorization of a sparse matrix
> in Julia? In Matlab, you can write R = qr(A), but I don't see it in the
> Julia documentation. Sorry if I missed it.
>
> Thanks.
>

Re: [julia-users] Why is String deprecated in favour of AbstractString?

[Steven G. Johnson]

On Sunday, September 27, 2015 at 6:31:33 AM UTC-4, Tim Holy wrote:
>
> I think the only advantage of ASCIIString is that str[8:12] is performant, 
> because you know the byte offset directly from the index. That's not true 
> for 
> UTF8String. 


The indices passed to strings in Julia are byte offsets, not character 
offsets.  So str[8:12] has the same complexity for UTF8String as for 
ASCIIString.  (The downside of this is that it is possible to pass invalid 
byte indices to a UTF8String, which throws an exception. 
 See https://github.com/JuliaLang/julia/issues/9297 for a proposal to avoid 
this.)