[julia-users] Re: What do you call an (Associative{Int,T} or AbstractArray{T})

[Matt Bauman]

On Wednesday, April 13, 2016 at 6:29:21 PM UTC-4, James Fairbanks wrote:
>
> Or do you make a constructor that validates C <: Associative{NTuple{N, 
> Int},T} at construction time?
> What would be the appropriate error to throw in this case?
>

Exactly!  It's not currently possible to express the 
"triangular-dispatch-like" dependency between `C` and `T`, `N`, so you can 
just enforce it in the constructors.  An ArgumentError here is probably 
sensible, but I often find that in cases like these the inner constructor 
becomes complicated enough that users always use the more convenient outer 
constructors.  Just by limiting the signature of your outer constructor, 
you effectively end up with MethodErrors.

If your default element is going to be zero(T), have you tried using 
SparseVectors?  They should have *significantly* better performance than a 
dictionary in many cases.

[julia-users] Re: Should `append!(a::Vector{T}, items::NTuple{N, T})` be defined in Base?

[Davide Lasagna]

Interestingly, I have just noticed a bug in append!, see 
https://github.com/JuliaLang/julia/issues/15868

It occurs when you try to append a vector of elements which have a 
different type with respect to that of the original vector and when the 
conversion mechanism fails.

On Wednesday, April 13, 2016 at 11:44:29 PM UTC+1, Steven G. Johnson wrote:
>
>
>
> On Wednesday, April 13, 2016 at 6:22:27 PM UTC-4, Greg Plowman wrote:
>>
>> Considering the existing append! is pretty loose wrt the items being 
>> appended, a simple extension to the signature might work:
>>
>> append!{T}(a::Array{T,1}, items::Union{AbstractVector,Tuple})
>>
>
> Arguably, the signature should be append!(a::AbstractVector, itr), i.e. 
> you should be able to append any iterable object.
>

[julia-users] Re: Should `append!(a::Vector{T}, items::NTuple{N, T})` be defined in Base?

[Steven G. Johnson]

On Wednesday, April 13, 2016 at 6:22:27 PM UTC-4, Greg Plowman wrote:
>
> Considering the existing append! is pretty loose wrt the items being 
> appended, a simple extension to the signature might work:
>
> append!{T}(a::Array{T,1}, items::Union{AbstractVector,Tuple})
>

Arguably, the signature should be append!(a::AbstractVector, itr), i.e. you 
should be able to append any iterable object.

[julia-users] Re: What do you call an (Associative{Int,T} or AbstractArray{T})

[James Fairbanks]

I am glad to get two consistent answers within 1 minute of each other!

On Wednesday, April 13, 2016 at 1:48:20 PM UTC-4, Matt Bauman wrote:
>
> If you're able to define a `size` method for the Associative types, then 
> I'd call them all AbstractArrays.
>
 
Yeah they are 1 dimensional and have size(A) = n. I am thinking that it is 
0 on every index that hasn't been set yet, and the only valid indices are i 
in 1:n.
I want to use Dict{Int,T} as a "lazily allocated" Vector{T}.
 

>  I'd use a wrapper type like the last example in 
> http://docs.julialang.org/en/release-0.4/manual/interfaces/#abstract-arrays. 
>  You could parameterize the `data` field so any associative type could be 
> wrapped.  As a bonus: now it works like an array in Base code, too, without 
> changing any signatures.
>
 
So the SparseArray in the example would become
immutable SparseArray{C<:Associative{N, T},T,N} <: AbstractArray{T,N}
 data::C
 dims::N
end

And then all my functions that currently use Array{T,N} can use 
AbstractArray{T,N} and then can use this SparseArray automagically?
This gives an error 

ERROR: UndefVarError: N not defined

immutable SparseArray2{C<:Associative,T,N} <: AbstractArray{T,N}
 data::C
 dims::NTuple{N,Int}
end
Works but then when constructing it you need to make sure that C, T, and N 
are consistent in the constructor logic because there is nothing in the 
type definition that would forbid you from instantiating a

SparseArray2{Dict{Int, Float64}, Float32, 3}(Dict{Int, Float64}(), (2,3,4))

The problem is that data is not an Associative{NTuple{N, Int}, T}.
Is there any way to specify this in the Type definitions?
Or do you make a constructor that validates C <: Associative{NTuple{N, 
Int},T} at construction time?
What would be the appropriate error to throw in this case?

Thanks,
James

[julia-users] Re: Should `append!(a::Vector{T}, items::NTuple{N, T})` be defined in Base?

['Greg Plowman' via julia-users]

Considering the existing append! is pretty loose wrt the items being 
appended, a simple extension to the signature might work:

append!{T}(a::Array{T,1}, items::Union{AbstractVector,Tuple})


You could extend this yourself to try it out.


On Thursday, April 14, 2016 at 4:07:45 AM UTC+10, Davide Lasagna wrote:

> Hi all,
>
> I need to extend a vector with contents from n-tuples i generate 
> iteratively. Currently 
>
> append!(a::Vector{T}, items::NTuple{N, T})
>
> is not defined, whereas the method 
>
> append!{T}(a::Array{T,1}, items::AbstractVector)
>
> exists and is defined in array.jl. 
>
> Anyone finds this useful to justify opening a pull request? What would be 
> a good implementation?
>

[julia-users] Re: edit() with foreground emacs

[Josef Sachs]

> On Wed, 13 Apr 2016 14:03:08 -0700 (PDT), daniel matz said:

> It seems to work for me.  What were you trying to set JULIA_EDITOR
> to when you were trying emacs?  Were you trying to use console emacs
> with emacs -nw?

> On Wednesday, April 13, 2016 at 7:46:21 AM UTC-5, Josef Sachs wrote:
>> 
>> Is there a way that I can use edit() to start emacs in the
>> foreground with support for line number?
>> 
>> As a kludge, I am currently setting JULIA_EDITOR=mvim, and I have a
>> mvim in my PATH that is a symbolic link to emacs.

My EDITOR is set to emacs.  I am connected to an Ubuntu system via ssh,
with no X Window System.  When I unset JULIA_EDITOR and run julia,

julia> edit("Makefile")
emacs: standard input is not a tty

Maybe that's what you mean by "console emacs"?

Are you running the X Window System?  If so, then running emacs in the
background would work.

[julia-users] Re: edit() with foreground emacs

[daniel . matz]

It seems to work for me.

What were you trying to set JULIA_EDITOR to when you were trying emacs? 
 Were you trying to use console emacs with emacs -nw?

On Wednesday, April 13, 2016 at 7:46:21 AM UTC-5, Josef Sachs wrote:
>
> Is there a way that I can use edit() to start emacs in the foreground 
> with support for line number? 
>
> As a kludge, I am currently setting JULIA_EDITOR=mvim, and I have a 
> mvim in my PATH that is a symbolic link to emacs. 
>

[julia-users] Re: GtkIDE.jl, a semi-functional editor for Julia

[jonathan . bieler]

Hum, I guess you need to add it before you can check it out : 
Pkg.add("Gtk").

I'll update the readme.

[julia-users] Re: GtkIDE.jl, a semi-functional editor for Julia

[LarryD]

Hi.  I just loaded Julia 0.4.5 and entered the starting line of your 
installation instructions:  Pkg.checkout("Gtk").
I get the error message   ERROR:  Gtk is not a git repot in checkout at 
pkg/entry.jl:203

Is there something else I need to load first, or what am I doing wrong?

Thanks

Larry Dworsky



On Wednesday, April 13, 2016 at 7:30:33 AM UTC-5, jonatha...@alumni.epfl.ch 
wrote:
>
> GtkIDE.jl is a IDE for Julia 0.4 written in Julia, aiming at providing 
> something similar to the Matlab
> editor (with a console, plots, tools, and the possibility to make customs 
> GUIs).
>
> I've been working on this for a while and although the code is still 
> messy, and there's a lot
> of issues, I find it relatively usable compared to other solutions.
>
> Features include multiple consoles (one per worker), interactive plots 
> using Immerse, a tabbed editor
> with autocompletion, search, panels, etc.
>
> You can try it here:
>
> https://github.com/jonathanBieler/GtkIDE.jl
>
> Report issues on Github if you have an account. 
>

[julia-users] Re: DataFrames: How to change column name?

[Andrew McKay]

minor update: 

rename!(df, :x1, :randomnumbers)


On Monday, December 9, 2013 at 2:27:10 AM UTC-8, Johan Sigfrids wrote:
>
> There is a rename!() function which does this. You can use it ilke this:
> df = DataFrame(x1=rand(5)
> rename!(df, "x1", "randomnubers")
>
>
>
> On Monday, December 9, 2013 11:50:05 AM UTC+2, RecentConvert wrote:
>>
>> Data has been loaded using DataFrames but since the column names are 
>> *not* on the first line the resulting data set has default column names. 
>> How do I change the names after the fact?
>>
>

[julia-users] Should `append!(a::Vector{T}, items::NTuple{N, T})` be defined in Base?

[Davide Lasagna]

Hi all,

I need to extend a vector with contents from n-tuples i generate 
iteratively. Currently 

append!(a::Vector{T}, items::NTuple{N, T})

is not defined, whereas the method 

append!{T}(a::Array{T,1}, items::AbstractVector)

exists and is defined in array.jl. 

Anyone finds this useful to justify opening a pull request? What would be a 
good implementation?

[julia-users] Re: What do you call an (Associative{Int,T} or AbstractArray{T})

[Matt Bauman]

If you're able to define a `size` method for the Associative types, then 
I'd call them all AbstractArrays.  I'd use a wrapper type like the last 
example 
in http://docs.julialang.org/en/release-0.4/manual/interfaces/#abstract-arrays. 
 You could parameterize the `data` field so any associative type could be 
wrapped.  As a bonus: now it works like an array in Base code, too, without 
changing any signatures.

But Unions are fine to use in method signatures — there's no penalty there. 
 I think the only place where you'll see a penalty is if you use a Union as 
a field type in a performance-critical object.  That's not unique to 
Unions… you just want those fields to have concrete 
types: 
http://docs.julialang.org/en/release-0.4/manual/performance-tips/#avoid-fields-with-abstract-type.

On Wednesday, April 13, 2016 at 1:14:42 PM UTC-4, James Fairbanks wrote:
>
> Over at LightGraphs we have been discussing support for collections 
> indexed by integers that can be either dense like Vector{T} or sparse like 
> Dict{Int,T}.
> The idea is that you want to collect some T's together indexed by a range 
> of integers 1:n. Often you will have a value for all or most of the indices 
> and should use a Vector{T} for that case. But sometimes you will only have 
> a few values and don't want to allocate O(n) storage just to hold a much 
> smaller amount of data.
>
> What is the best way to express this in types? Does 
> Union{Associative{Int,T}, AbstractArray{T}} express this with no 
> performance penalty? Is there any reason to avoid Union types?
>
> Thanks,
> James
>

[julia-users] Re: What do you call an (Associative{Int,T} or AbstractArray{T})

[Steven G. Johnson]

On Wednesday, April 13, 2016 at 1:14:42 PM UTC-4, James Fairbanks wrote:
>
> What is the best way to express this in types? Does 
> Union{Associative{Int,T}, AbstractArray{T}} express this with no 
> performance penalty? Is there any reason to avoid Union types?
>

Unions have no better or worse performance than any other abstract type.   
Whether there is any performance impact at all depends on the context.

1) In a function argument, type declarations have zero effect on 
performance.  It doesn't matter to the compiler whether you declare a 
function as f(a), f(a::Any), f(a::Vector{Float64}), or 
f{T}(a::Union{Associative{Int,T}, AbstractVector{T}}).   

The key thing to remember about Julia is that, each time you call a 
function f(a) with a different type of argument, Julia recompiles a new 
version of f specialized for that argument type, which is used for all 
subsequent calls for the same argument types.  This specialized version is 
just as fast as if you had explicitly typed f(a::SomeType) in the first 
place.

Argument-type declarations are not for performance in Julia, they are a 
filter: they say "use this method for these types".  This is useful for 
multiple dispatch (if you have different methods depending on the argument 
types), for correctness (if your function will give unexpected/incorrect 
results for some types), and for clarity (to indicate clearly to the user 
what is expected to be passed to a function).

(I feel like this should be added as an "anti-tip" to the performance tips 
in the manual: don't declare argument types for performance reasons).

2) When you define a data structure, any abstract type for a field (whether 
it is a Union type or another abstract type like Associative) will be 
significantly slower than a concrete type.  See:

  
 
http://docs.julialang.org/en/latest/manual/performance-tips/#avoid-fields-with-abstract-type

Re: [julia-users] Re: sparse rank, sparse nullspace, sparse linear algebra over rationals?

[James Fairbanks]

Does this 
help? 
https://github.com/JuliaLang/IterativeSolvers.jl/blob/master/src/svdl.jl#L192

On Wednesday, April 13, 2016 at 10:30:32 AM UTC-4, Alex Dowling wrote:
>
> Hello Laurent,
>
> Thanks. I've used svds in MATLAB before with some success. Ideally I'd 
> like to have a pure Julia implementation. Do you know of any appropriate 
> packages?
>
> Alex
>
> On Tuesday, April 12, 2016 at 4:41:06 PM UTC-5, Laurent Bartholdi wrote:
>>
>> @Stefan: sorry, I had meant that Julia doesn't yet have sparse 
>> non-(real/complex) matrices. However, I see that that's wrong too: I can 
>> create sparse matrices with Int64 entries. It would now make a lot of sense 
>> to implement the algorithms in linbox so as to compute rank etc. of Int or 
>> BigInt sparse matrices.
>>
>> @Alex: if you're only interested in the 10 lowest singular values of a 
>> sparse matrix, then MATLAB is quite good at it. Here's from the doc:
>>
>> S = svds(A,K,SIGMA) computes the K singular values closest to the 
>> scalar shift SIGMA.  For example, S = svds(A,K,0) computes the K
>> smallest singular values.
>>
>>
>> On Tue, 12 Apr 2016 at 22:29 Stefan Karpinski  
>> wrote:
>>
>>> Julia does have complex sparse matrices:
>>>
>>> julia> C = sparse(rand(1:10, 10), rand(1:10, 10), randn(10) + 
>>> randn(10)im, 10, 10)
>>> 10x10 sparse matrix with 9 Complex{Float64} entries:
>>>   [7 ,  1]  =  1.1711-0.587334im
>>>   [5 ,  3]  =  0.940755+1.00755im
>>>   [1 ,  4]  =  1.51515-1.77335im
>>>   [4 ,  4]  =  -0.815624-0.678038im
>>>   [9 ,  5]  =  -0.598111-0.970266im
>>>   [2 ,  6]  =  0.671339-1.07398im
>>>   [7 ,  6]  =  -1.69705+1.08698im
>>>   [10,  7]  =  -1.32233-1.88083im
>>>   [7 , 10]  =  1.26453-0.399423im
>>>
>>> How much you can do with these depends on what kinds of special methods 
>>> are implemented, but you can call eigs on them, which lets you figure out 
>>> what the rank is:
>>>
>>> julia> map(norm,eigs(C)[1])
>>> 6-element Array{Float64,1}:
>>>  1.74612
>>>  1.74612
>>>  1.06065
>>>  4.28017e-6
>>>  4.28016e-6
>>>  4.28016e-6
>>>
>>> In this case, for example, the matrix is rank 3.
>>>
>>> On Tue, Apr 12, 2016 at 3:29 PM, Laurent Bartholdi <
>>> laurent@gmail.com> wrote:
>>>
 It's tricky, but sprank is definitely not competitive with finer 
 implementations. As you certainly know, rank calculations are very 
 unstable, so if your matrix has integer entries you should prefer an exact 
 method, or a calculation in a finite field. (Sadly, Julia does not 
 contain, 
 yet, sparse matrices with non-real/complex entries). See 
 http://dx.doi.org.sci-hub.io/10.1145/2513109.2513116 for a recent 
 discussion of sparse matrix rank.

 The following routines compute null spaces. To obtain the rank, you 
 subtract the nullspace dimension from the row space dimension (i.e. number 
 of columns). If you want pure Julia, you could try

 function julia_null_space{T}(A::SparseMatrixCSC{T})
 SVD = svdfact(full(A), thin = false)
 any(1.e-8 .< SVD.S .< 1.e-4) && error("Values are dangerously 
 small")
 indstart = sum(SVD.S .> 1.e-8) + 1
 nullspace = SVD.Vt[indstart:end,:]'
 return sparse(nullspace .* (abs(nullspace) .> 1.e-8))
 end

 If you have MATLAB, the following is faster:

 using MATLAB
 global m_session = MSession()

 function matlab_null_space{T}(A::SparseMatrixCSC{T})
 m, n = size(A)
 (m == 0 || n == 0) && return speye(T, n)

 put_variable(m_session,:A,convert(SparseMatrixCSC{Float64},A))
 eval_string(m_session,"N = spqr_null(A,struct('tol',1.e-8));")
 eval_string(m_session,"ns = 
 spqr_null_mult(N,speye(size(N.X,2)),1);")
 eval_string(m_session,"ns = sparseclean(ns,1.e-8);")
 ns = get_mvariable(m_session,:ns)
 return jvariable(ns)
 end

 Finally, if your matrices are over Z, Q or a finite field, do give a 
 look to linbox (http://www.linalg.org/linbox-html/index.html).

 HTH, Laurent

 On Tue, 12 Apr 2016 at 20:49 Alex Dowling  wrote:

> Hello,
>
> I am also looking to compute the (approximate) rank of a sparse 
> matrix. For my applications I'm consider dimensions of 10k - 100k by 10k 
> - 
> 100k, not millions by millions. I've previously done this in MATLAB using 
> the sprank command 
> . Does anyone 
> have recommendations for similar functions in Julia?
>
> Thanks,
> Alex
>
>
> On Tuesday, November 17, 2015 at 3:08:29 AM UTC-6, 
> ming...@irt-systemx.fr wrote:
>>
>> hello,
>>
>> getting the rank of a huge sparse matrix is mathematically difficult
>>
>>
>> http://math.stackexchange.com/questions/554777/rank-computation-of-large-matrices
>>
>> bests,
>> M.
>>
>> Le lundi 16 novembre 

[julia-users] What do you call an (Associative{Int,T} or AbstractArray{T})

[James Fairbanks]

Over at LightGraphs we have been discussing support for collections indexed 
by integers that can be either dense like Vector{T} or sparse like 
Dict{Int,T}.
The idea is that you want to collect some T's together indexed by a range 
of integers 1:n. Often you will have a value for all or most of the indices 
and should use a Vector{T} for that case. But sometimes you will only have 
a few values and don't want to allocate O(n) storage just to hold a much 
smaller amount of data.

What is the best way to express this in types? Does 
Union{Associative{Int,T}, AbstractArray{T}} express this with no 
performance penalty? Is there any reason to avoid Union types?

Thanks,
James

[julia-users] Re: I am trying to figure out how to pass DataTypes for a dataframe to @ListStore in Gtk.jl

[Min-Woong Sohn]

I just did and it works perfectly.

Thank you so much!


On Tuesday, April 12, 2016 at 7:04:39 PM UTC-4, Eric Forgy wrote:
>
> Hi,
>
> I'm not sitting at a computer at the moment, but just curious if you've 
> tried
>
> ls = @ListStore(eltypes(df)...)
>
> Sorry for the noise if that doesn't work :)
>
>

Re: [julia-users] Re: sparse rank, sparse nullspace, sparse linear algebra over rationals?

[Alex Dowling]

Hello Laurent,

Thanks. I've used svds in MATLAB before with some success. Ideally I'd like 
to have a pure Julia implementation. Do you know of any appropriate 
packages?

Alex

On Tuesday, April 12, 2016 at 4:41:06 PM UTC-5, Laurent Bartholdi wrote:
>
> @Stefan: sorry, I had meant that Julia doesn't yet have sparse 
> non-(real/complex) matrices. However, I see that that's wrong too: I can 
> create sparse matrices with Int64 entries. It would now make a lot of sense 
> to implement the algorithms in linbox so as to compute rank etc. of Int or 
> BigInt sparse matrices.
>
> @Alex: if you're only interested in the 10 lowest singular values of a 
> sparse matrix, then MATLAB is quite good at it. Here's from the doc:
>
> S = svds(A,K,SIGMA) computes the K singular values closest to the 
> scalar shift SIGMA.  For example, S = svds(A,K,0) computes the K
> smallest singular values.
>
>
> On Tue, 12 Apr 2016 at 22:29 Stefan Karpinski  > wrote:
>
>> Julia does have complex sparse matrices:
>>
>> julia> C = sparse(rand(1:10, 10), rand(1:10, 10), randn(10) + 
>> randn(10)im, 10, 10)
>> 10x10 sparse matrix with 9 Complex{Float64} entries:
>>   [7 ,  1]  =  1.1711-0.587334im
>>   [5 ,  3]  =  0.940755+1.00755im
>>   [1 ,  4]  =  1.51515-1.77335im
>>   [4 ,  4]  =  -0.815624-0.678038im
>>   [9 ,  5]  =  -0.598111-0.970266im
>>   [2 ,  6]  =  0.671339-1.07398im
>>   [7 ,  6]  =  -1.69705+1.08698im
>>   [10,  7]  =  -1.32233-1.88083im
>>   [7 , 10]  =  1.26453-0.399423im
>>
>> How much you can do with these depends on what kinds of special methods 
>> are implemented, but you can call eigs on them, which lets you figure out 
>> what the rank is:
>>
>> julia> map(norm,eigs(C)[1])
>> 6-element Array{Float64,1}:
>>  1.74612
>>  1.74612
>>  1.06065
>>  4.28017e-6
>>  4.28016e-6
>>  4.28016e-6
>>
>> In this case, for example, the matrix is rank 3.
>>
>> On Tue, Apr 12, 2016 at 3:29 PM, Laurent Bartholdi > > wrote:
>>
>>> It's tricky, but sprank is definitely not competitive with finer 
>>> implementations. As you certainly know, rank calculations are very 
>>> unstable, so if your matrix has integer entries you should prefer an exact 
>>> method, or a calculation in a finite field. (Sadly, Julia does not contain, 
>>> yet, sparse matrices with non-real/complex entries). See 
>>> http://dx.doi.org.sci-hub.io/10.1145/2513109.2513116 for a recent 
>>> discussion of sparse matrix rank.
>>>
>>> The following routines compute null spaces. To obtain the rank, you 
>>> subtract the nullspace dimension from the row space dimension (i.e. number 
>>> of columns). If you want pure Julia, you could try
>>>
>>> function julia_null_space{T}(A::SparseMatrixCSC{T})
>>> SVD = svdfact(full(A), thin = false)
>>> any(1.e-8 .< SVD.S .< 1.e-4) && error("Values are dangerously small")
>>> indstart = sum(SVD.S .> 1.e-8) + 1
>>> nullspace = SVD.Vt[indstart:end,:]'
>>> return sparse(nullspace .* (abs(nullspace) .> 1.e-8))
>>> end
>>>
>>> If you have MATLAB, the following is faster:
>>>
>>> using MATLAB
>>> global m_session = MSession()
>>>
>>> function matlab_null_space{T}(A::SparseMatrixCSC{T})
>>> m, n = size(A)
>>> (m == 0 || n == 0) && return speye(T, n)
>>>
>>> put_variable(m_session,:A,convert(SparseMatrixCSC{Float64},A))
>>> eval_string(m_session,"N = spqr_null(A,struct('tol',1.e-8));")
>>> eval_string(m_session,"ns = spqr_null_mult(N,speye(size(N.X,2)),1);")
>>> eval_string(m_session,"ns = sparseclean(ns,1.e-8);")
>>> ns = get_mvariable(m_session,:ns)
>>> return jvariable(ns)
>>> end
>>>
>>> Finally, if your matrices are over Z, Q or a finite field, do give a 
>>> look to linbox (http://www.linalg.org/linbox-html/index.html).
>>>
>>> HTH, Laurent
>>>
>>> On Tue, 12 Apr 2016 at 20:49 Alex Dowling >> > wrote:
>>>
 Hello,

 I am also looking to compute the (approximate) rank of a sparse matrix. 
 For my applications I'm consider dimensions of 10k - 100k by 10k - 100k, 
 not millions by millions. I've previously done this in MATLAB using the 
 sprank 
 command . Does 
 anyone have recommendations for similar functions in Julia?

 Thanks,
 Alex


 On Tuesday, November 17, 2015 at 3:08:29 AM UTC-6, 
 ming...@irt-systemx.fr wrote:
>
> hello,
>
> getting the rank of a huge sparse matrix is mathematically difficult
>
>
> http://math.stackexchange.com/questions/554777/rank-computation-of-large-matrices
>
> bests,
> M.
>
> Le lundi 16 novembre 2015 22:12:04 UTC+1, Laurent Bartholdi a écrit :
>>
>> Hello world,
>> I'm new at julia, and trying it out as a replacement for matlab and 
>> other computer algebra systems. I'm a bit stuck with sparse matrices: I 
>> have largeish matrices (10^6 x 10^6) that are very sparse, and
>> want to know 

Re: [julia-users] Re: Setting min()=Inf and max()=-Inf

[Stefan Karpinski]

The decision here was made to be consistent across types: since most types
don't have a way of representing ± infinite values, there's no general way
to do this. It's a bit too much of a subtle corner case to make this work,
but *only* for arrays of concrete floating-point types. Imagine you write
some code and notice that you're only ever putting moderately-sized integer
values into your array before you take its maximum. With the current
arrangement, you can safely change the type of the array to `Int` and
everything will work the same as before. It's one of these cases where
there is no perfect answer.

On Wed, Apr 13, 2016 at 3:30 AM, Niclas Wiberg 
wrote:

> What about minimum() and maximum() with empty floating-point arrays? Would
> it make sense for those to return -Inf and +Inf by default?
>
> I get:
>
> *julia> **a = Array(Float64,(0,))*
>
> *0-element Array{Float64,1}*
>
>
> *julia> **minimum(a)*
>
> *ERROR: ArgumentError: reducing over an empty collection is not allowed*
>
> * in _mapreduce at reduce.jl:139*
>
> * in minimum at reduce.jl:325*
>
>
> Niclas
>
>
>
> Den onsdag 13 april 2016 kl. 09:03:57 UTC+2 skrev Milan Bouchet-Valat:
>>
>> Le mardi 12 avril 2016 à 20:21 -0700, Anonymous a écrit :
>> > Those are good points, although I always kind of wondered why Float
>> > gets Inf while Int doesn't, I guess there's no way to have Inf belong
>> > to 2 distinct concrete types.
>> The problem is that native integers have no way of representing
>> infinite values, contrary to floating point. They can only store actual
>> values. (But you can use floating point formats to store integer data
>> if you need Inf.)
>>
>>
>> Regards
>>
>> > >
>> > > > Have the Julia developers considered the effects of setting
>> > > > Base.min()=Inf and Base.max()=-Inf.  This is common in real
>> > > > analysis since it plays nice with set theory, i.e.
>> > > >
>> > > It only plays nicely with sets of real numbers.  What about sets of
>> > > other types that have a total ordering?  e.g. strings?
>> > >
>> > > Also, one of the general principles guiding the design of the Julia
>> > > standard library is to provide idioms that don't cause types to
>> > > change arbitrarily underneath the user; this principle is critical
>> > > to being able to use the standard library in high-performance code
>> > > (since type stability is critical to compiler optimization).  For
>> > > example min(1,2) == 1 (an Int), min(1) == 1 (an Int), but then
>> > > min() = Inf (floating-point)?
>> > >
>>
>

Re: [julia-users] local types or macros?

[Stefan Karpinski]

To answer somewhat the reason for the lack of local macros: Julia relies on
macros considerably less than Lisp does. In fact, they're generally seen as
a last resort. From this perspective, there's not so much call for local
macros. There are, of course, namespace-local macros, which seems
sufficient.

On Wed, Apr 13, 2016 at 8:13 AM, Tamas Papp  wrote:

>
> On Wed, Apr 13 2016, Didier Verna wrote:
>
> > Tamas Papp  wrote:
> >
> >> My perception is that simply pointing out that something is different
> >> in Common Lisp is unlikely to move the Julia language team to make
> >> fundamental changes to the language
> >
> >   ... which is not my intention. I'm simply curious about the language,
> >   and when I see something different from what I'm used to or which
> >   surprises me, I'm asking questions to get a better understanding.
> >
> >   Is all ;-)
>
> Once you are familiar with the language, it would be great if you would
> consider writing some blog posts or tutorials about macros in Julia from
> a Lisper perspective. I have been ignoring them almost completely for
> now, exploring other powerful features (expecially the possibilities of
> the rich type system).
>
> Best,
>
> Tamas
>

[julia-users] Re: Int or Int64

[Scott Jones]

There is no Float, you should use Float32 or Float64 depending on precision 
needed for your application.
I'd definitely use Int instead of Int64 as long as Int32 will be large 
enough, to avoid performance issues on 32-bit machines.
(I build and use Julia on my 32-bit ARM based Raspberry Pi)

On Wednesday, April 13, 2016 at 5:09:27 AM UTC-4, vincent leclere wrote:
>
> Hi all,
>
> quick question: I am building a package and has been defining types with 
> Int64 or Float64 properties.
> Is there any reason why I should be using Int and Float instead ? (Does 
> Int64 work on 32bits processors ?)
> Will it be at the price of efficiency loss ?
>
> Thanks
>

Re: [julia-users] Re: Setting min()=Inf and max()=-Inf

[Niclas Wiberg]

What about minimum() and maximum() with empty floating-point arrays? Would 
it make sense for those to return -Inf and +Inf by default?

I get:

*julia> **a = Array(Float64,(0,))*

*0-element Array{Float64,1}*


*julia> **minimum(a)*

*ERROR: ArgumentError: reducing over an empty collection is not allowed*

* in _mapreduce at reduce.jl:139*

* in minimum at reduce.jl:325*


Niclas



Den onsdag 13 april 2016 kl. 09:03:57 UTC+2 skrev Milan Bouchet-Valat:
>
> Le mardi 12 avril 2016 à 20:21 -0700, Anonymous a écrit : 
> > Those are good points, although I always kind of wondered why Float 
> > gets Inf while Int doesn't, I guess there's no way to have Inf belong 
> > to 2 distinct concrete types. 
> The problem is that native integers have no way of representing 
> infinite values, contrary to floating point. They can only store actual 
> values. (But you can use floating point formats to store integer data 
> if you need Inf.) 
>
>
> Regards 
>
> > > 
> > > > Have the Julia developers considered the effects of setting 
> > > > Base.min()=Inf and Base.max()=-Inf.  This is common in real 
> > > > analysis since it plays nice with set theory, i.e. 
> > > > 
> > > It only plays nicely with sets of real numbers.  What about sets of 
> > > other types that have a total ordering?  e.g. strings? 
> > > 
> > > Also, one of the general principles guiding the design of the Julia 
> > > standard library is to provide idioms that don't cause types to 
> > > change arbitrarily underneath the user; this principle is critical 
> > > to being able to use the standard library in high-performance code 
> > > (since type stability is critical to compiler optimization).  For 
> > > example min(1,2) == 1 (an Int), min(1) == 1 (an Int), but then 
> > > min() = Inf (floating-point)? 
> > > 
>

[julia-users] edit() with foreground emacs

[Josef Sachs]

Is there a way that I can use edit() to start emacs in the foreground
with support for line number?

As a kludge, I am currently setting JULIA_EDITOR=mvim, and I have a
mvim in my PATH that is a symbolic link to emacs.

[julia-users] GtkIDE.jl, a semi-functional editor for Julia

[jonathan . bieler]

GtkIDE.jl is a IDE for Julia 0.4 written in Julia, aiming at providing 
something similar to the Matlab
editor (with a console, plots, tools, and the possibility to make customs 
GUIs).

I've been working on this for a while and although the code is still messy, 
and there's a lot
of issues, I find it relatively usable compared to other solutions.

Features include multiple consoles (one per worker), interactive plots 
using Immerse, a tabbed editor
with autocompletion, search, panels, etc.

You can try it here:

https://github.com/jonathanBieler/GtkIDE.jl

Report issues on Github if you have an account. 

Re: [julia-users] local types or macros?

[Tamas Papp]

On Wed, Apr 13 2016, Didier Verna wrote:

> Tamas Papp  wrote:
>
>> My perception is that simply pointing out that something is different
>> in Common Lisp is unlikely to move the Julia language team to make
>> fundamental changes to the language
>
>   ... which is not my intention. I'm simply curious about the language,
>   and when I see something different from what I'm used to or which
>   surprises me, I'm asking questions to get a better understanding.
>
>   Is all ;-)

Once you are familiar with the language, it would be great if you would
consider writing some blog posts or tutorials about macros in Julia from
a Lisper perspective. I have been ignoring them almost completely for
now, exploring other powerful features (expecially the possibilities of
the rich type system).

Best,

Tamas

Re: [julia-users] Re: [ANN] Cuba.jl: library for multidimensional numerical integration

[Kaj Wiik]

Perfect!

The documentation looks very good, thanks!

Cheers,
Kaj

On Wednesday, April 13, 2016 at 2:15:05 PM UTC+3, Mosè Giordano wrote:
>
> Hi Kaj,
>
> thanks for your question, it served me as inspiration to add another 
> example to the manual: 
> https://cubajl.readthedocs.org/en/latest/#passing-data-to-the-integrand-function
>
> Bye,
> Mosè
>
>
> 2016-04-13 5:14 GMT+02:00 Steven G. Johnson  >:
>
>>
>>
>> On Tuesday, April 12, 2016 at 4:51:07 PM UTC-4, Kaj Wiik wrote:
>>>
>>> Very nice work indeed!
>>>
>>> Is it possible to pass 'userdata' to integrand in Julia? It is mentioned 
>>> in sources but is not listed in keywords.
>>>
>>
>> You don't need an explicit userdata argument -- this is just a crude 
>> simulation of closures in C, but Julia has true closures and lexical 
>> scoping.
>>
>> For example
>>
>>
>> myvar = 7
>> Vegas( (x,f) -> f[1] = log(x[1] + myvar)/sqrt(x[1]), 1, 1)
>>
>>
>> will "capture" the value of myvar and pass it through Vegas to the 
>> integrand, via the closure.
>>
>
>

Re: [julia-users] Int or Int64

[Mauro]

Also, note that floats work the same on both 32 and 64 bit machines (and
both default to making Float64).  Concerning ints: use Int64 if you need
them for your code to be correct, otherwise use Int.  (Maybe best to
just use Int64 to be on the save side?)

This has been discussed on this list before, a search could turn up more
details.

On Wed, 2016-04-13 at 11:09, vincent leclere  wrote:
> Hi all,
>
> quick question: I am building a package and has been defining types with
> Int64 or Float64 properties.
> Is there any reason why I should be using Int and Float instead ? (Does
> Int64 work on 32bits processors ?)
> Will it be at the price of efficiency loss ?
>
> Thanks

Re: [julia-users] scoping wat

[Didier Verna]

I wrote:

> Consider for example embedding a for loop in a macro, and the risk for
> variable capture.

  Forget that. Macros seem to be hygienic.

-- 
ELS'16 registration open! http://www.european-lisp-symposium.org

Lisp, Jazz, Aïkido: http://www.didierverna.info

[julia-users] Re: Need help with GR and PyPlot

[Josef Heinen]

To solve the PyPlot backend problem, I made a PR (Add support for the GR 
backend #207 ) . This patch 
solved the problem for me.

To fix the savefig() problem, please checkout the GR.jl master ( Pkg.
checkout("GR")) and/or rebuild the package.
There was a configuration error on my build system (for OS X) which I 
didn't realize. Sorry!

Regards,
Josef

On Wednesday, April 13, 2016 at 1:34:31 AM UTC+2, Daniel Carrera wrote:
>
> Hello,
>
> So... GR is a new plotting framework that is faster than Matplotlib and 
> can be used as a backend for Matplotlib, including Julia's PyPlot package.
>
> https://github.com/jheinen/gr
> http://gr-framework.org/tutorials/matplotlib.html
>
> I have installed GR,
>
> > Pkg.add("GR")
>
> and my reading of the second link is that all I have to do to get 
> Matplotlib to use GR is change an environment variable:
>
> export MPLBACKEND="module://gr.matplotlib.backend_gr"
>
>
> So I did that, but that doesn't seem to have changed anything in PyPlot:
>
> julia> using PyPlot
>
> julia> plt[:get_backend]()
> "TkAgg"
>
> julia> plt[:switch_backend]()
>
> ERROR ... valid backends are ['pdf', 'pgf', 'Qt4Agg', 'Gtk' ...] 
>
>
> So it looks like I'm missing some steps. I don't know whether the problem 
> is on the Julia side or the Python side. Does anyone know how to get PyPlot 
> to work with GR?
>
>
> On a related note, I tried using GR on its own. It went well until I tried 
> to save.
>
> julia> using GR
> ...
> julia> savefig("plot.png")
> GKS: Ghostscript support not compiled in
>
>
> Since GKS was installed by `Pkg.add()`, I don't know how I'm supposed to 
> recompile it with Ghostscript support. Does anyone know?
>
>
> Thanks for the help.
>
> Cheers,
> Daniel.
>

[julia-users] Re: Need help with GR and PyPlot

[Josef Heinen]

To solve the PyPlot backend problem, I made a PR. This patch solved the 
problem for me.

To fix the ``savefig`` problem, please checkout the GR.jl master 
(``Pkg.checkout("GR")``) and/or rebuild the package.
There was a configuration error on my build system (for OS X) which I 
didn't realize. Sorry!

Regards,
Josef

On Wednesday, April 13, 2016 at 1:34:31 AM UTC+2, Daniel Carrera wrote:
>
> Hello,
>
> So... GR is a new plotting framework that is faster than Matplotlib and 
> can be used as a backend for Matplotlib, including Julia's PyPlot package.
>
> https://github.com/jheinen/gr
> http://gr-framework.org/tutorials/matplotlib.html
>
> I have installed GR,
>
> > Pkg.add("GR")
>
> and my reading of the second link is that all I have to do to get 
> Matplotlib to use GR is change an environment variable:
>
> export MPLBACKEND="module://gr.matplotlib.backend_gr"
>
>
> So I did that, but that doesn't seem to have changed anything in PyPlot:
>
> julia> using PyPlot
>
> julia> plt[:get_backend]()
> "TkAgg"
>
> julia> plt[:switch_backend]()
>
> ERROR ... valid backends are ['pdf', 'pgf', 'Qt4Agg', 'Gtk' ...] 
>
>
> So it looks like I'm missing some steps. I don't know whether the problem 
> is on the Julia side or the Python side. Does anyone know how to get PyPlot 
> to work with GR?
>
>
> On a related note, I tried using GR on its own. It went well until I tried 
> to save.
>
> julia> using GR
> ...
> julia> savefig("plot.png")
> GKS: Ghostscript support not compiled in
>
>
> Since GKS was installed by `Pkg.add()`, I don't know how I'm supposed to 
> recompile it with Ghostscript support. Does anyone know?
>
>
> Thanks for the help.
>
> Cheers,
> Daniel.
>

[julia-users] Re: Need help with GR and PyPlot

[Josef Heinen]

I made a PR (Add support for the GR backend #207 
) to enable GR support for 
the PyPlot library. It would be nice if the changes could be merged.

I don't know, why showing the plot should freeze everything else.

Changing the backend to GR did speed-up the following animation example by 
a factor > 3:

ENV["MPLBACKEND"] = "module://gr.matplotlib.backend_gr"

import PyPlot

x = collect(0:0.01:2*pi)
line, = PyPlot.plot(x, sin(x))

for i = 1:200
line[:set_ydata](sin(x + i / 10.0))
PyPlot.draw()
PyPlot.pause(0.0001)
end


Thanks in advance,

Josef


On Wednesday, April 13, 2016 at 5:11:21 AM UTC+2, Steven G. Johnson wrote:
>
> The PyPlot library doesn't currently support the GR backend, mainly 
> because it doesn't know how to do event loops for this backend (which is 
> important for interactive plotting, so that showing the plot doesn't freeze 
> everything else). 
>
> As I understand it, GR can use Qt or wx for the UI?  In which case PyCall 
> does implement these event loops, and PyPlot just needs to be able to 
> figure out which event loop to start.
>

Re: [julia-users] How to load data from a *.mat file on all workers in Julia 0.4.5 without require()?

['Jhan Jar' via julia-users]

Thanks Tim,

The second link helped me figure out the issue(s)/bug(s).
Really appreciate you guys!

On Tuesday, April 12, 2016 at 3:54:58 PM UTC+5, Tim Holy wrote:
>
> This is covered is multiple previous posts to the mailing list. 
>
> https://groups.google.com/forum/#!searchin/julia-users/@everywhere$20using/julia-users/5Xf7duBT6WI/Q8sCr44qBwAJ
>  
> https://groups.google.com/d/msg/julia-users/KKscQCby0GM/cOr2Dr3aAAAJ 
>
> Best, 
> --Tim 
>
> On Tuesday, April 12, 2016 03:41:48 AM 'Jhan Jar' via julia-users wrote: 
> > Hi, 
> > 
> > In Julia 0.3.5, the following loaded data on all workers: 
> > 
> > addprocs(3) 
> > require("data_loading_script.jl") 
> > 
> > Contents of my data_loading_script.jl were akin to: 
> > 
> > using MAT 
> > source_file = matopen(data_filename) 
> > 
> > var1 = read(source_file, "var1"); 
> > var2 = read(source_file, "var2") 
> > . 
> > . 
> > varN = read(source_file, "varN") 
> > 
> > close(source_file) 
> > 
> > Now, to make it work without require() in Julia 0.4.5 I changed 
> > data_loading_script.jl 
> > to: 
> >   @everywhere begin 
> > using MAT 
> > source_file = matopen(data_filename) 
> > 
> > var1 = read(source_file, "var1"); 
> > var2 = read(source_file, "var2") 
> > . 
> > . 
> > varN = read(source_file, "varN") 
> > 
> > close(source_file) 
> >   end 
> > 
> > And when I do a include("data_loading_script.jl"), the data/vars get 
> loaded 
> > on all workers, but the REPL displays: 
> > 
> > WARNING: replacing module MAT 
> > WARNING: Method definition read(Union{HDF5.HDF5Group, HDF5.HDF5Datatype, 
> > HDF5.HD 
> > F5Dataset}, Type{Bool}) in module MAT_HDF5 at 
> > C:\Users\XYZ\.julia\v0.4\MAT\src\MA 
> > T_HDF5.jl:565 overwritten in module MAT_HDF5 at 
> > C:\Users\XYZ\.julia\v0.4\MAT\src\ 
> > MAT_HDF5.jl:565. 
> > WARNING: Method definition read(Union{HDF5.HDF5Group, HDF5.HDF5Datatype, 
> > HDF5.HD 
> > F5Dataset}, Type{Array{Bool, N<:Any}}) in module MAT_HDF5 at 
> > C:\Users\XYZ\.julia\ 
> > v0.4\MAT\src\MAT_HDF5.jl:569 overwritten in module MAT_HDF5 at 
> > C:\Users\XYZ\.juli 
> > a\v0.4\MAT\src\MAT_HDF5.jl:569. 
> > WARNING: replacing module MAT 
> > WARNING: Method definition read(Union{HDF5.HDF5Group, HDF5.HDF5Datatype, 
> > HDF5.HD 
> > F5Dataset}, Type{Bool}) in module MAT_HDF5 at 
> > C:\Users\XYZ\.julia\v0.4\MAT\src\MA 
> > T_HDF5.jl:565 overwritten in module MAT_HDF5 at 
> > C:\Users\XYZ\.julia\v0.4\MAT\src\ 
> > MAT_HDF5.jl:565. 
> > WARNING: Method definition readWARNING: replacing module MAT 
> > (Union{HDF5.HDF5Group, HDF5WARNING: Method definition 
> > read.(HDF5DatatypeUnion, { 
> > HDF5HDF5..HDF5DatasetHDF5Group}, , HDF5Type.{HDF5DatatypeArray, 
> {HDF5Bool., 
> > HDF5 
> > DatasetN<:}Any, }Type}{)Bool in module MAT_HDF5} at 
> > C:\Users\XYZ\.julia\v0.4\MAT\ 
> > src\MAT_HDF5.jl:569) overwritten in module MAT_HDF5 in module MAT_HDF5 
> at 
> > C:\Use 
> > rs\XYZ\.julia\v0.4\MAT\src\MAT_HDF5.jl:569 at 
> > C:\Users\XYZ\.julia\v0.4\MAT\src\MAT 
> > _HDF5.jl:565. 
> >  overwritten in module MAT_HDF5 at 
> > C:\Users\XYZ\.julia\v0.4\MAT\src\MAT_HDF5.jl:5 
> > 65. 
> > WARNING: Method definition read(Union{HDF5.HDF5Group, HDF5.HDF5Datatype, 
> > HDF5.HD 
> > F5Dataset}, Type{Array{Bool, N<:Any}}) in module MAT_HDF5 at 
> > C:\Users\XYZ\.julia\ 
> > v0.4\MAT\src\MAT_HDF5.jl:569 overwritten in module MAT_HDF5 at 
> > C:\Users\XYZ\.juli 
> > a\v0.4\MAT\src\MAT_HDF5.jl:569. 
> > 
> > 
> > What am I doing wrong? 
> > 
> > Thanks. 
>
>

Re: [julia-users] Re: [ANN] Cuba.jl: library for multidimensional numerical integration

[Mosè Giordano]

Hi Kaj,

thanks for your question, it served me as inspiration to add another
example to the manual:
https://cubajl.readthedocs.org/en/latest/#passing-data-to-the-integrand-function

Bye,
Mosè


2016-04-13 5:14 GMT+02:00 Steven G. Johnson :

>
>
> On Tuesday, April 12, 2016 at 4:51:07 PM UTC-4, Kaj Wiik wrote:
>>
>> Very nice work indeed!
>>
>> Is it possible to pass 'userdata' to integrand in Julia? It is mentioned
>> in sources but is not listed in keywords.
>>
>
> You don't need an explicit userdata argument -- this is just a crude
> simulation of closures in C, but Julia has true closures and lexical
> scoping.
>
> For example
>
>
> myvar = 7
> Vegas( (x,f) -> f[1] = log(x[1] + myvar)/sqrt(x[1]), 1, 1)
>
>
> will "capture" the value of myvar and pass it through Vegas to the
> integrand, via the closure.
>

[julia-users] Re: [ANN] Cuba.jl: library for multidimensional numerical integration

[Kaj Wiik]

On Wednesday, April 13, 2016 at 6:14:29 AM UTC+3, Steven G. Johnson wrote:
 

> You don't need an explicit userdata argument -- this is just a crude 
> simulation of closures in C, but Julia has true closures and lexical 
> scoping.
>
> For example
>
>
> myvar = 7
> Vegas( (x,f) -> f[1] = log(x[1] + myvar)/sqrt(x[1]), 1, 1)
>
>
> will "capture" the value of myvar and pass it through Vegas to the 
> integrand, via the closure.
>

Ah, of course. Some Julia magic :-).

Thanks!

Kaj
 

Re: [julia-users] scoping wat

[Didier Verna]

Jeff Bezanson  wrote:

> Yes, one could argue that a `for` loop variable should always be a new
> variable, but that does make the constructs less orthogonal.

  It's funny that you see this as less orthogonal, considering that, as
  Stefan pointed out, your "for" index will leak its final
  value. Consider for example embedding a for loop in a macro, and the
  risk for variable capture. Sounds pretty anti-orthogonal to me...


> In any case I don't see how this is "do or don't, it depends". Depends
> on what?

  Is the i in for(i=1:3) local to the loop? It depends (on whether there
  is an outer i or not).

  Does assignment create a binding? It depends (on the construct you're
  in). E.g.
  julia> if true; k = 10 end # -> 10
  julia> k # -> 10
  julia> let; l = 10 end # -> 10
  julia> l # -> ERROR: UndefVarError: l not defined

  Does assignment in a function create a local binding? It depends (on
  whether the function is nested).

  etc.

-- 
ELS'16 registration open! http://www.european-lisp-symposium.org

Lisp, Jazz, Aïkido: http://www.didierverna.info

[julia-users] Re: Int or Int64

['Bill Hart' via julia-users]

Int is either Int32 or Int64, depending on the machine. Int64 does still 
seem to be defined on a 32 bit machine. In fact, even Int128 is defined. 
But of course it is going to have to emulate processor instructions to do 
64 bit arithmetic unless the machine actually has such instructions. So it 
could well be quite a bit slower.

On Wednesday, 13 April 2016 11:09:27 UTC+2, vincent leclere wrote:
>
> Hi all,
>
> quick question: I am building a package and has been defining types with 
> Int64 or Float64 properties.
> Is there any reason why I should be using Int and Float instead ? (Does 
> Int64 work on 32bits processors ?)
> Will it be at the price of efficiency loss ?
>
> Thanks
>

Re: [julia-users] scoping wat

[Didier Verna]

Jeff Bezanson  wrote:

> It works this way because we didn't want to require all variables to
> be explicitly introduced with a construct like `var x = 0`. This adds
> a lot of noise to a program and is annoying to those used to python or
> matlab.

  I see your point and I understand the concern for Python or Matlab
  users. You see local declarations as noise whereas as I see it as
  explicit intent. I still have a hard time digesting the fact that
  assignment creates new local bindings, but not always though ;-)

-- 
ELS'16 registration open! http://www.european-lisp-symposium.org

Lisp, Jazz, Aïkido: http://www.didierverna.info

[julia-users] Int or Int64

[vincent leclere]

Hi all,

quick question: I am building a package and has been defining types with 
Int64 or Float64 properties.
Is there any reason why I should be using Int and Float instead ? (Does 
Int64 work on 32bits processors ?)
Will it be at the price of efficiency loss ?

Thanks

Re: [julia-users] local types or macros?

[Didier Verna]

Tamas Papp  wrote:

> My perception is that simply pointing out that something is different
> in Common Lisp is unlikely to move the Julia language team to make
> fundamental changes to the language

  ... which is not my intention. I'm simply curious about the language,
  and when I see something different from what I'm used to or which
  surprises me, I'm asking questions to get a better understanding.

  Is all ;-)

-- 
ELS'16 registration open! http://www.european-lisp-symposium.org

Lisp, Jazz, Aïkido: http://www.didierverna.info

Re: [julia-users] Creating an empty 2D array and append values to it

['Greg Plowman' via julia-users]

> julia> reshape(d,3,2)

3x2 Array{ASCIIString,2}:

 "x1"  "y2"

 "y1"  "x3"

 "x2"  "y3"


This is because of Julia's column-major ordering.

you see the problem ? instead I would like to have :

x1 y1

x2 y2

..

xn yn 


In this case, you could use:

julia> reshape(d,2,3)'
3x2 Array{ASCIIString,2}:
 "x1"  "y1"
 "x2"  "y2"
 "x3"  "y3"



On Wednesday, April 13, 2016 at 12:38:41 AM UTC+10, Fred wrote:

> Thank you very much Tim !
>
> In fact I want to create an X,Y array so if I create a 1D array, I can 
> only append to it (x1,y1) then (x2,y2)... (xn, yn), because I calculate x1 
> before x2...
>
> julia> d = ["x1", "y1", "x2", "y2", "x3", "y3"]
> 6-element Array{ASCIIString,1}:
>  "x1"
>  "y1"
>  "x2"
>  "y2"
>  "x3"
>  "y3"
>
> julia> reshape(d,3,2)
> 3x2 Array{ASCIIString,2}:
>  "x1"  "y2"
>  "y1"  "x3"
>  "x2"  "y3"
>
> you see the problem ? instead I would like to have :
> x1 y1
> x2 y2
> ..
> xn yn 
>
> because I want to be able to work on columns and line ... of course 
> another easy solution is to use dataframes, but I tried with arrays because 
> the code should be faster... :)
>
> Le mardi 12 avril 2016 16:27:50 UTC+2, Tim Holy a écrit :
>>
>> Note that in `a = Array{Float64,2}`, `a` is a *type*, not an *instance*. 
>> You 
>> presumably mean `a = Array(Float64, 0, 0)`. 
>>
>> But Yichao is right that you can't grow a 2d array, only a 1d one. 
>>
>> Best, 
>> --Tim 
>>
>

Re: [julia-users] local types or macros?

[Tamas Papp]

Hi Didier,

It is good to see some familiar names from comp.lang.lisp :D

I switched to Julia from Lisp a while ago, expecting it to be some kind
of Common Lisp with Dylan-like surface syntax, only faster and with
parametric types.

It isn't, and while Common Lisp influenced the design considerably,
Julia made a lot of different choices, most of them consciously: either
to make the language more familiar for people migrating from
Matlab/R/etc, or to make it easier to optimize, or just because they
liked it that way.

My perception is that simply pointing out that something is different in
Common Lisp is unlikely to move the Julia language team to make
fundamental changes to the language, or even to introduce new
constructs. On the other hand, from reading the discussions on the issue
tracker, it seems that well thought-out examples of real-world problems,
especially if they come with a suggestion for a solution, are more
likely to get sympathetic attention.

So if you use Julia for a while and feel that it should have a construct
equivalent to macrolet, maybe you could write up a detailed proposal,
with code examples from Base or libraries, and how it would simplify
things.

Best,

Tamas

On Wed, Apr 13 2016, Didier Verna wrote:

> Cedric St-Jean  wrote:
>
>> Local macros in Lisp are expanded at compile-time. They're useful
>> inside macro-expansions, eg.
>
> Not even inside other macros, but as local macros inside any kind of
> code block. E.g. (silly):
>
> CL-USER> (let (list)
>  (macrolet ((add (element) `(push ,element list)))
>(add 3)
>(add 2)
>(add 1)))
> (1 2 3)
> CL-USER> 

Re: [julia-users] local types or macros?

[Didier Verna]

Cedric St-Jean  wrote:

> Local macros in Lisp are expanded at compile-time. They're useful
> inside macro-expansions, eg.

Not even inside other macros, but as local macros inside any kind of
code block. E.g. (silly):

CL-USER> (let (list)
   (macrolet ((add (element) `(push ,element list)))
 (add 3)
 (add 2)
 (add 1)))
(1 2 3)
CL-USER> 

-- 
ELS'16 registration open! http://www.european-lisp-symposium.org

Lisp, Jazz, Aïkido: http://www.didierverna.info

Re: [julia-users] Re: [ANN] Cuba.jl: library for multidimensional numerical integration

[Mosè Giordano]

Hi Oliver,

2016-04-12 21:38 GMT+02:00 Oliver Schulz :
> Very nice, Mose! I thought I might have to write a Julia wrapper for Cuba at
> some point, but you beat me to it (which I'm grateful for!). :-)

Thanks!

> I noticed that you're maintaining a modified version of Cuba for this - I
> guess because the upstream Cuba doesn't support "make shared"?

Yes, exactly, these are the differences with vanilla Cuba Library:
https://github.com/giordano/cuba/compare/julia  Only configure and
makefile are involved.

> Are you in
> contact with Thomas? He may be willing to add that - if you like, I can ask,
> his office is two floors up from mine. ;-)

I had been in contact with him in the past, and I think I'll contact
him very soon again.

Ciao,
Mosè

Re: [julia-users] Re: [ANN] Cuba.jl: library for multidimensional numerical integration

[Mosè Giordano]

Hi Chris,

thanks for your comments :-)  Regarding integration algorithm, unless you
have specific reasons to use Vegas I warmly recommend to use Cuhre, which
in my experience is the best in terms of speed and precision.  There must
be a reason if Cubature,jl, the only widely used numerical integration
packages so far, implements the same algorithm ;-)  Only once I found
Divonne more useful because I had a wild function with peaks in known
positions and you can tell Divonne to increase sampling around those points.

Bye,
Mosè


2016-04-12 19:08 GMT+02:00 Chris Rackauckas :

> Nice! I was looking for a Vegas function awhile ago and the GSL.jl one
> isn't bound correctly yet. This will be a nice addition to the Julia
> package list. Good job!
>
> On Sunday, April 10, 2016 at 1:34:53 PM UTC-7, Mosè Giordano wrote:
>>
>> Dear all,
>>
>> I am proud to announce Cuba.jl  a
>> library for multidimensional numerical integration with four independent
>> algorithms: Vegas, Suave, Divonne, and Cuhre (this algorithm is the same
>> used in Cubature.jl).  This package is just a wrapper around Cuba Library
>> , written in C by Thomas Hahn.
>>
>> Cuba.jl is a registered Julia package, so you can install it with the
>> package manager:
>>
>> Pkg.add("Cuba")
>>
>> The package is usable, but I must admit user interface is not optimal.
>> One has to define a function of this type:
>>
>> function integrand(ndim::Cint, xx::Ptr{Cdouble}, ncomp::Cint, ff::Ptr{
>> Cdouble},
>>userdata::Ptr{Void})
>> # Take arrays from "xx" and "ff" pointers.
>> x = pointer_to_array(xx, (ndim,))
>> f = pointer_to_array(ff, (ncomp,))
>> # Do calculations on "f" here
>> #   ...
>> # Store back the results to "ff"
>> ff = pointer_from_objref(f)
>> return Cint(0)::Cint
>> end
>>
>> and then call one of the four integrator functions available with this
>> syntax:
>>
>> Vegas(integrand, ndim, ncomp[, keywords...])
>> Suave(integrand, ndim, ncomp[, keywords...])
>> Divonne(integrand, ndim, ncomp[, keywords...])
>> Cuhre(integrand, ndim, ncomp[, keywords...])
>>
>> Issue #3  tracks this
>> problem, if someone wants to help on this is warmly welcome.
>>
>> Documentation of the package is available at
>> https://cubajl.readthedocs.org/ and you can also download the PDF
>> version of the manual from
>> https://media.readthedocs.org/pdf/cubajl/latest/cubajl.pdf  In
>> particular, there is a section with some useful examples:
>> https://cubajl.readthedocs.org/en/latest/#examples
>>
>> Even though Cuba.jl does not support parallelization (see issue #1
>> ), its performance is
>> comparable with those of equivalent codes written in C or Fortran relying
>> on Cuba Library: https://github.com/giordano/Cuba.jl#performance
>>
>> Cuba.jl is released under the terms of LGPLv3 and is available for
>> GNU/Linux and OS X (Windows support is currently missing
>> , Cubature.jl is a better
>> alternative for that platform).
>>
>> Feel free to share your comments and suggestions on this package!
>>
>> Cheers,
>> Mosè
>>
>

Re: [julia-users] Re: Setting min()=Inf and max()=-Inf

[Milan Bouchet-Valat]

Le mardi 12 avril 2016 à 20:21 -0700, Anonymous a écrit :
> Those are good points, although I always kind of wondered why Float
> gets Inf while Int doesn't, I guess there's no way to have Inf belong
> to 2 distinct concrete types.
The problem is that native integers have no way of representing
infinite values, contrary to floating point. They can only store actual
values. (But you can use floating point formats to store integer data
if you need Inf.)


Regards

> > 
> > > Have the Julia developers considered the effects of setting
> > > Base.min()=Inf and Base.max()=-Inf.  This is common in real
> > > analysis since it plays nice with set theory, i.e.
> > > 
> > It only plays nicely with sets of real numbers.  What about sets of
> > other types that have a total ordering?  e.g. strings?
> > 
> > Also, one of the general principles guiding the design of the Julia
> > standard library is to provide idioms that don't cause types to
> > change arbitrarily underneath the user; this principle is critical
> > to being able to use the standard library in high-performance code
> > (since type stability is critical to compiler optimization).  For
> > example min(1,2) == 1 (an Int), min(1) == 1 (an Int), but then
> > min() = Inf (floating-point)?
> >