date:20160823

[julia-users] Re: applying non zero boundary conditions in FEM

2016-08-23 Thread Chris Rackauckas

In Julia you use [] for dereference. So changes things to K[udofs,:]=0 . 
Comments are #. Semicolins aren't necessary in scripts.

You might want to check out this page of the 
manual: http://docs.julialang.org/en/release-0.4/manual/noteworthy-differences/

On Tuesday, August 23, 2016 at 9:29:52 PM UTC-7, Nguyen Vinh Phu wrote:
>
> Hello all,
>
> I am implementing a finite element solver in Julia. I have computed the 
> stiffness matrix (as a sparse matrix K) and the force vector (F). I have 
> some non zero boundary conditions on 
> the unknown. In Matlab, here is what I do:
>
> bcwt=mean(diag(K)); % a measure of the average size of an element in K
> % used to keep the conditioning of the K matrix
> udofs=fixedNode;   % global indecies of the fixed  displacements
> f=f-K(:,udofs)*uFixed;  % modify the force vector
> K(udofs,:)=0;
> K(:,udofs)=0;
> K(udofs,udofs)=bcwt*speye(length(udofs)); % put ones*bcwt on the diagonal
> f(udofs)=bcwt*speye(length(udofs))*uFixed;
>  U=K\f;
>
> I implemented the above in Julia and I got several errors associated with 
> the following
>
> f=f-K(:,udofs)*uFixed;  % modify the force vector
> K(udofs,:)=0;
> K(:,udofs)=0;
> K(udofs,udofs)=bcwt*speye(length(udofs)); % put ones*bcwt on the diagonal
> f(udofs)=bcwt*speye(length(udofs))*uFixed;
>
> I would appreciate very much if someone can help. Thanks.
>
> Best regards,
> Phu
>
>

[julia-users] applying non zero boundary conditions in FEM

2016-08-23 Thread Nguyen Vinh Phu

Hello all,

I am implementing a finite element solver in Julia. I have computed the 
stiffness matrix (as a sparse matrix K) and the force vector (F). I have 
some non zero boundary conditions on 
the unknown. In Matlab, here is what I do:

bcwt=mean(diag(K)); % a measure of the average size of an element in K
% used to keep the conditioning of the K matrix
udofs=fixedNode;   % global indecies of the fixed  displacements
f=f-K(:,udofs)*uFixed;  % modify the force vector
K(udofs,:)=0;
K(:,udofs)=0;
K(udofs,udofs)=bcwt*speye(length(udofs)); % put ones*bcwt on the diagonal
f(udofs)=bcwt*speye(length(udofs))*uFixed;
 U=K\f;

I implemented the above in Julia and I got several errors associated with 
the following

f=f-K(:,udofs)*uFixed;  % modify the force vector
K(udofs,:)=0;
K(:,udofs)=0;
K(udofs,udofs)=bcwt*speye(length(udofs)); % put ones*bcwt on the diagonal
f(udofs)=bcwt*speye(length(udofs))*uFixed;

I would appreciate very much if someone can help. Thanks.

Best regards,
Phu

Re: [julia-users] New to Julia - Need some basic help

2016-08-23 Thread Jeffrey Sarnoff

As Steven mentioned, starting the program from the directory where the 
files reside allows you to include the file using its filename without the 
full path.  If that is easy for you, it is probably best.  An alternative 
is to do it with code.  Let me know if you need that.

On Monday, August 22, 2016 at 5:06:33 PM UTC-4, Pigskin Ablanket wrote:
>
> No problem.  If you get a chance - great
>
> On Saturday, August 20, 2016 at 12:13:40 PM UTC-4, Jeffrey Sarnoff wrote:
>>
>> There is a way -- after the weekend.
>>
>> On Friday, August 19, 2016 at 8:04:58 PM UTC-4, Pigskin Ablanket wrote:
>>>
>>> I probably dont want to change the input file names more than once 
>>> although I would be updating its data daily - and I think I know how to do 
>>> that (change the name of the file itself as well as in the code).  The 
>>> output file though - I might want to change more regularly,
>>>
>>> Also - when I ran it - a few things were deprecated - does that just 
>>> mean outdated?  Does updating with the new term change the file - or just 
>>> the underlying solving?  Not sure if you can know that or not.
>>>
>>> I was just looking for a way yo shortcut that long as heck include 
>>> string I have now.  Cause I will run that daily and lord knows I mistyped 
>>> it like 10 times.
>>>
>>> On Friday, August 19, 2016 at 7:28:40 PM UTC-4, Jeffrey Sarnoff wrote:

 You are most welcome.

 What do you want to change, if anything, from day to day, for example: 
  one or both input file names, the output file name, reuse some/all file 
 names while changing the data inside?


 On Friday, August 19, 2016 at 7:01:54 PM UTC-4, Pigskin Ablanket wrote:
>
> IT Works   Thank you so much.  Found my error in the code.
>
> I am curious if there is a way to shortcut the command as I would want 
> to run this daily to test and it seems like a lot to type correctly.
>
> Thanks for the time today
>
> On Friday, August 19, 2016 at 6:26:34 PM UTC-4, Jeffrey Sarnoff wrote:
>>
>> Look correct?
>>
>> I will answer that after you try running it.
>>
>>
>> On Friday, August 19, 2016 at 6:19:33 PM UTC-4, Pigskin Ablanket 
>> wrote:
>>>
>>> Thanks for providing me so much help today - much appreciated.
>>>
>>> I copied the properties right here for folder Julia  which is where 
>>> the code file is located:
>>> C:\Users\JHerron\Documents\Documents\Personal\DFS\NHL
>>>
>>> Interesting that it didnt bring it over as My_Documents.
>>>
>>> Based on this, I would believe the command needs to be:
>>> include("C:\\Users\\JHerron\\Documents\\Documents\\
>>> Personal\\DFS\\NHL\\Julia\\code_for_Github.jl")
>>>
>>> Look correct?
>>>
>>> I made the changes to the paths in the file as well
>>>
>>> "C:\\Users\\JHerron\\Documents\\Documents\\Personal\\DFS\\NHL\\Julia\\example_skaters.csv"
>>>
>>> On Friday, August 19, 2016 at 6:01:50 PM UTC-4, Jeffrey Sarnoff 
>>> wrote:

 two things,
 you wrote:

  
 include("C:\\Users\\JHerron\\My_Documents\\My_Documents/Personal\\DFS/NHL\\Julia/code_for_Github.jl")
 and I wonder, do you mean   !   
  !

  
 include("C:\\Users\\JHerron\\My_Documents\\My_Documents_Personal\\DFS\\NHL\\Julia\\code_for_Github.jl")
 or

  
 include("C:\\Users\\JHerron\\My_Documents\\My_Documents_Personal\\DFS_NHL\\Julia\\code_for_Github.jl")

 when you go to the directory where you see the file: 
 code_for_Github.jl and you put the mouse on that file and right-click 
 to 
 see the popup menu and select the last thing "properties" there is 
 something that says Location,if does it not exactly match:
 C:/Users/JHerron/My_Documents/My_Documents/Personal/DFS/NHL/Julia
 then you have miscopied it, if it looks like this 
 C:/Users/JHerron/My_Documents/My_Documents_Personal/DFS_NHL/Julia
 then you should be using (and fix the paths in the 
 code_for_Github.jl file, too)

  
 include("C:\\Users\\JHerron\\My_Documents\\My_Documents_Personal\\DFS_NHL\\Julia\\code_for_Github.jl")

 ---


 On Friday, August 19, 2016 at 5:12:41 PM UTC-4, Pigskin Ablanket 
 wrote:
>
> Sadly, I get the following response from 
> include("C:\\Users\\JHerron\\My_Documents\\My_Documents/Personal\\DFS/NHL\\Julia/code_for_Github.jl")
>
> *ERROR: could not copen file 
> C:\Users\JHerron\My_Documents\My_Documents\Personal\DFS\NHL\Julia\code_for_github.jl*
> *in include at boot.jl:261*
> *in include_from_node1 at loading.jl:320*
>
> On Friday, August 19, 2016 at 4:49:16 PM UTC-4, Jeffrey

[julia-users] Re: Julia Plugin System

2016-08-23 Thread Cedric St-Jean

I think we need a more complete description of your problem, because a 
plugin can be a lot of things, and I don't know about Salt. In any case, re.

plugin(hub, "subsystem.module.function")(args/kwargs)

You're right, that doesn't look very Julian. Would something like this work?

module Subsystems
type ModuleFunction
...
end
end

function plugin(hub::Hub, mf::Subsystems.ModuleFunction, args..., kwargs...)
...
end

That way you can define one plugin function per type, and let multiple 
dispatch do the job. 

On Tuesday, August 23, 2016 at 7:21:54 PM UTC-4, Thomas Hatch wrote:
>
> I am asking this just to look for some opinions or ideas on the most 
> Julia-like way to do something, as usual, I have no complaints with Julia :)
>
> I am working on writing a plugin system in Julia and had a syntax 
> question. The plugin system was originally written in python and was based 
> loosely on the Salt plugin system. The plugin system allows for plugin 
> subsystems to be defined and then they all share a data "hub" so the plugin 
> systems can easily cross communicate.
>
> In python the plugin system uses nested python objects to directly 
> reference the plugin function:
> hub.subsystem.module.function(args/kwargs)
>
> In Julia I have implemented it like this:
> plugin(hub, "subsystem.module.function")(args/kwargs)
>
> Would there be a better, more Julia-like way to represent this concept?
>
>
> Thomas S. Hatch  |  Founder, CTO
>
> 3400 N. Ashton Blvd, Suite 110 | Lehi, UT 84043
> tha...@saltstack.com  | www.saltstack.com 
> 
>

Re: [julia-users] New to Julia - Need some basic help

2016-08-23 Thread Jeffrey Sarnoff

As Steven mentioned, starting the program from the directory where the
files reside allows you to include the file using its filename without the
full path.  If that is easy for you, it is probably best.  An alternative
is to do it with code.  Let me know if you need that.

On Mon, Aug 22, 2016 at 5:06 PM, Pigskin Ablanket  wrote:

> No problem.  If you get a chance - great
>
>
> On Saturday, August 20, 2016 at 12:13:40 PM UTC-4, Jeffrey Sarnoff wrote:
>>
>> There is a way -- after the weekend.
>>
>> On Friday, August 19, 2016 at 8:04:58 PM UTC-4, Pigskin Ablanket wrote:
>>>
>>> I probably dont want to change the input file names more than once
>>> although I would be updating its data daily - and I think I know how to do
>>> that (change the name of the file itself as well as in the code).  The
>>> output file though - I might want to change more regularly,
>>>
>>> Also - when I ran it - a few things were deprecated - does that just
>>> mean outdated?  Does updating with the new term change the file - or just
>>> the underlying solving?  Not sure if you can know that or not.
>>>
>>> I was just looking for a way yo shortcut that long as heck include
>>> string I have now.  Cause I will run that daily and lord knows I mistyped
>>> it like 10 times.
>>>
>>> On Friday, August 19, 2016 at 7:28:40 PM UTC-4, Jeffrey Sarnoff wrote:

 You are most welcome.

 What do you want to change, if anything, from day to day, for example:
  one or both input file names, the output file name, reuse some/all file
 names while changing the data inside?


 On Friday, August 19, 2016 at 7:01:54 PM UTC-4, Pigskin Ablanket wrote:
>
> IT Works   Thank you so much.  Found my error in the code.
>
> I am curious if there is a way to shortcut the command as I would want
> to run this daily to test and it seems like a lot to type correctly.
>
> Thanks for the time today
>
> On Friday, August 19, 2016 at 6:26:34 PM UTC-4, Jeffrey Sarnoff wrote:
>>
>> Look correct?
>>
>> I will answer that after you try running it.
>>
>>
>> On Friday, August 19, 2016 at 6:19:33 PM UTC-4, Pigskin Ablanket
>> wrote:
>>>
>>> Thanks for providing me so much help today - much appreciated.
>>>
>>> I copied the properties right here for folder Julia  which is where
>>> the code file is located:
>>> C:\Users\JHerron\Documents\Documents\Personal\DFS\NHL
>>>
>>> Interesting that it didnt bring it over as My_Documents.
>>>
>>> Based on this, I would believe the command needs to be:
>>> include("C:\\Users\\JHerron\\Documents\\Documents\\Personal\
>>> \DFS\\NHL\\Julia\\code_for_Github.jl")
>>>
>>> Look correct?
>>>
>>> I made the changes to the paths in the file as well
>>> "C:\\Users\\JHerron\\Documents\\Documents\\Personal\\DFS\\
>>> NHL\\Julia\\example_skaters.csv"
>>>
>>> On Friday, August 19, 2016 at 6:01:50 PM UTC-4, Jeffrey Sarnoff
>>> wrote:

 two things,
 you wrote:
  include("C:\\Users\\JHerron\\My_Documents\\My_Documents/Per
 sonal\\DFS/NHL\\Julia/code_for_Github.jl")
 and I wonder, do you mean   !
  !
  include("C:\\Users\\JHerron\\My_Documents\\My_Documents_Per
 sonal\\DFS\\NHL\\Julia\\code_for_Github.jl")
 or
  include("C:\\Users\\JHerron\\My_Documents\\My_Documents_Per
 sonal\\DFS_NHL\\Julia\\code_for_Github.jl")

 when you go to the directory where you see the file:
 code_for_Github.jl and you put the mouse on that file and right-click 
 to
 see the popup menu and select the last thing "properties" there is
 something that says Location,if does it not exactly match:
 C:/Users/JHerron/My_Documents/My_Documents/Personal/DFS/NHL/Julia
 then you have miscopied it, if it looks like this
 C:/Users/JHerron/My_Documents/My_Documents_Personal/DFS_NHL/Julia
 then you should be using (and fix the paths in the
 code_for_Github.jl file, too)
  include("C:\\Users\\JHerron\\My_Documents\\My_Documents_Per
 sonal\\DFS_NHL\\Julia\\code_for_Github.jl")

 ---


 On Friday, August 19, 2016 at 5:12:41 PM UTC-4, Pigskin Ablanket
 wrote:
>
> Sadly, I get the following response from
> include("C:\\Users\\JHerron\\My_Documents\\My_Documents/Pers
> onal\\DFS/NHL\\Julia/code_for_Github.jl")
>
> *ERROR: could not copen file
> C:\Users\JHerron\My_Documents\My_Documents\Personal\DFS\NHL\Julia\code_for_github.jl*
> *in include at boot.jl:261*
> *in include_from_node1 at loading.jl:320*
>
> On Friday, August 19, 2016 at 4:49:16 PM UTC-4, Jeffrey Sarnoff
> wrote:
>>
>>

[julia-users] Pkg.update() error, 0.4.6

2016-08-23 Thread Liye zhang

When I run Pkg.update(), I got the following error:

fata;: read error: Invalid argument
 ERROR: failed process: Process('git pull --rebase -q', ProcessExited(1)) 
[1] in pipeline_error at process.jl:555

windows 7, Julia0.4.6

Re: [julia-users] Performant methods for enclosing parameters?

2016-08-23 Thread Erik Schnetter

`gelelementptr inbounds` takes as input a pointer to a C struct (or
equivalent) as well as the offset to a field in that struct, and returns
the pointer to that field. It's how LLVM accesses fields in a struct. This
usually becomes a single add instruction, and can often be folded into
other instructions. In other words, it is in this case a very cheap
instruction.

I prefer to look at the generated native code (`@code_native`) because this
tells me what is actually going on. LLVM is quite high level, and it can be
difficult make performance predictions from it.

-erik


On Tue, Aug 23, 2016 at 8:14 PM, Chris Rackauckas 
wrote:

> In my scenarios, the function k is given by the user. So this method won't
> work. If you move that definition of k outside of test() and pass it into
> your test, you'll see that the LLVM code explodes (at least it does for
> me). The issue is defining a closure on a function which was defined
> outside of the current scope.
>
>
> BTW, what exactly is "%3 = getelementptr inbounds %"##30#34", %"##30#34"*
> %0, i64 0, i32 1". How harmful is it to performance (I just see inbounds
> and an extra line and want to get rid of it, but if it's harmless then
> there are two solutions in here).
>
>
> On Tuesday, August 23, 2016 at 5:04:21 PM UTC-7, Andrew wrote:
>>
>> I'm pretty confused about what you're trying to accomplish beyond
>> standard closures. What is your ParameterHolder type for?
>>
>> I rewrote your first example wrapping everything in a function. Is this
>> doing what you want it to? The LLVM looks fine.
>> function test(α)
>> k(u::Float64,t::Float64,α) = α*u
>> G = (u,t) -> k(u,t,1.01)
>> G2 = (u,t)->k(u,t,α)
>> const β = 1.01
>> G3 = (u,t)->k(u,t,β)
>>
>> @code_llvm G(1., 2.)
>> @code_llvm G2(1., 2.)
>> @code_llvm G3(1., 2.)
>> end
>>
>> julia> test(2.)
>>
>> define double @"julia_#28_70100"(double, double) #0 {
>> top:
>>   %2 = fmul double %0, 1.01e+00
>>   ret double %2
>> }
>>
>> define double @"julia_#29_70102"(%"##29#33"*, double, double) #0 {
>> top:
>>   %3 = getelementptr inbounds %"##29#33", %"##29#33"* %0, i64 0, i32 0
>>   %4 = load double, double* %3, align 8
>>   %5 = fmul double %4, %1
>>   ret double %5
>> }
>>
>> define double @"julia_#30_70104"(%"##30#34"*, double, double) #0 {
>> top:
>>   %3 = getelementptr inbounds %"##30#34", %"##30#34"* %0, i64 0, i32 1
>>   %4 = load double, double* %3, align 8
>>   %5 = fmul double %4, %1
>>   ret double %5
>> }
>>
>>
>>
>>
>> On Tuesday, August 23, 2016 at 6:00:37 PM UTC-4, Chris Rackauckas wrote:
>>>
>>> Yes, I am looking for a closure which has the least overhead possible
>>> (this was all in v0.5). For example, for re-ordering parameters: g =
>>> (du,u,t) -> f(t,u,du), or for enclosing parameter values as above.
>>>
>>> I'll give the Val method a try and see whether the compile time is
>>> significant (it will probably be an option).
>>>
>>> Even a solution which is like translator1/2 where the inbounds check is
>>> able to be turned off would likely be performant enough to not be
>>> noticeably different.
>>>
>>> On Tuesday, August 23, 2016 at 1:27:25 PM UTC-7, Erik Schnetter wrote:

 Chris

 I don't quite understand what you mean. Are you looking for a closure /
 lambda expression?

 ```Julia
 function myfunc(x0, x1, alpha)
 f(x) = alpha * x
 ODE.solve(f, x0, x1)
 end
 ```

 Or is it important for your that your function `f` is optimized, i.e.
 you want to re-run the code generator (expensive!) every time there's a new
 value for `alpha`? For this, you can use `Val` (but please benchmark 
 first):

 ```Julia
 function f{alpha}(x, ::Type{Val{alpha}})
 alpha * x
 end

 function myfunc(x0, x1, alpha)
 f1(x) = f(x, Val{alpha})
 ODE.solve(f, x0, x1)
 end
 ```

 This will have a marginally faster evaluation of `f`, at the cost of
 compiling a separate function for each value of `alpha`.

 Since these examples use closures, they will be much more efficient in
 Julia 0.5 than in 0.4.

 -erik




 On Tue, Aug 23, 2016 at 2:23 PM, Chris Rackauckas 
 wrote:

> Note: This looks long, but really just has a lot of LLVM IR!
>
> I have been digging into the issue recently of the best way to
> enclose parameters with a function
> .
> This is an issue that comes up a lot with scientific codes, and so I was
> hoping to try and get it right. However, the results of my experiments
> aren't looking too good, and so I was hoping to find out whether I am
> running into some bug or simply just not finding the optimal solution.
>
> The example is as follows (with LLVM IR included to show how exactly
> everything is compiling). Say the user wants we to do a bunch of things
> with the

Re: [julia-users] Performant methods for enclosing parameters?

2016-08-23 Thread Chris Rackauckas

Oh, I see what happened... in my example I did

 h(u,t,α) = α*u
 α = 1.01
 g = (u,t) -> h(u,t,α)

but since α was also defined in the global scope, this picked up that 
global α and resulted in the horrible output.

Sorry for making such a fuss! Makes me feel better to know that closures 
actually do work well (like I thought they should).

The only question left just what are the two extra lines that come from 
making the closure, and are they significant at all?

On Tuesday, August 23, 2016 at 5:21:51 PM UTC-7, Andrew wrote:
>
> I tried moving k outside.
> julia> outside_k(u::Float64,t::Float64,α) = α*u
> outside_k (generic function with 1 method)
>
> julia> function test(α, k)
>G = (u,t) -> k(u,t,1.01)
>G2 = (u,t)->k(u,t,α)
>const β = 1.01
>G3 = (u,t)->k(u,t,β)
>
>@code_llvm G(1., 2.)
>@code_llvm G2(1., 2.)
>@code_llvm G3(1., 2.)
>end
> test (generic function with 1 method)
>
> julia> test(2., outside_k)
>
> define double @"julia_#1_69882"(double, double) #0 {
> top:
>   %2 = fmul double %0, 1.01e+00
>   ret double %2
> }
>
> define double @"julia_#2_69884"(%"##2#5"*, double, double) #0 {
> top:
>   %3 = getelementptr inbounds %"##2#5", %"##2#5"* %0, i64 0, i32 0
>   %4 = load double, double* %3, align 8
>   %5 = fmul double %4, %1
>   ret double %5
> }
>
> define double @"julia_#3_69886"(%"##3#6"*, double, double) #0 {
> top:
>   %3 = getelementptr inbounds %"##3#6", %"##3#6"* %0, i64 0, i32 1
>   %4 = load double, double* %3, align 8
>   %5 = fmul double %4, %1
>   ret double %5
> }
>
>
>
> I think the problem with your original code is that you haven't defined α, 
> so it looks like a global variable. 
>
> On Tuesday, August 23, 2016 at 8:14:00 PM UTC-4, Chris Rackauckas wrote:
>>
>> In my scenarios, the function k is given by the user. So this method 
>> won't work. If you move that definition of k outside of test() and pass it 
>> into your test, you'll see that the LLVM code explodes (at least it does 
>> for me). The issue is defining a closure on a function which was defined 
>> outside of the current scope.
>>
>>
>> BTW, what exactly is "%3 = getelementptr inbounds %"##30#34", 
>> %"##30#34"* %0, i64 0, i32 1". How harmful is it to performance (I just 
>> see inbounds and an extra line and want to get rid of it, but if it's 
>> harmless then there are two solutions in here).
>>
>>  
>> On Tuesday, August 23, 2016 at 5:04:21 PM UTC-7, Andrew wrote:
>>>
>>> I'm pretty confused about what you're trying to accomplish beyond 
>>> standard closures. What is your ParameterHolder type for?
>>>
>>> I rewrote your first example wrapping everything in a function. Is this 
>>> doing what you want it to? The LLVM looks fine.
>>> function test(α)
>>> k(u::Float64,t::Float64,α) = α*u
>>> G = (u,t) -> k(u,t,1.01)
>>> G2 = (u,t)->k(u,t,α)
>>> const β = 1.01
>>> G3 = (u,t)->k(u,t,β)
>>>
>>> @code_llvm G(1., 2.)
>>> @code_llvm G2(1., 2.)
>>> @code_llvm G3(1., 2.)
>>> end
>>>
>>> julia> test(2.)
>>>
>>> define double @"julia_#28_70100"(double, double) #0 {
>>> top:
>>>   %2 = fmul double %0, 1.01e+00
>>>   ret double %2
>>> }
>>>
>>> define double @"julia_#29_70102"(%"##29#33"*, double, double) #0 {
>>> top:
>>>   %3 = getelementptr inbounds %"##29#33", %"##29#33"* %0, i64 0, i32 0
>>>   %4 = load double, double* %3, align 8
>>>   %5 = fmul double %4, %1
>>>   ret double %5
>>> }
>>>
>>> define double @"julia_#30_70104"(%"##30#34"*, double, double) #0 {
>>> top:
>>>   %3 = getelementptr inbounds %"##30#34", %"##30#34"* %0, i64 0, i32 1
>>>   %4 = load double, double* %3, align 8
>>>   %5 = fmul double %4, %1
>>>   ret double %5
>>> }
>>>
>>>
>>>
>>>
>>> On Tuesday, August 23, 2016 at 6:00:37 PM UTC-4, Chris Rackauckas wrote:

 Yes, I am looking for a closure which has the least overhead possible 
 (this was all in v0.5). For example, for re-ordering parameters: g = 
 (du,u,t) -> f(t,u,du), or for enclosing parameter values as above.

 I'll give the Val method a try and see whether the compile time is 
 significant (it will probably be an option). 

 Even a solution which is like translator1/2 where the inbounds check is 
 able to be turned off would likely be performant enough to not be 
 noticeably different.

 On Tuesday, August 23, 2016 at 1:27:25 PM UTC-7, Erik Schnetter wrote:
>
> Chris
>
> I don't quite understand what you mean. Are you looking for a closure 
> / lambda expression?
>
> ```Julia
> function myfunc(x0, x1, alpha)
> f(x) = alpha * x
> ODE.solve(f, x0, x1)
> end
> ```
>
> Or is it important for your that your function `f` is optimized, i.e. 
> you want to re-run the code generator (expensive!) every time there's a 
> new 
> value for `alpha`? For this, you can use `Val` (but please benchmark 
> first):
>
> ```Julia
> function f{alpha}(x, ::Type{Val{alpha}})
> alpha * x
>

[julia-users] Re: Julia Plugin System

2016-08-23 Thread JColn

Why not use nested modules?

Also- will there be a salt.jl :p?

On Tuesday, August 23, 2016 at 7:21:54 PM UTC-4, Thomas Hatch wrote:
>
> I am asking this just to look for some opinions or ideas on the most 
> Julia-like way to do something, as usual, I have no complaints with Julia :)
>
> I am working on writing a plugin system in Julia and had a syntax 
> question. The plugin system was originally written in python and was based 
> loosely on the Salt plugin system. The plugin system allows for plugin 
> subsystems to be defined and then they all share a data "hub" so the plugin 
> systems can easily cross communicate.
>
> In python the plugin system uses nested python objects to directly 
> reference the plugin function:
> hub.subsystem.module.function(args/kwargs)
>
> In Julia I have implemented it like this:
> plugin(hub, "subsystem.module.function")(args/kwargs)
>
> Would there be a better, more Julia-like way to represent this concept?
>
>
> Thomas S. Hatch  |  Founder, CTO
>
> 3400 N. Ashton Blvd, Suite 110 | Lehi, UT 84043
> tha...@saltstack.com  | www.saltstack.com 
> 
>

Re: [julia-users] Performant methods for enclosing parameters?

2016-08-23 Thread Andrew

I tried moving k outside.
julia> outside_k(u::Float64,t::Float64,α) = α*u
outside_k (generic function with 1 method)

julia> function test(α, k)
   G = (u,t) -> k(u,t,1.01)
   G2 = (u,t)->k(u,t,α)
   const β = 1.01
   G3 = (u,t)->k(u,t,β)

   @code_llvm G(1., 2.)
   @code_llvm G2(1., 2.)
   @code_llvm G3(1., 2.)
   end
test (generic function with 1 method)

julia> test(2., outside_k)

define double @"julia_#1_69882"(double, double) #0 {
top:
  %2 = fmul double %0, 1.01e+00
  ret double %2
}

define double @"julia_#2_69884"(%"##2#5"*, double, double) #0 {
top:
  %3 = getelementptr inbounds %"##2#5", %"##2#5"* %0, i64 0, i32 0
  %4 = load double, double* %3, align 8
  %5 = fmul double %4, %1
  ret double %5
}

define double @"julia_#3_69886"(%"##3#6"*, double, double) #0 {
top:
  %3 = getelementptr inbounds %"##3#6", %"##3#6"* %0, i64 0, i32 1
  %4 = load double, double* %3, align 8
  %5 = fmul double %4, %1
  ret double %5
}



I think the problem with your original code is that you haven't defined α, 
so it looks like a global variable. 

On Tuesday, August 23, 2016 at 8:14:00 PM UTC-4, Chris Rackauckas wrote:
>
> In my scenarios, the function k is given by the user. So this method won't 
> work. If you move that definition of k outside of test() and pass it into 
> your test, you'll see that the LLVM code explodes (at least it does for 
> me). The issue is defining a closure on a function which was defined 
> outside of the current scope.
>
>
> BTW, what exactly is "%3 = getelementptr inbounds %"##30#34", %"##30#34"* 
> %0, i64 0, i32 1". How harmful is it to performance (I just see inbounds 
> and an extra line and want to get rid of it, but if it's harmless then 
> there are two solutions in here).
>
>  
> On Tuesday, August 23, 2016 at 5:04:21 PM UTC-7, Andrew wrote:
>>
>> I'm pretty confused about what you're trying to accomplish beyond 
>> standard closures. What is your ParameterHolder type for?
>>
>> I rewrote your first example wrapping everything in a function. Is this 
>> doing what you want it to? The LLVM looks fine.
>> function test(α)
>> k(u::Float64,t::Float64,α) = α*u
>> G = (u,t) -> k(u,t,1.01)
>> G2 = (u,t)->k(u,t,α)
>> const β = 1.01
>> G3 = (u,t)->k(u,t,β)
>>
>> @code_llvm G(1., 2.)
>> @code_llvm G2(1., 2.)
>> @code_llvm G3(1., 2.)
>> end
>>
>> julia> test(2.)
>>
>> define double @"julia_#28_70100"(double, double) #0 {
>> top:
>>   %2 = fmul double %0, 1.01e+00
>>   ret double %2
>> }
>>
>> define double @"julia_#29_70102"(%"##29#33"*, double, double) #0 {
>> top:
>>   %3 = getelementptr inbounds %"##29#33", %"##29#33"* %0, i64 0, i32 0
>>   %4 = load double, double* %3, align 8
>>   %5 = fmul double %4, %1
>>   ret double %5
>> }
>>
>> define double @"julia_#30_70104"(%"##30#34"*, double, double) #0 {
>> top:
>>   %3 = getelementptr inbounds %"##30#34", %"##30#34"* %0, i64 0, i32 1
>>   %4 = load double, double* %3, align 8
>>   %5 = fmul double %4, %1
>>   ret double %5
>> }
>>
>>
>>
>>
>> On Tuesday, August 23, 2016 at 6:00:37 PM UTC-4, Chris Rackauckas wrote:
>>>
>>> Yes, I am looking for a closure which has the least overhead possible 
>>> (this was all in v0.5). For example, for re-ordering parameters: g = 
>>> (du,u,t) -> f(t,u,du), or for enclosing parameter values as above.
>>>
>>> I'll give the Val method a try and see whether the compile time is 
>>> significant (it will probably be an option). 
>>>
>>> Even a solution which is like translator1/2 where the inbounds check is 
>>> able to be turned off would likely be performant enough to not be 
>>> noticeably different.
>>>
>>> On Tuesday, August 23, 2016 at 1:27:25 PM UTC-7, Erik Schnetter wrote:

 Chris

 I don't quite understand what you mean. Are you looking for a closure / 
 lambda expression?

 ```Julia
 function myfunc(x0, x1, alpha)
 f(x) = alpha * x
 ODE.solve(f, x0, x1)
 end
 ```

 Or is it important for your that your function `f` is optimized, i.e. 
 you want to re-run the code generator (expensive!) every time there's a 
 new 
 value for `alpha`? For this, you can use `Val` (but please benchmark 
 first):

 ```Julia
 function f{alpha}(x, ::Type{Val{alpha}})
 alpha * x
 end

 function myfunc(x0, x1, alpha)
 f1(x) = f(x, Val{alpha})
 ODE.solve(f, x0, x1)
 end
 ```

 This will have a marginally faster evaluation of `f`, at the cost of 
 compiling a separate function for each value of `alpha`.

 Since these examples use closures, they will be much more efficient in 
 Julia 0.5 than in 0.4.

 -erik




 On Tue, Aug 23, 2016 at 2:23 PM, Chris Rackauckas  
 wrote:

> Note: This looks long, but really just has a lot of LLVM IR!
>
> I have been digging into the issue recently of the best way to 
> enclose parameters with a function 
>

[julia-users] Re: Using Latex Symbols (unicode characters) as Julia operators

2016-08-23 Thread Steven G. Johnson

You can just look in


 http://docs.julialang.org/en/latest/manual/unicode-input/#man-unicode-input

Pretty much anything that looks like an infix operator is parsed as one.

(Note that a dictionary of these symbols can be found in 
Base.REPLCompletions.latex_symbols)

Re: [julia-users] Performant methods for enclosing parameters?

2016-08-23 Thread Chris Rackauckas

In my scenarios, the function k is given by the user. So this method won't 
work. If you move that definition of k outside of test() and pass it into 
your test, you'll see that the LLVM code explodes (at least it does for 
me). The issue is defining a closure on a function which was defined 
outside of the current scope.

BTW, what exactly is "%3 = getelementptr inbounds %"##30#34", %"##30#34"* 
%0, i64 0, i32 1". How harmful is it to performance (I just see inbounds 
and an extra line and want to get rid of it, but if it's harmless then 
there are two solutions in here).

On Tuesday, August 23, 2016 at 5:04:21 PM UTC-7, Andrew wrote:
>
> I'm pretty confused about what you're trying to accomplish beyond standard 
> closures. What is your ParameterHolder type for?
>
> I rewrote your first example wrapping everything in a function. Is this 
> doing what you want it to? The LLVM looks fine.
> function test(α)
> k(u::Float64,t::Float64,α) = α*u
> G = (u,t) -> k(u,t,1.01)
> G2 = (u,t)->k(u,t,α)
> const β = 1.01
> G3 = (u,t)->k(u,t,β)
>
> @code_llvm G(1., 2.)
> @code_llvm G2(1., 2.)
> @code_llvm G3(1., 2.)
> end
>
> julia> test(2.)
>
> define double @"julia_#28_70100"(double, double) #0 {
> top:
>   %2 = fmul double %0, 1.01e+00
>   ret double %2
> }
>
> define double @"julia_#29_70102"(%"##29#33"*, double, double) #0 {
> top:
>   %3 = getelementptr inbounds %"##29#33", %"##29#33"* %0, i64 0, i32 0
>   %4 = load double, double* %3, align 8
>   %5 = fmul double %4, %1
>   ret double %5
> }
>
> define double @"julia_#30_70104"(%"##30#34"*, double, double) #0 {
> top:
>   %3 = getelementptr inbounds %"##30#34", %"##30#34"* %0, i64 0, i32 1
>   %4 = load double, double* %3, align 8
>   %5 = fmul double %4, %1
>   ret double %5
> }
>
>
>
>
> On Tuesday, August 23, 2016 at 6:00:37 PM UTC-4, Chris Rackauckas wrote:
>>
>> Yes, I am looking for a closure which has the least overhead possible 
>> (this was all in v0.5). For example, for re-ordering parameters: g = 
>> (du,u,t) -> f(t,u,du), or for enclosing parameter values as above.
>>
>> I'll give the Val method a try and see whether the compile time is 
>> significant (it will probably be an option). 
>>
>> Even a solution which is like translator1/2 where the inbounds check is 
>> able to be turned off would likely be performant enough to not be 
>> noticeably different.
>>
>> On Tuesday, August 23, 2016 at 1:27:25 PM UTC-7, Erik Schnetter wrote:
>>>
>>> Chris
>>>
>>> I don't quite understand what you mean. Are you looking for a closure / 
>>> lambda expression?
>>>
>>> ```Julia
>>> function myfunc(x0, x1, alpha)
>>> f(x) = alpha * x
>>> ODE.solve(f, x0, x1)
>>> end
>>> ```
>>>
>>> Or is it important for your that your function `f` is optimized, i.e. 
>>> you want to re-run the code generator (expensive!) every time there's a new 
>>> value for `alpha`? For this, you can use `Val` (but please benchmark first):
>>>
>>> ```Julia
>>> function f{alpha}(x, ::Type{Val{alpha}})
>>> alpha * x
>>> end
>>>
>>> function myfunc(x0, x1, alpha)
>>> f1(x) = f(x, Val{alpha})
>>> ODE.solve(f, x0, x1)
>>> end
>>> ```
>>>
>>> This will have a marginally faster evaluation of `f`, at the cost of 
>>> compiling a separate function for each value of `alpha`.
>>>
>>> Since these examples use closures, they will be much more efficient in 
>>> Julia 0.5 than in 0.4.
>>>
>>> -erik
>>>
>>>
>>>
>>>
>>> On Tue, Aug 23, 2016 at 2:23 PM, Chris Rackauckas  
>>> wrote:
>>>
 Note: This looks long, but really just has a lot of LLVM IR!

 I have been digging into the issue recently of the best way to enclose 
 parameters with a function 
 . 
 This is an issue that comes up a lot with scientific codes, and so I was 
 hoping to try and get it right. However, the results of my experiments 
 aren't looking too good, and so I was hoping to find out whether I am 
 running into some bug or simply just not finding the optimal solution.

 The example is as follows (with LLVM IR included to show how exactly 
 everything is compiling). Say the user wants we to do a bunch of things 
 with the function f(u,t)=α*u where α is some parameter. They don't 
 necessarily want to replace it as a constant since they may change it 
 around a bit, but every time this function is given to me, I can treat it 
 as a constant. If they were willing to treat it as a constant, then they 
 could take this function:

 k(u::Float64,t::Float64,α) = α*u
 println("Standard k definition")
 @code_llvm k(1.0,2.0,1.01)

 #Result

 define double @julia_k_70163(double, double, double) #0 {
 top:
   %3 = fmul double %0, %2
   ret double %3
 }

 and enclose the constant:

 G = (u,t) -> k(u,t,1.01)
 G2 = (u,t)->k(u,t,α)
 println("Top level inlined k")
 @code_llvm G(1.0,2.0)

Re: [julia-users] Performant methods for enclosing parameters?

2016-08-23 Thread Andrew

I'm pretty confused about what you're trying to accomplish beyond standard 
closures. What is your ParameterHolder type for?

I rewrote your first example wrapping everything in a function. Is this 
doing what you want it to? The LLVM looks fine.
function test(α)
k(u::Float64,t::Float64,α) = α*u
G = (u,t) -> k(u,t,1.01)
G2 = (u,t)->k(u,t,α)
const β = 1.01
G3 = (u,t)->k(u,t,β)

@code_llvm G(1., 2.)
@code_llvm G2(1., 2.)
@code_llvm G3(1., 2.)
end

julia> test(2.)

define double @"julia_#28_70100"(double, double) #0 {
top:
  %2 = fmul double %0, 1.01e+00
  ret double %2
}

define double @"julia_#29_70102"(%"##29#33"*, double, double) #0 {
top:
  %3 = getelementptr inbounds %"##29#33", %"##29#33"* %0, i64 0, i32 0
  %4 = load double, double* %3, align 8
  %5 = fmul double %4, %1
  ret double %5
}

define double @"julia_#30_70104"(%"##30#34"*, double, double) #0 {
top:
  %3 = getelementptr inbounds %"##30#34", %"##30#34"* %0, i64 0, i32 1
  %4 = load double, double* %3, align 8
  %5 = fmul double %4, %1
  ret double %5
}




On Tuesday, August 23, 2016 at 6:00:37 PM UTC-4, Chris Rackauckas wrote:
>
> Yes, I am looking for a closure which has the least overhead possible 
> (this was all in v0.5). For example, for re-ordering parameters: g = 
> (du,u,t) -> f(t,u,du), or for enclosing parameter values as above.
>
> I'll give the Val method a try and see whether the compile time is 
> significant (it will probably be an option). 
>
> Even a solution which is like translator1/2 where the inbounds check is 
> able to be turned off would likely be performant enough to not be 
> noticeably different.
>
> On Tuesday, August 23, 2016 at 1:27:25 PM UTC-7, Erik Schnetter wrote:
>>
>> Chris
>>
>> I don't quite understand what you mean. Are you looking for a closure / 
>> lambda expression?
>>
>> ```Julia
>> function myfunc(x0, x1, alpha)
>> f(x) = alpha * x
>> ODE.solve(f, x0, x1)
>> end
>> ```
>>
>> Or is it important for your that your function `f` is optimized, i.e. you 
>> want to re-run the code generator (expensive!) every time there's a new 
>> value for `alpha`? For this, you can use `Val` (but please benchmark first):
>>
>> ```Julia
>> function f{alpha}(x, ::Type{Val{alpha}})
>> alpha * x
>> end
>>
>> function myfunc(x0, x1, alpha)
>> f1(x) = f(x, Val{alpha})
>> ODE.solve(f, x0, x1)
>> end
>> ```
>>
>> This will have a marginally faster evaluation of `f`, at the cost of 
>> compiling a separate function for each value of `alpha`.
>>
>> Since these examples use closures, they will be much more efficient in 
>> Julia 0.5 than in 0.4.
>>
>> -erik
>>
>>
>>
>>
>> On Tue, Aug 23, 2016 at 2:23 PM, Chris Rackauckas  
>> wrote:
>>
>>> Note: This looks long, but really just has a lot of LLVM IR!
>>>
>>> I have been digging into the issue recently of the best way to enclose 
>>> parameters with a function 
>>> . 
>>> This is an issue that comes up a lot with scientific codes, and so I was 
>>> hoping to try and get it right. However, the results of my experiments 
>>> aren't looking too good, and so I was hoping to find out whether I am 
>>> running into some bug or simply just not finding the optimal solution.
>>>
>>> The example is as follows (with LLVM IR included to show how exactly 
>>> everything is compiling). Say the user wants we to do a bunch of things 
>>> with the function f(u,t)=α*u where α is some parameter. They don't 
>>> necessarily want to replace it as a constant since they may change it 
>>> around a bit, but every time this function is given to me, I can treat it 
>>> as a constant. If they were willing to treat it as a constant, then they 
>>> could take this function:
>>>
>>> k(u::Float64,t::Float64,α) = α*u
>>> println("Standard k definition")
>>> @code_llvm k(1.0,2.0,1.01)
>>>
>>> #Result
>>>
>>> define double @julia_k_70163(double, double, double) #0 {
>>> top:
>>>   %3 = fmul double %0, %2
>>>   ret double %3
>>> }
>>>
>>>
>>> and enclose the constant:
>>>
>>> G = (u,t) -> k(u,t,1.01)
>>> G2 = (u,t)->k(u,t,α)
>>> println("Top level inlined k")
>>> @code_llvm G(1.0,2.0)
>>> println("Top level not inlined k")
>>> @code_llvm G2(1.0,2.0)
>>> const β = 1.01
>>> G3 = (u,t)->k(u,t,β)
>>> println("Top level not inlined but const k")
>>> @code_llvm G3(1.0,2.0)
>>>
>>> #Results
>>>
>>> Top level inlined k
>>>
>>> define double @"julia_#159_70165"(double, double) #0 {
>>> top:
>>>   %2 = fmul double %0, 1.01e+00
>>>   ret double %2
>>> }
>>>
>>> Top level not inlined k
>>>
>>> define %jl_value_t* @"julia_#161_70167"(double, double) #0 {
>>> top:
>>>   %thread_ptr = call i8* asm "movq %fs:0, $0", "=r"() #2
>>>   %ptls_i8 = getelementptr i8, i8* %thread_ptr, i64 -2672
>>>   %ptls = bitcast i8* %ptls_i8 to %jl_value_t***
>>>   %2 = alloca [5 x %jl_value_t*], align 8
>>>   %.sub = getelementptr inbounds [5 x %jl_value_t*], [5 x %jl_value_t*]* 
>>> %2, i64 0, i64 0
>>>   %3 = getelementptr [5 x

[julia-users] Julia Plugin System

2016-08-23 Thread Thomas S Hatch

I am asking this just to look for some opinions or ideas on the most
Julia-like way to do something, as usual, I have no complaints with Julia :)

I am working on writing a plugin system in Julia and had a syntax question.
The plugin system was originally written in python and was based loosely on
the Salt plugin system. The plugin system allows for plugin subsystems to
be defined and then they all share a data "hub" so the plugin systems can
easily cross communicate.

In python the plugin system uses nested python objects to directly
reference the plugin function:
hub.subsystem.module.function(args/kwargs)

In Julia I have implemented it like this:
plugin(hub, "subsystem.module.function")(args/kwargs)

Would there be a better, more Julia-like way to represent this concept?


Thomas S. Hatch  |  Founder, CTO

3400 N. Ashton Blvd, Suite 110 | Lehi, UT 84043
tha...@saltstack.com | www.saltstack.com

[julia-users] Recursive/Circular parametric types

2016-08-23 Thread Ben Ward

I'm doing some development and wondered if this kind of pattern is 
problematic:

abstract AbstractNode
abstract PhylogenyNode <: AbstractNode
abstract NetworkNode <: AbstractNode
abstract AbstractEdge
abstract PhylogenyEdge <: AbstractEdge
abstract NetworkEdge <: AbstractEdge

type Branch{N <: PhylogenyNode} <: PhylogenyEdge
from::N{Branch}
to::N{Branch}
length::Float64

function Branch{N}(::Type{N})
x = new()
length!(x, -1.0)
return x
end
end

type Clade{E <: PhylogenyEdge} <: PhylogenyNode
from::E
to::Vector{E}
confidence::Float64

function Clade{E}(::Type{E})
x = new()
x.to = Vector{E}()
confidence!(x, -1.0)
return x
end
end



As you can see both concrete types are parametric, and as a result there is 
a certain circularity to it 
Clade{Branch{Clade{Branch{Clade{Branch} That ultimately ends in 
something like Clade{Branch{N<:PhylogenyNode}}. I'd like to know if this is 
type-certain or not - the fact it terminates in N<:PhylogenyNode or 
E<:PhylogenyEdge makes me doubt it.

Re: [julia-users] Performant methods for enclosing parameters?

2016-08-23 Thread Chris Rackauckas

Yes, I am looking for a closure which has the least overhead possible (this 
was all in v0.5). For example, for re-ordering parameters: g = (du,u,t) -> 
f(t,u,du), or for enclosing parameter values as above.

I'll give the Val method a try and see whether the compile time is 
significant (it will probably be an option). 

Even a solution which is like translator1/2 where the inbounds check is 
able to be turned off would likely be performant enough to not be 
noticeably different.

On Tuesday, August 23, 2016 at 1:27:25 PM UTC-7, Erik Schnetter wrote:
>
> Chris
>
> I don't quite understand what you mean. Are you looking for a closure / 
> lambda expression?
>
> ```Julia
> function myfunc(x0, x1, alpha)
> f(x) = alpha * x
> ODE.solve(f, x0, x1)
> end
> ```
>
> Or is it important for your that your function `f` is optimized, i.e. you 
> want to re-run the code generator (expensive!) every time there's a new 
> value for `alpha`? For this, you can use `Val` (but please benchmark first):
>
> ```Julia
> function f{alpha}(x, ::Type{Val{alpha}})
> alpha * x
> end
>
> function myfunc(x0, x1, alpha)
> f1(x) = f(x, Val{alpha})
> ODE.solve(f, x0, x1)
> end
> ```
>
> This will have a marginally faster evaluation of `f`, at the cost of 
> compiling a separate function for each value of `alpha`.
>
> Since these examples use closures, they will be much more efficient in 
> Julia 0.5 than in 0.4.
>
> -erik
>
>
>
>
> On Tue, Aug 23, 2016 at 2:23 PM, Chris Rackauckas  > wrote:
>
>> Note: This looks long, but really just has a lot of LLVM IR!
>>
>> I have been digging into the issue recently of the best way to enclose 
>> parameters with a function 
>> . 
>> This is an issue that comes up a lot with scientific codes, and so I was 
>> hoping to try and get it right. However, the results of my experiments 
>> aren't looking too good, and so I was hoping to find out whether I am 
>> running into some bug or simply just not finding the optimal solution.
>>
>> The example is as follows (with LLVM IR included to show how exactly 
>> everything is compiling). Say the user wants we to do a bunch of things 
>> with the function f(u,t)=α*u where α is some parameter. They don't 
>> necessarily want to replace it as a constant since they may change it 
>> around a bit, but every time this function is given to me, I can treat it 
>> as a constant. If they were willing to treat it as a constant, then they 
>> could take this function:
>>
>> k(u::Float64,t::Float64,α) = α*u
>> println("Standard k definition")
>> @code_llvm k(1.0,2.0,1.01)
>>
>> #Result
>>
>> define double @julia_k_70163(double, double, double) #0 {
>> top:
>>   %3 = fmul double %0, %2
>>   ret double %3
>> }
>>
>>
>> and enclose the constant:
>>
>> G = (u,t) -> k(u,t,1.01)
>> G2 = (u,t)->k(u,t,α)
>> println("Top level inlined k")
>> @code_llvm G(1.0,2.0)
>> println("Top level not inlined k")
>> @code_llvm G2(1.0,2.0)
>> const β = 1.01
>> G3 = (u,t)->k(u,t,β)
>> println("Top level not inlined but const k")
>> @code_llvm G3(1.0,2.0)
>>
>> #Results
>>
>> Top level inlined k
>>
>> define double @"julia_#159_70165"(double, double) #0 {
>> top:
>>   %2 = fmul double %0, 1.01e+00
>>   ret double %2
>> }
>>
>> Top level not inlined k
>>
>> define %jl_value_t* @"julia_#161_70167"(double, double) #0 {
>> top:
>>   %thread_ptr = call i8* asm "movq %fs:0, $0", "=r"() #2
>>   %ptls_i8 = getelementptr i8, i8* %thread_ptr, i64 -2672
>>   %ptls = bitcast i8* %ptls_i8 to %jl_value_t***
>>   %2 = alloca [5 x %jl_value_t*], align 8
>>   %.sub = getelementptr inbounds [5 x %jl_value_t*], [5 x %jl_value_t*]* 
>> %2, i64 0, i64 0
>>   %3 = getelementptr [5 x %jl_value_t*], [5 x %jl_value_t*]* %2, i64 0, 
>> i64 2
>>   %4 = bitcast %jl_value_t** %3 to i8*
>>   call void @llvm.memset.p0i8.i32(i8* %4, i8 0, i32 24, i32 8, i1 false)
>>   %5 = bitcast [5 x %jl_value_t*]* %2 to i64*
>>   store i64 6, i64* %5, align 8
>>   %6 = getelementptr [5 x %jl_value_t*], [5 x %jl_value_t*]* %2, i64 0, 
>> i64 1
>>   %7 = bitcast i8* %ptls_i8 to i64*
>>   %8 = load i64, i64* %7, align 8
>>   %9 = bitcast %jl_value_t** %6 to i64*
>>   store i64 %8, i64* %9, align 8
>>   store %jl_value_t** %.sub, %jl_value_t*** %ptls, align 8
>>   %10 = getelementptr [5 x %jl_value_t*], [5 x %jl_value_t*]* %2, i64 0, 
>> i64 4
>>   %11 = getelementptr [5 x %jl_value_t*], [5 x %jl_value_t*]* %2, i64 0, 
>> i64 3
>>   %12 = load i64, i64* inttoptr (i64 139896404414328 to i64*), align 8
>>   %13 = bitcast %jl_value_t** %11 to i64*
>>   store i64 %12, i64* %13, align 8
>>   store %jl_value_t* inttoptr (i64 139896327403528 to %jl_value_t*), 
>> %jl_value_t** %3, align 8
>>   %14 = call %jl_value_t* @jl_gc_pool_alloc(i8* %ptls_i8, i32 1432, i32 
>> 16)
>>   %15 = getelementptr inbounds %jl_value_t, %jl_value_t* %14, i64 -1, i32 
>> 0
>>   store %jl_value_t* inttoptr (i64 139896322417392 to %jl_value_t*), 
>>

Re: [julia-users] Make a histogram

2016-08-23 Thread Ahmed Mazari

but the x-axis must be ordered from the smallest to the largest value . My 
question know is how to determine the number of bins ?
On Tuesday, August 23, 2016 at 4:46:22 PM UTC+2, Christof Stocker wrote:
>
> If you know the categories then one thing you could do is think about it 
> as a barplot
>
> *julia> **UnicodePlots.barplot(a[:,1], a[:,2], symb = "▇")*
> *  ┌┐* 
> *7 │**▇▇** 4**│* 
> *4 │**▇▇▇** 2*   *│* 
> *9 │**▇▇** 3**│* 
>*10 │**▇▇▇** 1*   *│* 
> *2 │**▇** 5* *│* 
> *3 │**▇▇▇** 1*   *│* 
> *5 │**▇▇▇** 1*   *│* 
> *8 │**▇▇▇** 1*   *│* 
> *6 │**▇▇▇** 1*   *│* 
> *1 │**▇▇▇** 1*   *│* 
> *  └┘* 
>
> On 23 Aug 2016, at 16:14, Ahmed Mazari  
> wrote:
>
> Hello, 
> l have this matrix where the first column represents different values and 
> second column represents the number of occurences of each value. How can 
> plot a histogram x-axis : the different values, y-axis : the number of 
> occurences.
>
> 
> 10x2 Array{Int64,2}:
>   7  4
>   4  2
>   9  3
>  10  1
>   2  5
>   3  1
>   5  1
>   8  1
>   6  1
>   1  1
>
>
>
> Thank you
>
>
>

[julia-users] Using Latex Symbols (unicode characters) as Julia operators

2016-08-23 Thread jandehaan500

I wanted to use a specific Unicode character as an operator. It took a 
little poking around, so I'm sharing my solution to save you some time.

First I looked at the file 
github.com/JuliaLang/julia/blob/master/src/julia-parser.scm
Starting on line 9 is a grouping of all the operators supported by Julia. 
Operators with the lowest precedence are at the top, those with the highest 
precedence at the bottom.
I selected the character ⟺which is in the prec-arrow group.

The next problem was how to enter that character in the Julia console or in 
IJulia (Jupyter). For that I wrote the following bit of code.

include("path\\to\\julia\sourcecode\\base\\latex_symbols.jl")
import Base.find
function find(dict::Dict, valuetofind::AbstractString)
for (k,v) in dict
if v == valuetofind return k end
end
   ""
end
find(latex_symbols, "⟺")  # returns  "\\Longleftrightarrow"

In the Julia console or IJulia type \Longleftrightarrow and press the tab 
key to see it being converted to ⟺

Note: Some Unicode characters may show up as open boxes in your favorite 
editor. This is because the current font does not support it. Use a 
different font. Lookup "Unicode font" in Wikipedia to find one that might 
work for you.

Enjoy.

Re: [julia-users] Performant methods for enclosing parameters?

2016-08-23 Thread Erik Schnetter

Chris

I don't quite understand what you mean. Are you looking for a closure /
lambda expression?

```Julia
function myfunc(x0, x1, alpha)
f(x) = alpha * x
ODE.solve(f, x0, x1)
end
```

Or is it important for your that your function `f` is optimized, i.e. you
want to re-run the code generator (expensive!) every time there's a new
value for `alpha`? For this, you can use `Val` (but please benchmark first):

```Julia
function f{alpha}(x, ::Type{Val{alpha}})
alpha * x
end

function myfunc(x0, x1, alpha)
f1(x) = f(x, Val{alpha})
ODE.solve(f, x0, x1)
end
```

This will have a marginally faster evaluation of `f`, at the cost of
compiling a separate function for each value of `alpha`.

Since these examples use closures, they will be much more efficient in
Julia 0.5 than in 0.4.

-erik




On Tue, Aug 23, 2016 at 2:23 PM, Chris Rackauckas 
wrote:

> Note: This looks long, but really just has a lot of LLVM IR!
>
> I have been digging into the issue recently of the best way to enclose
> parameters with a function
> .
> This is an issue that comes up a lot with scientific codes, and so I was
> hoping to try and get it right. However, the results of my experiments
> aren't looking too good, and so I was hoping to find out whether I am
> running into some bug or simply just not finding the optimal solution.
>
> The example is as follows (with LLVM IR included to show how exactly
> everything is compiling). Say the user wants we to do a bunch of things
> with the function f(u,t)=α*u where α is some parameter. They don't
> necessarily want to replace it as a constant since they may change it
> around a bit, but every time this function is given to me, I can treat it
> as a constant. If they were willing to treat it as a constant, then they
> could take this function:
>
> k(u::Float64,t::Float64,α) = α*u
> println("Standard k definition")
> @code_llvm k(1.0,2.0,1.01)
>
> #Result
>
> define double @julia_k_70163(double, double, double) #0 {
> top:
>   %3 = fmul double %0, %2
>   ret double %3
> }
>
>
> and enclose the constant:
>
> G = (u,t) -> k(u,t,1.01)
> G2 = (u,t)->k(u,t,α)
> println("Top level inlined k")
> @code_llvm G(1.0,2.0)
> println("Top level not inlined k")
> @code_llvm G2(1.0,2.0)
> const β = 1.01
> G3 = (u,t)->k(u,t,β)
> println("Top level not inlined but const k")
> @code_llvm G3(1.0,2.0)
>
> #Results
>
> Top level inlined k
>
> define double @"julia_#159_70165"(double, double) #0 {
> top:
>   %2 = fmul double %0, 1.01e+00
>   ret double %2
> }
>
> Top level not inlined k
>
> define %jl_value_t* @"julia_#161_70167"(double, double) #0 {
> top:
>   %thread_ptr = call i8* asm "movq %fs:0, $0", "=r"() #2
>   %ptls_i8 = getelementptr i8, i8* %thread_ptr, i64 -2672
>   %ptls = bitcast i8* %ptls_i8 to %jl_value_t***
>   %2 = alloca [5 x %jl_value_t*], align 8
>   %.sub = getelementptr inbounds [5 x %jl_value_t*], [5 x %jl_value_t*]*
> %2, i64 0, i64 0
>   %3 = getelementptr [5 x %jl_value_t*], [5 x %jl_value_t*]* %2, i64 0,
> i64 2
>   %4 = bitcast %jl_value_t** %3 to i8*
>   call void @llvm.memset.p0i8.i32(i8* %4, i8 0, i32 24, i32 8, i1 false)
>   %5 = bitcast [5 x %jl_value_t*]* %2 to i64*
>   store i64 6, i64* %5, align 8
>   %6 = getelementptr [5 x %jl_value_t*], [5 x %jl_value_t*]* %2, i64 0,
> i64 1
>   %7 = bitcast i8* %ptls_i8 to i64*
>   %8 = load i64, i64* %7, align 8
>   %9 = bitcast %jl_value_t** %6 to i64*
>   store i64 %8, i64* %9, align 8
>   store %jl_value_t** %.sub, %jl_value_t*** %ptls, align 8
>   %10 = getelementptr [5 x %jl_value_t*], [5 x %jl_value_t*]* %2, i64 0,
> i64 4
>   %11 = getelementptr [5 x %jl_value_t*], [5 x %jl_value_t*]* %2, i64 0,
> i64 3
>   %12 = load i64, i64* inttoptr (i64 139896404414328 to i64*), align 8
>   %13 = bitcast %jl_value_t** %11 to i64*
>   store i64 %12, i64* %13, align 8
>   store %jl_value_t* inttoptr (i64 139896327403528 to %jl_value_t*),
> %jl_value_t** %3, align 8
>   %14 = call %jl_value_t* @jl_gc_pool_alloc(i8* %ptls_i8, i32 1432, i32 16)
>   %15 = getelementptr inbounds %jl_value_t, %jl_value_t* %14, i64 -1, i32 0
>   store %jl_value_t* inttoptr (i64 139896322417392 to %jl_value_t*),
> %jl_value_t** %15, align 8
>   %16 = bitcast %jl_value_t* %14 to double*
>   store double %0, double* %16, align 8
>   store %jl_value_t* %14, %jl_value_t** %10, align 8
>   %17 = call %jl_value_t* @jl_apply_generic(%jl_value_t** %3, i32 3)
>   %18 = load i64, i64* %9, align 8
>   store i64 %18, i64* %7, align 8
>   ret %jl_value_t* %17
> }
>
> Top level not inlined but const k
>
> define double @"julia_#163_70169"(double, double) #0 {
> top:
>   %2 = fmul double %0, 1.01e+00
>   ret double %2
> }
>
> It's clear from these results that the user would have to treat that
> values they enclose as a constant. This is a known performance issue due to
> global variables.
>
> So let's say I will be doing the enclosing on my end. The parameters ends
> up

Re: [julia-users] creating a DataFrame from C now fails in 0.5 rc 1+1

2016-08-23 Thread Keno Fischer

If you create objects from C you need to be very careful to have
appropriate gc roots, for all values involved before yielding control
back to julia.

On Tue, Aug 9, 2016 at 6:23 PM,   wrote:
> I'm contributing a bit to rjulia and I've run into some trouble creating
> julia DataFrames from C in 0.5 (rc 1+1)
>
> Creating a DataFrame from C like this:
>
> jl_value_t *ans = jl_eval_string("DataFrame( Any[ 1:4, 5:8 ], [:a,:b] )");
>
> worked in 0.4 as did
>
> jl_function_t *func = jl_get_function(jl_main_module, "DataFrame");
> jl_value_t *ans = jl_call2(func, (jl_value_t *)col_list, (jl_value_t
> *)col_names);
>
> assuming the DataFrames package had been loaded.  col_list is an
> Array{Any,1} and col_names is an Array{Symbol,1}.
>
> In 0.5 rc 1+1 with DataFrames 0.7.7,
>
> I get a very verbose error message:
>
> signal (11): Segmentation fault: 11
>  while loading no file, in expression starting on line 0
>  gc_mark_stack at
> /Users/osx/buildbot/slave/package_osx10_9-x64/build/src/gc.c:1239 [inlined]
>  gc_mark_task_stack at
> /Users/osx/buildbot/slave/package_osx10_9-x64/build/src/gc.c:1275 [inlined]
>  gc_mark_task at
> /Users/osx/buildbot/slave/package_osx10_9-x64/build/src/gc.c:1298
>  push_root at
> /Users/osx/buildbot/slave/package_osx10_9-x64/build/src/gc.c:1426
>  gc_push_root at
> /Users/osx/buildbot/slave/package_osx10_9-x64/build/src/gc.c:1179 [inlined]
>  gc_mark_module at
> /Users/osx/buildbot/slave/package_osx10_9-x64/build/src/gc.c:1208
>  push_root at
> /Users/osx/buildbot/slave/package_osx10_9-x64/build/src/gc.c:1419
> ...
>
> As a positive control,
>
> jl_value_t *ans = jl_eval_string("DataFrame()");
>
> works in both 0.4 and 0.5.
>
> Can anyone think of something that changed that might cause such a problem?
> The "OutOfMemory" bug in 0.5 rc0 caused some similar trouble, so I'm hoping
> that another (soon to be fixed) issue in 0.5 may be responsible

[julia-users] Re: Correct way to use squeeze function

2016-08-23 Thread jonathan . bieler

Squeeze will remove s dimension of size one, so you can transform an array 
of size 5x1x4 into 5x4 by squeezing the dimension 2.

In 0.4 the last dimension is automatically squeezed, and it seems that in 
0.5 they all are.

[julia-users] Re: creating a DataFrame from C now fails in 0.5 rc 1+1

2016-08-23 Thread phaverty

Fixed by something in julia rc 3.  Great!

On Tuesday, August 9, 2016 at 5:28:08 PM UTC-7, phav...@gene.com wrote:
>
> I'm contributing a bit to rjulia and I've run into some trouble creating 
> julia DataFrames from C in 0.5 (rc 1+1)
>
> Creating a DataFrame from C like this:
>
> jl_value_t *ans = jl_eval_string("DataFrame( Any[ 1:4, 5:8 ], [:a,:b] )");
>
> worked in 0.4 as did 
>
> jl_function_t *func = jl_get_function(jl_main_module, "DataFrame");
> jl_value_t *ans = jl_call2(func, (jl_value_t *)col_list, (jl_value_t 
> *)col_names);
>
> assuming the DataFrames package had been loaded.  col_list is an 
> Array{Any,1} and col_names is an Array{Symbol,1}.
>
> In 0.5 rc 1+1 with DataFrames 0.7.7,
>
> I get a very verbose error message:
>
> signal (11): Segmentation fault: 11
>  while loading no file, in expression starting on line 0
>  gc_mark_stack at 
> /Users/osx/buildbot/slave/package_osx10_9-x64/build/src/gc.c:1239 [inlined]
>  gc_mark_task_stack at 
> /Users/osx/buildbot/slave/package_osx10_9-x64/build/src/gc.c:1275 [inlined]
>  gc_mark_task at 
> /Users/osx/buildbot/slave/package_osx10_9-x64/build/src/gc.c:1298
>  push_root at 
> /Users/osx/buildbot/slave/package_osx10_9-x64/build/src/gc.c:1426
>  gc_push_root at 
> /Users/osx/buildbot/slave/package_osx10_9-x64/build/src/gc.c:1179 [inlined]
>  gc_mark_module at 
> /Users/osx/buildbot/slave/package_osx10_9-x64/build/src/gc.c:1208
>  push_root at 
> /Users/osx/buildbot/slave/package_osx10_9-x64/build/src/gc.c:1419
> ...
>
> As a positive control, 
>
> jl_value_t *ans = jl_eval_string("DataFrame()");
>
> works in both 0.4 and 0.5.
>
> Can anyone think of something that changed that might cause such a 
> problem?  The "OutOfMemory" bug in 0.5 rc0 caused some similar trouble, so 
> I'm hoping that another (soon to be fixed) issue in 0.5 may be responsible
>

[julia-users] Performant methods for enclosing parameters?

2016-08-23 Thread Chris Rackauckas

Note: This looks long, but really just has a lot of LLVM IR!

I have been digging into the issue recently of the best way to enclose 
parameters with a function 
. 
This is an issue that comes up a lot with scientific codes, and so I was 
hoping to try and get it right. However, the results of my experiments 
aren't looking too good, and so I was hoping to find out whether I am 
running into some bug or simply just not finding the optimal solution.

The example is as follows (with LLVM IR included to show how exactly 
everything is compiling). Say the user wants we to do a bunch of things 
with the function f(u,t)=α*u where α is some parameter. They don't 
necessarily want to replace it as a constant since they may change it 
around a bit, but every time this function is given to me, I can treat it 
as a constant. If they were willing to treat it as a constant, then they 
could take this function:

k(u::Float64,t::Float64,α) = α*u
println("Standard k definition")
@code_llvm k(1.0,2.0,1.01)

#Result

define double @julia_k_70163(double, double, double) #0 {
top:
  %3 = fmul double %0, %2
  ret double %3
}


and enclose the constant:

G = (u,t) -> k(u,t,1.01)
G2 = (u,t)->k(u,t,α)
println("Top level inlined k")
@code_llvm G(1.0,2.0)
println("Top level not inlined k")
@code_llvm G2(1.0,2.0)
const β = 1.01
G3 = (u,t)->k(u,t,β)
println("Top level not inlined but const k")
@code_llvm G3(1.0,2.0)

#Results

Top level inlined k

define double @"julia_#159_70165"(double, double) #0 {
top:
  %2 = fmul double %0, 1.01e+00
  ret double %2
}

Top level not inlined k

define %jl_value_t* @"julia_#161_70167"(double, double) #0 {
top:
  %thread_ptr = call i8* asm "movq %fs:0, $0", "=r"() #2
  %ptls_i8 = getelementptr i8, i8* %thread_ptr, i64 -2672
  %ptls = bitcast i8* %ptls_i8 to %jl_value_t***
  %2 = alloca [5 x %jl_value_t*], align 8
  %.sub = getelementptr inbounds [5 x %jl_value_t*], [5 x %jl_value_t*]* 
%2, i64 0, i64 0
  %3 = getelementptr [5 x %jl_value_t*], [5 x %jl_value_t*]* %2, i64 0, i64 
2
  %4 = bitcast %jl_value_t** %3 to i8*
  call void @llvm.memset.p0i8.i32(i8* %4, i8 0, i32 24, i32 8, i1 false)
  %5 = bitcast [5 x %jl_value_t*]* %2 to i64*
  store i64 6, i64* %5, align 8
  %6 = getelementptr [5 x %jl_value_t*], [5 x %jl_value_t*]* %2, i64 0, i64 
1
  %7 = bitcast i8* %ptls_i8 to i64*
  %8 = load i64, i64* %7, align 8
  %9 = bitcast %jl_value_t** %6 to i64*
  store i64 %8, i64* %9, align 8
  store %jl_value_t** %.sub, %jl_value_t*** %ptls, align 8
  %10 = getelementptr [5 x %jl_value_t*], [5 x %jl_value_t*]* %2, i64 0, 
i64 4
  %11 = getelementptr [5 x %jl_value_t*], [5 x %jl_value_t*]* %2, i64 0, 
i64 3
  %12 = load i64, i64* inttoptr (i64 139896404414328 to i64*), align 8
  %13 = bitcast %jl_value_t** %11 to i64*
  store i64 %12, i64* %13, align 8
  store %jl_value_t* inttoptr (i64 139896327403528 to %jl_value_t*), 
%jl_value_t** %3, align 8
  %14 = call %jl_value_t* @jl_gc_pool_alloc(i8* %ptls_i8, i32 1432, i32 16)
  %15 = getelementptr inbounds %jl_value_t, %jl_value_t* %14, i64 -1, i32 0
  store %jl_value_t* inttoptr (i64 139896322417392 to %jl_value_t*), 
%jl_value_t** %15, align 8
  %16 = bitcast %jl_value_t* %14 to double*
  store double %0, double* %16, align 8
  store %jl_value_t* %14, %jl_value_t** %10, align 8
  %17 = call %jl_value_t* @jl_apply_generic(%jl_value_t** %3, i32 3)
  %18 = load i64, i64* %9, align 8
  store i64 %18, i64* %7, align 8
  ret %jl_value_t* %17
}

Top level not inlined but const k

define double @"julia_#163_70169"(double, double) #0 {
top:
  %2 = fmul double %0, 1.01e+00
  ret double %2
}

It's clear from these results that the user would have to treat that values 
they enclose as a constant. This is a known performance issue due to global 
variables. 

So let's say I will be doing the enclosing on my end. The parameters ends 
up inside my function, and I am willing to wrap that into another function 
which holds all the parameters (can be necessary for calling some C 
libraries). However, I ran into issues finding any option which was 
performant. Here's my attempts:

# Some helpers
immutable ParameterHolder{uType<:Number}
  α::uType
end

function translator(f,α)
  Base.@propagate_inbounds g(u::Float64,t) = f(u::Float64,t,α)
  return g
end

function translator2(f,α)
  @inbounds g = (u::Float64,t) -> f(u::Float64,t,α)
  return g
end


# The "main" function the user will call
function code_test()
  local u::Float64 = 1.0
  const pconst = ParameterHolder(1.01)
  p = ParameterHolder(1.01)

  f(u,t,p) = @inbounds return p.α*u
  println("Inside using ParameterHolder Constant")
  @code_llvm f(1.0,2.0,pconst)
  println("Inside using ParameterHolder")
  @code_llvm f(1.0,2.0,p)
  h(u,t,α) = α*u
  α = 1.01
  g = (u,t) -> h(u,t,α)
  println("Inside using closure with variable")
  @code_llvm g(u,2.0)
  const β = 1.01
  l = (u,t) -> h(u,t,β)
  println("Inside using closure with const variable")

[julia-users] Correct way to use squeeze function

2016-08-23 Thread Sigurd Stoll



Hello everyone, I'm having some difficulties understanding the squeeze 
function, let's say I have a 3 dimensional array A of size 5x4x3, and I 
want to extract the elements corresponding to A[:,:,1]. I suppose I could 
do B = A[:,:,1], but what's the point of squeeze then?
The Julia documentation Release 0.4.7-pre has this to say about squeeze: 
"Remove the dimensions specified by dims from array A. Elements of dims 
must be unique and within the range 1:ndims(A)." From this it seems like B 
= squeeze(A,3) should do the trick, i.e. extract the elements A[:,:,1] from 
A, and form a new array B of size 5x4. This however produces an error 
stating that squeezed dims must all be size 1". I'm clearly missing 
something here. Does anyone have some advice?

Re: [julia-users] Proposed solution for writing Enums

2016-08-23 Thread Stefan Karpinski

On Tue, Aug 23, 2016 at 12:39 PM, Brian Rogoff  wrote:

> It's a bit surprising that Julia doesn't have built in enums and a
> case/switch form. I'm glad that there's open
> issue https://github.com/JuliaLang/julia/issues/5410 to address the lack
> of case/switch. Is there any hope that
> we may see these (or at least the built in case/switch) in 1.0?
>

It's certainly possible. The best way to make it happen is to write a good
Julep for how case/switch should behave and once there's general agreement
on the plan, make a PR to implement it.

[julia-users] Re: can't get pyjulia to work

2016-08-23 Thread Tim Wheeler

So here is what I did:

in Julia v0.4.6:

julia> Pkg.pin("PyCall", v"1.3.0")
julia> Pkg.build("PyCall")

removed core.py in /usr/local/lib/python2.7/dist-packages/julia/
created a new core.py containing these contents 
.

running, in python:

>>> import julia
>>> julia.Julia()

works fine.

[julia-users] Help wanted! Make sure the new testset PR doesn't break everything horribly!

2016-08-23 Thread Katie H

Hi everyone,

I've been working on improvements to Base Julia's test system, so that we 
can use testsets and have pretty printing and parallelism and all kinds of 
wonderful things that start with p. As you can see, the base tests pass! 
However, I know lots of package maintainers use testsets. I really don't 
want to merge anything that would break usability for those folks, so if 
you are a package maintainer (or a package user!) of a Julia package that 
uses testsets in their current form, I would be very grateful if you could 
try your package against my branch 
(https://github.com/JuliaLang/julia/pull/17165 - you can follow the 
horrendous development of this work in all its "glory"). In particular, if 
error reporting doesn't work right for you, or your tests are just worse in 
any way, I'd love to fix it so everyone can use the cool new features.

Thanks!
Katie

[julia-users] Re: Questions regarding Julia for general purpose programming (strings, modules, dispatch, inheritance)

2016-08-23 Thread Chris Rackauckas

I don't necessarily have a large project, but there are a few tidbits I 
think I can share. I'm not familiar with all the things strings, so I'll 
let someone else take that.

2. You can always do composition instead of inheritance. For many it's a 
preferred coding practice anyways 
. In the end I 
find it leads to less breakage.

3. Instead of "using Module", you can just do "import Module" and the 
namespace will be cleaner, but you'll need to use Module.thing to reference 
them. If your package is mostly defining functions on your own types, then 
you don't need to worry about any clashes anyways (unless some package that 
you import has a type which is the same name, and defines a method with the 
same name and uses that same type). It's hard to know how Julia will fare 
for large projects since it's still young. For a good reference on 
organizing code really well using dispatch and metaprogramming, see 
Plots.jl's source.

4. Multiple dispatch isn't just a utility of code design, it's THE 
fundamental part of Julia which makes it look like a scripting language 
while being write strictly typed (hopefully type-stable) compiled functions 
every step of the way. You can think of it as a smart trick which makes 
what you're writing look like fluid Python, but in reality every time you 
call a function, it's actually calling a special-cased (and therefore 
well-optimized) compiled function for exactly the types you give it. 

Here's an analogy for multiple dispatch. Speaking to Python is like 
speaking to politicians: the words/syntax are nice and concise, but there's 
a lot of behind the scenes translations that are going on which makes it 
slower to "get to the point". You say "free-market", the politician hears 
"regulations" and after some discussion with advisers it can respond to you 
with what you want. Advantage: it gives you want you want with little 
effort. Disadvantage: it can be a slow process, and sometimes you don't 
know what exactly is going on behind the scenes (what is the interpreter 
actually doing when using a Float as an Int?). 

Speaking with Julia is like speaking with a professor at a coffee shop. 
You're talking and just say "yeah, take the derivative of that F to 
maximize u" which means "take the Frechet derivative 
 of the functional 
to get the u which maximizes the  norm in the function space ". 
Everything you are saying is shorthand which, when expanded, gets right to 
the point. Advantage: fast. Disadvantage: it will be slow and the 
conversation will meander if you don't actually know what the specific 
statement is supposed to mean (i.e. you don't write a type-unstable 
function).

That turned out longer than I thought it would, but I think it gets the 
point across: multiple dispatch is always useful for getting you good clean 
performance if the functions you're writing are clean and type-stable (and 
if that's the case, you can get close to 1x with C). Whether you'll put in 
the effort to strictly type things and make the functions type-stable is up 
to you (in which case, Julia will still be expressive, but not the most 
performant). In the end, some mix where you prototype with less strict 
types but clean it up to end up with fast performant functions is a nice 
way to write code, and that's not an because of Julia: it's because of 
multiple dispatch (... so Julia is essentially taking a design philosophy 
based on multiple-dispatch on top of a compiler to an extreme. We've come 
full circle).

On Tuesday, August 23, 2016 at 5:39:26 AM UTC-7, JColn wrote:
>
> Hello,
>
> I'm looking at Julia for general purpose programming and things look good 
> so far. However, I want to see if I can elicit feedback from those that 
> have ventured   deeper into larger projects before moving further. Below 
> are questions regarding areas of concern I've seen cited and I'm wondering 
> if these issues are real. If anyone can provide experience I would be much 
> obliged( My frame of reference is python).
>
> 1. Strings. Are they faster in 0.5 (python speed or better). How about 
> ease of use?
>
> 2. Inheritance- Any issues with not being able to  do concrete inheritance?
>
> 3. Module system and dispatch- Lots of  Ink has been spilled on this, and 
> I understand that organizing multi dispatch code is an open research 
> question. However, it seems there are legitimate concerns about name 
> clashes,ease of use etc I've also perused some open issues, but don't see a 
> fundamental redesign. How does Julia fare for larger general projects 
> compared to say python or java>
>
> 4. Multi dispatch. How do you find its utility for non numerical code?
>
> Thanks!
>
>
>

Re: [julia-users] Proposed solution for writing Enums

2016-08-23 Thread Jacob Quinn

Julia indeed has built-in enums: Just below here in the docs:
http://docs.julialang.org/en/latest/stdlib/base/#Base.Val{c}

On Tue, Aug 23, 2016 at 10:51 AM, Evan Fields  wrote:

> @enum doesn't do what you want for enums?
>

Re: [julia-users] Proposed solution for writing Enums

2016-08-23 Thread Evan Fields

@enum doesn't do what you want for enums?

[julia-users] CDF of a multivariate normal distribution

2016-08-23 Thread jamesmnason

Hi:

Can anyone suggest how to compute the cdf of a multivariate normal 
distribution in Julia?

Distributions.jl provides the cdf function for univariate distributions, 
but I do not see a cdf function for multivariate distributions.  Have I 
missed this?

The cdf of a multivariate normal distribution appears to be a bit of a 
heavy lift computationally, but advice/suggestions is appreciated.

Thanks.

Jim

Re: [julia-users] Proposed solution for writing Enums

2016-08-23 Thread Brian Rogoff

It's a bit surprising that Julia doesn't have built in enums and a 
case/switch form. I'm glad that there's open
issue https://github.com/JuliaLang/julia/issues/5410 to address the lack of 
case/switch. Is there any hope that
we may see these (or at least the built in case/switch) in 1.0?

On Tuesday, August 23, 2016 at 5:57:20 AM UTC-7, Stefan Karpinski wrote:
>
> Oh, I see that you have: 
> https://groups.google.com/forum/#!topic/julia-users/fgzVlbGcw-o.
>
> On Tue, Aug 23, 2016 at 8:55 AM, Stefan Karpinski  > wrote:
>
>> The formatting on that came out pretty garbled. Can you repost with line 
>> breaks and such?
>>
>> On Mon, Aug 22, 2016 at 5:03 PM, Paul Sorensen > > wrote:
>>
>>> The following is my idea of writing enums that are better than the macro 
>>> because they give you a  typesafe way of passing them to a 
>>> functionbaremodule EnumNameimmutable enumnamex::UInt8end
>>> const Value_A = enumname(0)const Value_B = enumname(1)end# usage 
>>> examplebaremodule Colorimmutable colorx::UInt8endconst 
>>> Red = color(1)const Green = color(2)const Blue = color(3)const 
>>> White = color(4)const Black = color(5)endfunction 
>>> testColor(c::Color.color)println("A color was 
>>> passed")endtestColor(Color.Red)
>>>
>>
>>
>

[julia-users] Re: ANN: Julia 0.5.0-rc2 now available

2016-08-23 Thread Tony Kelman

Release candidate 3 is now available:

https://s3.amazonaws.com/julialang/bin/linux/x64/0.5/julia-0.5.0-rc3-linux-x86_64.tar.gz
 
https://s3.amazonaws.com/julialang/bin/linux/x86/0.5/julia-0.5.0-rc3-linux-i686.tar.gz
 
https://s3.amazonaws.com/julialang/bin/osx/x64/0.5/julia-0.5.0-rc3-osx10.7+.dmg 
https://s3.amazonaws.com/julialang/bin/winnt/x64/0.5/julia-0.5.0-rc3-win64.exe 
https://s3.amazonaws.com/julialang/bin/winnt/x86/0.5/julia-0.5.0-rc3-win32.exe 
https://s3.amazonaws.com/julialang/bin/checksums/julia-0.5.0-rc3.sha256 
https://s3.amazonaws.com/julialang/bin/checksums/julia-0.5.0-rc3.md5

This has backported the addition of proxy support for the package manager 
via libcurl on Linux and Mac (libgit2 should support proxies fine on 
Windows without needing libcurl). Please test and report any issues. There 
are some open pull requests fixing issues involving precompilation that we 
will likely want to make a release candidate 4 with towards the end of the 
week or early next week, but if nothing else major comes up, that could be 
our last RC before tagging 0.5.0 final.


On Friday, August 12, 2016 at 5:38:20 AM UTC-7, Tony Kelman wrote:
>
> I have just tagged and uploaded release candidate 2 for Julia version 
> 0.5.0. Binaries are available from
>
>
> https://s3.amazonaws.com/julialang/bin/linux/x64/0.5/julia-0.5.0-rc2-linux-x86_64.tar.gz
>  
>
> https://s3.amazonaws.com/julialang/bin/linux/x86/0.5/julia-0.5.0-rc2-linux-i686.tar.gz
>  
>
> https://s3.amazonaws.com/julialang/bin/osx/x64/0.5/julia-0.5.0-rc2-osx10.7+.dmg
>  
>
> https://s3.amazonaws.com/julialang/bin/winnt/x64/0.5/julia-0.5.0-rc2-win64.exe
>  
>
> https://s3.amazonaws.com/julialang/bin/winnt/x86/0.5/julia-0.5.0-rc2-win32.exe
>  
> https://s3.amazonaws.com/julialang/bin/checksums/julia-0.5.0-rc2.sha256 
> https://s3.amazonaws.com/julialang/bin/checksums/julia-0.5.0-rc2.md5 
> For gpg signatures (with this key http://julialang.org/juliareleases.asc) 
> of the Linux tar.gz binaries, append .asc to the filename.
>
> (arm binaries are taking a while to build, I will upload them later - we 
> will also put links to this release candidate on the web site soon)
>
> The primary thing this does not yet include that we do plan on getting 
> into the final 0.5.0 release is proxy support for the package manager. A 
> preliminary version of that has been merged to master but still has some 
> build system issues that need to be worked out. We will put out a release 
> candidate 3 next week that will hopefully have this resolved, along with 
> any other major bug fixes that happen by then. If all goes well and no 
> major blocking issues come up after that, RC3 could possibly be the last 
> release candidate and promoted to final, but we will see how it goes next 
> week. Follow the progress at 
> https://github.com/JuliaLang/julia/issues/17418 and please report any 
> issues you find.
>
> -Tony
>
>

Re: [julia-users] Make a histogram

2016-08-23 Thread Christof Stocker

If you know the categories then one thing you could do is think about it as a 
barplot

julia> UnicodePlots.barplot(a[:,1], a[:,2], symb = "▇")
  ┌┐ 
7 │▇▇ 4│ 
4 │▇▇▇ 2   │ 
9 │▇▇ 3│ 
   10 │▇▇▇ 1   │ 
2 │▇ 5 │ 
3 │▇▇▇ 1   │ 
5 │▇▇▇ 1   │ 
8 │▇▇▇ 1   │ 
6 │▇▇▇ 1   │ 
1 │▇▇▇ 1   │ 
  └┘ 

> On 23 Aug 2016, at 16:14, Ahmed Mazari  wrote:
> 
> Hello, 
> l have this matrix where the first column represents different values and 
> second column represents the number of occurences of each value. How can plot 
> a histogram x-axis : the different values, y-axis : the number of occurences.
> 
>
> 10x2 Array{Int64,2}:
>   7  4
>   4  2
>   9  3
>  10  1
>   2  5
>   3  1
>   5  1
>   8  1
>   6  1
>   1  1
> 
> 
> 
> Thank you

[julia-users] Make a histogram

2016-08-23 Thread Ahmed Mazari

Hello, 
l have this matrix where the first column represents different values and 
second column represents the number of occurences of each value. How can 
plot a histogram x-axis : the different values, y-axis : the number of 
occurences.


10x2 Array{Int64,2}:
  7  4
  4  2
  9  3
 10  1
  2  5
  3  1
  5  1
  8  1
  6  1
  1  1



Thank you

Re: [julia-users] { } vector syntax is discontinued?

2016-08-23 Thread Scott T

And again at lines 30 and 40 in that file.

On Tuesday, 23 August 2016 14:11:44 UTC+1, Scott T wrote:
>
> Looks like like 5 uses the old syntax:
>
> flag = Sundials.CVodeSetUserData(mem, {f,r,d,p})
>
> Try:
>
> flag = Sundials.CVodeSetUserData(mem, [f,r,d,p])
>
>
> On Tuesday, 23 August 2016 14:06:24 UTC+1, Simon Frost wrote:
>>
>> Thanks for the info; it still isn't clear to me how the (generic) call to 
>> this function should be changed:
>>
>> function cvode{f,r,T}(::Type{f},::Type{r},d::Array{Int64},p::Vector{T}, 
>> y0::Vector{Float64}, t::Vector{Float64}; reltol::Float64=1e-4, abstol
>> ::Float64=1e-6)
>>
>> (from https://github.com/sdwfrost/PDMP.jl/blob/master/src/cvode.jl)
>>
>> On Monday, August 22, 2016 at 10:19:14 AM UTC+1, Mauro wrote:
>>>
>>> It used to mean Any[], but not anymore (so `Any[]` is the new syntax). 
>>> It was still usable in 0.4 with a deprecation warning, now in 0.5 an 
>>> error is thrown.  It will get a new meaning in the 0.6 release, but it 
>>> is not decided for what yet. See e.g.: 
>>> https://github.com/JuliaLang/julia/issues/8470 
>>>
>>> On Mon, 2016-08-22 at 11:13, Simon Frost  wrote: 
>>> > Dear All, 
>>> > 
>>> > Apologies if this is mentioned somewhere, but I couldn't find the 
>>> answer in 
>>> > various searches. What does '{ } vector syntax is discontinued' mean, 
>>> and 
>>> > what is the new syntax? 
>>> > 
>>> > Best 
>>> > Simon 
>>>
>>

Re: [julia-users] { } vector syntax is discontinued?

2016-08-23 Thread Scott T

Looks like like 5 uses the old syntax:

flag = Sundials.CVodeSetUserData(mem, {f,r,d,p})

Try:

flag = Sundials.CVodeSetUserData(mem, [f,r,d,p])


On Tuesday, 23 August 2016 14:06:24 UTC+1, Simon Frost wrote:
>
> Thanks for the info; it still isn't clear to me how the (generic) call to 
> this function should be changed:
>
> function cvode{f,r,T}(::Type{f},::Type{r},d::Array{Int64},p::Vector{T}, y0
> ::Vector{Float64}, t::Vector{Float64}; reltol::Float64=1e-4, abstol
> ::Float64=1e-6)
>
> (from https://github.com/sdwfrost/PDMP.jl/blob/master/src/cvode.jl)
>
> On Monday, August 22, 2016 at 10:19:14 AM UTC+1, Mauro wrote:
>>
>> It used to mean Any[], but not anymore (so `Any[]` is the new syntax). 
>> It was still usable in 0.4 with a deprecation warning, now in 0.5 an 
>> error is thrown.  It will get a new meaning in the 0.6 release, but it 
>> is not decided for what yet. See e.g.: 
>> https://github.com/JuliaLang/julia/issues/8470 
>>
>> On Mon, 2016-08-22 at 11:13, Simon Frost  wrote: 
>> > Dear All, 
>> > 
>> > Apologies if this is mentioned somewhere, but I couldn't find the 
>> answer in 
>> > various searches. What does '{ } vector syntax is discontinued' mean, 
>> and 
>> > what is the new syntax? 
>> > 
>> > Best 
>> > Simon 
>>
>

Re: [julia-users] { } vector syntax is discontinued?

2016-08-23 Thread Simon Frost

Thanks for the info; it still isn't clear to me how the (generic) call to 
this function should be changed:

function cvode{f,r,T}(::Type{f},::Type{r},d::Array{Int64},p::Vector{T}, y0
::Vector{Float64}, t::Vector{Float64}; reltol::Float64=1e-4, abstol::Float64
=1e-6)

(from https://github.com/sdwfrost/PDMP.jl/blob/master/src/cvode.jl)

On Monday, August 22, 2016 at 10:19:14 AM UTC+1, Mauro wrote:
>
> It used to mean Any[], but not anymore (so `Any[]` is the new syntax). 
> It was still usable in 0.4 with a deprecation warning, now in 0.5 an 
> error is thrown.  It will get a new meaning in the 0.6 release, but it 
> is not decided for what yet. See e.g.: 
> https://github.com/JuliaLang/julia/issues/8470 
>
> On Mon, 2016-08-22 at 11:13, Simon Frost  
> wrote: 
> > Dear All, 
> > 
> > Apologies if this is mentioned somewhere, but I couldn't find the answer 
> in 
> > various searches. What does '{ } vector syntax is discontinued' mean, 
> and 
> > what is the new syntax? 
> > 
> > Best 
> > Simon 
>

[julia-users] Re: Distributions.jl : generating samples from stable distributions

2016-08-23 Thread Mirmu

Thx a lot !



Le lundi 22 août 2016 23:19:11 UTC+2, Rock Pereira a écrit :
>
> RCall is a simple two-step process:
>
>1. Write the R script inside Julia's R macrostrings
>2. Copy the objects in R as objects in Julia
>
> The documentation is just one page. 
> http://juliastats.github.io/RCall.jl/latest/gettingstarted/
>
> R has a massive collection in its Distributions Task View 
> http://lib.stat.cmu.edu/R/CRAN/web/views/Distributions.html
> Search (press F3) for 'stable' to find other packages.
>
> If you're dealing only with draws from the Levy distribution (and not the 
> whole family of stable distributions) 
> you can do it in Julia: http://distributionsjl.readthedocs.io/en/latest/
>
> using Distributions
> x = rand(Levy(u, c), numSamples)
>

Re: [julia-users] Proposed way of doing Enums

2016-08-23 Thread Stefan Karpinski

The current behavior was chosen because it allows you to put the enum in a
module or not. I agree that it's often nice to do so. One issue is that the
module name and the enum name "want" to be the same, which doesn't work
well, so you'd need to provide both an inner enum name and an outer module
name.

On Tue, Aug 23, 2016 at 8:50 AM, Paul Sorensen  wrote:

> The following code is my idea for doing enums in julia, I tried pasting
> the code but google groups breaks it:
> http://pastebin.com/Vxw0KdmC
> Let me know what you think. Is it a good idea?
>
>
> 
>
>

Re: [julia-users] Proposed solution for writing Enums

2016-08-23 Thread Stefan Karpinski

Oh, I see that you have:
https://groups.google.com/forum/#!topic/julia-users/fgzVlbGcw-o.

On Tue, Aug 23, 2016 at 8:55 AM, Stefan Karpinski 
wrote:

> The formatting on that came out pretty garbled. Can you repost with line
> breaks and such?
>
> On Mon, Aug 22, 2016 at 5:03 PM, Paul Sorensen  wrote:
>
>> The following is my idea of writing enums that are better than the macro
>> because they give you a  typesafe way of passing them to a
>> functionbaremodule EnumNameimmutable enumnamex::UInt8end
>> const Value_A = enumname(0)const Value_B = enumname(1)end# usage
>> examplebaremodule Colorimmutable colorx::UInt8endconst
>> Red = color(1)const Green = color(2)const Blue = color(3)const
>> White = color(4)const Black = color(5)endfunction
>> testColor(c::Color.color)println("A color was
>> passed")endtestColor(Color.Red)
>>
>
>

Re: [julia-users] Proposed solution for writing Enums

2016-08-23 Thread Stefan Karpinski

The formatting on that came out pretty garbled. Can you repost with line
breaks and such?

On Mon, Aug 22, 2016 at 5:03 PM, Paul Sorensen  wrote:

> The following is my idea of writing enums that are better than the macro
> because they give you a  typesafe way of passing them to a
> functionbaremodule EnumNameimmutable enumnamex::UInt8end
> const Value_A = enumname(0)const Value_B = enumname(1)end# usage
> examplebaremodule Colorimmutable colorx::UInt8endconst
> Red = color(1)const Green = color(2)const Blue = color(3)const
> White = color(4)const Black = color(5)endfunction
> testColor(c::Color.color)println("A color was
> passed")endtestColor(Color.Red)
>

Re: [julia-users] Re: Unexpected slowdown

2016-08-23 Thread Stefan Karpinski

You might want to check if a*a > n instead since multiplication is much
cheaper than sqrt.

On Mon, Aug 22, 2016 at 5:22 PM, Taylor Pospisil  wrote:

> It's memory allocation.  If you don't make the whole array and just break
> out of the loop early you can get it about 50x faster on my machine.  Also
> I took the liberty of fixing a bug; you should check for <= sqrt(n).
>
> function a()
> pl = [2]
> n = 3
> ct = 1
> while ct < 10001
> isnprime = true
> for a in pl
> if n % a == 0
> isnprime = false
> break
> end
> if a > sqrt(n)
> break
> end
> end
> if isnprime
> push!(pl,n)
> ct += 1
> end
> n += 2
> end
> return pl
> end
>
>
>
> On Monday, August 22, 2016 at 4:58:30 PM UTC-4, Achu wrote:
>
>> I have a simple piece of code that finds me 10001 prime numbers.
>>
>> function a()
>> pl=[2]
>> n=3
>> ct=1
>> while(ct<10001)
>> isnprime=true
>> for a in pl
>> if n%a==0
>> isnprime=false
>> break
>> end
>> end
>> if isnprime
>> push!(pl,n)
>> ct+=1
>> end
>> n+=2
>> end
>> return pl
>> end
>>
>> When I tweaked the code to check only prime factors less than the sqrt of
>> the number, it slowed it down by a factor of 3.
>>
>> function a()
>> pl=[2]
>> n=3
>> ct=1
>> while(ct<10001)
>> isnprime=true
>> for a in pl[pl.> if n%a==0
>> isnprime=false
>> break
>> end
>> end
>> if isnprime
>> push!(pl,n)
>> ct+=1
>> end
>> n+=2
>> end
>> return pl
>> end
>>
>> Why is that?
>>
>>

Re: [julia-users] Invalid history file (~/.julia_history) format

2016-08-23 Thread Stefan Karpinski

The notion of what HOME is on Windows is a bit confusing and ambiguous.

On Tue, Aug 23, 2016 at 8:51 AM, Stefan Karpinski 
wrote:

> That's strange. Did it create a ~/.julia_history file after you deleted
> the old one? If so, what's in it?
>
> I wonder if the ~/.julia_history file you deleted was not the one that
> Julia's looking at.
>
>
> On Tue, Aug 23, 2016 at 8:10 AM, Andy Dobson 
> wrote:
>
>> Hi All,
>>
>> This morning when starting Julia 0.4.3 (which I've been using daily since
>> February) I received this error message :
>> -
>> ERROR: Invalid history file (~/.julia_history) format:
>> If you have a history file left over from an older version of Julia,
>> try renaming or deleting it.
>> Invalid character: '#' at line 465034
>>  in error at error.jl:22
>> -
>>
>> A thread on this site ("PSA: new ~/.julia_history format") suggested deleting
>> the julia_history file. I tried this, and it did not work. Next I
>> uninstalled Julia and re-installed the latest (0.4.6) version. The error
>> message is the same.
>>
>> Can anybody suggest a solution? I'm running on Windows 7 Enterprise.
>>
>> Thanks
>>
>> Andy
>>
>>
>

Re: [julia-users] Invalid history file (~/.julia_history) format

2016-08-23 Thread Stefan Karpinski

That's strange. Did it create a ~/.julia_history file after you deleted the
old one? If so, what's in it?

I wonder if the ~/.julia_history file you deleted was not the one that
Julia's looking at.

On Tue, Aug 23, 2016 at 8:10 AM, Andy Dobson 
wrote:

> Hi All,
>
> This morning when starting Julia 0.4.3 (which I've been using daily since
> February) I received this error message :
> -
> ERROR: Invalid history file (~/.julia_history) format:
> If you have a history file left over from an older version of Julia,
> try renaming or deleting it.
> Invalid character: '#' at line 465034
>  in error at error.jl:22
> -
>
> A thread on this site ("PSA: new ~/.julia_history format") suggested deleting
> the julia_history file. I tried this, and it did not work. Next I
> uninstalled Julia and re-installed the latest (0.4.6) version. The error
> message is the same.
>
> Can anybody suggest a solution? I'm running on Windows 7 Enterprise.
>
> Thanks
>
> Andy
>
>

[julia-users] Proposed way of doing Enums

2016-08-23 Thread Paul Sorensen

The following code is my idea for doing enums in julia, I tried pasting the 
code but google groups breaks it:
http://pastebin.com/Vxw0KdmC
Let me know what you think. Is it a good idea?

Re: [julia-users] Re: Why aren't multiple const definitions allowed on a line?

2016-08-23 Thread Stefan Karpinski

These syntaxes should be more uniform:
https://github.com/JuliaLang/julia/issues/18197.

On Tue, Aug 23, 2016 at 12:59 AM, 'Greg Plowman' via julia-users <
julia-users@googlegroups.com> wrote:

> global const u = 7, v = 11, w = 13
> seems to work.
>
>

[julia-users] Re: Unexpected slowdown

2016-08-23 Thread Taylor Pospisil

It's memory allocation.  If you don't make the whole array and just break 
out of the loop early you can get it about 50x faster on my machine.  Also 
I took the liberty of fixing a bug; you should check for <= sqrt(n).

function a()
pl = [2]
n = 3
ct = 1
while ct < 10001
isnprime = true
for a in pl
if n % a == 0
isnprime = false
break
end
if a > sqrt(n)
break
end
end
if isnprime
push!(pl,n)
ct += 1
end
n += 2
end
return pl
end



On Monday, August 22, 2016 at 4:58:30 PM UTC-4, Achu wrote:
>
> I have a simple piece of code that finds me 10001 prime numbers. 
>
> function a()
> pl=[2]
> n=3
> ct=1
> while(ct<10001)
> isnprime=true
> for a in pl  
> if n%a==0
> isnprime=false
> break
> end
> end
> if isnprime
> push!(pl,n)
> ct+=1
> end
> n+=2
> end
> return pl
> end
>
> When I tweaked the code to check only prime factors less than the sqrt of 
> the number, it slowed it down by a factor of 3.
>
> function a()
> pl=[2]
> n=3
> ct=1
> while(ct<10001)
> isnprime=true
> for a in pl[pl. if n%a==0
> isnprime=false
> break
> end
> end
> if isnprime
> push!(pl,n)
> ct+=1
> end
> n+=2
> end
> return pl
> end
>
> Why is that?
>
>

[julia-users] Questions regarding Julia for general purpose programming (strings, modules, dispatch, inheritance)

2016-08-23 Thread JColn

Hello,

I'm looking at Julia for general purpose programming and things look good 
so far. However, I want to see if I can elicit feedback from those that 
have ventured   deeper into larger projects before moving further. Below 
are questions regarding areas of concern I've seen cited and I'm wondering 
if these issues are real. If anyone can provide experience I would be much 
obliged( My frame of reference is python).

1. Strings. Are they faster in 0.5 (python speed or better). How about ease 
of use?

2. Inheritance- Any issues with not being able to  do concrete inheritance?

3. Module system and dispatch- Lots of  Ink has been spilled on this, and I 
understand that organizing multi dispatch code is an open research 
question. However, it seems there are legitimate concerns about name 
clashes,ease of use etc I've also perused some open issues, but don't see a 
fundamental redesign. How does Julia fare for larger general projects 
compared to say python or java>

4. Multi dispatch. How do you find its utility for non numerical code?

Thanks!

[julia-users] Re: Using Interpolations.jl How to define the behavior when out of bounds?

2016-08-23 Thread Carlo Galli

Thanks! Very helpful.

Looks like however evaluating the extrapolation object below on a Array ( 
itp = extrapolate(interpolate(...), NaN)[-3.5,-3.4] for example ) throws an 
error, while this works well with interpolation objects.

A solution would be to use a comprehension
[extrapolate(interpolate(...), NaN)[x] for x in Array]

but for some reason this becomes a type Any array, so it requires
Array{Float64}([extrapolate(interpolate(...), NaN)[x] for x in Array])

Have I missed something, or this is just the way extrapolate works? 
Apologies if this has already been posted somewhere, am quite new to Julia 
and sometimes I find that documentation seems not too easy to access.

Thanks again!

On Wednesday, January 27, 2016 at 6:15:08 AM UTC, Tomas Lycken wrote:
>
> Yes, that's the correct way to specify the extrapolation behavior, but you 
> don't seem to use it afterwards; your last two lines refer to Uinterp and 
> Vinterp, rather than Uextrap and Vextrap. To get the desired behavior for 
> OOB indices, you must index into the result of extrapolate(...). 
>
> If you want to avoid this, you can of course do both interpolation and 
> extrapolation in one step:
>
> itp = extrapolate(interpolate(...), NaN)
> itp[-3.5] # NaN
>
> // T 
>
>

[julia-users] Proposed solution for writing Enums

2016-08-23 Thread Paul Sorensen

The following is my idea of writing enums that are better than the macro 
because they give you a  typesafe way of passing them to a 
functionbaremodule EnumNameimmutable enumnamex::UInt8end
const Value_A = enumname(0)const Value_B = enumname(1)end# usage 
examplebaremodule Colorimmutable colorx::UInt8endconst 
Red = color(1)const Green = color(2)const Blue = color(3)const 
White = color(4)const Black = color(5)endfunction 
testColor(c::Color.color)println("A color was 
passed")endtestColor(Color.Red)

[julia-users] Invalid history file (~/.julia_history) format

2016-08-23 Thread Andy Dobson

Hi All, 

This morning when starting Julia 0.4.3 (which I've been using daily since 
February) I received this error message : 
-
ERROR: Invalid history file (~/.julia_history) format: 
If you have a history file left over from an older version of Julia, 
try renaming or deleting it. 
Invalid character: '#' at line 465034 
 in error at error.jl:22 
- 

A thread on this site ("PSA: new ~/.julia_history format") suggested deleting 
the julia_history file. I tried this, and it did not work. Next I 
uninstalled Julia and re-installed the latest (0.4.6) version. The error 
message is the same.   

Can anybody suggest a solution? I'm running on Windows 7 Enterprise. 

Thanks 

Andy

[julia-users] Re: ANN: Documenter.jl 0.3

2016-08-23 Thread Michael Hatherly

Just an extra note to add: we've set up a Gitter chat room [1] for the 
JuliaDocs packages, so if anyone has questions that aren't really "issues", 
but rather just usage questions or requests for help when setting up your 
package docs, then feel free to ask them there.

[1]: https://gitter.im/juliadocs/users

On Friday, 19 August 2016 23:07:55 UTC+2, Morten Piibeleht wrote:
>
> We are happy to announce version 0.3 of Documenter.jl 
>  – a package for building the 
> documentation of other Julia packages. Documentation is available at 
> https://juliadocs.github.io/Documenter.jl/stable/.
>
>
> Compared to the 0.2-branch there should be no visible changes to the user 
> other than some resolved bugs. However, there have been some changes to the 
> code base so please don’t hesitate to report any issues on the issue 
> tracker .
>
>
> The largest bit of news is that experimental *native HTML output* is now 
> available as an option [*]. This means that instead of relying on MkDocs, 
> Documenter.jl is able to produce its own complete static HTML site. The 
> generated site’s style borrows heavily from the Julia manual and is already 
> being used to build Documenter’s own documentation.
>
>
> We would like to encourage everyone to give the HTML output a try 
> (including just browsing) and send feedback so that we could iron out any 
> remaining issues and improve user experience. See the documentation 
> 
>  for 
> more information on how to enable HTML output on your own repository. There 
> is the meta-issue #212 
>  where we are 
> tracking future improvements of this feature.
>
>
> Finally, a big thanks to everyone who have been testing the package and 
> submitting issues so far. Keep ‘em coming!
>
>
> Cheers, 
> Morten & Mike
>
>
> [*] Developed as part of Morten’s Google Summer of Code project 
> 
> .
>

Re: [julia-users] Re: ANN: Documenter.jl 0.3

2016-08-23 Thread Michael Hatherly

> Maybe it is a bit redundant to have the base module name before all the 
type and function names?

That was done to avoid getting two docstrings for objects with the same 
name but from different modules appearing together, which, though probably 
an unlikely situation, would be a bit confusing to readers. Perhaps a 
middle ground would be to only print the parent module name, rather than 
the entire module "path".

On Monday, 22 August 2016 22:30:39 UTC+2, Kristoffer Carlsson wrote:
>
> Just from looking at the generated docs for the Documenter package I would 
> say that I strongly like the layout and "feel" of the HTML output. Much 
> better than what I have seen from using the Mkdocs. 
>
> Maybe it is a bit redundant to have the base module name before all the 
> type and function names?
>
> On Monday, August 22, 2016 at 10:23:35 PM UTC+2, Michael Hatherly wrote:
>>
>> Yes, Morten's additions to the package over the summer have really be 
>> great!
>>
>> I'd also like to re-emphasise his call for feedback and suggestions 
>> (there's already been lots, but we're always looking for more) on the new 
>> HTML output,
>> and the package in general. We want to end up with a documentation 
>> solution for Julia that any package author can simply pick up and use 
>> without having
>> to worry about anything other than writing great content for their docs. 
>> It's definitely not there just yet, but we'll get there soon enough I'm 
>> sure.
>>
>> On Monday, 22 August 2016 18:58:43 UTC+2, David Anthoff wrote:
>>>
>>> Yes, this is really cool, much appreciated!!
>>>
>>>  
>>>
>>> *From:* julia...@googlegroups.com [mailto:julia...@googlegroups.com] *On 
>>> Behalf Of *Christoph Ortner
>>> *Sent:* Saturday, August 20, 2016 6:56 PM
>>> *To:* julia-users 
>>> *Subject:* [julia-users] Re: ANN: Documenter.jl 0.3
>>>
>>>  
>>>
>>> this is really nice; thank you for putting this package together.
>>>
>>> On Saturday, 20 August 2016 12:36:21 UTC+1, Morten Piibeleht wrote:
>>>
>>> On Saturday, August 20, 2016 at 2:18:37 AM UTC+3, Christoph Ortner wrote:
>>>
>>> I want to give this a try but I can't find the example of HTML output, 
>>> which is supposed to be in test/html? 
>>>
>>>  
>>>
>>> Thank you. 
>>>
>>>  
>>>
>>> I apologize, the linked docs are a bit outdated and will be updated 
>>> shortly. As was already mentioned, since Documenter uses the HTML output 
>>> for its own docs, `docs/make.jl` is the best example.
>>>
>>>  
>>>
>>> `mkdocs.yml` has been dropped indeed. Instead the site's structure and 
>>> title have to be defined in `make.jl`, via the (currently undocumented) 
>>> `sitename` and `pages` options.
>>>
>>>  
>>>
>>> The HTML site gets built into `build/` directly, where we normally have 
>>> outputted the processed Markdown files (with the filenames being translated 
>>> as `path/file.md` -> `path/file.html`).
>>>
>>>  
>>>
>>> On Saturday, August 20, 2016 at 2:53:23 AM UTC+3, Stefan Karpinski wrote:
>>>
>>> On Fri, Aug 19, 2016 at 5:07 PM, Morten Piibeleht >> > wrote:
>>>
>>> [*] Developed as part of Morten’s Google Summer of Code project 
>>> 
>>> .
>>>
>>> Since I think that page is private, here's the description of the 
>>> project:
>>>
>>>  
>>>
>>> Yes, the correct link should have been 
>>> https://summerofcode.withgoogle.com/projects/#5046486001778688 (but it 
>>> basically only contains the description Stefan already posted).
>>>
>>>

[julia-users] Re: help with deepcopy_internal

2016-08-23 Thread Tommy Hofmann

Why do you think that deepcopy works on SelfReferential without defining 
deepcopy_internal? Line 8 of deepcopy.jl is: deepcopy(x) = 
deepcopy_internal(x, ObjectIdDict())

On Tuesday, August 23, 2016 at 10:52:35 AM UTC+2, Chris Stook wrote:
>
> I created this simple example to try to understand deepcopy_internal.
>
> type SelfReferential
>   obj::SelfReferential
>
>   SelfReferential() = (x = new(); x.obj = x)
> end
>
> function deepcopy_internal(sr::SelfReferential, oidd::ObjectIdDict)
> #  if haskey(oidd,sr)
> #return oidd[sr]
> #  else
> new_obj = deepcopy_internal(sr,oidd)
> new_sr = sr(new_obj)
> oidd[sr] = new_sr
> return new_sr
> #  end
> end
>
> sr = SelfReferential()
> deepcopy_sr = deepcopy(sr)
>
> This works, but deepcopy works on SelfReferential without defining 
> deepcopy_internal, so this isn't a good 
> example.  
>
> How should this be modified so deepcopy_internal is required?
>
> Are the commented out lines of code necessary?
>
> Thanks,
> Chris
>
>

[julia-users] help with deepcopy_internal

2016-08-23 Thread Chris Stook

I created this simple example to try to understand deepcopy_internal.

type SelfReferential
  obj::SelfReferential

  SelfReferential() = (x = new(); x.obj = x)
end

function deepcopy_internal(sr::SelfReferential, oidd::ObjectIdDict)
#  if haskey(oidd,sr)
#return oidd[sr]
#  else
new_obj = deepcopy_internal(sr,oidd)
new_sr = sr(new_obj)
oidd[sr] = new_sr
return new_sr
#  end
end

sr = SelfReferential()
deepcopy_sr = deepcopy(sr)

This works, but deepcopy works on SelfReferential without defining 
deepcopy_internal, so this isn't a good 
example.  

How should this be modified so deepcopy_internal is required?

Are the commented out lines of code necessary?

Thanks,
Chris

[julia-users] Re: JupyterLab

2016-08-23 Thread Michael Borregaard

They have updated to 0.2. It works fine for me, I just had to get used to 
that to start a julia notebook, I have to first open a new Notebook that 
opens with the Python2 kernel, and the 'switch kernel'.

57 matches

Mail list logo