[julia-users] Re: Fast, robust predicates with Julia

[Toivo Henningsson]

On Thursday, 15 May 2014 09:36:06 UTC+2, Ariel Keselman wrote:
>
> they are MIT licensed, no need for permission :)
>
> how efficient is Voroni construction using conic hulls, I think Qhull 
> which uses convex hulls is way slower than what I plan with the algorithms 
> described in here: http://arxiv.org/pdf/0901.4107v3.pdf
>

Looking at the paper more carefully, I see that you only need to do 
insertion of generators and not removal.
I believe that the incremental insertion method that I have implemented is 
similar but has the chance to be somewhat more efficient. It falls out 
pretty naturally from thinking about convex/conic hulls.

Both methods insert one generator at a time. The method in the paper does 
this by first splitting the facet that contains the generator, and then 
flipping neighbouring pairs of facets until Delaunayhood is restored.

The method that I have implemented first finds one facet in the hull that 
is dominated by the generator (that the generator is in front of). This 
might be the facet that contains the generator as seen in the Delaunay 
triangulation, or it might be one of the other facets that will be 
replaced. It then finds the whole cluster of dominated facets, which is 
connected. It finally removes the dominated facets and then forms the new 
facets by extruding the edges between removed and unremoved facets to the 
newly inserted generator.
The potential efficiency increase comes from two places:

   - Fewer predicates to test. We only need to test once for each facet 
   whether it is dominated (in-circle test). No additional predicates to test 
   if an edge is flippable, and if so in which way.
   - No intermediate facets are created when inserting a generator.
   
The thing that becomes slightly more complex is reconnecting the new facets 
with their neighbours, but that only means walking through a few facets to 
find the right connection. The end result is of course the same after a 
generator has been inserted.
Now I'm not saying that my current implementation is very efficient :) But 
I think that the method might be of interest to you.

[julia-users] DataFrames, no method push!

[Travis Porco]

This from Julia 0.2.1 on MacOSX 10.7.5, using the DataFrames package, 
just now updated before the following attemp to execute example code from 
the manual:

Version 0.2.1 (2014-02-11 06:30 UTC)
 _/ |\__'_|_|_|\__'_|  |  Official http://julialang.org/ release
|__/   |  x86_64-apple-darwin12.5.0

julia> using DataFrames

julia> df = DataFrame()
0x0 DataFrame:

julia> df[:A] = 1:8
ERROR: no method push!(Index,Symbol)
 in insert_single_column! at 
/Users/travis/.julia/DataFrames/src/dataframe.jl:480
 in setindex! at /Users/travis/.julia/DataFrames/src/dataframe.jl:525

julia> df[:B] = ["M", "F", "F", "M", "F", "M", "M", "F"]
ERROR: no method push!(Index,Symbol)
 in insert_single_column! at 
/Users/travis/.julia/DataFrames/src/dataframe.jl:480
 in setindex! at /Users/travis/.julia/DataFrames/src/dataframe.jl:525

But stranger, to me:

julia> push!
push! (generic function with 12 methods)

Etc. I googled "no method push!" julia
but I didn't see anything that seemed relevant to my beginner's mind, and I 
searched 
this group as well.

Also, the same problem happened just before updating (the update was a 
failed attempt to fix it).

Is it fixable and worth fixing, or should I just wait for the official 0.3? 

Thanks kindly.

[julia-users] DataFrames, no method push!

[Travis Porco]

Hello--sorry to bug you all.
This from Julia 0.2.0 on MacOSX 10.7.5, using the DataFrames package, 
just now updated before the following attemp to execute example code from 
the manual:
Version 0.2.0 (2013-11-16 23:44 UTC)
Official http://julialang.org release
x86_64-apple-darwin12.5.0

julia> using DataFrames

julia> df = DataFrame()
0x0 DataFrame:

julia> df[:A] = 1:8
ERROR: no method push!(Index,Symbol)
 in insert_single_column! at 
/Users/travis/.julia/DataFrames/src/dataframe.jl:480
 in setindex! at /Users/travis/.julia/DataFrames/src/dataframe.jl:525

julia> df[:B] = ["M", "F", "F", "M", "F", "M", "M", "F"]
ERROR: no method push!(Index,Symbol)
 in insert_single_column! at 
/Users/travis/.julia/DataFrames/src/dataframe.jl:480
 in setindex! at /Users/travis/.julia/DataFrames/src/dataframe.jl:525

But stranger, to me:

julia> push!
push! (generic function with 12 methods)

Etc. I googled *"no method push!" julia*
but I didn't see anything that seemed relevant to my beginner's mind, and I 
searched 
this group as well.

Also, the same problem happened just before updating (the update was a 
failed attempt to fix it).

Is it fixable and worth fixing, or should I just wait for the official 0.3? 

Thanks kindly.

Re: [julia-users] UnionType -> tuple of DataType(s)

[Tony Fong]

Fantastic. Thank you all. 

Re: [julia-users] Re: Design patterns for an API

[Isaiah Norton]

Github provides a web-based issue tracker tool where many of the
discussions have occurred and may be commented on:

https://github.com/JuliaLang/ODE.jl/issues


On Fri, May 16, 2014 at 10:26 PM,  wrote:

> I am new to GitHub. Is there some kind of forum, or do you mean to create
> a new file with my thoughts on it ?
>
>
> On Friday, May 16, 2014 11:26:21 PM UTC+2, Alex wrote:
>
>>  so if you have a github account it might be good to post your thoughts
>> there as well.
>>
>

[julia-users] Re: Design patterns for an API

[francois . fayard]

I am new to GitHub. Is there some kind of forum, or do you mean to create a 
new file with my thoughts on it ?

On Friday, May 16, 2014 11:26:21 PM UTC+2, Alex wrote:
>
>  so if you have a github account it might be good to post your thoughts 
> there as well. 
>

Re: [julia-users] Re: Execution order of nested iterations in comprehensions vs for loops

[Stefan Karpinski]

It would be confusing because it's at odds with all the mathematical literature 
in existence.

> On May 16, 2014, at 5:21 PM, francois.fay...@gmail.com wrote:
> 
> Why would it be confusing ?
> 
> I've seen as many math people (with no knowledge of memory ordering in 
> programming languages) giving matrices in row major order and giving matrices 
> in column major order.
> 
>> On Friday, May 16, 2014 11:10:19 PM UTC+2, Stefan Karpinski wrote:
>> It's less about the array ordering and more about the fact that 
>> mathematically the row index comes before the column index and doing it the 
>> other way would be very confusing. It's a shame these don't match, but 
>> there's not much to do about it.

Re: [julia-users] fill! with copies

[Stefan Karpinski]

When you write fill!(arr, ChannVals()) you are asking to fill arr with the
one value that is the result of evaluating ChannVals() once. Doing anything
else would be bizarre. We could have a version of fill! that takes a thunk
so you could write

fill!(arr) do
  ChannVals()
end


That would have the desired effect as well, but it seems to me that using a
comprehension is just as easy in that case.


On Fri, May 16, 2014 at 4:21 PM, Ivar Nesje  wrote:

> @Jameson They are immutable, but they contain references to mutable
> arrays, and all the immutable types will reference the same arrays. That
> way you would not just need a copy but a deepcopy. That will probably be
> too much overhead for fill!(), and will be problematic if someone decided
> to fill! an array with some large structure.
>
> On the other hand, I think it would be reasonable for fill! to take a
> shallow copy of mutable types. Not sure what others think on that subject
> though.
>
> Ivar
>
> kl. 17:01:56 UTC+2 fredag 16. mai 2014 skrev Jameson følgende:
>>
>> Since they are immutable, fill! did exactly what you wanted
>>
>> On Friday, May 16, 2014, Tim Holy  wrote:
>>
>>> Try
>>>
>>> arr = [ChannVals() for i = 1:10]
>>>
>>> On Friday, May 16, 2014 01:27:18 AM Carlos Becker wrote:
>>> > Hello all,
>>> >
>>> > I wanted to create an array of an immutable type and initialize an
>>> empty
>>> > copy in each (with the default constructor).
>>> > I am wondering which is the best way to do it, so far:
>>> >
>>> >immutable ChannVals
>>> > taus::Vector{Float64}
>>> > alphas::Vector{Float64}
>>> >
>>> > ChannVals() = new( Float64[], Float64[] )
>>> >end
>>> >
>>> ># create 10 new instances
>>> >arr = ChannVals[ChannVals() for i=1:10]
>>> >
>>> >
>>> > Now, a neat but incorrect way is to do
>>> >
>>> >arr = Array( ChannVals, 10 )
>>> >fill!(allVals, ChannVals())
>>> >
>>> > because it will fill them with the same instance.
>>> > Is there a neat way, such as a fillwithcopies!() ?
>>> >
>>> >
>>> > Cheers.
>>>
>>

[julia-users] Re: Design patterns for an API

[francois . fayard]

Hi Alex,

I do have a GitHub account, and I'll post my ideas over there. Here are my 
thoughts :

- The solver need to be fast and for that, inlining is of paramount 
importance. I know that there is no way to inline F for the time being. Do 
we expect inlining on function argument in the near future of Julia ?
- It might be nice to have the general case : y^(n)(t) = F(t, y, y'(t), ... 
, y^(n-1)(t)). Even though nth-order equation can be reduced to first order 
equation, I've heard that some specific methods exists for n-th order 
equation. I need to check on this.
- I think that the options need to be more organized. I like how it is 
handled in the GSL. Basically, there are 2 main options :
  - How do you go from t, to t + dt : Euler, Explicit Runge-Kutta, etc...
  - How do you choose dt : Given by tspan, computed for a tolerance, 
Gving 2 identified objects is a nice way to stress that.

François



On Friday, May 16, 2014 11:26:21 PM UTC+2, Alex wrote:
>
> Hi François, 
>
> Nice to hear that you are interested in contributing to ODE.jl. Any input 
> is greatly appreciated! I guess you have also seen some of the open issues 
> discussing the API over at ODE.jl, so if you have a github account it might 
> be good to post your thoughts there as well. 
>
> Regarding the API I think we roughly came to the following consensus: 
> - there should be a "simple" API with solvers like you said, odeX(F, y0, 
> tspan; kwargs), where odeX denotes the method (say ode45 for an explicit 
> Runge-Kutta method using pair 4-5), F is the rhs of the ODE, tspan gives a 
> integration interval and kwargs are  keywords like tolerances etc. 
> - for more sophisticated control we will have an abstract type ODEProblem 
> from which more specific problems, like ExplicitODE or ImplicitODE, can be 
> derived and which will allow for providing additional information like 
> Jacobians and so on. The method will probably still be selected by the 
> function name and by using multiple dispatch the methods can "choose" which 
> problems they support. 
>
> I should add that most of this (maybe the second part more than the first 
> one) is still under debate and we are open for any suggestions. 
>
> Best, 
>
> Alex. 
>
>
>
> > Hi, 
> > 
> > 
> > I am starting to use Julia, and I would like to learn and contribute a 
> bit. As I have some experience in numerics I am thinking of contributing to 
> the ODE package. 
> > 
> > 
> > I've read the ideas for the API, and I believe that we can still improve 
> it. Usually, for this kind of solver, we could expect something such as : 
> > 
> > 
> > ode_solve( F, y_0, t_0:t_1; stepping_method; step_choice_method ) 
> > 
> > 
> > where the stepping_method could be : 
> > - Explicit Runge-Kutta 
> >   It is is that kind of method, we also need some parameters such as the 
> order of the method 
> > - other methods ... 
> > 
> > 
> > So how would you organise that ?My idea would be choosing SteppingMethod 
> as an abstract type, and ExplicitRungeKutta as a concrete subtype that has 
> different parameters. What do you think of that ? Is there a standard way 
> to pass options to a function ? 
> > 
> > 
> > I was thinking at looking at Gadfly to see how options are handled here. 
> Do you recommend another package worth checking ? 
> > 
> > 
> > Best regards, 
> > François 
>

[julia-users] Re: Design patterns for an API

[Alex]

Hi François,

Nice to hear that you are interested in contributing to ODE.jl. Any input is 
greatly appreciated! I guess you have also seen some of the open issues 
discussing the API over at ODE.jl, so if you have a github account it might be 
good to post your thoughts there as well.

Regarding the API I think we roughly came to the following consensus:
- there should be a "simple" API with solvers like you said, odeX(F, y0, tspan; 
kwargs), where odeX denotes the method (say ode45 for an explicit Runge-Kutta 
method using pair 4-5), F is the rhs of the ODE, tspan gives a integration 
interval and kwargs are  keywords like tolerances etc.
- for more sophisticated control we will have an abstract type ODEProblem from 
which more specific problems, like ExplicitODE or ImplicitODE, can be derived 
and which will allow for providing additional information like Jacobians and so 
on. The method will probably still be selected by the function name and by 
using multiple dispatch the methods can "choose" which problems they support.

I should add that most of this (maybe the second part more than the first one) 
is still under debate and we are open for any suggestions.

Best,

Alex.



> Hi,
> 
> 
> I am starting to use Julia, and I would like to learn and contribute a bit. 
> As I have some experience in numerics I am thinking of contributing to the 
> ODE package.
> 
> 
> I've read the ideas for the API, and I believe that we can still improve it. 
> Usually, for this kind of solver, we could expect something such as :
> 
> 
> ode_solve( F, y_0, t_0:t_1; stepping_method; step_choice_method )
> 
> 
> where the stepping_method could be :
> - Explicit Runge-Kutta
>   It is is that kind of method, we also need some parameters such as the 
> order of the method
> - other methods ...
> 
> 
> So how would you organise that ?My idea would be choosing SteppingMethod as 
> an abstract type, and ExplicitRungeKutta as a concrete subtype that has 
> different parameters. What do you think of that ? Is there a standard way to 
> pass options to a function ?
> 
> 
> I was thinking at looking at Gadfly to see how options are handled here. Do 
> you recommend another package worth checking ?
> 
> 
> Best regards,
> François

Re: [julia-users] Re: Execution order of nested iterations in comprehensions vs for loops

[francois . fayard]

Why would it be confusing ?

I've seen as many math people (with no knowledge of memory ordering in 
programming languages) giving matrices in row major order and giving 
matrices in column major order.

On Friday, May 16, 2014 11:10:19 PM UTC+2, Stefan Karpinski wrote:
>
> It's less about the array ordering and more about the fact that 
> mathematically the row index comes before the column index and doing it the 
> other way would be very confusing. It's a shame these don't match, but 
> there's not much to do about it.
>

Re: [julia-users] Re: Execution order of nested iterations in comprehensions vs for loops

[Peter Simon]

No big deal, just now noticed it, is all.  FWIW, I like the comprehension 
order better (inner = faster).  Although I also see François' point about 
the for loop nesting.

Thanks,
--Peter

On Friday, May 16, 2014 2:10:19 PM UTC-7, Stefan Karpinski wrote:
>
> It's less about the array ordering and more about the fact that 
> mathematically the row index comes before the column index and doing it the 
> other way would be very confusing. It's a shame these don't match, but 
> there's not much to do about it.
>
> On May 16, 2014, at 4:57 PM, francoi...@gmail.com  wrote:
>
> I am very new to Julia, but here is my guess :
> - for i = , j =
>   should be the same as
>   for i =
> for j =
>   It would be awkward to have something else.
> - For comprehensions, the order is the other way around because matrices 
> are stored in Julia in column order as in Fortran (and maybe Matlab) as 
> opposed to C. Therefore, ordering the comprehension that way make the 
> filling of the array cache-friendly.
>
> François
>
> On Friday, May 16, 2014 10:52:22 PM UTC+2, Peter Simon wrote:
>>
>> Comprehensions and for loops do not perform nested looping in the same 
>> order:
>>
>> julia> [begin println((i,j)); (i,j) end  for i = 1:3, j = 1:4]
>> (1,1)
>> (2,1)
>> (3,1)
>> (1,2)
>> (2,2)
>> (3,2)
>> (1,3)
>> (2,3)
>> (3,3)
>> (1,4)
>> (2,4)
>> (3,4)
>> 3x4 Array{(Int64,Int64),2}:
>>  (1,1)  (1,2)  (1,3)  (1,4)
>>  (2,1)  (2,2)  (2,3)  (2,4)
>>  (3,1)  (3,2)  (3,3)  (3,4)
>>
>>
>> julia> for i = 1:3, j=1:4
>>println((i,j))
>>end
>> (1,1)
>> (1,2)
>> (1,3)
>> (1,4)
>> (2,1)
>> (2,2)
>> (2,3)
>> (2,4)
>> (3,1)
>> (3,2)
>> (3,3)
>> (3,4)
>>
>>
>>
>> Just wondering what the rationale is for this difference.
>>
>> --Peter
>>
>

Re: [julia-users] Re: Execution order of nested iterations in comprehensions vs for loops

[Stefan Karpinski]

It's less about the array ordering and more about the fact that mathematically 
the row index comes before the column index and doing it the other way would be 
very confusing. It's a shame these don't match, but there's not much to do 
about it.

> On May 16, 2014, at 4:57 PM, francois.fay...@gmail.com wrote:
> 
> I am very new to Julia, but here is my guess :
> - for i = , j =
>   should be the same as
>   for i =
> for j =
>   It would be awkward to have something else.
> - For comprehensions, the order is the other way around because matrices are 
> stored in Julia in column order as in Fortran (and maybe Matlab) as opposed 
> to C. Therefore, ordering the comprehension that way make the filling of the 
> array cache-friendly.
> 
> François
> 
>> On Friday, May 16, 2014 10:52:22 PM UTC+2, Peter Simon wrote:
>> Comprehensions and for loops do not perform nested looping in the same order:
>> 
>> julia> [begin println((i,j)); (i,j) end  for i = 1:3, j = 1:4]
>> (1,1)
>> (2,1)
>> (3,1)
>> (1,2)
>> (2,2)
>> (3,2)
>> (1,3)
>> (2,3)
>> (3,3)
>> (1,4)
>> (2,4)
>> (3,4)
>> 3x4 Array{(Int64,Int64),2}:
>>  (1,1)  (1,2)  (1,3)  (1,4)
>>  (2,1)  (2,2)  (2,3)  (2,4)
>>  (3,1)  (3,2)  (3,3)  (3,4)
>> 
>> 
>> julia> for i = 1:3, j=1:4
>>println((i,j))
>>end
>> (1,1)
>> (1,2)
>> (1,3)
>> (1,4)
>> (2,1)
>> (2,2)
>> (2,3)
>> (2,4)
>> (3,1)
>> (3,2)
>> (3,3)
>> (3,4)
>> 
>> 
>> 
>> Just wondering what the rationale is for this difference.
>> 
>> --Peter

[julia-users] Re: Execution order of nested iterations in comprehensions vs for loops

[francois . fayard]

I am very new to Julia, but here is my guess :
- for i = , j =
  should be the same as
  for i =
for j =
  It would be awkward to have something else.
- For comprehensions, the order is the other way around because matrices 
are stored in Julia in column order as in Fortran (and maybe Matlab) as 
opposed to C. Therefore, ordering the comprehension that way make the 
filling of the array cache-friendly.

François

On Friday, May 16, 2014 10:52:22 PM UTC+2, Peter Simon wrote:
>
> Comprehensions and for loops do not perform nested looping in the same 
> order:
>
> julia> [begin println((i,j)); (i,j) end  for i = 1:3, j = 1:4]
> (1,1)
> (2,1)
> (3,1)
> (1,2)
> (2,2)
> (3,2)
> (1,3)
> (2,3)
> (3,3)
> (1,4)
> (2,4)
> (3,4)
> 3x4 Array{(Int64,Int64),2}:
>  (1,1)  (1,2)  (1,3)  (1,4)
>  (2,1)  (2,2)  (2,3)  (2,4)
>  (3,1)  (3,2)  (3,3)  (3,4)
>
>
> julia> for i = 1:3, j=1:4
>println((i,j))
>end
> (1,1)
> (1,2)
> (1,3)
> (1,4)
> (2,1)
> (2,2)
> (2,3)
> (2,4)
> (3,1)
> (3,2)
> (3,3)
> (3,4)
>
>
>
> Just wondering what the rationale is for this difference.
>
> --Peter
>

[julia-users] Execution order of nested iterations in comprehensions vs for loops

[Peter Simon]

Comprehensions and for loops do not perform nested looping in the same 
order:

julia> [begin println((i,j)); (i,j) end  for i = 1:3, j = 1:4]
(1,1)
(2,1)
(3,1)
(1,2)
(2,2)
(3,2)
(1,3)
(2,3)
(3,3)
(1,4)
(2,4)
(3,4)
3x4 Array{(Int64,Int64),2}:
 (1,1)  (1,2)  (1,3)  (1,4)
 (2,1)  (2,2)  (2,3)  (2,4)
 (3,1)  (3,2)  (3,3)  (3,4)


julia> for i = 1:3, j=1:4
   println((i,j))
   end
(1,1)
(1,2)
(1,3)
(1,4)
(2,1)
(2,2)
(2,3)
(2,4)
(3,1)
(3,2)
(3,3)
(3,4)



Just wondering what the rationale is for this difference.

--Peter

Re: [julia-users] fill! with copies

[Ivar Nesje]

@Jameson They are immutable, but they contain references to mutable arrays, 
and all the immutable types will reference the same arrays. That way you 
would not just need a copy but a deepcopy. That will probably be too much 
overhead for fill!(), and will be problematic if someone decided to fill! 
an array with some large structure.

On the other hand, I think it would be reasonable for fill! to take a 
shallow copy of mutable types. Not sure what others think on that subject 
though.

Ivar

kl. 17:01:56 UTC+2 fredag 16. mai 2014 skrev Jameson følgende:
>
> Since they are immutable, fill! did exactly what you wanted
>
> On Friday, May 16, 2014, Tim Holy > wrote:
>
>> Try
>>
>> arr = [ChannVals() for i = 1:10]
>>
>> On Friday, May 16, 2014 01:27:18 AM Carlos Becker wrote:
>> > Hello all,
>> >
>> > I wanted to create an array of an immutable type and initialize an empty
>> > copy in each (with the default constructor).
>> > I am wondering which is the best way to do it, so far:
>> >
>> >immutable ChannVals
>> > taus::Vector{Float64}
>> > alphas::Vector{Float64}
>> >
>> > ChannVals() = new( Float64[], Float64[] )
>> >end
>> >
>> ># create 10 new instances
>> >arr = ChannVals[ChannVals() for i=1:10]
>> >
>> >
>> > Now, a neat but incorrect way is to do
>> >
>> >arr = Array( ChannVals, 10 )
>> >fill!(allVals, ChannVals())
>> >
>> > because it will fill them with the same instance.
>> > Is there a neat way, such as a fillwithcopies!() ?
>> >
>> >
>> > Cheers.
>>
>

Re: [julia-users] Natural language processing in Julia

[Jonathan Malmaud]

Hi Sorami,
Yes, JuliaText is meant to be the repository of Julia NLP packages and I 
agree with you about Julia's potential in the NLP domain. There hasn't been 
a lot of action there since I think there aren't many people using Julia 
for NLP yet (although I hope that changes). Any contributions you wanted to 
make would be most appreciated. 

On Thursday, May 8, 2014 7:03:18 AM UTC-7, ther...@gmail.com wrote:
>
> Hi all,
>
>
> I am interested in writing Natural Language Processing (NLP) tools in 
> Julia.
>
> My name is Sorami, I am a data scientist at BrainPad Inc. in Tokyo, Japan. 
> I used to be a graduate student doing NLP.
>
> I am much interested in Julia, and I see its great potential as a powerful 
> NLP / Text Mining tool. 
>
> -
>
> I have read the "Natural language processing in Julia"  posts in 
> julia-user Group ( 
> https://groups.google.com/forum/#!searchin/julia-users/nlp/julia-users/SxB16X6lM1c/IWidFfJaDhUJ);
> Are there any updates on Julia+NLP since then? Is "JuliaText" ( 
> https://github.com/JuliaText ) the center  for NLP stuff? How about 
> "TextAnalysis.jl"?
>
> -
>
> FYI: I have uploaded the source code for a naïve "Dependency Parser" in 
> Julia, which I wrote when I was playing around with Julia. 
> https://github.com/sorami/DependencyParser.jl
>
> (Dependency parser is a kind of syntactic analysis tool for natural 
> languages like English or Japanese)
>
>
> Cheers,
> --
> Sorami Hisamoto
> http://89.io
>
>
>
> On Tuesday, January 28, 2014 1:31:07 AM UTC+9, John Myles White wrote:
>>
>> JuliaText would be great.
>>
>> TextAnalysis.jl really needs a lot of love to move forward. For now, I’d 
>> strongly push people towards NLTK.
>>
>>  — John
>>
>> On Jan 27, 2014, at 8:29 AM, Jonathan Malmaud  wrote:
>>
>> I was thinking of starting up a Julia NLP meta-project on github if 
>> there's enough interest. It could host projects like textanalysis.jl, a 
>> Julia interface to NLTK, a Julia interface to some of Stanford's NLP tools, 
>> and whatever more native solutions people put together.
>>
>> On Friday, October 25, 2013 9:32:10 AM UTC-4, Dahua Lin wrote:
>>>
>>> I wish there is something comparable to NLTK in Julia. In a recent 
>>> project that involves text parsing, I have to implement the text handling 
>>> module in Python, simply for the purpose of using NTLK and Jinja2. 
>>>
>>> If we can get the attention of the NLP community, I believe some NLP 
>>> people will build such things very soon.
>>>
>>> - Dahua
>>>
>>>
>>> On Tuesday, October 22, 2013 7:35:57 PM UTC-5, John Myles White wrote:

 There's a package called TextAnalysis.jl that has stemming and very 
 basic tokenization. Patches to do POS tagging would be very welcome. 

  -- John 

 On Oct 22, 2013, at 5:29 PM, Jonathan Malmaud  
 wrote: 

 > Is anyone working on or know of a package to do NLP tasks with Julia, 
 like part-of-speech tagging and stemming? PyCall works fine with Python's 
 NLTK, so that would be my default choice if there isn't anything more 
 native at the moment. 


>>

[julia-users] Design patterns for an API

[francois . fayard]

Hi,

I am starting to use Julia, and I would like to learn and contribute a bit. 
As I have some experience in numerics I am thinking of contributing to the 
ODE package.

I've read the ideas for the API, and I believe that we can still improve 
it. Usually, for this kind of solver, we could expect something such as :

ode_solve( F, y_0, t_0:t_1; stepping_method; step_choice_method )

where the stepping_method could be :
- Explicit Runge-Kutta
  It is is that kind of method, we also need some parameters such as the 
order of the method
- other methods ...

So how would you organise that ?My idea would be choosing SteppingMethod as 
an abstract type, and ExplicitRungeKutta as a concrete subtype that has 
different parameters. What do you think of that ? Is there a standard way 
to pass options to a function ?

I was thinking at looking at Gadfly to see how options are handled here. Do 
you recommend another package worth checking ?

Best regards,
François

Re: [julia-users] Re: JuliaCon Question Thread

[Stefan Karpinski]

We're going to film but not live stream. We'll film the lightning talks too
– good to have a reminder.


On Fri, May 16, 2014 at 3:50 PM, Job van der Zwan
wrote:

> Are you going to film/livestream it? Are you going to have lightning
> talks? If the answer to both questions is "yes", don't forget to
> film/stream the latter! Apparently the  GopherCon last month had some
> amazing lightning talks but nobody remembered to film them.
>
>
> On Tuesday, 13 May 2014 05:43:34 UTC+2, Hunter Owens wrote:
>>
>> Hey All-
>>
>> As, you (hopefully) know, registration for JuliaCon is 
>> now open.
>>
>> I'm starting this thread so you can ask me (or any of the other
>> organizers, who are cc'ed) any questions you may have about the conference.
>>
>> Please do consider submitting a talk proposal or attending the
>> conference, as we are looking forward to seeing folks in Chicago summer.
>>
>> Thanks,
>> Hunter
>>
>

Re: [julia-users] Trouble with Type Parameters

[Mauro]

On Fri, 2014-05-16 at 17:18, Toivo wrote:
> Yes, that is exactly the kind of example that I'm referring to. (As is the 
> example that started this thread as well.)

Haha, well sometimes I just take a bit longer to figure things
out... ;-)

> I suspect that the pragmatic rule that Julia follows is that each type 
> declaration that involves a type parameter T must in itself determine a 
> unique possible value for T based on the type of the method arguments.

It looks like the type T is fixed by the first argument in which T
features and for all other arguments of type T it then requires type
equality.

Anyway, I think this is not a big issue.  It only crops up with
composite types with an abstract type parameter, which is usually not
the case.  Otherwise it's pretty intuitive.  If triangular dispatch gets
implemented (I think this is the name it has been referred to), then
Leah's second try will work:

function unshift!{T,I<:T}(l::List{T},item::I)
...
end

Anyway, is there a solution to Leah's problem?  Maybe just leave the
second ::T away and let the Node constructor error on any unsuitable
item?

function Base.unshift!{T}(l::List{T},item)
 new_node = Node{T}(item,l.head)
 l.head = new_node
 return l
end


> Jeff or Stefan: Care to comment?
>
> On Friday, 16 May 2014 11:48:29 UTC+2, Mauro wrote:
>>
>> Here is an example of the difference Toivo refers to (I think): 
>>
>>
>> julia> foo{T<:Real}(a::Array{T},b::T) = T 
>> foo (generic function with 1 method) 
>>
>> julia> bar(a::Array{Real},b::Real) = Real 
>> 
>> 
>> bar (generic function with 1 method) 
>>
>> julia> aR = Real[1,2]; aI = Int[1,2]; 
>> 
>> 
>>
>> julia> foo(aR, 5) 
>> ERROR: no method foo(Array{Real,1}, Int64) 
>>
>> julia> foo(aI, 5) 
>> 
>> 
>> Int64 
>>
>> julia> bar(aR, 5) 
>> 
>> 
>> Real 
>>
>>
>> When calling foo(aR, 5), then T is set to Real.  Now in case of 
>> parameterized functions this means that typeof(b)===T, i.e. typeof(b) 
>> must be Real.  (which in this case is never possible as Real is an 
>> abstract type).  This contrasts to bar where only the weaker constraint 
>> typeof(b)<:Real is needed, i.e. a isa relation. 
>>
>> Thus, Toivo's complaint is that in function definitions :: usually means 
>> `isa` whereas for parameterized functions it means type equality `===`. 
>> However, I think this realisation does not make the :: situation worse 
>> than it already is.  :: has different meanings depending on context: 
>> ditto when in function declarations, then in function bodies it can also 
>> be a sub-type-assert, or a type declaration of a variable in the sense 
>> of check-and-convert (if check fails).  So, three meanings of :: are 
>> possible. 
>>
>> As an aside, in the issue about "function return type declarations" 
>> https://github.com/JuliaLang/julia/issues/1090 it is suggested to add 
>> syntax like f(a)::Int = 5 to declare that f returns an Int.  The 
>> discussion there suggests that there :: will have the check-and-convert 
>> semantics.  Thus a line like this could contain all three meanings of :: 
>>
>> f{T<:Real}((a::Array{T},b::T,c::Integer)::Complex = ... 
>>
>> ! 
>>
>> On Fri, 2014-05-16 at 08:15, tomas@gmail.com  wrote: 
>> >> But do you agree that the usage of x::T as a formal parameter is quite 
>> > different when T is a type parameter compared to when it is a plain 
>> type? 
>> > 
>> > I'm not 100% sure I grok what you're getting at, but *if *what you're 
>> > asking is whether I see a difference between foo(x::Real) and 
>> > foo{T<:Real}(x::Array{T}), then really no - I don't. 
>> > 
>> > I just the latter as shorthand for defining a function with a whole 
>> bunch 
>> > of methods - foo(x::Array{Int64}), foo(x::Array{Float64}), etc etc - 
>> with 
>> > the same Julia implementation. They will still, just as the former for 
>> > foo(x::Int64) and foo(x::Float64), be compiled to different versions, 
>> > strongly typed to the runtime type of the argument, and I could get 
>> exactly 
>> > the same behavior without parametric methods by copy-pasting the 
>> > implementation and using different specific type signatures. I'd need 
>> one 
>> > for every subtype of Real, so of course this isn't feasible in practice, 
>> > but the way I look at it the difference is really mainly syntactic 
>> sugar. 
>> > 
>> > The possibility to do diagonal dispatch with the help of type parameters 
>> is 
>> > also syntactic sugar - I

[julia-users] Re: JuliaCon Question Thread

[Job van der Zwan]

Are you going to film/livestream it? Are you going to have lightning talks? 
If the answer to both questions is "yes", don't forget to film/stream the 
latter! Apparently the  GopherCon last month had some amazing lightning 
talks but nobody remembered to film them.

On Tuesday, 13 May 2014 05:43:34 UTC+2, Hunter Owens wrote:
>
> Hey All-
>
> As, you (hopefully) know, registration for JuliaCon is 
> now open. 
>
> I'm starting this thread so you can ask me (or any of the other 
> organizers, who are cc'ed) any questions you may have about the conference. 
>
> Please do consider submitting a talk proposal or attending the conference, 
> as we are looking forward to seeing folks in Chicago summer. 
>
> Thanks,
> Hunter
>

[julia-users] Re: how to Replicate array, translate from matlab

[Gabor]

B=repmat(A,x...)

On Friday, May 16, 2014 8:18:14 PM UTC+2, paul analyst wrote:

> in matlab :
> x=[1,4]
> B=repmat(A,x)
>
> /(B==)
>
>
> how to replicate A in Julia
> Paul
>
>
>

[julia-users] Re: how to Replicate array, translate from matlab

[Jason Merrill]

Julia has repmat. You can look up its methods like this:

julia> methods(repmat)
# 3 methods for generic function "repmat":
repmat(a::AbstractArray{T,1},m::Int64) at abstractarray.jl:964
repmat(a::Union(AbstractArray{T,2},AbstractArray{T,1}),m::Int64) at 
abstractarray.jl:950
repmat(a::Union(AbstractArray{T,2},AbstractArray{T,1}),m::Int64,n::Int64) 
at abstractarray.jl:950

>From these signatures, you can read off that Julia expects integers as the 
trailing arguments, not an array. The third signature is the one we're 
looking for.

julia> A = rand(3, 3)
3x3 Array{Float64,2}:
 0.595856  0.413262   0.652419
 0.111673  0.709227   0.16245
 0.577607  0.0896444  0.943816

julia> B = repmat(A, 1, 4)
3x12 Array{Float64,2}:
 0.595856  0.413262   0.652419  0.595856  …  0.595856  0.413262   0.652419
 0.111673  0.709227   0.16245   0.111673 0.111673  0.709227   0.16245
 0.577607  0.0896444  0.943816  0.577607 0.577607  0.0896444  0.943816

Alternatively, you can use the splat operator, "..."

julia> B = repmat(A, [1, 4]...)
3x12 Array{Float64,2}:
 0.595856  0.413262   0.652419  0.595856  …  0.595856  0.413262   0.652419
 0.111673  0.709227   0.16245   0.111673 0.111673  0.709227   0.16245
 0.577607  0.0896444  0.943816  0.577607 0.577607  0.0896444  0.943816

On Friday, May 16, 2014 11:18:14 AM UTC-7, paul analyst wrote:
>
> in matlab :
> x=[1,4]
> B=repmat(A,x)
>
> /(B==)
>
>
> how to replicate A in Julia
> Paul
>
>
>

[julia-users] how to Replicate array, translate from matlab

[paul analyst]

in matlab :
x=[1,4]
B=repmat(A,x)

/(B==)


how to replicate A in Julia
Paul

[julia-users] Re: JuliaCon Question Thread

[G. Patrick Mauroy]

I think it is great to have most topics advanced, it is a fun and 
educational way to engage with contributors and see all the power of the 
language in action.

However if one of the objectives of the conference is also to broaden a bit 
the audience -- e.g., spark the interest of a few more R/Matlab/Python 
users, then I think covering some basics would be well worth 30min as a 
first session after the introduction.  And I am sure the experts could have 
some fun contributing to such short session in Q&A by offering further 
suggestions & references.

In this 
post,
 
I had made a few suggestions on what such a 101 or rather 102 session could 
look like.  For such a conference, a session 101 covering the detailed 
syntax would certainly be too basic.  My vision of basic 102 is a typical 
workflow: read, crunch, plot, report, and write data.  Look at a few basic 
alternatives and compare with other languages like R.

If organizers & attendees agree it would not be a waste of time then I am 
open to contribute to such a session, like work with someone somewhat 
already proficient in Julia on designing & creating a simple script hitting 
a number of basic scenarios.  I could write it in R as a comparative point 
but I would prefer if someone else would write the bulk of possible 
approaches in Julia.  I think a simple working script written in Julia and 
other languages like R & Matlab for comparison would be an effective way to 
help newcomers relate to Julia and bootstrap adoption.  In this conference, 
such a basic & comparative session could serve as a warm up before getting 
into the more advanced sessions.

The tutorials I see online are either too basic for the conference (i.e., 
going over the syntax in details) or hitting very specific scenarios.  I 
have not stumbled upon something hitting the basic workflow in a somewhat 
comprehensive, simple, & practical way.

Within the next few weeks, I am planning on writing my first Julia test 
script.  I am coming to the conference.  I am excited.  Getting me to stick 
with Julia would be an accomplishment!  :)

On Wednesday, May 14, 2014 11:51:23 AM UTC-4, James Porter wrote:
>
> Hey all—
>
> As far as Patrick's question goes—
>
> It is true that a lot of the talks at the conference are going to be about 
> fairly advanced topics (Julia internals, a prototype Julia typechecker, 
> etc.). That said there will also be a number of talks that deal with using 
> Julia to solve some sort of technical computing problem (e.g. parallelizing 
> sparse matrix multiplication), which even novice Julia users will probably 
> be able to appreciate provided that they have some understanding of the 
> mathematical/scientific content. So I would say in order to get a lot out 
> of the conference, attendees should probably ether be relatively 
> experienced Julia users, or have domain knowledge in one or more areas that 
> Julia is used in (numerical linear algebra, statistics, machine learning, 
> etc.)
>
> As far as Luis's question—
>
> Yes, we've been meaning to get this information up for a while, it should 
> be on the website soon.
>
> Cheers,
> James
>
>
> On Wed, May 14, 2014 at 10:26 AM, Luis Benet 
> > wrote:
>
>> Hi,
>>
>> can you post some information/recommendation about nearby hotels or other 
>> accommodation possibilities?
>>
>> Thanks,
>>
>> Luis
>>
>
>

Re: [julia-users] for loops

[Stefan Karpinski]

That form of iteration is common from Ruby, which is where I'm guessing
this interest is coming from? Ruby has the block/proc/lambda distinction
that makes the for loop and .each forms behaviorally similar, whereas in
Julia, there's just the one kind of anonymous function. As a result, if
this were made to work, enumerate(a) do i,x and for (i,x) in enumerate(a)
would not behave exactly the same – return in the former would exit the
current loop iteration whereas return in the latter exits the enclosing
function. I'm not sure it's a good idea to introduce too many different
ways to write this. If we were going to implement this, we wouldn't do it
by adding language features, but by adding methods to iterator-producing
functions like enumerate. In this case, you could do something like this:

function enumerate(f::Callable, x)
  for (i,x) in enumerate(x)
f(i,x)
  end
end


That pattern could be emitted by a macro, of course.

Re: [julia-users] Trouble with Type Parameters

[Toivo Henningsson]

Yes, that is exactly the kind of example that I'm referring to. (As is the 
example that started this thread as well.)
In all other cases, x::T is covariant in the sense that it allows typeof(x) 
<: T. But in an argument list when T is a type parameter to the same 
method, x::T is instead invariant in the sense that it only allows 
typeof(x) === T.

To me, this is a much bigger (and completely different kind of) difference 
than between using :: as a type declaration and type assertion.
Now that I know this, I'm starting to doubt what I thought that I knew 
about type parameters in other cases. How about

f{T}(x::AbstractArray{T}) = T

Does this accept subtypes of AbstractArray{T}? It turns out that it does. 
But how do I know?

I suspect that the pragmatic rule that Julia follows is that each type 
declaration that involves a type parameter T must in itself determine a 
unique possible value for T based on the type of the method arguments.

Jeff or Stefan: Care to comment?

On Friday, 16 May 2014 11:48:29 UTC+2, Mauro wrote:
>
> Here is an example of the difference Toivo refers to (I think): 
>
>
> julia> foo{T<:Real}(a::Array{T},b::T) = T 
> foo (generic function with 1 method) 
>
> julia> bar(a::Array{Real},b::Real) = Real 
> 
> 
> bar (generic function with 1 method) 
>
> julia> aR = Real[1,2]; aI = Int[1,2]; 
> 
> 
>
> julia> foo(aR, 5) 
> ERROR: no method foo(Array{Real,1}, Int64) 
>
> julia> foo(aI, 5) 
> 
> 
> Int64 
>
> julia> bar(aR, 5) 
> 
> 
> Real 
>
>
> When calling foo(aR, 5), then T is set to Real.  Now in case of 
> parameterized functions this means that typeof(b)===T, i.e. typeof(b) 
> must be Real.  (which in this case is never possible as Real is an 
> abstract type).  This contrasts to bar where only the weaker constraint 
> typeof(b)<:Real is needed, i.e. a isa relation. 
>
> Thus, Toivo's complaint is that in function definitions :: usually means 
> `isa` whereas for parameterized functions it means type equality `===`. 
> However, I think this realisation does not make the :: situation worse 
> than it already is.  :: has different meanings depending on context: 
> ditto when in function declarations, then in function bodies it can also 
> be a sub-type-assert, or a type declaration of a variable in the sense 
> of check-and-convert (if check fails).  So, three meanings of :: are 
> possible. 
>
> As an aside, in the issue about "function return type declarations" 
> https://github.com/JuliaLang/julia/issues/1090 it is suggested to add 
> syntax like f(a)::Int = 5 to declare that f returns an Int.  The 
> discussion there suggests that there :: will have the check-and-convert 
> semantics.  Thus a line like this could contain all three meanings of :: 
>
> f{T<:Real}((a::Array{T},b::T,c::Integer)::Complex = ... 
>
> ! 
>
> On Fri, 2014-05-16 at 08:15, tomas@gmail.com  wrote: 
> >> But do you agree that the usage of x::T as a formal parameter is quite 
> > different when T is a type parameter compared to when it is a plain 
> type? 
> > 
> > I'm not 100% sure I grok what you're getting at, but *if *what you're 
> > asking is whether I see a difference between foo(x::Real) and 
> > foo{T<:Real}(x::Array{T}), then really no - I don't. 
> > 
> > I just the latter as shorthand for defining a function with a whole 
> bunch 
> > of methods - foo(x::Array{Int64}), foo(x::Array{Float64}), etc etc - 
> with 
> > the same Julia implementation. They will still, just as the former for 
> > foo(x::Int64) and foo(x::Float64), be compiled to different versions, 
> > strongly typed to the runtime type of the argument, and I could get 
> exactly 
> > the same behavior without parametric methods by copy-pasting the 
> > implementation and using different specific type signatures. I'd need 
> one 
> > for every subtype of Real, so of course this isn't feasible in practice, 
> > but the way I look at it the difference is really mainly syntactic 
> sugar. 
> > 
> > The possibility to do diagonal dispatch with the help of type parameters 
> is 
> > also syntactic sugar - I could just as easily define bar(x::Int64, 
> > y::Int64) etc for all real types, but with no methods for bar that take 
> > arguments of different kinds, as define bar{T<:Real}(x::T, y::T). Again, 
> > this would mean an insane amount of code duplication, so I'm really glad 
> I 
> > don't *have* to code this way, but I certainly could if I for some 
> wicked 
> > reason want

Re: [julia-users] Indexing DataFrames

[Jason Solack]

perfect, thank you!

On Friday, May 16, 2014 11:28:46 AM UTC-4, John Myles White wrote:
>
> This is a result of the weird precedence of &. Try this: 
>
> (df[:A] .== 1) & (df[:B] .== 1) 
>
>  — John 
>
> On May 16, 2014, at 8:25 AM, Jason Solack > 
> wrote: 
>
> > Hello all 
> > 
> > I'm trying to index a dataframe in the folowing manner: 
> > 
> > df = DataFrame(A = round(rand(1000) * 10), B = round(rand(1000) * 10)) 
> > df[:C] = 0 
> > df[(df[:A] .== 1 & df[:B] .== 1),: C] = 1 
> > 
> > 
> > I get an error "ERROR: no method &(Int64, DataArray{Float64, 1}) 
> > 
> > if i index like this, it works but i won't be able to do "ors" 
> > 
> > df[(df[:A] .== 1 .* df[:B] .== 1),: C] = 1 
> > 
> > is there another way of going about this? 
> > 
> > Thank you, 
> > 
> > Jason 
>
>

Re: [julia-users] Indexing DataFrames

[John Myles White]

This is a result of the weird precedence of &. Try this:

(df[:A] .== 1) & (df[:B] .== 1)

 — John

On May 16, 2014, at 8:25 AM, Jason Solack  wrote:

> Hello all
> 
> I'm trying to index a dataframe in the folowing manner:
> 
> df = DataFrame(A = round(rand(1000) * 10), B = round(rand(1000) * 10))
> df[:C] = 0
> df[(df[:A] .== 1 & df[:B] .== 1),: C] = 1
> 
> 
> I get an error "ERROR: no method &(Int64, DataArray{Float64, 1})
> 
> if i index like this, it works but i won't be able to do "ors"
> 
> df[(df[:A] .== 1 .* df[:B] .== 1),: C] = 1
> 
> is there another way of going about this?
> 
> Thank you, 
> 
> Jason

[julia-users] Indexing DataFrames

[Jason Solack]

Hello all

I'm trying to index a dataframe in the folowing manner:

df = DataFrame(A = round(rand(1000) * 10), B = round(rand(1000) * 10))
df[:C] = 0
df[(df[:A] .== 1 & df[:B] .== 1),: C] = 1


I get an error "ERROR: no method &(Int64, DataArray{Float64, 1})

if i index like this, it works but i won't be able to do "ors"

df[(df[:A] .== 1 .* df[:B] .== 1),: C] = 1

is there another way of going about this?

Thank you, 

Jason

Re: [julia-users] Re: Inconsistent dictionary behaviour

[Stefan Karpinski]

No, that's perfect. Thanks!


On Fri, May 16, 2014 at 11:14 AM, Andrew B. Martin <
andrew.brown.mar...@gmail.com> wrote:

> Issue filed:
> https://github.com/JuliaLang/julia/issues/6870
>
> I'm new to filing issues on github, so please feel free to clarify if I'm
> not expressing the problem well.
>

Re: [julia-users] Re: Inconsistent dictionary behaviour

[Andrew B. Martin]

Issue filed:
https://github.com/JuliaLang/julia/issues/6870

I'm new to filing issues on github, so please feel free to clarify if I'm 
not expressing the problem well.

Re: [julia-users] Re: Inconsistent dictionary behaviour

[Stefan Karpinski]

Well, SubStrings are Strings. The issue here is that we're hashing tuples
based on their type, which is problematic. We very much need to (re)think
how collection hashing works. The basic question is whether containers
should hash differently based on their type, their eltype, or just their
contents. Currently, it's a mishmash of all of the above.


On Fri, May 16, 2014 at 10:50 AM, Andrew B. Martin <
andrew.brown.mar...@gmail.com> wrote:

> Should this be mentioned in the documentation?
>
> Currently it reads that split returns an array of strings, but I'm finding
> that it returns an array of SubStrings.
>

Re: [julia-users] fill! with copies

[Jameson Nash]

Since they are immutable, fill! did exactly what you wanted

On Friday, May 16, 2014, Tim Holy  wrote:

> Try
>
> arr = [ChannVals() for i = 1:10]
>
> On Friday, May 16, 2014 01:27:18 AM Carlos Becker wrote:
> > Hello all,
> >
> > I wanted to create an array of an immutable type and initialize an empty
> > copy in each (with the default constructor).
> > I am wondering which is the best way to do it, so far:
> >
> >immutable ChannVals
> > taus::Vector{Float64}
> > alphas::Vector{Float64}
> >
> > ChannVals() = new( Float64[], Float64[] )
> >end
> >
> ># create 10 new instances
> >arr = ChannVals[ChannVals() for i=1:10]
> >
> >
> > Now, a neat but incorrect way is to do
> >
> >arr = Array( ChannVals, 10 )
> >fill!(allVals, ChannVals())
> >
> > because it will fill them with the same instance.
> > Is there a neat way, such as a fillwithcopies!() ?
> >
> >
> > Cheers.
>

[julia-users] Re: Inconsistent dictionary behaviour

[Andrew B. Martin]

Should this be mentioned in the documentation?

Currently it reads that split returns an array of strings, but I'm finding 
that it returns an array of SubStrings.

Re: [julia-users] Re: Inconsistent dictionary behaviour

[Stefan Karpinski]

We really need to make that work the same way – can you open an issue?


On Fri, May 16, 2014 at 10:42 AM, Andrew B. Martin <
andrew.brown.mar...@gmail.com> wrote:

> Found the problem.
>
> The indices are tuples of substrings and I'm querying using strings.
>
>
>

[julia-users] Re: Inconsistent dictionary behaviour

[Andrew B. Martin]

Found the problem.

The indices are tuples of substrings and I'm querying using strings.

[julia-users] Inconsistent dictionary behaviour

[Andrew B. Martin]

Hey guys,

I'm confused by this dictionary behaviour.

I create a dictionary like this:

for line=readlines(open(string(directo, "4_column_file.tab")))[2:end]
tmp = split(line, '\t')
ste_data[(tmp[1], tmp[2], tmp[3])] = tmp[4]
end


Then I run 
v = collect(keys(ste_data)) 

to get an array of dictionary keys.

If I run
>> ste_data[v[1]]
>> "12233/r/r/n"

where v[1] = ("27517","66", "2") according to stdout from assigning v.

If however I enter:
ste_data["27517","66", "2"] or ste_data[("27517","66", "2")] then I get a 
keyerror.

It seems to me that these should be equivalent to entering v[1].

Can anyone explain what's going on.

Andrew

Re: [julia-users] suggestion of OSX julia/ijulia setup

[Ethan Anderes]

+1 for Cameron. I use the same workflow. 

Re: [julia-users] suggestion of OSX julia/ijulia setup

[Adrian Cuthbertson]

I follow an identical process to Cameron, with the same results.

- Adrian.


On Fri, May 16, 2014 at 3:37 PM, Cameron McBride
wrote:

> I am not sure if this appeals to you, but I'm happy to share my
> configuration.  I just use the REPL and a decent editor (vim), which I'm
> happy with.
>
> I've been using this setup for the past couple months (mid-March). I've
> only had occasionally issues, but I follow HEAD so that is expected.  I am
> now on 10.9, but this has been short enough that only a few deps have been
> updated via system homebrew.  Things could break there, but never have.
>
> The situation I finally created was:
>  - homebrew and then pip to install python / scipy / ipython (see iJulia
> docs)
>  - git repo of Julia github/master
>  - Pkg.add(...), Pkg.update(), etc.
>
> Ideally, I'm not sure I really need the julia homebrew which this uses by
> default.  But it works, so I haven't worried about resolving this.
>
> 1. I pull and re-compile master every few days.  I usually scan the dev /
> users list before that to look for any ongoing gotchas, or new github
> issues.
> 2. When I compile Julia, and I do a few tests (basic crunching, Winston
> plots via Cairo, iJulia) then I use a local tag in my git repo to signify
> the working version.  It is just easier for me to roll things back, but
> certainly not strictly necessary.
> 3. I usually only  Pkg.update() after I've confirmed a new Julia compiles
> and seems to work from the above tests.
>
> Most of the issues I've had were between 2 & 3 not being in sync.  Some
> small changes where packages didn't catch up.  I've been impressed with how
> quickly many of the authors have fixed things, so it's rarely been an
> issue.  The one issue of Julia rollback I had to do was pretty easy (an
> issue that broke Grid.jl, I rolled back master for a couple days and
> watched the discussion / issue until it was resolved).
>
> I think this works as a lot of developers try and run real stuff with
> master, and most of the current packages are tracking master as the
> language develops.  YMMV, but I've been satisfied with the stability of
> this.
>
> Cameron
>
> p.s. I tried using anaconda to pin the python previously, which worked,
> but had some issues. I was happier when I did homebrew only python.
>

[julia-users] Problems with the scheduling example in the docs

[St Elmo Wilken]

Hi,

I'm struggling to understand the scheduling subsection (in the parallel 
computation section) of the docs; specifically how the pmap function as 
shown there works. I've copy-pasted the code I used below my questions.

Question 1) Is the purpose of the @sync block just to wait for all the 
processes to finish before returning the variable results i.e. so that no 
incomplete references are returned?

Question 2) If you run the code below (I added 2 other processes) you'll 
see the following output:

In @async, p = 2, idx = 1
In @async, p = 3, idx = 2
In @async, p = 3, idx = 3
In @async, p = 2, idx = 4
In @async, p = 3, idx = 5

How does p go from 2 to 3 to 2 etc.? I thought a for loop runs through its 
iterations sequentially? Clearly @async does something exotic but I don't 
get it?

Any help appreciated!


The code:

M = {rand(800,800), rand(800,800), rand(600,600), rand(600,600), 
rand(500,500)} 


function pmap2(f, lst)

   np = nprocs()  # determine the number of processes available

   n = length(lst)

   results = cell(n)

   i = 1

   # function to produce the next work item from the queue.

   # in this case it's just an index.

   nextidx() = (idx=i; i+=1; idx)

   @sync begin

 for p=1:np

 if p != myid() || np == 1

 @async begin

   while true

   idx = nextidx()

   if idx > n

   break

   end

   println("In @async, p = ",p,", idx = ", idx)

   results[idx] = remotecall_fetch(p, f, 
lst[idx])

 end

 end

 end


 end

 end


results

end


a = pmap2(svd, M)
1+1 # this is just so that a is not printed by default...

Re: [julia-users] suggestion of OSX julia/ijulia setup

[Cameron McBride]

I am not sure if this appeals to you, but I'm happy to share my
configuration.  I just use the REPL and a decent editor (vim), which I'm
happy with.

I've been using this setup for the past couple months (mid-March). I've
only had occasionally issues, but I follow HEAD so that is expected.  I am
now on 10.9, but this has been short enough that only a few deps have been
updated via system homebrew.  Things could break there, but never have.

The situation I finally created was:
 - homebrew and then pip to install python / scipy / ipython (see iJulia
docs)
 - git repo of Julia github/master
 - Pkg.add(...), Pkg.update(), etc.

Ideally, I'm not sure I really need the julia homebrew which this uses by
default.  But it works, so I haven't worried about resolving this.

1. I pull and re-compile master every few days.  I usually scan the dev /
users list before that to look for any ongoing gotchas, or new github
issues.
2. When I compile Julia, and I do a few tests (basic crunching, Winston
plots via Cairo, iJulia) then I use a local tag in my git repo to signify
the working version.  It is just easier for me to roll things back, but
certainly not strictly necessary.
3. I usually only  Pkg.update() after I've confirmed a new Julia compiles
and seems to work from the above tests.

Most of the issues I've had were between 2 & 3 not being in sync.  Some
small changes where packages didn't catch up.  I've been impressed with how
quickly many of the authors have fixed things, so it's rarely been an
issue.  The one issue of Julia rollback I had to do was pretty easy (an
issue that broke Grid.jl, I rolled back master for a couple days and
watched the discussion / issue until it was resolved).

I think this works as a lot of developers try and run real stuff with
master, and most of the current packages are tracking master as the
language develops.  YMMV, but I've been satisfied with the stability of
this.

Cameron

p.s. I tried using anaconda to pin the python previously, which worked, but
had some issues. I was happier when I did homebrew only python.

Re: [julia-users] UnionType -> tuple of DataType(s)

[Mauro]

the `names` function is indeed the right way to go about it:

julia> un = Union(Int, Float64)
Union(Int64,Float64)

julia> names(un)
1-element Array{Symbol,1}:
 :types

julia> un.types
(Int64,Float64)

julia> un.types[1]
Int64

julia> un.types[2]
Float64


For datatypes:

julia> type A
   a::Int
   b::Float64
   end

julia> names(DataType)
14-element Array{Symbol,1}:
 :fptr
 :env 
 :code
 :name
 :super   
 :parameters  
 :names   
 :types   
 :ctor_factory
 :instance
 :size
 :abstract
 :mutable 
 :pointerfree 

julia> A.types
(Int64,Float64)

Also have a look at this excellent post:
http://blog.leahhanson.us/julia-helps.html


On Fri, 2014-05-16 at 08:09, tony.hf.f...@gmail.com wrote:
> Hello, new user and subscriber here. Is there a way to decompose a 
> UnionType back into its constituent type(s)?
>
> I tried names():
>
>> dt = Union(Int,Float64)
>> names(dt)
> 1-element Array{Symbol,1}:
>  :types
>
> convert() seems to hit dead-ends.
>
> Help appreciated.
>
> Tony

-- 

[julia-users] Re: UnionType -> tuple of DataType(s)

[Patrick O'Leary]

On Friday, May 16, 2014 2:09:03 AM UTC-5, Tony Fong wrote:
>
> Hello, new user and subscriber here. Is there a way to decompose a 
> UnionType back into its constituent type(s)?
>
> I tried names():
>
> > dt = Union(Int,Float64)
> > names(dt)
> 1-element Array{Symbol,1}:
>  :types
>
> convert() seems to hit dead-ends.
>

Lest it be lost, in a follow-up which he couldn't post at the time, Tony 
also asked:
"* with a Composite Type, is there a way to get the type of a field? (I 
only have a type, but not a value of the composite type)"

Sorry it took so long to get your post moderated; you can post freely now 
(we do a first-time posters moderation to avoid some nasty spam we've had 
in the past.)

[julia-users] UnionType -> tuple of DataType(s)

[Tony Fong]

Hello, new user and subscriber here. Is there a way to decompose a 
UnionType back into its constituent type(s)?

I tried names():

> dt = Union(Int,Float64)
> names(dt)
1-element Array{Symbol,1}:
 :types

convert() seems to hit dead-ends.

Help appreciated.

Tony

[julia-users] suggestion of OSX julia/ijulia setup

[Jon Norberg]

Hi all,

I have been using julia and ijulia for a while and everything worked fine. 
over time I get more and more issues, trying to upgrade/reinstall etc and 
now I can't get it to work at all anymore. As I intend to reinstall osx 
anyway, I was wondering if you good people have any good setup for 
python/ijulia/julia/juliastudio that is simple to maintain over time. I 
want to use one version of julia so somehow let julia-studio use that 
(annoying that they hardcode the julia path to julia-basic...)

I was ambitious to try to keep a --HEAD version of julia but maybe I will 
have to settle for a latest stable pre-release version to avoid trouble.

But I also find that sometimes there are issues with the dependencies and 
libraries, how do you keep those right?

So how do you people keep julia smoothly updating and working. Are you 
using brew, anaconda, enthought, for the python part, are you using xcode 
compiler or others, are you building julia yourself...

I'd appreciate any help in setting this up for the longer run than I have 
been able to keep it working so far.

Many thanks

[julia-users] Re: Fast, robust predicates with Julia

[Job van der Zwan]

Thank you so much!

I am very busy with other things at the moment, but will dive into the 
code, attempt to update as necessary in a few weeks and share the results, 
if any.

On Monday, 12 May 2014 22:52:17 UTC+2, Ariel Keselman wrote:
>
> Just looked for the code in some old backup drive and found it, see 
> attached. Straight from 2011. Drawing code in Python, Voronoi in Golang 
> (some pre-1 version). It also supports linear gradients within the voronoi, 
> see image below. So code is good but old golang and no docs... sorry for 
> that
>
> Of course most of the math in the gist above is just generated using 
> sympy, as I wrote previously. Now I updated the gist, it contains way less 
> terms and is faster (all by the mat trick of moving the origin). Eventually 
> I want to implement all this in Julia, but it is a lot of work...
>
>
> 
>
>
>
>

Re: [julia-users] NFFT Package

[Tobias Knopp]

Well, this is actually an interesting story. In my first test the code was 
about 100 times slower for which reason I did not investigate Julia further 
and concentrated on a Numpy like multidimensional array package called 
numcpp: https://github.com/tknopp/numcpp. And with C++11 I got actually 
quite far.

But at some point I reevaluated Julia and thanks to 
https://github.com/JuliaLang/julia/issues/4832 got the performance issues 
sorted out.

In the end I was about a factor 1.3 slower than the C version. At least for 
1D and 2D. ND currently only has a fallback implementation. The cartesian 
macros could make this a lot faster.

Am Freitag, 16. Mai 2014 13:18:39 UTC+2 schrieb Ariel Keselman:
>
> How close did you get to c speed?

[julia-users] Re: logical indexing... broadcasting

[Abe Schneider]

I might try something like (note the code code is written for clarity, not 
for compactness or completeness):

function encode_name(name::String)
  if name == "setosa"
return [1 0 2];
  elseif name == "versicolor"
 return [2 1 0];
  else
return [0 2 1];
  end
end

output = map(encode_name, iris_data)



On Wednesday, May 14, 2014 8:05:50 AM UTC-4, Héctor Fabio Satizábal Mejía 
wrote:
>
> Hello
>
> I am trying to conduct some tests on machine learning algorithms with 
> Julia but given that I am new to the language I am kind of stuck in a very 
> simple thing.
>
> I am working with the Iris dataset, and I want to translate the species 
> name into a code like this:
>
> "setosa" = [1 0 2]
> "versicolor" = [2 1 0]
> "virginica" = [0 2 1]
>
> I would like to have something like:
>
> using RDatasets
> iris_data = dataset("datasets", "iris");
>
> iris_output = zeros(length(iris_data.columns[5]), 3);
> iris_output[iris_data.columns[5].=="setosa",:] = [1 0 2];
> iris_output[iris_data.columns[5].=="versicolor",:] = [2 1 0];
> iris_output[iris_data.columns[5].=="virginica",:] = [0 2 1];
>
> Unfortunately this is not working. I get this error message:
>
> ERROR: DimensionMismatch("tried to assign 1x3 array to 50x3 destination")
>
> Which I think is a broadcasting problem.
>
> Any help? Is there a compact way of doing that?
>
> Thanks in advance
>
> Héctor
>
>
> By the way, I manage to do this in R using the following code:
>
> iris.data <- iris
> iris.output <- matrix(0, 3, 150)
> iris.output[,iris.data[,5]=="setosa"] <- c(1,0,0)
> iris.output[,iris.data[,5]=="versicolor"] <- c(0,1,0)
> iris.output[,iris.data[,5]=="virginica"] <- c(0,0,1)
> iris.output <- t(iris.output)
>
>
>
>

Re: [julia-users] NFFT Package

[Ariel Keselman]

How close did you get to c speed?

Re: [julia-users] Trouble with Type Parameters

[Alex]

Correct me if I am wrong, but IMHO the comparison of the two functions in 
Mauro's last post is not entirely fair for :: because the parametrized version 
imposed an additional constraint which has nothing to do with :: 

Essentially in the two cases the following types are required:

foo: T <: Real && eltype(a) === T && typeof(b) === T
bar: eltype(a) <: Real && typeof(b) <: Real

The latter is equivalent to

T <: Real && S <: Real && eltype(a) === T && typeof(b) === S,

which requires two /independent/ type parameters, while in foo the types are 
linked by construction. From that perspective I would say that the behavior of 
:: is consistent.

Hope that makes sense,

Alex.

[julia-users] Re: Adding new column to dataframe

[Jason Solack]

Thank you!

Re: [julia-users] NFFT Package

[Tim Holy]

On Friday, May 16, 2014 02:57:13 AM Tobias Knopp wrote:
> I initially wrote this to play with Julia and determine how close to C 
> speed one can get. 

But it will be quite useful functionality to have! Thanks for contributing it.

Best,
--Tim

Re: [julia-users] fill! with copies

[Tim Holy]

Try

arr = [ChannVals() for i = 1:10]

On Friday, May 16, 2014 01:27:18 AM Carlos Becker wrote:
> Hello all,
> 
> I wanted to create an array of an immutable type and initialize an empty
> copy in each (with the default constructor).
> I am wondering which is the best way to do it, so far:
> 
>immutable ChannVals
> taus::Vector{Float64}
> alphas::Vector{Float64}
> 
> ChannVals() = new( Float64[], Float64[] )
>end
> 
># create 10 new instances
>arr = ChannVals[ChannVals() for i=1:10]
> 
> 
> Now, a neat but incorrect way is to do
> 
>arr = Array( ChannVals, 10 )
>fill!(allVals, ChannVals())
> 
> because it will fill them with the same instance.
> Is there a neat way, such as a fillwithcopies!() ?
> 
> 
> Cheers.

[julia-users] NFFT Package

[Tobias Knopp]

This is just an anouncement that I have been working on a package for 
performing non-equidistant fast Fourier transforms (NFFT). The package 
should now be accessible using Pkg.add("NFFT"). Some basic usage examples 
can be found here: https://github.com/tknopp/NFFT.jl

The NFFT (also known as Gridding or NUFFT) allows to apply Fourier 
transforms where the sampling nodes in one of the domains are irregular. 
One application can be found in magnetic resonance imaging (MRI) 
reconstruction.

I initially wrote this to play with Julia and determine how close to C 
speed one can get. 

Re: [julia-users] Trouble with Type Parameters

[Mauro]

Here is an example of the difference Toivo refers to (I think):


julia> foo{T<:Real}(a::Array{T},b::T) = T
foo (generic function with 1 method)

julia> bar(a::Array{Real},b::Real) = Real   

  
bar (generic function with 1 method)

julia> aR = Real[1,2]; aI = Int[1,2];   

  

julia> foo(aR, 5)
ERROR: no method foo(Array{Real,1}, Int64)

julia> foo(aI, 5)   

  
Int64

julia> bar(aR, 5)   

  
Real


When calling foo(aR, 5), then T is set to Real.  Now in case of
parameterized functions this means that typeof(b)===T, i.e. typeof(b)
must be Real.  (which in this case is never possible as Real is an
abstract type).  This contrasts to bar where only the weaker constraint
typeof(b)<:Real is needed, i.e. a isa relation.

Thus, Toivo's complaint is that in function definitions :: usually means
`isa` whereas for parameterized functions it means type equality `===`.
However, I think this realisation does not make the :: situation worse
than it already is.  :: has different meanings depending on context:
ditto when in function declarations, then in function bodies it can also
be a sub-type-assert, or a type declaration of a variable in the sense
of check-and-convert (if check fails).  So, three meanings of :: are
possible.

As an aside, in the issue about "function return type declarations"
https://github.com/JuliaLang/julia/issues/1090 it is suggested to add
syntax like f(a)::Int = 5 to declare that f returns an Int.  The
discussion there suggests that there :: will have the check-and-convert
semantics.  Thus a line like this could contain all three meanings of ::

f{T<:Real}((a::Array{T},b::T,c::Integer)::Complex = ...

!

On Fri, 2014-05-16 at 08:15, tomas.lyc...@gmail.com wrote:
>> But do you agree that the usage of x::T as a formal parameter is quite 
> different when T is a type parameter compared to when it is a plain type? 
>
> I'm not 100% sure I grok what you're getting at, but *if *what you're 
> asking is whether I see a difference between foo(x::Real) and 
> foo{T<:Real}(x::Array{T}), then really no - I don't.
>
> I just the latter as shorthand for defining a function with a whole bunch 
> of methods - foo(x::Array{Int64}), foo(x::Array{Float64}), etc etc - with 
> the same Julia implementation. They will still, just as the former for 
> foo(x::Int64) and foo(x::Float64), be compiled to different versions, 
> strongly typed to the runtime type of the argument, and I could get exactly 
> the same behavior without parametric methods by copy-pasting the 
> implementation and using different specific type signatures. I'd need one 
> for every subtype of Real, so of course this isn't feasible in practice, 
> but the way I look at it the difference is really mainly syntactic sugar.
>
> The possibility to do diagonal dispatch with the help of type parameters is 
> also syntactic sugar - I could just as easily define bar(x::Int64, 
> y::Int64) etc for all real types, but with no methods for bar that take 
> arguments of different kinds, as define bar{T<:Real}(x::T, y::T). Again, 
> this would mean an insane amount of code duplication, so I'm really glad I 
> don't *have* to code this way, but I certainly could if I for some wicked 
> reason wanted to.
>
> There is of course one thing that differs profoundly: if you define 
> foo{T<:Real}(x::Array{T}) and then someone else comes, later on, and 
> defines a new subtype to Real, your definition just works. Had you done it 
> without type parameters, it of course wouldn't have worked without also 
> adding a specific implementation for foo(x::Array{MyNewRealType}).
>
> // Tomas
>
> On Thursday, May 15, 2014 10:03:12 PM UTC+2, Kevin Squire wrote:
>>
>> FWIW, I really appreciate you pointing out the different uses of :: Toivo. 
>>  Along with the different meanings of parameterizations in types and 
>> functions, this is another area I haven't been clear about (and I wasn't 
>> even aware of it until you pointed it out).
>>
>> Cheers!
>>Kevin
>>
>>
>> On Thu, May 15, 2014 at 11:49 AM, Toivo Henningsson 
>> 
>> > wrote:
>>
>>>
>>>
>>> On Thursday, 15 May 2014 10:59:07 UTC+2, Tomas Lycken wrote:

 it silently uses :: in a different sense than anywhere else in the 
> language


 I started writing a reply here, but realized it would be more 
 instructive to have it as an IJulia notebook, where we can actually 
 inspect 
 the values of various statements along the way - take a look here instea

Re: [julia-users] fill! with copies

[Carlos Becker]

* correction, 'allVals'  is 'arr' in the last line of code.


--
Carlos


On Fri, May 16, 2014 at 10:27 AM, Carlos Becker wrote:

> Hello all,
>
> I wanted to create an array of an immutable type and initialize an empty
> copy in each (with the default constructor).
> I am wondering which is the best way to do it, so far:
>
>immutable ChannVals
> taus::Vector{Float64}
> alphas::Vector{Float64}
>
>  ChannVals() = new( Float64[], Float64[] )
>end
>
># create 10 new instances
>arr = ChannVals[ChannVals() for i=1:10]
>
>
> Now, a neat but incorrect way is to do
>
>arr = Array( ChannVals, 10 )
>fill!(allVals, ChannVals())
>
> because it will fill them with the same instance.
> Is there a neat way, such as a fillwithcopies!() ?
>
>
> Cheers.
>

[julia-users] fill! with copies

[Carlos Becker]

Hello all,

I wanted to create an array of an immutable type and initialize an empty 
copy in each (with the default constructor).
I am wondering which is the best way to do it, so far:

   immutable ChannVals
taus::Vector{Float64}
alphas::Vector{Float64}

ChannVals() = new( Float64[], Float64[] )
   end

   # create 10 new instances
   arr = ChannVals[ChannVals() for i=1:10]


Now, a neat but incorrect way is to do

   arr = Array( ChannVals, 10 )
   fill!(allVals, ChannVals())

because it will fill them with the same instance.
Is there a neat way, such as a fillwithcopies!() ?


Cheers.

Re: [julia-users] Trouble with Type Parameters

[Tomas Lycken]

> But do you agree that the usage of x::T as a formal parameter is quite 
different when T is a type parameter compared to when it is a plain type? 

I'm not 100% sure I grok what you're getting at, but *if *what you're 
asking is whether I see a difference between foo(x::Real) and 
foo{T<:Real}(x::Array{T}), then really no - I don't.

I just the latter as shorthand for defining a function with a whole bunch 
of methods - foo(x::Array{Int64}), foo(x::Array{Float64}), etc etc - with 
the same Julia implementation. They will still, just as the former for 
foo(x::Int64) and foo(x::Float64), be compiled to different versions, 
strongly typed to the runtime type of the argument, and I could get exactly 
the same behavior without parametric methods by copy-pasting the 
implementation and using different specific type signatures. I'd need one 
for every subtype of Real, so of course this isn't feasible in practice, 
but the way I look at it the difference is really mainly syntactic sugar.

The possibility to do diagonal dispatch with the help of type parameters is 
also syntactic sugar - I could just as easily define bar(x::Int64, 
y::Int64) etc for all real types, but with no methods for bar that take 
arguments of different kinds, as define bar{T<:Real}(x::T, y::T). Again, 
this would mean an insane amount of code duplication, so I'm really glad I 
don't *have* to code this way, but I certainly could if I for some wicked 
reason wanted to.

There is of course one thing that differs profoundly: if you define 
foo{T<:Real}(x::Array{T}) and then someone else comes, later on, and 
defines a new subtype to Real, your definition just works. Had you done it 
without type parameters, it of course wouldn't have worked without also 
adding a specific implementation for foo(x::Array{MyNewRealType}).

// Tomas

On Thursday, May 15, 2014 10:03:12 PM UTC+2, Kevin Squire wrote:
>
> FWIW, I really appreciate you pointing out the different uses of :: Toivo. 
>  Along with the different meanings of parameterizations in types and 
> functions, this is another area I haven't been clear about (and I wasn't 
> even aware of it until you pointed it out).
>
> Cheers!
>Kevin
>
>
> On Thu, May 15, 2014 at 11:49 AM, Toivo Henningsson 
> 
> > wrote:
>
>>
>>
>> On Thursday, 15 May 2014 10:59:07 UTC+2, Tomas Lycken wrote:
>>>
>>> it silently uses :: in a different sense than anywhere else in the 
 language
>>>
>>>
>>> I started writing a reply here, but realized it would be more 
>>> instructive to have it as an IJulia notebook, where we can actually inspect 
>>> the values of various statements along the way - take a look here instead: 
>>> http://nbviewer.ipython.org/github/tlycken/IJulia-Notebooks/blob/master/
>>> A%20more%20thorough%20look%20at%20Julia's%20%22double%
>>> 20colon%22%20syntax.ipynb
>>>
>>> I hope it makes things a little clearer. I tried to base it on the 
>>> relevant section on `::` in the manual (http://docs.julialang.org/en/
>>> latest/manual/types/#type-declarations) and expand it with more 
>>> examples etc, so I hope it's possible to see the connections.
>>>
>>
>>  / Toivo
>>
>
>