[julia-users] Re: MethodError closest candidate is same as "no matching method" method

[michael]

I finally realized what I should have done and felt like an idiot for 
taking so long on this.

S = MatrixSpace(ZZ, 3, 3)
@eval @everywhere S=$S



On Wednesday, June 15, 2016 at 12:24:16 PM UTC-5, michael wrote:
>
> That would almost definitely be it. I had been using 
> @everywhere using Nemo
> as a hacky way of dealing with types not being defined on other processes. 
> I've read the documentation where it gives the example DummyModule and 
> talks about the scope but I've never really grasped the "correct" way to 
> create an object of custom type on multiples processes. If I wanted to have 
> an object S of type MatrixSpace on all processes it seems like it should be 
> something like
>
> for i = 1:nprocs()
>   S = RemoteRef(i)
>   put!(S, MatrixSpace(ZZ, 3, 3)
> end
>
> and then I could use S inside an @parallel loop? I'm sure something with 
> my syntax is off but is that the correct idea or am I off-base?
>
> On Tuesday, June 14, 2016 at 5:46:50 AM UTC-5, Toivo Henningsson wrote:
>>
>> Could it be that you happened to reload Nemo after using/importing it? 
>> This kind of thing can happen when there are two live instances of the same 
>> module and your code happens to combine types/functions from both.
>>
>

Re: [julia-users] Skylake support

[Yichao Yu]

On Thu, Jun 23, 2016 at 11:22 PM,   wrote:
> Anyone had success using Julia on Intel's Skylake processors?

Yes.

> I get some segfaults when using Julia (download precompiled) + Ubuntu 14.04.
> I also tried to compile it from source, but I get some segfaults when
> compiling LLVM.

Re: [julia-users] Skylake support

[Keno Fischer]

Are you sure that your computer's memory is ok? That sounds like a
suspicious number of segfaults.

On Thu, Jun 23, 2016 at 11:22 PM,   wrote:
> Anyone had success using Julia on Intel's Skylake processors?
> I get some segfaults when using Julia (download precompiled) + Ubuntu 14.04.
> I also tried to compile it from source, but I get some segfaults when
> compiling LLVM.

[julia-users] how can i rewrite my code to make use of the parallel feature of julia?

[博陈]

Below is part of my code, I wrote it with FFTW.set_num_threads() to get 
parallel fft calculation. However, the for loops "for eachindex" are just 
serial. Is it possible to rewrite the code in a parallel way? I don't know 
how to implement it with @parallel, SharedArray or the simple @spawn 
features. To me, the documentations is far from clear.


using JLD

function ground(ϕ0::Array{Complex{Float64},2}, dx::Float64
, dt::Float64)

FFTW.set_num_threads(CPU_CORES)

ns = size( ϕ0, 1)
x = get_x(ns, dx)
p = get_p(ns, dx)

# FFT plan
p_fft! = plan_fft!( similar(ϕ0), flags=FFTW.MEASURE )

prop_x = Array( Float64, ns , ns)
prop_p = similar( prop_x )

@inbounds for j in 1:ns
@inbounds for i in 1:ns
prop_x[i, j] = exp( -get_potential(x[i], x[j]) * dt / 2 )
prop_p[i, j] = exp( -(p[i]^2 + p[j]^2)/2.0 * dt )
end
end

normϕ = √(sumabs2(ϕ0)) * dx
scale!( ϕ0, 1 / normϕ )

ϕ2 = similar( ϕ0 )
Δϕ = Array(Float64, 0)
push!(Δϕ, 1.0)
nn = 0
while Δϕ[1] > 1.e-15
for j in eachindex(ϕ2)
ϕ2[j] = ϕ0[j] * prop_x[j]
end

p_fft! * ϕ2
for j in eachindex(ϕ2)
ϕ2[j] *= prop_p[j]
end

p_fft! \ ϕ2
for j in eachindex(ϕ2)
ϕ2[j] *= prop_x[j]
end

normϕ = √(sumabs2(ϕ2)) * dx
scale!( ϕ2, 1 / normϕ )

nn += 1

empty!(Δϕ)
push!(Δϕ, maxabs( ϕ2 - ϕ0 ))
ϕ0, ϕ2 = ϕ2, ϕ0
end

save("data/gs.jld", "ϕ", ϕ0)

ϕ0
end

[julia-users] Skylake support

[felipenoris]

Anyone had success using Julia on Intel's Skylake processors?
I get some segfaults when using Julia (download precompiled) + Ubuntu 14.04.
I also tried to compile it from source, but I get some segfaults when 
compiling LLVM.

[julia-users] how can i rewrite the code to make use of the parallel feature in julia?

[博陈]

This is my code, I wrote it with 

using ..Utils
using JLD

function ground(ϕ0::Array{Complex{Float64},2}, dx::Float64
, dt::Float64)

FFTW.set_num_threads(CPU_CORES)

ns = size( ϕ0, 1)
x = get_x(ns, dx)
p = get_p(ns, dx)

# FFT plan
p_fft! = plan_fft!( similar(ϕ0), flags=FFTW.MEASURE )

prop_x = Array( Float64, ns , ns)
prop_p = similar( prop_x )

@inbounds for j in 1:ns
@inbounds for i in 1:ns
prop_x[i, j] = exp( -get_potential(x[i], x[j]) * dt / 2 )
prop_p[i, j] = exp( -(p[i]^2 + p[j]^2)/2.0 * dt )
end
end

normϕ = √(sumabs2(ϕ0)) * dx
scale!( ϕ0, 1 / normϕ )

ϕ2 = similar( ϕ0 )
Δϕ = Array(Float64, 0)
push!(Δϕ, 1.0)
nn = 0
while Δϕ[1] > 1.e-15
for j in eachindex(ϕ2)
ϕ2[j] = ϕ0[j] * prop_x[j]
end

p_fft! * ϕ2
for j in eachindex(ϕ2)
ϕ2[j] *= prop_p[j]
end

p_fft! \ ϕ2
for j in eachindex(ϕ2)
ϕ2[j] *= prop_x[j]
end

normϕ = √(sumabs2(ϕ2)) * dx
scale!( ϕ2, 1 / normϕ )

nn += 1

empty!(Δϕ)
push!(Δϕ, maxabs( ϕ2 - ϕ0 ))
ϕ0, ϕ2 = ϕ2, ϕ0
end

save("data/gs.jld", "ϕ", ϕ0)

ϕ0
end

[julia-users] how to save array to text file "correctly"?

[Hoang-Ngan Nguyen]

Hi,

I have the following array
data = [
 -0.5 
 0.0 
 -2.18199e-5
 1.53967e-5
 -1.7899e-5 
 1.26717e-5
 -2.24327e-6
 1.60087e-6]


When I save it using either 

writecsv("filename.csv",data)

or

writedlm("filename.csv",data,",")


I get this
-.5
0
-21819881018654233e-21
153966589305464e-19
-17898976869144106e-21
12671715235247999e-21
-22432716786997375e-22
16008706220269127e-22

Is there anyway for me to, instead, get the following:
-.5
0
-.21819881018654233
.153966589305464
-.17898976869144106
.12671715235247999
-.022432716786997375
.016008706220269127

Thanks,
Ngan

Re: [julia-users] How to make a Matrix of Matrix's?

[Dan]

[[M] [M]] works.
And is the same as Matrix{Float64}[[M] [M]]

But concur it is unintuitive.

On Thursday, June 23, 2016 at 10:28:39 PM UTC-4, Sheehan Olver wrote:
>
>
> [M,M]  will do a Vector of Matrices in 0.5.   But [M M] still does 
> concatenation.  So the question is how to do Matrices of Matrices without 
> concatinating. 
>
>
>
>
> > On 24 Jun 2016, at 12:05 PM, Lutfullah Tomak  > wrote: 
> > 
> > By default [M M] (without delimeter like , or ;) means concatenation so 
> it throws error. But I think in julia 0.5 [M, M] should do Matrix of 
> Matricies. 
>
>

Re: [julia-users] How to make a Matrix of Matrix's?

[Sheehan Olver]

[M,M]  will do a Vector of Matrices in 0.5.   But [M M] still does 
concatenation.  So the question is how to do Matrices of Matrices without 
concatinating.




> On 24 Jun 2016, at 12:05 PM, Lutfullah Tomak  wrote:
> 
> By default [M M] (without delimeter like , or ;) means concatenation so it 
> throws error. But I think in julia 0.5 [M, M] should do Matrix of Matricies.

[julia-users] How to make a Matrix of Matrix's?

[Lutfullah Tomak]

By default [M M] (without delimeter like , or ;) means concatenation so it 
throws error. But I think in julia 0.5 [M, M] should do Matrix of Matricies.

Re: [julia-users] How to make a Matrix of Matrix's?

[Miguel Bazdresch]

You can simplify the declaration as follows:

MM = Matrix(Matrix(1,2))

You can use comprehensions too:

MM = [ randn(5,5) for x=1:2, y=1 ]

Here, MM has two rows and one column, and each of its elements is a 5x5
matrix.

-- mb


On Thu, Jun 23, 2016 at 9:28 PM, Sheehan Olver 
wrote:

> This caught me by surprise:
>
>
> *julia> **M=rand(5,5)*
>
> *5x5 Array{Float64,2}:*
>
> * 0.621195  0.301080.611089  0.880044  0.779199*
>
> * 0.100477  0.0581337  0.198601  0.639252  0.400357*
>
> * 0.716917  0.179181   0.548913  0.787072  0.157769*
>
> * 0.971473  0.981921   0.307854  0.201917  0.290429*
>
> * 0.43822   0.362467   0.160296  0.725931  0.850726*
>
>
> *julia> **Matrix{Float64}[M M]*
>
> *ERROR: MethodError: `convert` has no method matching
> convert(::Type{Array{Float64,2}}, ::Float64)*
>
> *This may have arisen from a call to the constructor
> Array{Float64,2}(...),*
>
> *since type constructors fall back to convert methods.*
>
> Closest candidates are:
>
>   call{T}(::Type{T}, ::Any)
>
>   convert{T,S,N}(::Type{Array{T,N}},
> *::SubArray{S,N,P<:AbstractArray{T,N},I<:Tuple{Vararg{Union{AbstractArray{T,1},Colon,Int64}}},LD}*
> )
>
>   convert{T,n}(::Type{Array{T,n}}, *::Array{T,n}*)
>
>   ...
>
>  in copy! at abstractarray.jl:344
>
>  in typed_hcat at abstractarray.jl:784
>
>
> What's the correct way to do this?  The following works but is not ideal:
>
> *julia> **MM=Matrix{Matrix{Float64}}(1,2)*
>
> *1x2 Array{Array{Float64,2},2}:*
>
> * #undef  #undef*
>
>
> *julia> **MM[1,1]=M;MM[1,2]=M*
>
>
>
>
>

[julia-users] How to make a Matrix of Matrix's?

[Sheehan Olver]

This caught me by surprise:


*julia> **M=rand(5,5)*

*5x5 Array{Float64,2}:*

* 0.621195  0.301080.611089  0.880044  0.779199*

* 0.100477  0.0581337  0.198601  0.639252  0.400357*

* 0.716917  0.179181   0.548913  0.787072  0.157769*

* 0.971473  0.981921   0.307854  0.201917  0.290429*

* 0.43822   0.362467   0.160296  0.725931  0.850726*


*julia> **Matrix{Float64}[M M]*

*ERROR: MethodError: `convert` has no method matching 
convert(::Type{Array{Float64,2}}, ::Float64)*

*This may have arisen from a call to the constructor Array{Float64,2}(...),*

*since type constructors fall back to convert methods.*

Closest candidates are:

  call{T}(::Type{T}, ::Any)

  convert{T,S,N}(::Type{Array{T,N}}, 
*::SubArray{S,N,P<:AbstractArray{T,N},I<:Tuple{Vararg{Union{AbstractArray{T,1},Colon,Int64}}},LD}*
)

  convert{T,n}(::Type{Array{T,n}}, *::Array{T,n}*)

  ...

 in copy! at abstractarray.jl:344

 in typed_hcat at abstractarray.jl:784


What's the correct way to do this?  The following works but is not ideal:

*julia> **MM=Matrix{Matrix{Float64}}(1,2)*

*1x2 Array{Array{Float64,2},2}:*

* #undef  #undef*


*julia> **MM[1,1]=M;MM[1,2]=M*

RE: [julia-users] Re: VS code extension

[David Anthoff]

I added a gitter room for the VS Code plugin, maybe best to move further 
discussion of the extension there: 
https://gitter.im/JuliaEditorSupport/julia-vscode.

 

I have a prototype  up and running for sending selected or individual lines of 
code from the editor to a REPL via Ctrl+Enter. All very rough at this point and 
for a smooth story it will need some work on Microsoft’s part, but generally it 
is pretty straightforward to get something up and running. 
https://github.com/JuliaEditorSupport/julia-vscode/pull/2

 

Cheers,

David

 

From: julia-users@googlegroups.com [mailto:julia-users@googlegroups.com] On 
Behalf Of David Anthoff
Sent: Thursday, June 23, 2016 12:07 PM
To: julia-users@googlegroups.com
Subject: RE: [julia-users] Re: VS code extension

 

Yes, VS Code does feel a lot snappier than Atom. I never had problem with 
installation or updating with Atom, though.

 

Right now the VS Code plugin is very bare and has hardly any features (syntax 
highlighting, latex completion, and one command to open a package in a new 
window). Right now I mostly feel that it is good to have some bare bones 
support for VS Code. I don’t know whether there is enough man power/interest to 
ever try to get it into a polished thing that supports more of the VS Code 
extension points for languages. While I’ll maintain the extension, I have no 
plans for major development.

 

PRs are welcome, though!

 

Cheers,

David

 

From: julia-users@googlegroups.com   
[mailto:julia-users@googlegroups.com] On Behalf Of Tony Kelman
Sent: Wednesday, June 22, 2016 8:11 PM
To: julia-users  >
Subject: [julia-users] Re: VS code extension

 

VS Code feels much snappier and higher performance to me than Atom, especially 
on larger files. If you're on Windows especially, the installation and updating 
experience is just a lot more polished and customizable. The downside is 
there's been a lot less work on Julia-specific addin integration so far.


On Wednesday, June 22, 2016 at 10:36:58 PM UTC-4, Gabriel Gellner wrote:

Are there benefits to using this over atom? Why are people moving over? Pros, 
Cons?

On Tuesday, June 21, 2016 at 3:26:52 PM UTC-7, David Anthoff wrote:

Hi all,

 

I’ve created a new github repo for a VS code extension 
https://github.com/davidanthoff/julia-vscode and it is published here 
https://marketplace.visualstudio.com/items?itemName=julialang.language-julia. 
Be5invis will delete the old julia extension from the marketplace because he is 
no longer maintaining it. At this point my extension has zero additional 
features over his old one, except that there is a public github repo where in 
theory people could contribute.

 

Two questions:

1) could we move the github repo under some official julia organization? I know 
most other editor plugins are under julialang, but I also remember talk about 
creating something like a juliaeditor org or something like that? In any case, 
I would like to move the repo to something more official. I’m happy to maintain 
it for the foreseeable future, so no fear on that front.

2) I used the julia logo. I hope that is ok from a copyright point of view? I 
took it from the repo for the julia homepage, and that whole repo seemed to be 
under an MIT license, but just wanted to be sure.

 

And if anyone wants to add stuff to the extension, PRs are welcome! Especially 
a debug adapter would of course be fantastic.

 

Cheers,

David 

 

--

David Anthoff

University of California, Berkeley

 

http://www.david-anthoff.com

 

[julia-users] Hide and disable REPL

[David Anthoff]

Hi,

 

is there a way to switch off the REPL and then on again, from a task?

 

Specifically, I want to start a julia instance and pass a script in with the
-L parameter that will open a socket, listen for connections and the process
messages from that socket. This server listening code is all wrapped in
@async macro calls. So when I start things this way, julia shows the REPL
and at the same time listens for incoming messages. I can use the REPL etc.
This is exactly what I want.

 

But when I receive a message, I want to temporarily switch the REPL off,
i.e. it should visually disappear while I process that message, and then I
want to switch it back on once I'm done processing that message.

 

Can that be done somehow?

 

Thanks,

David

 

--

David Anthoff

University of California, Berkeley

 

http://www.david-anthoff.com

 

Re: [julia-users] indexing over `zip(collection1, collection2)`

[Mauro]

My recollection is that part of the indexing interface in Julia (just by
convention) is that indexing should be of O(1) (or close to that)
complexity.  Iterable things, in general, have O(n) complexity to access
the n-th element, because you have to traverse the data to get there
(the classic example are linked lists).  Thus, it makes sense that
indexing is not supported, instead you have to call collect first if you
want to index.

On Thu, 2016-06-23 at 20:43, Davide Lasagna  wrote:
> Hi Jacob,
>
> In my view, in principle, all "iterators" should be indexable, (at least
> read-only), *unless *the underlying data is not indexable by nature, e.g.
> with data that comes from a stream...  Doing `zip([1, 2], [2, 3])[1]`
> should probably just work.
>
> I also think that for `Zip`s if the zipped collections are not indexable,
> then the "outer" getindex method should fail internally with a MethodError,
> on the "inner" getindex calls not implemented for the non-indexable
> collections.
>
> On Thursday, June 23, 2016 at 7:23:34 PM UTC+1, Jacob Quinn wrote:
>>
>> Sorry, to clarify a little:
>>
>> The things you're zipping are not necessarily indexable (i.e. other
>> iterators), so it's not safe to assume you can always index a Zip.
>>
>> On Thu, Jun 23, 2016 at 2:21 PM, Jacob Quinn > > wrote:
>>
>>> Most "iterator" types are not indexable, AFAIK. The typical
>>> recommendation/idiom is to just call `collect(itr)` if you need to
>>> specifically index.
>>>
>>> -Jacob
>>>
>>> On Thu, Jun 23, 2016 at 2:18 PM, Davide Lasagna >> > wrote:
>>>
 Is there any particular reason why `Zip` objects are iterable but not
 indexable? Python allows that.

 From previous discussion on the topic (2014 topic at
 https://groups.google.com/forum/#!topic/julia-dev/5bgMvzJveWA) it seems
 that it has not been implemented yet.

 Thanks,



>>>
>>

Re: [julia-users] Re: indexing over `zip(collection1, collection2)`

[Davide Lasagna]

Yes, I meant python 2.x

On Thursday, June 23, 2016 at 8:06:20 PM UTC+1, Yichao Yu wrote:
>
> On Thu, Jun 23, 2016 at 2:53 PM, Jussi Piitulainen  > wrote: 
> > 
> > 
> > torstai 23. kesäkuuta 2016 21.18.22 UTC+3 Davide Lasagna kirjoitti: 
> >> 
> >> Is there any particular reason why `Zip` objects are iterable but not 
> >> indexable? Python allows that. 
> >> 
> > 
> > Does Python now allow that? I'm still on 3.4 and didn't see anything 
> > relevant in the "What's new" for 3.5. 
>
> I guess it's probably about python2 where zip isn't an iterator at all. 
>

Re: [julia-users] Re: indexing over `zip(collection1, collection2)`

[Yichao Yu]

On Thu, Jun 23, 2016 at 2:53 PM, Jussi Piitulainen  wrote:
>
>
> torstai 23. kesäkuuta 2016 21.18.22 UTC+3 Davide Lasagna kirjoitti:
>>
>> Is there any particular reason why `Zip` objects are iterable but not
>> indexable? Python allows that.
>>
>
> Does Python now allow that? I'm still on 3.4 and didn't see anything
> relevant in the "What's new" for 3.5.

I guess it's probably about python2 where zip isn't an iterator at all.

RE: [julia-users] Re: VS code extension

[David Anthoff]

Yes, VS Code does feel a lot snappier than Atom. I never had problem with 
installation or updating with Atom, though.

 

Right now the VS Code plugin is very bare and has hardly any features (syntax 
highlighting, latex completion, and one command to open a package in a new 
window). Right now I mostly feel that it is good to have some bare bones 
support for VS Code. I don’t know whether there is enough man power/interest to 
ever try to get it into a polished thing that supports more of the VS Code 
extension points for languages. While I’ll maintain the extension, I have no 
plans for major development.

 

PRs are welcome, though!

 

Cheers,

David

 

From: julia-users@googlegroups.com [mailto:julia-users@googlegroups.com] On 
Behalf Of Tony Kelman
Sent: Wednesday, June 22, 2016 8:11 PM
To: julia-users 
Subject: [julia-users] Re: VS code extension

 

VS Code feels much snappier and higher performance to me than Atom, especially 
on larger files. If you're on Windows especially, the installation and updating 
experience is just a lot more polished and customizable. The downside is 
there's been a lot less work on Julia-specific addin integration so far.


On Wednesday, June 22, 2016 at 10:36:58 PM UTC-4, Gabriel Gellner wrote:

Are there benefits to using this over atom? Why are people moving over? Pros, 
Cons?

On Tuesday, June 21, 2016 at 3:26:52 PM UTC-7, David Anthoff wrote:

Hi all,

 

I’ve created a new github repo for a VS code extension 
https://github.com/davidanthoff/julia-vscode and it is published here 
https://marketplace.visualstudio.com/items?itemName=julialang.language-julia. 
Be5invis will delete the old julia extension from the marketplace because he is 
no longer maintaining it. At this point my extension has zero additional 
features over his old one, except that there is a public github repo where in 
theory people could contribute.

 

Two questions:

1) could we move the github repo under some official julia organization? I know 
most other editor plugins are under julialang, but I also remember talk about 
creating something like a juliaeditor org or something like that? In any case, 
I would like to move the repo to something more official. I’m happy to maintain 
it for the foreseeable future, so no fear on that front.

2) I used the julia logo. I hope that is ok from a copyright point of view? I 
took it from the repo for the julia homepage, and that whole repo seemed to be 
under an MIT license, but just wanted to be sure.

 

And if anyone wants to add stuff to the extension, PRs are welcome! Especially 
a debug adapter would of course be fantastic.

 

Cheers,

David 

 

--

David Anthoff

University of California, Berkeley

 

http://www.david-anthoff.com

 

Re: [julia-users] JuliaCon birds of a feather

[AK]

Any chance there are notes or minutes available?

On Thursday, June 23, 2016 at 12:17:27 PM UTC-4, Alex Williams wrote:
>
> Shoot. Sorry to have missed this.
>
> Hope to catch up on these topics at the Hackathon, or after the conference 
> tonight. Let me know!
>
> -- Alex
>
> On Wednesday, June 22, 2016 at 5:43:52 PM UTC-4, Josh Day wrote:
>>
>> Sounds great, I'm in.  I'd be especially interested in talking about 
>> LearnBase.
>>
>

[julia-users] Re: indexing over `zip(collection1, collection2)`

[Jussi Piitulainen]

torstai 23. kesäkuuta 2016 21.18.22 UTC+3 Davide Lasagna kirjoitti:
>
> Is there any particular reason why `Zip` objects are iterable but not 
> indexable? Python allows that.
>
>
Does Python now allow that? I'm still on 3.4 and didn't see anything 
relevant in the "What's new" for 3.5.

Re: [julia-users] indexing over `zip(collection1, collection2)`

[Davide Lasagna]

Hi Jacob, 

In my view, in principle, all "iterators" should be indexable, (at least 
read-only), *unless *the underlying data is not indexable by nature, e.g. 
with data that comes from a stream...  Doing `zip([1, 2], [2, 3])[1]` 
should probably just work.

I also think that for `Zip`s if the zipped collections are not indexable, 
then the "outer" getindex method should fail internally with a MethodError, 
on the "inner" getindex calls not implemented for the non-indexable 
collections.

On Thursday, June 23, 2016 at 7:23:34 PM UTC+1, Jacob Quinn wrote:
>
> Sorry, to clarify a little:
>
> The things you're zipping are not necessarily indexable (i.e. other 
> iterators), so it's not safe to assume you can always index a Zip.
>
> On Thu, Jun 23, 2016 at 2:21 PM, Jacob Quinn  > wrote:
>
>> Most "iterator" types are not indexable, AFAIK. The typical 
>> recommendation/idiom is to just call `collect(itr)` if you need to 
>> specifically index.
>>
>> -Jacob
>>
>> On Thu, Jun 23, 2016 at 2:18 PM, Davide Lasagna > > wrote:
>>
>>> Is there any particular reason why `Zip` objects are iterable but not 
>>> indexable? Python allows that.
>>>
>>> From previous discussion on the topic (2014 topic at 
>>> https://groups.google.com/forum/#!topic/julia-dev/5bgMvzJveWA) it seems 
>>> that it has not been implemented yet. 
>>>
>>> Thanks,
>>>
>>>
>>>
>>
>

Re: [julia-users] indexing over `zip(collection1, collection2)`

[Jacob Quinn]

Sorry, to clarify a little:

The things you're zipping are not necessarily indexable (i.e. other
iterators), so it's not safe to assume you can always index a Zip.

On Thu, Jun 23, 2016 at 2:21 PM, Jacob Quinn  wrote:

> Most "iterator" types are not indexable, AFAIK. The typical
> recommendation/idiom is to just call `collect(itr)` if you need to
> specifically index.
>
> -Jacob
>
> On Thu, Jun 23, 2016 at 2:18 PM, Davide Lasagna 
> wrote:
>
>> Is there any particular reason why `Zip` objects are iterable but not
>> indexable? Python allows that.
>>
>> From previous discussion on the topic (2014 topic at
>> https://groups.google.com/forum/#!topic/julia-dev/5bgMvzJveWA) it seems
>> that it has not been implemented yet.
>>
>> Thanks,
>>
>>
>>
>

Re: [julia-users] indexing over `zip(collection1, collection2)`

[Jacob Quinn]

Most "iterator" types are not indexable, AFAIK. The typical
recommendation/idiom is to just call `collect(itr)` if you need to
specifically index.

-Jacob

On Thu, Jun 23, 2016 at 2:18 PM, Davide Lasagna 
wrote:

> Is there any particular reason why `Zip` objects are iterable but not
> indexable? Python allows that.
>
> From previous discussion on the topic (2014 topic at
> https://groups.google.com/forum/#!topic/julia-dev/5bgMvzJveWA) it seems
> that it has not been implemented yet.
>
> Thanks,
>
>
>

[julia-users] indexing over `zip(collection1, collection2)`

[Davide Lasagna]

Is there any particular reason why `Zip` objects are iterable but not 
indexable? Python allows that.

>From previous discussion on the topic (2014 topic 
at https://groups.google.com/forum/#!topic/julia-dev/5bgMvzJveWA) it seems 
that it has not been implemented yet. 

Thanks,

[julia-users] Re: Installing with Intel compiler

[Tony Kelman]

We'd welcome notes or adjustments if necessary to keep the Intel compilers 
working. We don't test against them very often at all. If the license 
agreement or the hardware resources we had available allowed us to do so, 
we'd like to test more regularly and ensure the build system and code works 
properly with Intel tools.


On Thursday, June 23, 2016 at 9:54:12 AM UTC-4, Victor Eijkhout wrote:
>
> Ok, feel free to close this ticket. By putting enough gcc stuff in the 
> path I managed to get it to install in the Intel compiler. At least I think 
> it's doing that. The configure messages are still quite ambiguous.
>
> V.
>

Re: [julia-users] define `scale!(::Float64, ::Real)` ?

[Davide Lasagna]

Thanks, I thought about that. That is why the method definition I wrote 
works like `scale` (which is deprecated), rather than `scale!`. 

This is more of a programming problem rather than a conceptual one. 
Probably, I could just do something along the lines of

if isa(out, Number)
out *= 42
else
scale!(out, 42)
end



On Thursday, June 23, 2016 at 6:42:41 PM UTC+1, Stefan Karpinski wrote:
>
> This method cannot be implemented since numbers are immutable.
>
> On Thu, Jun 23, 2016 at 1:20 PM, Davide Lasagna  > wrote:
>
>> I have a function that operates on an AbstractVector object `fs`, defined 
>> like this:
>>
>> function foo{T}(fs::AbstractVector{T})
>> out = zero(T)
>> for f in fs
>> # do some with out and f, e.g. sum
>> end
>> scale!(out, 42)
>> end
>>
>> This code should be generic, and the eltype `T` could be a number, e.g., 
>> a Float64, or a vector, e.g. Vector{Float64}. The function loops over the 
>> entries of `fs` and then scales the `out` variable by a magic number 42. 
>>
>> The above definition works well when `T` is a vector, but fails when `T` 
>> is a scalar with a MethodError, as scale! does not have a method when both 
>> inputs are numbers. A possible method definition would be something along 
>> the lines of
>>
>> scale!(a::Number, b::Number) = a*b
>>
>> Probably `scale!` is not the right way to implement this. Any suggestions 
>> that apply to 0.4 and/or 0.5 are very welcome!
>>
>> Thanks
>>
>>
>

Re: [julia-users] Re: Calling Fortran in Julia Windows 10 - dlopen Error

[Kaela Martin]

It was the cross-compiler problem. It worked when I compiled it using
mignw-w64 compilers.

Thanks!
Kaela

On Wed, Jun 22, 2016 at 8:06 PM, Tony Kelman  wrote:

> Most likely you're missing one of the dependency dll's (or Julia can't
> find it). Check in Dependency Walker and/or cygcheck to see which it is -
> probably the libgfortran dll. Also note that since Julia itself is built
> using mingw-w64 compilers, trying to load libraries built by the standard
> cygwin compilers may be unreliable. You can install the cross-compiler
> package mingw64-x86_64-gcc-fortran from Cygwin's setup.exe, then invoke
> x86_64-w64-mingw32-gfortran rather than just gfortran and you'll get a dll
> that is more likely to be compatible with Julia.
>
>
>
> On Wednesday, June 22, 2016 at 5:45:49 PM UTC-4, Kaela Martin wrote:
>>
>> I'm trying to get Julia to run a Fortran file on Windows 10, and Julia
>> says that it can't open the library. Libdl.dlopen also fails to open the
>> file. I've tried adding the current path to LOAD_PATH but still get the
>> same error.
>>
>> For a test case, I'm running the following module:
>>
>> module hello_module
>> use iso_c_binding
>> implicit none
>> contains
>>
>> subroutine hello() bind(C,name="hello")
>> !DEC$ ATTRIBUTES DLLEXPORT :: hello
>>   write(*,'(A)') "Hello World!!!"
>> end subroutine hello
>>
>> end module hello_module
>>
>> I'm compiling it in Cygwin64 (I'm on a 64bit Windows 10 machine) using
>> gfortran with:
>>
>> gfortran -shared -o2 -fPIC Hello.f90 -o HelloWorld.dll
>>
>> I get a warning that -fPIC is ignored, but the file compiles and creates
>> HelloWorld.dll
>>
>> In Julia, I call the library using
>>
>> ccall((:hello,"HelloWorld.dll"),Void,())
>>
>> which results in:
>>
>> ERROR: could not load library "HelloWorld.dll"
>> The specified module could not be found.
>>
>>  in dlopen at libdl.jl:36 (repeats 2 times)
>>  in dlopen at deprecated.jl:32
>>
>> Just trying to open the module using Libdl.dlopen("HelloWorld.dll")
>> gives the same error.
>>
>> Note that I moved the .dll file to a new location after compiling it
>> since the goal is to put the code in a single folder that other users can
>> put on their windows machines and run.
>>
>> How do I get Julia to open and run the code?
>>
>> Thanks,
>> Kaela
>>
>

Re: [julia-users] define `scale!(::Float64, ::Real)` ?

[Stefan Karpinski]

This method cannot be implemented since numbers are immutable.

On Thu, Jun 23, 2016 at 1:20 PM, Davide Lasagna 
wrote:

> I have a function that operates on an AbstractVector object `fs`, defined
> like this:
>
> function foo{T}(fs::AbstractVector{T})
> out = zero(T)
> for f in fs
> # do some with out and f, e.g. sum
> end
> scale!(out, 42)
> end
>
> This code should be generic, and the eltype `T` could be a number, e.g., a
> Float64, or a vector, e.g. Vector{Float64}. The function loops over the
> entries of `fs` and then scales the `out` variable by a magic number 42.
>
> The above definition works well when `T` is a vector, but fails when `T`
> is a scalar with a MethodError, as scale! does not have a method when both
> inputs are numbers. A possible method definition would be something along
> the lines of
>
> scale!(a::Number, b::Number) = a*b
>
> Probably `scale!` is not the right way to implement this. Any suggestions
> that apply to 0.4 and/or 0.5 are very welcome!
>
> Thanks
>
>

Re: [julia-users] A question of style: type constructors vs methods

[Nathan Smith]

Hi Gabriel, 

If you're types often have default values you may want to take a look 
Parameters.jl  for a neat and 
useful implementation of types with default values.

As for the Bar() constructor, is may be odd for future people looking at 
your code to have a constructor like method that doesn't correspond to a 
type. 

-Nathan

On Tuesday, 21 June 2016 14:49:40 UTC-4, Gabriel Gellner wrote:
>
> Ugh keyboard error.
>
> So lets say I have the type
>
> type Foo
> field1
> field2
> end
>
> So I have my nice constructors dealing with all the ways I want to create 
> Foo types, but then I want a specialized Foo that has field2 set to some 
> special value that has a special sub meaning from my default Foo. Say I 
> have a default constructor for Foo like
>
> Foo(;field1=, field2=)
>
> But I want to have a different default, so I call this
> Bar(;field1=, field2=) = Foo(field1, field2)
>
> My question! Really this is an abuse of the naming guide, as Bar is really 
> a method, not a type constructor with the same name as the type, but I 
> guess I am thinking about this as a kind of specialized type of Foo, hence 
> the uppercase, but should I instead do
>
> bar(...)
>
> when I am returning these kind of specialized versions of Foo?
>
> On Tuesday, June 21, 2016 at 11:44:07 AM UTC-7, Gabriel Gellner wrote:
>>
>> So going deeper into using my own types, and coding style in julia.
>>
>> Lets say I have the container type
>>
>> type Foo
>>
>>
>> On Monday, June 20, 2016 at 7:10:15 AM UTC-7, Gabriel Gellner wrote:
>>>
>>> That was what I was feeling. That this was a legacy issue for lowercase 
>>> type "constructors". Thanks so much.
>>>
>>> On Monday, June 20, 2016 at 1:11:41 AM UTC-7, Mauro wrote:

 I think you should use the constructors if the user expects to 
 construct 
 a certain type, e.g. `Dict()`.  Conversely if the user cares about the 
 action then use a function, e.g.: 

 julia> keys(Dict()) 
 Base.KeyIterator for a Dict{Any,Any} with 0 entries 

 here I don't care about the type, I just want to iterate the keys. 

 But of course, it's not that clear-cut: `linspace` has history, so does 
 `zeros`.  So, for a new container type I'd use the constructor 
 `FooBar`. 

 On Sun, 2016-06-19 at 23:12, Gabriel Gellner  
 wrote: 
 > I am currently making some container like types, so I am using the 
 > convention of studly caps for  the types ie `FooBar`. For usage I am 
 > confused on what the julian convention is for having expressive type 
 > constructors like for `Dict` and `DataFrame`, versus using methods 
 like 
 > `linspace`. Clearly I could use either, but it is not clear to me 
 when I 
 > should use one convention over the other. 
 > 
 > Clearly I can have my api be like: 
 > 
 > f = FooBar(...) 
 > 
 > or 
 > 
 > f = foobar() 
 > 
 > but is one preferred over the other? Is it just random when to use 
 one or 
 > the other when making container like types? 

>>>

[julia-users] define `scale!(::Float64, ::Real)` ?

[Davide Lasagna]

I have a function that operates on an AbstractVector object `fs`, defined 
like this:

function foo{T}(fs::AbstractVector{T})
out = zero(T)
for f in fs
# do some with out and f, e.g. sum
end
scale!(out, 42)
end

This code should be generic, and the eltype `T` could be a number, e.g., a 
Float64, or a vector, e.g. Vector{Float64}. The function loops over the 
entries of `fs` and then scales the `out` variable by a magic number 42. 

The above definition works well when `T` is a vector, but fails when `T` is 
a scalar with a MethodError, as scale! does not have a method when both 
inputs are numbers. A possible method definition would be something along 
the lines of

scale!(a::Number, b::Number) = a*b

Probably `scale!` is not the right way to implement this. Any suggestions 
that apply to 0.4 and/or 0.5 are very welcome!

Thanks

Re: [julia-users] JuliaCon birds of a feather

[Alex Williams]

Shoot. Sorry to have missed this.

Hope to catch up on these topics at the Hackathon, or after the conference 
tonight. Let me know!

-- Alex

On Wednesday, June 22, 2016 at 5:43:52 PM UTC-4, Josh Day wrote:
>
> Sounds great, I'm in.  I'd be especially interested in talking about 
> LearnBase.
>

Re: [julia-users] how to get all combination of rows in array

[programistawpf]

BigTHX, 

W dniu czwartek, 23 czerwca 2016 12:04:40 UTC+2 użytkownik Tamas Papp 
napisał:
>
> vcat(unique([A[i,:] for i in 1:size(A,1)])...) 
>
> On Thu, Jun 23 2016, programistawpf wrote: 
>
> > Thx, like below: 
> > How to crate one matix of result? 
> > 
> > julia> unique([A[i,:] for i in 1:size(A,1)]) 
> > 10-element Array{Any,1}: 
> >  1x3 Array{Int64,2}: 
> >  0  4  4 
> >  1x3 Array{Int64,2}: 
> >  4  2  0 
> >  1x3 Array{Int64,2}: 
> >  1  4  3 
> >  1x3 Array{Int64,2}: 
> >  2  5  1 
> >  1x3 Array{Int64,2}: 
> >  2  2  2 
> >  1x3 Array{Int64,2}: 
> >  2  2  3 
> >  1x3 Array{Int64,2}: 
> >  3  0  1 
> >  1x3 Array{Int64,2}: 
> >  4  1  4 
> >  1x3 Array{Int64,2}: 
> >  4  4  1 
> >  1x3 Array{Int64,2}: 
> >  1  3  4 
> > 
> > W dniu czwartek, 23 czerwca 2016 11:36:47 UTC+2 użytkownik Tamas Papp 
> > napisał: 
> >> 
> >> unique([A[i,:] for i in 1:size(A,1)]) 
> >> 
> >> you can make it faster by using sub, convert to vectors, etc, depending 
> >> on what you need it for. 
> >> 
> >> On Thu, Jun 23 2016, programistawpf wrote: 
> >> 
> >> > how to get all combination of rows in array ? 
> >> > 
> >> > 10x3 Array{Int64,2}: 
> >> >  0  4  4 
> >> >  4  2  0 
> >> >  1  4  3 
> >> >  2  5  1 
> >> >  2  2  2 
> >> >  2  2  3 
> >> >  3  0  1 
> >> >  4  1  4 
> >> >  4  4  1 
> >> >  1  3  4 
> >> > 
> >> > i.e... 
> >> > 001 
> >> > 014 
> >> > 020 
> >> > ect 
> >> > Paul 
> >> 
>

[julia-users] Re: Installing with Intel compiler

[Victor Eijkhout]

Ok, feel free to close this ticket. By putting enough gcc stuff in the path 
I managed to get it to install in the Intel compiler. At least I think it's 
doing that. The configure messages are still quite ambiguous.

V.

Re: [julia-users] async web socket read & write?

[Jon Norberg]

Thanks, that works perfectly

[julia-users] Re: Julia 0.4.6 Windows 32bits not run

[Tony Kelman]

Did the error mention "side by side configuration"? It sounds like this is an 
unintended consequence of a change I made so that PyCall would work better. For 
now you can either install 0.4.5 or find the MSVC 2008 runtime redistributable 
package and install that. We'll try to make this optional with future versions 
so only people who want to use PyCall need to worry about it.

[julia-users] Solver does not support quadratic solver .

[Tony Kelman]

This is a better question for the julia-opt mailing list, where I think you 
already posted.

Re: [julia-users] Re: Help with a macro

[Mosè Giordano]

Hi Mauro,

2016-06-22 21:13 GMT+02:00 Mauro:
>
> A REPL session of mine trying to figure out how to make that macro would 
> look something like this: 
>
> julia> ex = :(f(x, y, z, zz)) # this is what is passed into the macro 
> :(f(x,y,z,zz)) 
>
> julia> xdump(ex)  # xdump is nice to get an overview of nested 
> datastructures 
> Expr 
>   head: Symbol call 
>   args: Array(Any,(5,)) 
> 1: Symbol f 
> 2: Symbol x 
> 3: Symbol y 
> 4: Symbol z 
> 5: Symbol zz 
>   typ: Any::DataType  <: Any 
>

I knew and used "dump" but not "xdump".  I've seen that the latter has been 
deprecated in favor of the former in Julia 0.5.
 

> julia> target = :(f([x.re, y.re, z.re, zz.re].^2 + [x.im, y.im, z.im, 
> zz.im])) # this is your target 
> :(f([x.re,y.re,z.re,zz.re] .^ 2 + [x.im,y.im,z.im,zz.im])) 
>
> julia> xdump(target) 
> Expr 
>   head: Symbol call 
>   args: Array(Any,(2,)) 
> 1: Symbol f 
> 2: Expr 
>   head: Symbol call 
>   args: Array(Any,(3,)) 
> 1: Symbol + 
> 2: Expr 
>   head: Symbol call 
>   args: Array(Any,(3,)) 
>   typ: Any::DataType  <: Any 
> 3: Expr 
>   head: Symbol vect 
>   args: Array(Any,(4,)) 
>   typ: Any::DataType  <: Any 
>   typ: Any::DataType  <: Any 
>   typ: Any::DataType  <: Any 
>
>
> Now, writing the macro is really an exercise in manipulating nested data 
> structures.  With the added bonus that there are convenient constructors 
> for those datastructures, namely expression such as e.g. :(z = 4 +7). 
>
> julia> fn = ex.args[1] # extract the name of the function 
> :f 
>
> julia> args = ex.args[2:end] # its arguments 
> 4-element Array{Any,1}: 
>  :x 
>  :y 
>  :z 
>  :zz 
>
> julia> ar1 =:([])  # build up the first array 
> :([]) 
>
> julia> ar1.head # check 
> :vect 
>
> julia> [push!(ar1.args, :($(args[i]).re)) for i=1:length(args)] #add the 
> elements 
> 4-element Array{Any,1}: 
>  Any[:(x.re),:(y.re),:(z.re),:(zz.re)] 
>  Any[:(x.re),:(y.re),:(z.re),:(zz.re)] 
>  Any[:(x.re),:(y.re),:(z.re),:(zz.re)] 
>  Any[:(x.re),:(y.re),:(z.re),:(zz.re)] 
>
> julia> ar1 
> :([x.re,y.re,z.re,zz.re]) 
>
> julia> :($ar1^2) # square 
> :([x.re,y.re,z.re,zz.re] ^ 2) 
>
> etc. 
>
> It takes a bit of practice and patience.  Important, as Kristoffer said, 
> write out and test the code you expect the macro to form (at least until 
> you become a macro ninja), then write the macro.  For instance in one of 
> my projects I hand wrote all of the code I later built macros to 
> generate: 
> https://github.com/mauro3/Traits.jl/blob/master/test/manual-traitdef.jl 
>

Thank you so much, I've been able to change my "@uncertain" macro for 
Measurements.jl  package 
following your hints.  In the end, the trick was to quote rather than to 
evaluate the array of arguments.  Probably this is a good rule of thumb 
when writing macros.

Bye,
Mosè

Re: [julia-users] variables - qubit

[Stefan Karpinski]

I think you accidentally posted the same link twice.

On Thu, Jun 23, 2016 at 2:50 AM, Stirling Newberry <
stirling.newbe...@gmail.com> wrote:

> I am checking out variables.. I am looking for how to bridge
> Variable (mathematics) - Wikipedia, the free encyclopedia
> 
> into this
> Variable (mathematics) - Wikipedia, the free encyclopedia
> 
>
> esp. *qubit*
>

[julia-users] variables - qubit

[Stirling Newberry]

I am checking out variables.. I am looking for how to bridge
Variable (mathematics) - Wikipedia, the free encyclopedia 

into this
Variable (mathematics) - Wikipedia, the free encyclopedia 


esp. *qubit*

Re: [julia-users] how to get all combination of rows in array

[Tamas Papp]

vcat(unique([A[i,:] for i in 1:size(A,1)])...)

On Thu, Jun 23 2016, programistawpf wrote:

> Thx, like below:
> How to crate one matix of result?
>
> julia> unique([A[i,:] for i in 1:size(A,1)])
> 10-element Array{Any,1}:
>  1x3 Array{Int64,2}:
>  0  4  4
>  1x3 Array{Int64,2}:
>  4  2  0
>  1x3 Array{Int64,2}:
>  1  4  3
>  1x3 Array{Int64,2}:
>  2  5  1
>  1x3 Array{Int64,2}:
>  2  2  2
>  1x3 Array{Int64,2}:
>  2  2  3
>  1x3 Array{Int64,2}:
>  3  0  1
>  1x3 Array{Int64,2}:
>  4  1  4
>  1x3 Array{Int64,2}:
>  4  4  1
>  1x3 Array{Int64,2}:
>  1  3  4
>
> W dniu czwartek, 23 czerwca 2016 11:36:47 UTC+2 użytkownik Tamas Papp
> napisał:
>>
>> unique([A[i,:] for i in 1:size(A,1)])
>>
>> you can make it faster by using sub, convert to vectors, etc, depending
>> on what you need it for.
>>
>> On Thu, Jun 23 2016, programistawpf wrote:
>>
>> > how to get all combination of rows in array ?
>> >
>> > 10x3 Array{Int64,2}:
>> >  0  4  4
>> >  4  2  0
>> >  1  4  3
>> >  2  5  1
>> >  2  2  2
>> >  2  2  3
>> >  3  0  1
>> >  4  1  4
>> >  4  4  1
>> >  1  3  4
>> >
>> > i.e...
>> > 001
>> > 014
>> > 020
>> > ect
>> > Paul
>>

Re: [julia-users] how to get all combination of rows in array

[programistawpf]

Thx, like below:
How to crate one matix of result?

julia> unique([A[i,:] for i in 1:size(A,1)])
10-element Array{Any,1}:
 1x3 Array{Int64,2}:
 0  4  4
 1x3 Array{Int64,2}:
 4  2  0
 1x3 Array{Int64,2}:
 1  4  3
 1x3 Array{Int64,2}:
 2  5  1
 1x3 Array{Int64,2}:
 2  2  2
 1x3 Array{Int64,2}:
 2  2  3
 1x3 Array{Int64,2}:
 3  0  1
 1x3 Array{Int64,2}:
 4  1  4
 1x3 Array{Int64,2}:
 4  4  1
 1x3 Array{Int64,2}:
 1  3  4

W dniu czwartek, 23 czerwca 2016 11:36:47 UTC+2 użytkownik Tamas Papp 
napisał:
>
> unique([A[i,:] for i in 1:size(A,1)]) 
>
> you can make it faster by using sub, convert to vectors, etc, depending 
> on what you need it for. 
>
> On Thu, Jun 23 2016, programistawpf wrote: 
>
> > how to get all combination of rows in array ? 
> > 
> > 10x3 Array{Int64,2}: 
> >  0  4  4 
> >  4  2  0 
> >  1  4  3 
> >  2  5  1 
> >  2  2  2 
> >  2  2  3 
> >  3  0  1 
> >  4  1  4 
> >  4  4  1 
> >  1  3  4 
> > 
> > i.e... 
> > 001 
> > 014 
> > 020 
> > ect 
> > Paul 
>

Re: [julia-users] how to get all combination of rows in array

[Tamas Papp]

unique([A[i,:] for i in 1:size(A,1)])

you can make it faster by using sub, convert to vectors, etc, depending
on what you need it for.

On Thu, Jun 23 2016, programistawpf wrote:

> how to get all combination of rows in array ?
>
> 10x3 Array{Int64,2}:
>  0  4  4
>  4  2  0
>  1  4  3
>  2  5  1
>  2  2  2
>  2  2  3
>  3  0  1
>  4  1  4
>  4  4  1
>  1  3  4
>
> i.e...
> 001
> 014
> 020
> ect
> Paul

[julia-users] Re: Indicating Fortran path dependencies the correct way?

[Charles Ll]

Ok thanks! 

Yes I will have a look at Dierckx.jl, see if I can figure out how it does 
it.

Le jeudi 23 juin 2016 13:00:57 UTC+10, Tony Kelman a écrit :
>
> You have a few options. You can save the location of the library to a 
> module-level const variable and use that in your ccall's, or use BinDeps to 
> write the path of the found library (if any) to a generated file. I believe 
> Dierckx.jl is an example of using the former, where the library just gets 
> built or extracted to a known relative path w.r.t. the src of the package.
>
>
> On Wednesday, June 22, 2016 at 10:22:08 PM UTC-4, Charles Ll wrote:
>>
>> Dear all,
>>
>> I use a Fortran code in my package Spectra.jl, it is working really 
>> nicely. However, I still use the absolute library path in ccall. From 
>> discussion in the Gitter, I know that I could use eval, but my ccall is in 
>> a function so as eval works on global variables, it seems not appropriate...
>>
>> So my question is, how can we properly provide the shared library path to 
>> the ccall function, with keeping in mind that this process needs some 
>> flexibility, required for instance by the installation of the package on 
>> different OS? This seems particularly important when trying to distribute 
>> my package. For now, users have to change manually the path in the 
>> installed package, which seems a bad situation...
>>
>> I'm sure that this has already done for Fortran library such as the 
>> LAPACK library for instance, but despite having looked at the Github for 
>> the LAPACK wrapper, I don't understand how this is implemented...
>>
>> So if you have any insides, this will be greatly appreciated!
>>
>> Best,
>> Charles.
>>
>>
>>

[julia-users] how to get all combination of rows in array

[programistawpf]

how to get all combination of rows in array ?

10x3 Array{Int64,2}:
 0  4  4
 4  2  0
 1  4  3
 2  5  1
 2  2  2
 2  2  3
 3  0  1
 4  1  4
 4  4  1
 1  3  4

i.e...
001
014
020 
ect
Paul

[julia-users] Solver does not support quadratic solver .

[tannirind]

Hello,

After coming this error i add SCS solver . But the same error is happening 
. How can i remove ?

Thank you !

Best Regards,
Tanveer Iqbal