Re: [julia-users] Re: MongoDB and Julia

[Kevin Squire]

I would suggest CMongo.jl (when renaming this, be careful if you're on a
case-insensitive filesystem).  Of the fully capitalized names in Julia,
most of them imply that they are acronyms.

Suggestion: at this point, there isn't much code in the repo.  Since not
many people have (publicly) responded to your posts, IMHO, it would be good
to try to get a basic working system in place, and post your progress when
something basic is working--this will make it easier for people to
contribute.

One more thing you should look at is Clang.jl, which makes wrapping C
libraries easier.

Cheers!
   Kevin

On Tue, Jul 28, 2015 at 5:21 PM, Kevin Liu  wrote:

> I'll name it CMONGO.jl
>
> On Tue, Jul 28, 2015 at 9:13 PM, Kevin Liu  wrote:
>
>> Any suggestions for the name? I just want to remember this will be a
>> wrapper around C Mongo.
>>
>> On Tue, Jul 28, 2015 at 9:10 PM, Kevin Liu 
>> wrote:
>>
>>> Hey Kevin,
>>>
>>> That's great. Thanks for the advice. On it right now.
>>>
>>> Cheers!
>>>
>>> On Tue, Jul 28, 2015 at 7:50 PM, Kevin Squire 
>>> wrote:
>>>
 Hi Kevin,

 If you plan to make this a Julia package (and I encourage you to do
 so), it would be good to look at the Julia package naming conventions
 .
 You might consider choosing a different name, generating a package
 skeleton, and moving the files in this repo there.  Alternatively, renaming
 that repo shouldn't be hard.

 (This isn't mentioned explicitly there, but dashes also won't work for
 Julia package names.)

 Cheers!
Kevin

 On Mon, Jul 27, 2015 at 8:28 PM, Kevin Liu 
 wrote:

> Hi Julia Users, feel free to contribute to the Julia wrapper of the C
> Mongo Driver, maintained by Mongo
>
> https://github.com/tenthdimension/Julia-C-Mongo
>
> This Julia wrapper is based on the Lua wrapper of the C Mongo Driver.
> Jesse Davis from MongoDB recommended I used it as a reference.
>
> On Thursday, July 23, 2015 at 8:26:14 PM UTC-3, Kevin Liu wrote:
>>
>> Thanks
>>
>> On Thursday, July 23, 2015 at 8:24:12 PM UTC-3,
>> tim@multiscalehn.com wrote:
>>>
>>> https://github.com/pzion/LibBSON.jl/pull/4
>>> https://github.com/pzion/Mongo.jl/pull/6
>>>
>>> On Thursday, July 23, 2015 at 3:28:17 PM UTC-7, Kevin Liu wrote:

 I'm sorry Tim, check this out
 https://github.com/10gen-labs/mongorover/issues/16

 Could you share how you made it work properly?

 On Wednesday, July 22, 2015 at 5:20:42 PM UTC-3, Kevin Liu wrote:
>
> Hi Tim, did it pass specs 1, 2, and part of 3? 4 hasn't been
> started yet.
>
> These new MongoDB drivers conform to published specifications.
>
> 1. Server Selection - Deciding which server to send database
> operations to in a MongoDB deployment.
> 2. Server Discovery and Monitoring - All the logic required to
> make a MongoDB application highly available.
> 3. CRUD API - The API for how we Create, Read, Update and Delete
> data from MongoDB.
> 4. Authentication - The rules for how to authenticate to MongoDB
> servers.
>
>
> https://www.mongodb.com/blog/post/announcing-next-generation-drivers-mongodb
>
> On Wednesday, July 22, 2015 at 4:30:00 PM UTC-3,
> tim@multiscalehn.com wrote:
>>
>> I have just made pull requests to pzion/LibBSON.jl and
>> pzion/Mongo.jl to fix the driver in v0.4. Works fine for me, after 
>> adding
>> @compats
>>
>> On Sunday, July 12, 2015 at 12:17:44 AM UTC-7, Kevin Liu wrote:
>>>
>>> Hi,
>>>
>>> I have Julia 0.3, Mongodb-osx-x86_64-3.0.4,
>>> and Mongo-c-driver-1.1.9 installed, but can't get Julia to access 
>>> the Mongo
>>> Client through this 'untestable' package
>>> https://github.com/pzion/Mongo.jl, according to
>>> http://pkg.julialang.org/.
>>>
>>> I have tried Lytol/Mongo.jl and the command require("Mongo.jl")
>>> can't open file Mongo.jl, or the auto-generated deps.jl.
>>>
>>> Is anyone having similar problems trying to make Julia work with
>>> Mongo?
>>>
>>> Thank you
>>>
>>> Kevin
>>>
>>

>>>
>>
>

[julia-users] Re: What reason is different result, when I change R code to Julia code? Thank you!

[Tony Kelman]

The reason is & and | operators are bitwise in Julia, and have a higher 
precedence than == and !=.

julia> 1 == 1 & 3 == 3
false
julia> 1 == 1 && 3 == 3
true
julia> (1 == 1) & (3 == 3)
true
julia> 1 & 3
1

There are a few issues on this, combining the scalar bitwise and 
array-elementwise meanings into the same & and | operators is not ideal and 
can lead to confusion here. When in doubt use extra parentheses around 
conditionals, and use && or || for scalar comparisons.


On Tuesday, July 28, 2015 at 10:17:26 PM UTC-7, meib...@163.com wrote:
>
> #R code
> f=c(0.5,0.5)
> n.al <- length(f)
> P.1 <- P.2 <- array(0,dim=rep(n.al,4))
> for(a2 in 1:n.al) for(a1 in 1:n.al)
> for(a3 in 1:n.al) for(a4 in 1:n.al)
> {
> if (a1==a3 & a2==a4)
> {
> P.2[a1,a2,a3,a4] <- f[a1]*f[a2]
> P.1[a1,a2,a3,a4] <- f[a1]*f[a2]*(f[a1]+f[a2])/2
> }
> if (a1==a3 & a2!=a4)
> {
> P.1[a1,a2,a3,a4] <- f[a1]*f[a2]*f[a4]/2
> }
> if (a1!=a3 & a2==a4)
> {
> P.1[a1,a2,a3,a4] <- f[a1]*f[a3]*f[a2]/2
> }
> }
> #julia code 
> f=Array(Float64,1,2)
> f[:,:]=0.5
> p1=Array(Float64,nal,nal,nal,nal)
> p2=Array(Float64,nal,nal,nal,nal)
> p1[:,:,:,:]=0.0
> p2[:,:,:,:]=0.0
> for (a2 = 1:nal)  for (a1 = 1:nal)
> for (a3 = 1:nal)  for (a4 = 1:nal)
>if (a1==a3 & a2==a4)
>   p2[a1,a2,a3,a4] = f[a1]*f[a2]
>   p1[a1,a2,a3,a4] = f[a1]*f[a2]*(f[a1]+f[a2])/2.0
>end
>
>if (a1==a3 & a2!=a4)
>   p1[a1,a2,a3,a4] = f[a1]*f[a2]*f[a4]/2.0
>end
>
>if (a1!=a3 & a2==a4)
>   p1[a1,a2,a3,a4] = f[a1]*f[a3]*f[a2]/2.0
>end
> end end
> end end 
>
>
> 
>
>

[julia-users] What reason is different result, when I change R code to Julia code? Thank you!

[meibujun]

#R code
f=c(0.5,0.5)
n.al <- length(f)
P.1 <- P.2 <- array(0,dim=rep(n.al,4))
for(a2 in 1:n.al) for(a1 in 1:n.al)
for(a3 in 1:n.al) for(a4 in 1:n.al)
{
if (a1==a3 & a2==a4)
{
P.2[a1,a2,a3,a4] <- f[a1]*f[a2]
P.1[a1,a2,a3,a4] <- f[a1]*f[a2]*(f[a1]+f[a2])/2
}
if (a1==a3 & a2!=a4)
{
P.1[a1,a2,a3,a4] <- f[a1]*f[a2]*f[a4]/2
}
if (a1!=a3 & a2==a4)
{
P.1[a1,a2,a3,a4] <- f[a1]*f[a3]*f[a2]/2
}
}
#julia code 
f=Array(Float64,1,2)
f[:,:]=0.5
p1=Array(Float64,nal,nal,nal,nal)
p2=Array(Float64,nal,nal,nal,nal)
p1[:,:,:,:]=0.0
p2[:,:,:,:]=0.0
for (a2 = 1:nal)  for (a1 = 1:nal)
for (a3 = 1:nal)  for (a4 = 1:nal)
   if (a1==a3 & a2==a4)
  p2[a1,a2,a3,a4] = f[a1]*f[a2]
  p1[a1,a2,a3,a4] = f[a1]*f[a2]*(f[a1]+f[a2])/2.0
   end
   
   if (a1==a3 & a2!=a4)
  p1[a1,a2,a3,a4] = f[a1]*f[a2]*f[a4]/2.0
   end
   
   if (a1!=a3 & a2==a4)
  p1[a1,a2,a3,a4] = f[a1]*f[a3]*f[a2]/2.0
   end
end end
end end 



#R code
f=c(0.5,0.5)
n.al <- length(f)
P.1 <- P.2 <- array(0,dim=rep(n.al,4))
for(a2 in 1:n.al) for(a1 in 1:n.al)
for(a3 in 1:n.al) for(a4 in 1:n.al)
{
if (a1==a3 & a2==a4)
{
P.2[a1,a2,a3,a4] <- f[a1]*f[a2]
P.1[a1,a2,a3,a4] <- f[a1]*f[a2]*(f[a1]+f[a2])/2
}
if (a1==a3 & a2!=a4)
{
P.1[a1,a2,a3,a4] <- f[a1]*f[a2]*f[a4]/2
}
if (a1!=a3 & a2==a4)
{
P.1[a1,a2,a3,a4] <- f[a1]*f[a3]*f[a2]/2
}
}
#julia code 
f=Array(Float64,1,2)
f[:,:]=0.5
p1=Array(Float64,nal,nal,nal,nal)
p2=Array(Float64,nal,nal,nal,nal)
p1[:,:,:,:]=0.0
p2[:,:,:,:]=0.0
for (a2 = 1:nal)  for (a1 = 1:nal)
for (a3 = 1:nal)  for (a4 = 1:nal)
   if (a1==a3 & a2==a4)
  p2[a1,a2,a3,a4] = f[a1]*f[a2]
  p1[a1,a2,a3,a4] = f[a1]*f[a2]*(f[a1]+f[a2])/2.0
   end
   
   if (a1==a3 & a2!=a4)
  p1[a1,a2,a3,a4] = f[a1]*f[a2]*f[a4]/2.0
   end
   
   if (a1!=a3 & a2==a4)
  p1[a1,a2,a3,a4] = f[a1]*f[a3]*f[a2]/2.0
   end
end end
end end 

Re: [julia-users] In what version is Julia supposed to "mature"?

[Tony Kelman]

I'm with Kevin, having followed development (too) closely for the last year 
and a half I find the prospect of 1.0 any time during 2016 totally 
ridiculous and unrelealistic. Unless you fully anticipate releasing 2.0 
some time in 2017.


On Tuesday, July 28, 2015 at 6:52:36 PM UTC-7, Stefan Karpinski wrote:
>
> That's literally the only part of that post that I would change :-)
>
> But no, I'm not trolling, 1.0 should be out next year. Predicting down to 
> the month – or even quarter – is hard, but that's what I think we're 
> looking at. I'll post a 1.0 roadmap issue soon.
>
> On Tue, Jul 28, 2015 at 6:56 PM, Kevin Squire  > wrote:
>
>> Stefan, are you trolling again?  ;-P
>>
>> http://julialang.org/blog/2012/02/why-we-created-julia/
>>
>> On Tue, Jul 28, 2015 at 12:41 PM, Stefan Karpinski > > wrote:
>>
>>> Version 1.0 will be released around this time next year.
>>>
>>> On Tue, Jul 28, 2015 at 3:27 PM, Pileas >> > wrote:
>>>
 Greetings,

 I have been following the development of Julia for sometime now and I 
 am really thrilled to know that you guys have reached version 0.3.11.

 To my understanding sometime in the near future you will release the 
 new version 0.4.0., a version that it is supposed to bring many changes. 

 My question is simple: when is Julia expected to "mature", so that a 
 "universal" (more or less) documentation (or maybe more thorough books 
 than 
 those that exist by now) will follow and less bug fixed will be needed?

 I wish you the best! 

>>>
>>>
>>
>

[julia-users] Method dispatch shootout

[felipenoris]

Maybe this is worth sharing. When considering using enums instead of types, 
I came up with 7 different ways to dispatch to methods, and these are the 
results of the performance tests.

The code is at: https://gist.github.com/felipenoris/660537161af33db34dcb

*Results:*

julia> include("enum-vs-dispatch.jl")
enums with switch code
 323.515 milliseconds
Dispatch via Val Type
   1.068 seconds  (3 k allocations: 458 MB, 1.96% gc time)
Dispatch via Const Val Type
 145.355 milliseconds
*Dispatch via Type*
* 148.047 milliseconds*
Vector of functions dispatch
 833.969 milliseconds (3 k allocations: 458 MB, 2.14% gc time)
Functors
   1.011 seconds  (3 k allocations: 458 MB, 1.62% gc time)
Const Functors
 147.741 milliseconds

Re: [julia-users] In what version is Julia supposed to "mature"?

[Stefan Karpinski]

That's literally the only part of that post that I would change :-)

But no, I'm not trolling, 1.0 should be out next year. Predicting down to
the month – or even quarter – is hard, but that's what I think we're
looking at. I'll post a 1.0 roadmap issue soon.

On Tue, Jul 28, 2015 at 6:56 PM, Kevin Squire 
wrote:

> Stefan, are you trolling again?  ;-P
>
> http://julialang.org/blog/2012/02/why-we-created-julia/
>
> On Tue, Jul 28, 2015 at 12:41 PM, Stefan Karpinski 
> wrote:
>
>> Version 1.0 will be released around this time next year.
>>
>> On Tue, Jul 28, 2015 at 3:27 PM, Pileas 
>> wrote:
>>
>>> Greetings,
>>>
>>> I have been following the development of Julia for sometime now and I am
>>> really thrilled to know that you guys have reached version 0.3.11.
>>>
>>> To my understanding sometime in the near future you will release the new
>>> version 0.4.0., a version that it is supposed to bring many changes.
>>>
>>> My question is simple: when is Julia expected to "mature", so that a
>>> "universal" (more or less) documentation (or maybe more thorough books than
>>> those that exist by now) will follow and less bug fixed will be needed?
>>>
>>> I wish you the best!
>>>
>>
>>
>

Re: [julia-users] Re: MongoDB and Julia

[Kevin Liu]

I'll name it CMONGO.jl

On Tue, Jul 28, 2015 at 9:13 PM, Kevin Liu  wrote:

> Any suggestions for the name? I just want to remember this will be a
> wrapper around C Mongo.
>
> On Tue, Jul 28, 2015 at 9:10 PM, Kevin Liu  wrote:
>
>> Hey Kevin,
>>
>> That's great. Thanks for the advice. On it right now.
>>
>> Cheers!
>>
>> On Tue, Jul 28, 2015 at 7:50 PM, Kevin Squire 
>> wrote:
>>
>>> Hi Kevin,
>>>
>>> If you plan to make this a Julia package (and I encourage you to do so),
>>> it would be good to look at the Julia package naming conventions
>>> .
>>> You might consider choosing a different name, generating a package
>>> skeleton, and moving the files in this repo there.  Alternatively, renaming
>>> that repo shouldn't be hard.
>>>
>>> (This isn't mentioned explicitly there, but dashes also won't work for
>>> Julia package names.)
>>>
>>> Cheers!
>>>Kevin
>>>
>>> On Mon, Jul 27, 2015 at 8:28 PM, Kevin Liu 
>>> wrote:
>>>
 Hi Julia Users, feel free to contribute to the Julia wrapper of the C
 Mongo Driver, maintained by Mongo

 https://github.com/tenthdimension/Julia-C-Mongo

 This Julia wrapper is based on the Lua wrapper of the C Mongo Driver.
 Jesse Davis from MongoDB recommended I used it as a reference.

 On Thursday, July 23, 2015 at 8:26:14 PM UTC-3, Kevin Liu wrote:
>
> Thanks
>
> On Thursday, July 23, 2015 at 8:24:12 PM UTC-3,
> tim@multiscalehn.com wrote:
>>
>> https://github.com/pzion/LibBSON.jl/pull/4
>> https://github.com/pzion/Mongo.jl/pull/6
>>
>> On Thursday, July 23, 2015 at 3:28:17 PM UTC-7, Kevin Liu wrote:
>>>
>>> I'm sorry Tim, check this out
>>> https://github.com/10gen-labs/mongorover/issues/16
>>>
>>> Could you share how you made it work properly?
>>>
>>> On Wednesday, July 22, 2015 at 5:20:42 PM UTC-3, Kevin Liu wrote:

 Hi Tim, did it pass specs 1, 2, and part of 3? 4 hasn't been
 started yet.

 These new MongoDB drivers conform to published specifications.

 1. Server Selection - Deciding which server to send database
 operations to in a MongoDB deployment.
 2. Server Discovery and Monitoring - All the logic required to make
 a MongoDB application highly available.
 3. CRUD API - The API for how we Create, Read, Update and Delete
 data from MongoDB.
 4. Authentication - The rules for how to authenticate to MongoDB
 servers.


 https://www.mongodb.com/blog/post/announcing-next-generation-drivers-mongodb

 On Wednesday, July 22, 2015 at 4:30:00 PM UTC-3,
 tim@multiscalehn.com wrote:
>
> I have just made pull requests to pzion/LibBSON.jl and
> pzion/Mongo.jl to fix the driver in v0.4. Works fine for me, after 
> adding
> @compats
>
> On Sunday, July 12, 2015 at 12:17:44 AM UTC-7, Kevin Liu wrote:
>>
>> Hi,
>>
>> I have Julia 0.3, Mongodb-osx-x86_64-3.0.4,
>> and Mongo-c-driver-1.1.9 installed, but can't get Julia to access 
>> the Mongo
>> Client through this 'untestable' package
>> https://github.com/pzion/Mongo.jl, according to
>> http://pkg.julialang.org/.
>>
>> I have tried Lytol/Mongo.jl and the command require("Mongo.jl")
>> can't open file Mongo.jl, or the auto-generated deps.jl.
>>
>> Is anyone having similar problems trying to make Julia work with
>> Mongo?
>>
>> Thank you
>>
>> Kevin
>>
>
>>>
>>
>

Re: [julia-users] Re: MongoDB and Julia

[Kevin Liu]

Any suggestions for the name? I just want to remember this will be a
wrapper around C Mongo.

On Tue, Jul 28, 2015 at 9:10 PM, Kevin Liu  wrote:

> Hey Kevin,
>
> That's great. Thanks for the advice. On it right now.
>
> Cheers!
>
> On Tue, Jul 28, 2015 at 7:50 PM, Kevin Squire 
> wrote:
>
>> Hi Kevin,
>>
>> If you plan to make this a Julia package (and I encourage you to do so),
>> it would be good to look at the Julia package naming conventions
>> .
>> You might consider choosing a different name, generating a package
>> skeleton, and moving the files in this repo there.  Alternatively, renaming
>> that repo shouldn't be hard.
>>
>> (This isn't mentioned explicitly there, but dashes also won't work for
>> Julia package names.)
>>
>> Cheers!
>>Kevin
>>
>> On Mon, Jul 27, 2015 at 8:28 PM, Kevin Liu 
>> wrote:
>>
>>> Hi Julia Users, feel free to contribute to the Julia wrapper of the C
>>> Mongo Driver, maintained by Mongo
>>>
>>> https://github.com/tenthdimension/Julia-C-Mongo
>>>
>>> This Julia wrapper is based on the Lua wrapper of the C Mongo Driver.
>>> Jesse Davis from MongoDB recommended I used it as a reference.
>>>
>>> On Thursday, July 23, 2015 at 8:26:14 PM UTC-3, Kevin Liu wrote:

 Thanks

 On Thursday, July 23, 2015 at 8:24:12 PM UTC-3,
 tim@multiscalehn.com wrote:
>
> https://github.com/pzion/LibBSON.jl/pull/4
> https://github.com/pzion/Mongo.jl/pull/6
>
> On Thursday, July 23, 2015 at 3:28:17 PM UTC-7, Kevin Liu wrote:
>>
>> I'm sorry Tim, check this out
>> https://github.com/10gen-labs/mongorover/issues/16
>>
>> Could you share how you made it work properly?
>>
>> On Wednesday, July 22, 2015 at 5:20:42 PM UTC-3, Kevin Liu wrote:
>>>
>>> Hi Tim, did it pass specs 1, 2, and part of 3? 4 hasn't been started
>>> yet.
>>>
>>> These new MongoDB drivers conform to published specifications.
>>>
>>> 1. Server Selection - Deciding which server to send database
>>> operations to in a MongoDB deployment.
>>> 2. Server Discovery and Monitoring - All the logic required to make
>>> a MongoDB application highly available.
>>> 3. CRUD API - The API for how we Create, Read, Update and Delete
>>> data from MongoDB.
>>> 4. Authentication - The rules for how to authenticate to MongoDB
>>> servers.
>>>
>>>
>>> https://www.mongodb.com/blog/post/announcing-next-generation-drivers-mongodb
>>>
>>> On Wednesday, July 22, 2015 at 4:30:00 PM UTC-3,
>>> tim@multiscalehn.com wrote:

 I have just made pull requests to pzion/LibBSON.jl and
 pzion/Mongo.jl to fix the driver in v0.4. Works fine for me, after 
 adding
 @compats

 On Sunday, July 12, 2015 at 12:17:44 AM UTC-7, Kevin Liu wrote:
>
> Hi,
>
> I have Julia 0.3, Mongodb-osx-x86_64-3.0.4,
> and Mongo-c-driver-1.1.9 installed, but can't get Julia to access the 
> Mongo
> Client through this 'untestable' package
> https://github.com/pzion/Mongo.jl, according to
> http://pkg.julialang.org/.
>
> I have tried Lytol/Mongo.jl and the command require("Mongo.jl")
> can't open file Mongo.jl, or the auto-generated deps.jl.
>
> Is anyone having similar problems trying to make Julia work with
> Mongo?
>
> Thank you
>
> Kevin
>

>>
>

Re: [julia-users] Re: MongoDB and Julia

[Kevin Liu]

Hey Kevin,

That's great. Thanks for the advice. On it right now.

Cheers!

On Tue, Jul 28, 2015 at 7:50 PM, Kevin Squire 
wrote:

> Hi Kevin,
>
> If you plan to make this a Julia package (and I encourage you to do so),
> it would be good to look at the Julia package naming conventions
> .
> You might consider choosing a different name, generating a package
> skeleton, and moving the files in this repo there.  Alternatively, renaming
> that repo shouldn't be hard.
>
> (This isn't mentioned explicitly there, but dashes also won't work for
> Julia package names.)
>
> Cheers!
>Kevin
>
> On Mon, Jul 27, 2015 at 8:28 PM, Kevin Liu  wrote:
>
>> Hi Julia Users, feel free to contribute to the Julia wrapper of the C
>> Mongo Driver, maintained by Mongo
>>
>> https://github.com/tenthdimension/Julia-C-Mongo
>>
>> This Julia wrapper is based on the Lua wrapper of the C Mongo Driver.
>> Jesse Davis from MongoDB recommended I used it as a reference.
>>
>> On Thursday, July 23, 2015 at 8:26:14 PM UTC-3, Kevin Liu wrote:
>>>
>>> Thanks
>>>
>>> On Thursday, July 23, 2015 at 8:24:12 PM UTC-3, tim@multiscalehn.com
>>> wrote:

 https://github.com/pzion/LibBSON.jl/pull/4
 https://github.com/pzion/Mongo.jl/pull/6

 On Thursday, July 23, 2015 at 3:28:17 PM UTC-7, Kevin Liu wrote:
>
> I'm sorry Tim, check this out
> https://github.com/10gen-labs/mongorover/issues/16
>
> Could you share how you made it work properly?
>
> On Wednesday, July 22, 2015 at 5:20:42 PM UTC-3, Kevin Liu wrote:
>>
>> Hi Tim, did it pass specs 1, 2, and part of 3? 4 hasn't been started
>> yet.
>>
>> These new MongoDB drivers conform to published specifications.
>>
>> 1. Server Selection - Deciding which server to send database
>> operations to in a MongoDB deployment.
>> 2. Server Discovery and Monitoring - All the logic required to make a
>> MongoDB application highly available.
>> 3. CRUD API - The API for how we Create, Read, Update and Delete data
>> from MongoDB.
>> 4. Authentication - The rules for how to authenticate to MongoDB
>> servers.
>>
>>
>> https://www.mongodb.com/blog/post/announcing-next-generation-drivers-mongodb
>>
>> On Wednesday, July 22, 2015 at 4:30:00 PM UTC-3,
>> tim@multiscalehn.com wrote:
>>>
>>> I have just made pull requests to pzion/LibBSON.jl and
>>> pzion/Mongo.jl to fix the driver in v0.4. Works fine for me, after 
>>> adding
>>> @compats
>>>
>>> On Sunday, July 12, 2015 at 12:17:44 AM UTC-7, Kevin Liu wrote:

 Hi,

 I have Julia 0.3, Mongodb-osx-x86_64-3.0.4,
 and Mongo-c-driver-1.1.9 installed, but can't get Julia to access the 
 Mongo
 Client through this 'untestable' package
 https://github.com/pzion/Mongo.jl, according to
 http://pkg.julialang.org/.

 I have tried Lytol/Mongo.jl and the command require("Mongo.jl")
 can't open file Mongo.jl, or the auto-generated deps.jl.

 Is anyone having similar problems trying to make Julia work with
 Mongo?

 Thank you

 Kevin

>>>
>

Re: [julia-users] I need help with this constructor on Julia 0.4

[Diego Javier Zea]

Thanks Yichao! :)

El martes, 28 de julio de 2015, 17:19:35 (UTC-3), Yichao Yu escribió:
>
> On Tue, Jul 28, 2015 at 4:13 PM, Diego Javier Zea  > wrote: 
> > Hi! I need help with this constructor on Julia 0.4. What is the correct 
> form 
> > for write different constructors for D being 1, 2, 3... ? Thanks 
> > 
> > julia> immutable AdditiveSmoothing{T} 
> >  λ::T 
> >end 
> > 
> > julia> type ResidueCount{T, D} 
> >  N::Array{T, D} 
> > 
> >end 
> > 
> > julia> ResidueCount{T,1}(::Type{T}) = ResidueCount{T,1}(Array(T,21)) 
>
> call{T}(::Type{ResidueCount}, ::Type{T}) = ResidueCount{T, 1}(Array(T, 
> 21)) 
>
> > ERROR: syntax: malformed type parameter list 
> > 
> > 
>

Re: [julia-users] In what version is Julia supposed to "mature"?

[Kevin Squire]

Stefan, are you trolling again?  ;-P

http://julialang.org/blog/2012/02/why-we-created-julia/

On Tue, Jul 28, 2015 at 12:41 PM, Stefan Karpinski 
wrote:

> Version 1.0 will be released around this time next year.
>
> On Tue, Jul 28, 2015 at 3:27 PM, Pileas 
> wrote:
>
>> Greetings,
>>
>> I have been following the development of Julia for sometime now and I am
>> really thrilled to know that you guys have reached version 0.3.11.
>>
>> To my understanding sometime in the near future you will release the new
>> version 0.4.0., a version that it is supposed to bring many changes.
>>
>> My question is simple: when is Julia expected to "mature", so that a
>> "universal" (more or less) documentation (or maybe more thorough books than
>> those that exist by now) will follow and less bug fixed will be needed?
>>
>> I wish you the best!
>>
>
>

Re: [julia-users] Re: MongoDB and Julia

[Kevin Squire]

Hi Kevin,

If you plan to make this a Julia package (and I encourage you to do so), it
would be good to look at the Julia package naming conventions
.
You might consider choosing a different name, generating a package
skeleton, and moving the files in this repo there.  Alternatively, renaming
that repo shouldn't be hard.

(This isn't mentioned explicitly there, but dashes also won't work for
Julia package names.)

Cheers!
   Kevin

On Mon, Jul 27, 2015 at 8:28 PM, Kevin Liu  wrote:

> Hi Julia Users, feel free to contribute to the Julia wrapper of the C
> Mongo Driver, maintained by Mongo
>
> https://github.com/tenthdimension/Julia-C-Mongo
>
> This Julia wrapper is based on the Lua wrapper of the C Mongo Driver.
> Jesse Davis from MongoDB recommended I used it as a reference.
>
> On Thursday, July 23, 2015 at 8:26:14 PM UTC-3, Kevin Liu wrote:
>>
>> Thanks
>>
>> On Thursday, July 23, 2015 at 8:24:12 PM UTC-3, tim@multiscalehn.com
>> wrote:
>>>
>>> https://github.com/pzion/LibBSON.jl/pull/4
>>> https://github.com/pzion/Mongo.jl/pull/6
>>>
>>> On Thursday, July 23, 2015 at 3:28:17 PM UTC-7, Kevin Liu wrote:

 I'm sorry Tim, check this out
 https://github.com/10gen-labs/mongorover/issues/16

 Could you share how you made it work properly?

 On Wednesday, July 22, 2015 at 5:20:42 PM UTC-3, Kevin Liu wrote:
>
> Hi Tim, did it pass specs 1, 2, and part of 3? 4 hasn't been started
> yet.
>
> These new MongoDB drivers conform to published specifications.
>
> 1. Server Selection - Deciding which server to send database
> operations to in a MongoDB deployment.
> 2. Server Discovery and Monitoring - All the logic required to make a
> MongoDB application highly available.
> 3. CRUD API - The API for how we Create, Read, Update and Delete data
> from MongoDB.
> 4. Authentication - The rules for how to authenticate to MongoDB
> servers.
>
>
> https://www.mongodb.com/blog/post/announcing-next-generation-drivers-mongodb
>
> On Wednesday, July 22, 2015 at 4:30:00 PM UTC-3,
> tim@multiscalehn.com wrote:
>>
>> I have just made pull requests to pzion/LibBSON.jl and pzion/Mongo.jl
>> to fix the driver in v0.4. Works fine for me, after adding @compats
>>
>> On Sunday, July 12, 2015 at 12:17:44 AM UTC-7, Kevin Liu wrote:
>>>
>>> Hi,
>>>
>>> I have Julia 0.3, Mongodb-osx-x86_64-3.0.4, and Mongo-c-driver-1.1.9
>>> installed, but can't get Julia to access the Mongo Client through this
>>> 'untestable' package https://github.com/pzion/Mongo.jl, according
>>> to  http://pkg.julialang.org/.
>>>
>>> I have tried Lytol/Mongo.jl and the command require("Mongo.jl")
>>> can't open file Mongo.jl, or the auto-generated deps.jl.
>>>
>>> Is anyone having similar problems trying to make Julia work with
>>> Mongo?
>>>
>>> Thank you
>>>
>>> Kevin
>>>
>>

[julia-users] Re: Where to get general offline help with Julia?

[Joe Tusek]

I've got great assistance from the user-group, but I'm not wanting to wear 
out my welcome. Overall I find Julia documents good but lacking in 
the number and breadth of examples that would help fill in the missing bits 
for a person like me. The many web examples of Julia out there are 
at present mostly just a repeat of the same beginner examples and 
doesn't add much to the breadth of the information out there. The potential 
speed improvement in using Julia caught my eye as the Matlab code I am 
using contains an unoptimised PSO routine and cost function and takes 
anywhere from a day to 2 days to run. I was hoping porting to Julia would 
enable me to get that down to 2 - 3 iteration per day.  Learning by writing 
code for a purpose is a great way to learn but when you have taken a lot 
more time than you had for the task its then not the best. Writing code is 
not something I do for a living and its essentially for a love job which 
needs this code going.

>
>>

Re: [julia-users] Passing an array element from an image to PyPlot.plot.hist()

[Paul Wagner]

Thanks,

It seems that this works:

using Images, PyPlot
img = imread("image.jpg")
PyPlot.hist(vec(img), -1:255)



On Monday, July 20, 2015 at 2:07:18 PM UTC-4, El suisse wrote:
>
> Hi i think
> you need to unpack the vector of frequencies
>
> _, counts = hist(vec(img_gld_gs), -1:255)
> PyPlot.plot(counts)
>
> 2015-07-20 14:26 GMT-03:00 Paul Wagner >:
>
>> Hello,
>>
>> I'm new to Julia and have been reading all the documentation I can.  
>> Using Images.jl and PyPlot, I'm trying to take a image, convert and 
>> reinterpret it before plotting the count of the various pixel colors in a 
>> histogram.
>>
>> using Images
>> img_gld = imread("plane.jpg")
>> img_gld_gs = convert(Image,img_gld)
>> img_gld_gs = reinterpret(Uint8,data(img_gld_gs))
>>
>> hist(vec(img_gld_gs), -1:255)
>>  
>> Returns:
>>
>> *(-1:255,[1675,1122,1674,14998,23244,14503,14014,14959,14428,12569  … 
>>  215,183,137,86,96,242,499,3116,8958,597726])*
>>  
>>
>> The issue I am having is how to manipulate this array element with a 
>> sequence into being the the x and y axis in a PyPlot Histogram.  I think 
>> once I get a better grasp of how to manipulate this sort of vector Julia 
>> will open up to me.  I've tried a number of approaches that generally 
>> results in "*ValueError: setting an array element with a sequence." or 
>> similar.*
>>
>>
>> import PyPlot
>> PyPlot.plt.hist()
>> PyPlot.plt.plot()
>>
>> Thanks,
>>
>> Paul
>>
>
>

Re: [julia-users] I need help with this constructor on Julia 0.4

[Yichao Yu]

On Tue, Jul 28, 2015 at 4:13 PM, Diego Javier Zea  wrote:
> Hi! I need help with this constructor on Julia 0.4. What is the correct form
> for write different constructors for D being 1, 2, 3... ? Thanks
>
> julia> immutable AdditiveSmoothing{T}
>  λ::T
>end
>
> julia> type ResidueCount{T, D}
>  N::Array{T, D}
>
>end
>
> julia> ResidueCount{T,1}(::Type{T}) = ResidueCount{T,1}(Array(T,21))

call{T}(::Type{ResidueCount}, ::Type{T}) = ResidueCount{T, 1}(Array(T, 21))

> ERROR: syntax: malformed type parameter list
>
>

[julia-users] I need help with this constructor on Julia 0.4

[Diego Javier Zea]

Hi! I need help with this constructor on Julia 0.4. What is the correct 
form for write different constructors for D being 1, 2, 3... ? Thanks

julia> immutable AdditiveSmoothing{T}
 λ::T
   end

julia> type ResidueCount{T, D}
 N::Array{T, D}
 
   end

julia> ResidueCount{T,1}(::Type{T}) = ResidueCount{T,1}(Array(T,21))
ERROR: syntax: malformed type parameter list

Re: [julia-users] In what version is Julia supposed to "mature"?

[Stefan Karpinski]

Version 1.0 will be released around this time next year.

On Tue, Jul 28, 2015 at 3:27 PM, Pileas  wrote:

> Greetings,
>
> I have been following the development of Julia for sometime now and I am
> really thrilled to know that you guys have reached version 0.3.11.
>
> To my understanding sometime in the near future you will release the new
> version 0.4.0., a version that it is supposed to bring many changes.
>
> My question is simple: when is Julia expected to "mature", so that a
> "universal" (more or less) documentation (or maybe more thorough books than
> those that exist by now) will follow and less bug fixed will be needed?
>
> I wish you the best!
>

[julia-users] In what version is Julia supposed to "mature"?

[Pileas]

Greetings,

I have been following the development of Julia for sometime now and I am 
really thrilled to know that you guys have reached version 0.3.11.

To my understanding sometime in the near future you will release the new 
version 0.4.0., a version that it is supposed to bring many changes. 

My question is simple: when is Julia expected to "mature", so that a 
"universal" (more or less) documentation (or maybe more thorough books than 
those that exist by now) will follow and less bug fixed will be needed?

I wish you the best! 

[julia-users] Remote arguments in remote calls?

[Dominique Orban]

Sorry if this is a basic question. Here are a simple type and a simple 
function changing an instance in place:

type Something
  val :: Int

  function Something()
return new(0)
  end
end

function set_value(something :: Something, value :: Int)
  something.val = value
  return
end

I'd like to create a remote instance of `Something`, and then call 
`set_value()` on it remotely. The naive way doesn't work:

$ julia -p 2
julia> @everywhere include("something.jl")

julia> remote_thing = remotecall(2, Something)
RemoteRef(2,1,9)

julia> thing = fetch(remote_thing)
Something(0)

julia> remotecall(2, set_value, thing, 1)
RemoteRef(2,1,11)

julia> thing
Something(0)

One way to make it work is to change `set_value()` so it returns the 
updated `thing`.
But is there a way to call `set_value()` with whatever `remote_thing` is 
pointing to on the remote node as argument without changing `set_value()`?

Thanks.

[julia-users] Re: Where to get general offline help with Julia?

[Steven G. Johnson]

You could always hire a consultant (e.g. http://juliacomputing.com/) if you 
need offline support.

Re: [julia-users] Re: Read GML format graphs by using LightGraphs.jl

[Seth]

Thanks to Andrew's diligent efforts to track down and fix a couple of 
unrelated issues in Base, I'm pleased to announce that LightGraphs master 
now supports GML via Andrew's ParserCombinator package. 

You'll have much better performance on a recent (0.4.0-dev+6325 or later) 
build, but graphs load in both 0.3 and 0.4.


On Friday, July 17, 2015 at 9:29:07 PM UTC-7, andrew cooke wrote:
>
>
> the very latest from git has fixes for the issues Seth raised, i hope / 
> believe.  later this weekend i'll probably make a new release, but right 
> now you need to do 
>
> Pkg.clone("https://github.com/andrewcooke/ParserCombinator.jl.git";)
>
> cheers, andrew
>
>
> On Friday, 17 July 2015 19:51:20 UTC-3, Charles Santana wrote:
>>
>> Hi both,
>>
>> Thank you very much for doing it!! I will take a look at the parser along 
>> the weekend and I hope it can be useful for us. Thank you for being so 
>> proactive and helpful!!
>>
>> Best,
>>
>> Charles
>>
>> On 17 July 2015 at 08:45, Seth  wrote:
>>
>>> Hi Charles,
>>>
>>> I've implemented Andrew's excellent GML parser in LightGraphs (in the 
>>> "gml" branch for now until a few things can be clarified and docs can be 
>>> written). To use it, checkout the gml branch and then use g = 
>>> readgml("/path/to/file.gml").
>>>
>>> Note that there are a few issues with the GML parser (see the ones I 
>>> opened at https://github.com/andrewcooke/ParserCombinator.jl/issues) 
>>> but it seems to work for smaller gml files at this point.
>>>
>>> Note also that readgml() is not type-stable, as it will create either a 
>>> Graph or DiGraph depending on what it finds in the file. Not sure this is a 
>>> huge problem.
>>>
>>>
>>> On Thursday, July 16, 2015 at 3:11:41 PM UTC-7, andrew cooke wrote:


 hi, seth contacted me to see whether my ParserCombinator library could 
 do this, and i've just finished adding support for GML.  you can see it at 
 https://github.com/andrewcooke/ParserCombinator.jl#parsers

 that is currently only available via git (not yet in a published 
 release).  i've also emailed seth.  if either of you could have a look and 
 tell me whether it's adequate or not, and / or report any bugs then i can 
 look at releasing a version.

 cheers,
 andrew


 On Saturday, 11 July 2015 11:04:08 UTC-3, Seth wrote:
>
> Hi Charles,
>
> You're correct; for persistence, LightGraphs currently supports an 
> internal graph representation and GraphML. If you can convert to GraphML 
> you're in luck; otherwise, if you open up an issue someone might be able 
> to 
> code something up.
>
> The quickest thing, perhaps, would be to import the gml into NetworkX (
> http://networkx.github.io) and then write it out as GraphML, which 
> you should then be able to use in LightGraphs.
>
> Seth.
>
>
> On Saturday, July 11, 2015 at 3:48:52 AM UTC-7, Charles Santana wrote:
>>
>> Hi folks,
>>
>> Following the suggestion of Seth (
>> https://groups.google.com/forum/#!topic/julia-users/Ftdo2LmxC-g) I 
>> am trying to use LightGraphs.jl to read my graph files. 
>>
>> My graphs are in GML format (
>> http://gephi.github.io/users/supported-graph-formats/gml-format/). 
>> However, as far as I understand, LightGraphs.jl can not read graphs in 
>> this 
>> format.
>>
>> I just found this thread talking about the creation of a GraphsIO.jl 
>> and its integration with Graphs.jl and LightGraphs.jl (
>> https://github.com/JuliaLang/Graphs.jl/issues/37) Do you have any 
>> news about it? How can I read GML files to work with LightGraphs.jl?
>>
>> Thanks for any help!
>>
>> Charles
>>
>> -- 
>> Um axé! :)
>>
>> --
>> Charles Novaes de Santana, PhD
>> http://www.imedea.uib-csic.es/~charles
>>  
>
>>
>>
>> -- 
>> Um axé! :)
>>
>> --
>> Charles Novaes de Santana, PhD
>> http://www.imedea.uib-csic.es/~charles
>>  
>

[julia-users] Re: setindex! for matrix of vectors

[David Gold]

Oh wait, nvm, I missed that `Vector` prefix. Sorry!

On Tuesday, July 28, 2015 at 10:05:22 AM UTC-4, Matt Bauman wrote:
>
> Yes, this is one of the ever-tricky cases of "did you mean the container 
> or the elements of that container?"  Setindex always assumes that, if the 
> RHS of the assignment is an array of some sort, it's the elements that 
> should be assigned.
>
> David, `A[:] = Vector[[1,2,3]]` works as you'd expect (this is the array 
> concatenation vs construction issue), but this will only work if 
> `length(A)==1`.
>
> And Linus, an easy work-around (assuming that you don't always just have a 
> one-element) is to use `fill!` instead: `fill!(A, [1,2,3])`.
>
> On Tuesday, July 28, 2015 at 8:45:44 AM UTC-4, David Gold wrote:
>>
>> That error makes sense to me, insofar as `A[:]` is not a scalar entry but 
>> a whole vector. So assigning the vector `[1, 2, 3]` to `A[:]` is 
>> interpreted as, "put all the things from this vector into that vector". But 
>> by that logic, `A[:] = [[1, 2, 3],]` ought to work, and it doesn't. Of 
>> course, scalar assignment works as expected.
>>
>> If you can't avoid colon, one thing you can do is define a wrapper type 
>> that isn't interpreted as container of objects each of which is to be 
>> assigned to an index in `A[:]`, as well as an appropriate convert method:
>>
>> julia> type ArrayWrapper{T, N} 
>> A::Array{T, N} 
>> end
>>
>> julia> Base.convert{T, N}(::Type{Array{T, N}}, X::ArrayWrapper{T, N}) = 
>> X.A
>> convert (generic function with 700 methods)
>>
>> julia> A[:] = ArrayWrapper([1, 2, 3])
>> ArrayWrapper{Int64,1}([1,2,3])
>>
>> julia> A
>> 1-element Array{Array{Int64,1},1}:
>> [1,2,3]
>>
>>
>> On Tuesday, July 28, 2015 at 4:06:59 AM UTC-4, Linus Härenstam-Nielsen 
>> wrote:
>>>
>>> I'm implementing a setindex! method for an object with a field of type 
>>> Matrix{Vector{Float64}} (a matrix of vectors) and I've run into a problem 
>>> with getting the Colon() index to work properly. It comes down to this:
>>>
>>> julia> A = Array(Vector{Int}, 1)
>>> 1-element Array{Array{Int64,1},1}:
>>>  #undef
>>>
>>> julia> A[:] = [1,2,3]
>>> ERROR: DimensionMismatch("tried to assign 3 elements to 1 destinations")
>>>  in throw_setindex_mismatch at operators.jl:226
>>>
>>> Since the element I'm trying to assign is a vector setindex! calls the 
>>> wrong method for my purposes. What I would like is for the resulting array 
>>> to be:
>>>
>>> julia> A
>>> 1-element Array{Array{Int64,1},1}:
>>>  [1,2,3]
>>>
>>> Is there a way to get around this? I would change the datatype to 
>>> Array{Float64, 3} if I could but other functions rely on the current 
>>> structure.
>>>
>>

[julia-users] Re: setindex! for matrix of vectors

[David Gold]

@Matt I find it doesn't work for me -- am I missing something?

julia> A = Array(Vector{Int}, 1) 
1-element Array{Array{Int64,1},1}: 
#undef 

julia> A[:] = [[1, 2, 3]] 
ERROR: DimensionMismatch("tried to assign 3 elements to 1 destinations") 
in throw_setindex_mismatch at operators.jl:238 
in setindex_shape_check at operators.jl:289 
in _unsafe_batchsetindex! at multidimensional.jl:325 
in setindex! at abstractarray.jl:563


On Tuesday, July 28, 2015 at 10:05:22 AM UTC-4, Matt Bauman wrote:
>
> Yes, this is one of the ever-tricky cases of "did you mean the container 
> or the elements of that container?"  Setindex always assumes that, if the 
> RHS of the assignment is an array of some sort, it's the elements that 
> should be assigned.
>
> David, `A[:] = Vector[[1,2,3]]` works as you'd expect (this is the array 
> concatenation vs construction issue), but this will only work if 
> `length(A)==1`.
>
> And Linus, an easy work-around (assuming that you don't always just have a 
> one-element) is to use `fill!` instead: `fill!(A, [1,2,3])`.
>
> On Tuesday, July 28, 2015 at 8:45:44 AM UTC-4, David Gold wrote:
>>
>> That error makes sense to me, insofar as `A[:]` is not a scalar entry but 
>> a whole vector. So assigning the vector `[1, 2, 3]` to `A[:]` is 
>> interpreted as, "put all the things from this vector into that vector". But 
>> by that logic, `A[:] = [[1, 2, 3],]` ought to work, and it doesn't. Of 
>> course, scalar assignment works as expected.
>>
>> If you can't avoid colon, one thing you can do is define a wrapper type 
>> that isn't interpreted as container of objects each of which is to be 
>> assigned to an index in `A[:]`, as well as an appropriate convert method:
>>
>> julia> type ArrayWrapper{T, N} 
>> A::Array{T, N} 
>> end
>>
>> julia> Base.convert{T, N}(::Type{Array{T, N}}, X::ArrayWrapper{T, N}) = 
>> X.A
>> convert (generic function with 700 methods)
>>
>> julia> A[:] = ArrayWrapper([1, 2, 3])
>> ArrayWrapper{Int64,1}([1,2,3])
>>
>> julia> A
>> 1-element Array{Array{Int64,1},1}:
>> [1,2,3]
>>
>>
>> On Tuesday, July 28, 2015 at 4:06:59 AM UTC-4, Linus Härenstam-Nielsen 
>> wrote:
>>>
>>> I'm implementing a setindex! method for an object with a field of type 
>>> Matrix{Vector{Float64}} (a matrix of vectors) and I've run into a problem 
>>> with getting the Colon() index to work properly. It comes down to this:
>>>
>>> julia> A = Array(Vector{Int}, 1)
>>> 1-element Array{Array{Int64,1},1}:
>>>  #undef
>>>
>>> julia> A[:] = [1,2,3]
>>> ERROR: DimensionMismatch("tried to assign 3 elements to 1 destinations")
>>>  in throw_setindex_mismatch at operators.jl:226
>>>
>>> Since the element I'm trying to assign is a vector setindex! calls the 
>>> wrong method for my purposes. What I would like is for the resulting array 
>>> to be:
>>>
>>> julia> A
>>> 1-element Array{Array{Int64,1},1}:
>>>  [1,2,3]
>>>
>>> Is there a way to get around this? I would change the datatype to 
>>> Array{Float64, 3} if I could but other functions rely on the current 
>>> structure.
>>>
>>

Re: [julia-users] Getting the average of only nonzero elements of a matrix

[Jude]

Thanks Stefan and Tom, that's really helpful!  Stefan, I meant quicker as 
in faster.

Thanks a lot!




On Tuesday, July 28, 2015 at 5:06:00 PM UTC+1, Stefan Karpinski wrote:
>
> Oh, didn't catch that you wanted row sums, but yeah, same basic idea.
>
> On Tue, Jul 28, 2015 at 12:03 PM, Tom Breloff  > wrote:
>
>> I would just write the loop explicitly:
>>
>>
>> julia> function meanpositives(mat::Matrix)
>>nc = size(mat,2)
>>sums = zeros(nc)
>>counts = zeros(nc)
>>for c in 1:nc
>>for r in 1:size(mat,1)
>>v = mat[r,c]
>>if v > 0
>>sums[c] += v
>>counts[c] += 1.0
>>end
>>end
>>end
>>Float64[(counts[i]>0 ? sums[i]/counts[i] : 0.0) for i in 1:nc]
>>end
>> meanpositives (generic function with 1 method)
>>
>> julia> x
>> 3x3 Array{Float64,2}:
>>  10.0  5.0  0.0
>>   5.0  0.0  0.0
>>   0.0  0.0  0.0
>>
>> julia> meanpositives(x)
>> 3-element Array{Float64,1}:
>>  7.5
>>  5.0
>>  0.0
>>
>>
>> On Tue, Jul 28, 2015 at 12:01 PM, Stefan Karpinski > > wrote:
>>
>>> You mean quicker as in faster or as in easier? Using indexing is 
>>> probably easiest but not fastest:
>>>
>>> julia> M = randn(5,5)
>>> 5x5 Array{Float64,2}:
>>>  -1.51134 1.2331-0.186083   0.412282  -1.13114
>>>  -0.0411132   0.124684   0.377426   0.622427  -0.278162
>>>   0.788182   -0.834092   1.095061.45196   -0.620717
>>>   1.45856-0.889277  -0.768049  -0.95953   -0.340098
>>>   1.69666 0.695566   0.706905   0.630890.958474
>>>
>>> julia> mean(M[M .> 0])
>>> 0.8751552351448673
>>>
>>>
>>> If you want the fastest, loop through the matrix and keep totals and 
>>> counts:
>>>
>>> julia> function meanpos(a)
>>>t = zero(eltype(a))
>>>c = 0
>>>for x in a
>>>x > 0 || continue
>>>t += x
>>>c += 1
>>>end
>>>return t/c
>>>end
>>> meanpos (generic function with 1 method)
>>>
>>> julia> meanpos(M)
>>> 0.8751552351448673
>>>
>>>
>>> This should be fairly efficient for any non-sparse collection.
>>>
>>>
>>> On Tue, Jul 28, 2015 at 11:50 AM, Jude >> > wrote:
>>>
 Hi!

 Probably a quite basic question but was wondering if someone knows a quick 
 way to get the average of theh positive elements of a matrix, eg, If I 
 have 
 an m*n matrix and want to get the average for each m so have m*1 but only 
 want to work with non-zero elements and ignore the zero elements and 
 negative elements

 I guess I could using indexing and pull out the indexes corresponding 
 to the positive elements but just wondering if anyone knew quicker ways!

 Thanks!

>>>
>>>
>>
>

Re: [julia-users] Getting the average of only nonzero elements of a matrix

[Tom Breloff]

Heh... neither did I... I gave you code for column sums!  Should be easy
enough to convert...

On Tue, Jul 28, 2015 at 12:05 PM, Stefan Karpinski 
wrote:

> Oh, didn't catch that you wanted row sums, but yeah, same basic idea.
>
> On Tue, Jul 28, 2015 at 12:03 PM, Tom Breloff  wrote:
>
>> I would just write the loop explicitly:
>>
>>
>> julia> function meanpositives(mat::Matrix)
>>nc = size(mat,2)
>>sums = zeros(nc)
>>counts = zeros(nc)
>>for c in 1:nc
>>for r in 1:size(mat,1)
>>v = mat[r,c]
>>if v > 0
>>sums[c] += v
>>counts[c] += 1.0
>>end
>>end
>>end
>>Float64[(counts[i]>0 ? sums[i]/counts[i] : 0.0) for i in 1:nc]
>>end
>> meanpositives (generic function with 1 method)
>>
>> julia> x
>> 3x3 Array{Float64,2}:
>>  10.0  5.0  0.0
>>   5.0  0.0  0.0
>>   0.0  0.0  0.0
>>
>> julia> meanpositives(x)
>> 3-element Array{Float64,1}:
>>  7.5
>>  5.0
>>  0.0
>>
>>
>> On Tue, Jul 28, 2015 at 12:01 PM, Stefan Karpinski 
>> wrote:
>>
>>> You mean quicker as in faster or as in easier? Using indexing is
>>> probably easiest but not fastest:
>>>
>>> julia> M = randn(5,5)
>>> 5x5 Array{Float64,2}:
>>>  -1.51134 1.2331-0.186083   0.412282  -1.13114
>>>  -0.0411132   0.124684   0.377426   0.622427  -0.278162
>>>   0.788182   -0.834092   1.095061.45196   -0.620717
>>>   1.45856-0.889277  -0.768049  -0.95953   -0.340098
>>>   1.69666 0.695566   0.706905   0.630890.958474
>>>
>>> julia> mean(M[M .> 0])
>>> 0.8751552351448673
>>>
>>>
>>> If you want the fastest, loop through the matrix and keep totals and
>>> counts:
>>>
>>> julia> function meanpos(a)
>>>t = zero(eltype(a))
>>>c = 0
>>>for x in a
>>>x > 0 || continue
>>>t += x
>>>c += 1
>>>end
>>>return t/c
>>>end
>>> meanpos (generic function with 1 method)
>>>
>>> julia> meanpos(M)
>>> 0.8751552351448673
>>>
>>>
>>> This should be fairly efficient for any non-sparse collection.
>>>
>>>
>>> On Tue, Jul 28, 2015 at 11:50 AM, Jude  wrote:
>>>
 Hi!

 Probably a quite basic question but was wondering if someone knows a quick
 way to get the average of theh positive elements of a matrix, eg, If I have
 an m*n matrix and want to get the average for each m so have m*1 but only
 want to work with non-zero elements and ignore the zero elements and
 negative elements

 I guess I could using indexing and pull out the indexes corresponding
 to the positive elements but just wondering if anyone knew quicker ways!

 Thanks!

>>>
>>>
>>
>

Re: [julia-users] Getting the average of only nonzero elements of a matrix

[Stefan Karpinski]

Oh, didn't catch that you wanted row sums, but yeah, same basic idea.

On Tue, Jul 28, 2015 at 12:03 PM, Tom Breloff  wrote:

> I would just write the loop explicitly:
>
>
> julia> function meanpositives(mat::Matrix)
>nc = size(mat,2)
>sums = zeros(nc)
>counts = zeros(nc)
>for c in 1:nc
>for r in 1:size(mat,1)
>v = mat[r,c]
>if v > 0
>sums[c] += v
>counts[c] += 1.0
>end
>end
>end
>Float64[(counts[i]>0 ? sums[i]/counts[i] : 0.0) for i in 1:nc]
>end
> meanpositives (generic function with 1 method)
>
> julia> x
> 3x3 Array{Float64,2}:
>  10.0  5.0  0.0
>   5.0  0.0  0.0
>   0.0  0.0  0.0
>
> julia> meanpositives(x)
> 3-element Array{Float64,1}:
>  7.5
>  5.0
>  0.0
>
>
> On Tue, Jul 28, 2015 at 12:01 PM, Stefan Karpinski 
> wrote:
>
>> You mean quicker as in faster or as in easier? Using indexing is probably
>> easiest but not fastest:
>>
>> julia> M = randn(5,5)
>> 5x5 Array{Float64,2}:
>>  -1.51134 1.2331-0.186083   0.412282  -1.13114
>>  -0.0411132   0.124684   0.377426   0.622427  -0.278162
>>   0.788182   -0.834092   1.095061.45196   -0.620717
>>   1.45856-0.889277  -0.768049  -0.95953   -0.340098
>>   1.69666 0.695566   0.706905   0.630890.958474
>>
>> julia> mean(M[M .> 0])
>> 0.8751552351448673
>>
>>
>> If you want the fastest, loop through the matrix and keep totals and
>> counts:
>>
>> julia> function meanpos(a)
>>t = zero(eltype(a))
>>c = 0
>>for x in a
>>x > 0 || continue
>>t += x
>>c += 1
>>end
>>return t/c
>>end
>> meanpos (generic function with 1 method)
>>
>> julia> meanpos(M)
>> 0.8751552351448673
>>
>>
>> This should be fairly efficient for any non-sparse collection.
>>
>>
>> On Tue, Jul 28, 2015 at 11:50 AM, Jude  wrote:
>>
>>> Hi!
>>>
>>> Probably a quite basic question but was wondering if someone knows a quick
>>> way to get the average of theh positive elements of a matrix, eg, If I have
>>> an m*n matrix and want to get the average for each m so have m*1 but only
>>> want to work with non-zero elements and ignore the zero elements and
>>> negative elements
>>>
>>> I guess I could using indexing and pull out the indexes corresponding to
>>> the positive elements but just wondering if anyone knew quicker ways!
>>>
>>> Thanks!
>>>
>>
>>
>

Re: [julia-users] Getting the average of only nonzero elements of a matrix

[Tom Breloff]

I would just write the loop explicitly:


julia> function meanpositives(mat::Matrix)
   nc = size(mat,2)
   sums = zeros(nc)
   counts = zeros(nc)
   for c in 1:nc
   for r in 1:size(mat,1)
   v = mat[r,c]
   if v > 0
   sums[c] += v
   counts[c] += 1.0
   end
   end
   end
   Float64[(counts[i]>0 ? sums[i]/counts[i] : 0.0) for i in 1:nc]
   end
meanpositives (generic function with 1 method)

julia> x
3x3 Array{Float64,2}:
 10.0  5.0  0.0
  5.0  0.0  0.0
  0.0  0.0  0.0

julia> meanpositives(x)
3-element Array{Float64,1}:
 7.5
 5.0
 0.0


On Tue, Jul 28, 2015 at 12:01 PM, Stefan Karpinski 
wrote:

> You mean quicker as in faster or as in easier? Using indexing is probably
> easiest but not fastest:
>
> julia> M = randn(5,5)
> 5x5 Array{Float64,2}:
>  -1.51134 1.2331-0.186083   0.412282  -1.13114
>  -0.0411132   0.124684   0.377426   0.622427  -0.278162
>   0.788182   -0.834092   1.095061.45196   -0.620717
>   1.45856-0.889277  -0.768049  -0.95953   -0.340098
>   1.69666 0.695566   0.706905   0.630890.958474
>
> julia> mean(M[M .> 0])
> 0.8751552351448673
>
>
> If you want the fastest, loop through the matrix and keep totals and
> counts:
>
> julia> function meanpos(a)
>t = zero(eltype(a))
>c = 0
>for x in a
>x > 0 || continue
>t += x
>c += 1
>end
>return t/c
>end
> meanpos (generic function with 1 method)
>
> julia> meanpos(M)
> 0.8751552351448673
>
>
> This should be fairly efficient for any non-sparse collection.
>
>
> On Tue, Jul 28, 2015 at 11:50 AM, Jude  wrote:
>
>> Hi!
>>
>> Probably a quite basic question but was wondering if someone knows a quick
>> way to get the average of theh positive elements of a matrix, eg, If I have
>> an m*n matrix and want to get the average for each m so have m*1 but only
>> want to work with non-zero elements and ignore the zero elements and
>> negative elements
>>
>> I guess I could using indexing and pull out the indexes corresponding to
>> the positive elements but just wondering if anyone knew quicker ways!
>>
>> Thanks!
>>
>
>

Re: [julia-users] Getting the average of only nonzero elements of a matrix

[Stefan Karpinski]

You mean quicker as in faster or as in easier? Using indexing is probably
easiest but not fastest:

julia> M = randn(5,5)
5x5 Array{Float64,2}:
 -1.51134 1.2331-0.186083   0.412282  -1.13114
 -0.0411132   0.124684   0.377426   0.622427  -0.278162
  0.788182   -0.834092   1.095061.45196   -0.620717
  1.45856-0.889277  -0.768049  -0.95953   -0.340098
  1.69666 0.695566   0.706905   0.630890.958474

julia> mean(M[M .> 0])
0.8751552351448673


If you want the fastest, loop through the matrix and keep totals and counts:

julia> function meanpos(a)
   t = zero(eltype(a))
   c = 0
   for x in a
   x > 0 || continue
   t += x
   c += 1
   end
   return t/c
   end
meanpos (generic function with 1 method)

julia> meanpos(M)
0.8751552351448673


This should be fairly efficient for any non-sparse collection.

On Tue, Jul 28, 2015 at 11:50 AM, Jude  wrote:

> Hi!
>
> Probably a quite basic question but was wondering if someone knows a quick
> way to get the average of theh positive elements of a matrix, eg, If I have
> an m*n matrix and want to get the average for each m so have m*1 but only
> want to work with non-zero elements and ignore the zero elements and
> negative elements
>
> I guess I could using indexing and pull out the indexes corresponding to
> the positive elements but just wondering if anyone knew quicker ways!
>
> Thanks!
>

[julia-users] Getting the average of only nonzero elements of a matrix

[Jude]

Hi!

Probably a quite basic question but was wondering if someone knows a quick 
way to get the average of theh positive elements of a matrix, eg, If I have 
an m*n matrix and want to get the average for each m so have m*1 but only 
want to work with non-zero elements and ignore the zero elements and 
negative elements

I guess I could using indexing and pull out the indexes corresponding to 
the positive elements but just wondering if anyone knew quicker ways!

Thanks!

[julia-users] Re: Can I keep some things compiled?

[felipenoris]

On 0.3, I think your best option is to build a custom system image with 
precompiled modules on it.
On 0.4, there´s added support for incremental module precompilation using 
Base.compile(:module).

Check 
http://docs.julialang.org/en/latest/manual/modules/#module-initialization-and-precompilation
And 
also https://github.com/JuliaLang/julia/blob/release-0.3/base/precompile.jl

Em terça-feira, 28 de julho de 2015 12:27:56 UTC-3, LarryD escreveu:
>
> When I start Juno, I wait ~10 secs for "spinning  " to complete. Then 
> if I need, say, "using pyplot", I wait another ~15 secs. I am just learning 
> Julia, so I often make mistakes in my test programs, and it's not uncommon 
> to need to interrupt Julia to stop something I inadvertently created. But 
> then I have to go back through "using pyplot" + whatever else my program 
> needs.  Is there any way to separate stuff that's already compiled from 
> stuff that I'm working on so that the already compiled stuff can stay 
> compiled?
>
> Thanks
>
>
>

Re: [julia-users] Can I keep some things compiled?

[Yichao Yu]

On Tue, Jul 28, 2015 at 11:27 AM, LarryD  wrote:
> When I start Juno, I wait ~10 secs for "spinning  " to complete. Then if
> I need, say, "using pyplot", I wait another ~15 secs. I am just learning
> Julia, so I often make mistakes in my test programs, and it's not uncommon
> to need to interrupt Julia to stop something I inadvertently created. But
> then I have to go back through "using pyplot" + whatever else my program
> needs.  Is there any way to separate stuff that's already compiled from
> stuff that I'm working on so that the already compiled stuff can stay
> compiled?

On 0.4 yes. https://github.com/JuliaLang/julia/pull/8745

>
> Thanks
>
>

[julia-users] Can I keep some things compiled?

[LarryD]

When I start Juno, I wait ~10 secs for "spinning  " to complete. Then 
if I need, say, "using pyplot", I wait another ~15 secs. I am just learning 
Julia, so I often make mistakes in my test programs, and it's not uncommon 
to need to interrupt Julia to stop something I inadvertently created. But 
then I have to go back through "using pyplot" + whatever else my program 
needs.  Is there any way to separate stuff that's already compiled from 
stuff that I'm working on so that the already compiled stuff can stay 
compiled?

Thanks

[julia-users] Re: Where to get general offline help with Julia?

[felipenoris]

#Clone julia repo:
> git clone g...@github.com:JuliaLang/julia.git

# go into docs folder
> cd julia/doc

# build the docs
> make html

Em terça-feira, 28 de julho de 2015 09:34:18 UTC-3, Joe Tusek escreveu:
>
> Its embarrassing but where can you ask for some to provide offline 
> assistance with porting over Matlab code to Julia, its exhausted me for now 
> but I still need to get the code working?
>

[julia-users] Memory not freed up when deleting dictionary values

[Andrew B. Martin]

I asked this question on Julia-Opt, and Joey Huchette suggested I move it 
here.

https://groups.google.com/d/msg/julia-opt/i6wV8aeSLjg/pZHkEdhDjvsJ

The thrust of the question is that I'm deleting and garbage collecting 
dictionary values, but the memory associated with those values is not freed 
up after garbage collection. Joey pointed out that the dictionary could 
still be keeping a reference to the deleted object.

My example:
# System memory 500/15039MB

julia> d = buidModel();
"success"

# System memory at 8883/15039MB

# delete the model object - corresponds to about a 1 Gb LP file
# I observe the same effect if I enter
# julia> d["m"] = 0;

julia> delete!(d, “m”);

# System memory unchanged

julia> gc()

# System memory unchanged

# delete a list of affine expressions used to make constraints in the model 
- estimated 1GB - 2GB RAM
julia> d[“aff_exprs”] = 0

# System memory unchanged

julia> gc()

# System memory unchanged

julia> d = 0

# System memory unchanged

julia> gc()

# System memory 8255/15039MB

Why is memory not getting freed up when I delete or reassign dictionary 
values?

I can see how that by removing dictionary values with delete! references to 
deleted values might linger, but when I reassign and garbage collect it 
seems to me that they should be removed for good.

I'm using Ubuntu 14.04.1 LTS with Julia 0.3.8. I also observe this 
behaviour on Windows 7 with Julia 0.3.10.

Re: [julia-users] Reinterpreting bits types with rem?

[Galen Lynch]

Ah ok that makes sense.

On Tuesday, July 28, 2015 at 10:14:29 AM UTC-4, Yichao Yu wrote:
>
>
>
> On Tue, Jul 28, 2015 at 10:03 AM, Galen Lynch  > wrote:
>
>> Awesome, thanks for your reply!
>>
>> C cast does a type conversion on the value, right? For example, you could 
>> cast an integer 1 into a float 1.0 with cast. It seems like Julia's rem is 
>> doing something a little different, as doing `1 % Float32` is invalid.
>>
>
> Well, it doesn't allow pointer either. What I meant was that for 
> conversions that are allowed by `rem`, it basically behave like a c cast. 
> (you can use `methods(rem)` to see what it is defined for).
>
> This is different from the normal convert which will give you an error on 
> overflow.
>
>  
>
>>
>> I don't see a method for rem that applies to `Ptr`. Where do you see it? 
>>>
>>
>> Ah, you're right, I was reading over it too quickly and misunderstood the 
>> code. Here's the line I was thinking of (in isostream.jl, line 169)
>> ```
>> function read{T<:Union{UInt16, Int16, UInt32, Int32, UInt64, Int64}}(s
>> ::IOStream, ::Type{T}) ccall(:jl_ios_get_nbyte_int, UInt64, (Ptr{Void}, 
>> Csize_t), s.ios, sizeof(T)) % T end ``` Thanks again!
>> On Tuesday, July 28, 2015 at 9:18:07 AM UTC-4, Yichao Yu wrote:
>>>
>>> On Tue, Jul 28, 2015 at 9:02 AM, Galen Lynch  
>>> wrote: 
>>> > Does rem(x, bitsT) or x % bitsT reinterpret the bits in variable x as 
>>> a bits 
>>>
>>> AFAICT, `rem` is basically doing the C cast. 
>>>
>>> > type T, and is this "in place"? I noticed that in some places when 
>>> Julia 
>>>
>>> Bitstype are immutable so this is never in place. However, it doesn't 
>>> need any boxing either. It should be as efficient as when you write a 
>>> c cast in c. 
>>>
>>> ```julia 
>>> julia> @code_llvm rem(1, UInt32) 
>>>
>>> define i32 @julia_rem_20919(i64, %jl_value_t*) { 
>>> top: 
>>>  %2 = trunc i64 %0 to i32 
>>>  ret i32 %2 
>>> } 
>>> ``` 
>>>
>>> > gets a pointer from ccall it uses " % T" after the ccall,  presumably 
>>> to 
>>> > give Julia information about its type (boxing it?). Simple tests, such 
>>> as 
>>>
>>> I don't see a method for rem that applies to `Ptr`. Where do you see it? 
>>>
>>> > typemax(UInt32) % Int32 seem to behave like reinterpreting the 
>>> underlying 
>>> > bits. 
>>>
>>
>

[julia-users] Re: Gadfly legend for different layers

[elcitch]

Is there a way to specify the color once for the layer for both the line and 
the color key? It looks like you have to define the color for each layer twice.

Thanks!  

Re: [julia-users] Re: setindex! for matrix of vectors

[Yichao Yu]

On Tue, Jul 28, 2015 at 10:05 AM, Matt Bauman  wrote:
> Yes, this is one of the ever-tricky cases of "did you mean the container or
> the elements of that container?"  Setindex always assumes that, if the RHS
> of the assignment is an array of some sort, it's the elements that should be
> assigned.
>
> David, `A[:] = Vector[[1,2,3]]` works as you'd expect (this is the array
> concatenation vs construction issue), but this will only work if
> `length(A)==1`.
>
> And Linus, an easy work-around (assuming that you don't always just have a
> one-element) is to use `fill!` instead: `fill!(A, [1,2,3])`.

Well, depend on what you want, make sure you don't hit another pitfall

```julia
julia> a = Vector{Vector{Int}}(2)
2-element Array{Array{Int64,1},1}:
#undef
#undef

julia> fill!(a, [1, 2, 3])
2-element Array{Array{Int64,1},1}:
[1,2,3]
[1,2,3]

julia> push!(a[1], 4)
4-element Array{Int64,1}:
1
2
3
4

julia> a[2]
4-element Array{Int64,1}:
1
2
3
4
```

>
>
> On Tuesday, July 28, 2015 at 8:45:44 AM UTC-4, David Gold wrote:
>>
>> That error makes sense to me, insofar as `A[:]` is not a scalar entry but
>> a whole vector. So assigning the vector `[1, 2, 3]` to `A[:]` is interpreted
>> as, "put all the things from this vector into that vector". But by that
>> logic, `A[:] = [[1, 2, 3],]` ought to work, and it doesn't. Of course,
>> scalar assignment works as expected.
>>
>> If you can't avoid colon, one thing you can do is define a wrapper type
>> that isn't interpreted as container of objects each of which is to be
>> assigned to an index in `A[:]`, as well as an appropriate convert method:
>>
>> julia> type ArrayWrapper{T, N}
>> A::Array{T, N}
>> end
>>
>> julia> Base.convert{T, N}(::Type{Array{T, N}}, X::ArrayWrapper{T, N}) =
>> X.A
>> convert (generic function with 700 methods)
>>
>> julia> A[:] = ArrayWrapper([1, 2, 3])
>> ArrayWrapper{Int64,1}([1,2,3])
>>
>> julia> A
>> 1-element Array{Array{Int64,1},1}:
>> [1,2,3]
>>
>>
>> On Tuesday, July 28, 2015 at 4:06:59 AM UTC-4, Linus Härenstam-Nielsen
>> wrote:
>>>
>>> I'm implementing a setindex! method for an object with a field of type
>>> Matrix{Vector{Float64}} (a matrix of vectors) and I've run into a problem
>>> with getting the Colon() index to work properly. It comes down to this:
>>>
>>> julia> A = Array(Vector{Int}, 1)
>>> 1-element Array{Array{Int64,1},1}:
>>>  #undef
>>>
>>> julia> A[:] = [1,2,3]
>>> ERROR: DimensionMismatch("tried to assign 3 elements to 1 destinations")
>>>  in throw_setindex_mismatch at operators.jl:226
>>>
>>> Since the element I'm trying to assign is a vector setindex! calls the
>>> wrong method for my purposes. What I would like is for the resulting array
>>> to be:
>>>
>>> julia> A
>>> 1-element Array{Array{Int64,1},1}:
>>>  [1,2,3]
>>>
>>> Is there a way to get around this? I would change the datatype to
>>> Array{Float64, 3} if I could but other functions rely on the current
>>> structure.

Re: [julia-users] Reinterpreting bits types with rem?

[Yichao Yu]

On Tue, Jul 28, 2015 at 10:03 AM, Galen Lynch  wrote:

> Awesome, thanks for your reply!
>
> C cast does a type conversion on the value, right? For example, you could
> cast an integer 1 into a float 1.0 with cast. It seems like Julia's rem is
> doing something a little different, as doing `1 % Float32` is invalid.
>

Well, it doesn't allow pointer either. What I meant was that for
conversions that are allowed by `rem`, it basically behave like a c cast.
(you can use `methods(rem)` to see what it is defined for).

This is different from the normal convert which will give you an error on
overflow.



>
> I don't see a method for rem that applies to `Ptr`. Where do you see it?
>>
>
> Ah, you're right, I was reading over it too quickly and misunderstood the
> code. Here's the line I was thinking of (in isostream.jl, line 169)
> ```
> function read{T<:Union{UInt16, Int16, UInt32, Int32, UInt64, Int64}}(s
> ::IOStream, ::Type{T}) ccall(:jl_ios_get_nbyte_int, UInt64, (Ptr{Void},
> Csize_t), s.ios, sizeof(T)) % T end ``` Thanks again!
> On Tuesday, July 28, 2015 at 9:18:07 AM UTC-4, Yichao Yu wrote:
>>
>> On Tue, Jul 28, 2015 at 9:02 AM, Galen Lynch  wrote:
>> > Does rem(x, bitsT) or x % bitsT reinterpret the bits in variable x as a
>> bits
>>
>> AFAICT, `rem` is basically doing the C cast.
>>
>> > type T, and is this "in place"? I noticed that in some places when
>> Julia
>>
>> Bitstype are immutable so this is never in place. However, it doesn't
>> need any boxing either. It should be as efficient as when you write a
>> c cast in c.
>>
>> ```julia
>> julia> @code_llvm rem(1, UInt32)
>>
>> define i32 @julia_rem_20919(i64, %jl_value_t*) {
>> top:
>>  %2 = trunc i64 %0 to i32
>>  ret i32 %2
>> }
>> ```
>>
>> > gets a pointer from ccall it uses " % T" after the ccall,  presumably
>> to
>> > give Julia information about its type (boxing it?). Simple tests, such
>> as
>>
>> I don't see a method for rem that applies to `Ptr`. Where do you see it?
>>
>> > typemax(UInt32) % Int32 seem to behave like reinterpreting the
>> underlying
>> > bits.
>>
>

[julia-users] Re: setindex! for matrix of vectors

[Matt Bauman]

Yes, this is one of the ever-tricky cases of "did you mean the container or 
the elements of that container?"  Setindex always assumes that, if the RHS 
of the assignment is an array of some sort, it's the elements that should 
be assigned.

David, `A[:] = Vector[[1,2,3]]` works as you'd expect (this is the array 
concatenation vs construction issue), but this will only work if 
`length(A)==1`.

And Linus, an easy work-around (assuming that you don't always just have a 
one-element) is to use `fill!` instead: `fill!(A, [1,2,3])`.

On Tuesday, July 28, 2015 at 8:45:44 AM UTC-4, David Gold wrote:
>
> That error makes sense to me, insofar as `A[:]` is not a scalar entry but 
> a whole vector. So assigning the vector `[1, 2, 3]` to `A[:]` is 
> interpreted as, "put all the things from this vector into that vector". But 
> by that logic, `A[:] = [[1, 2, 3],]` ought to work, and it doesn't. Of 
> course, scalar assignment works as expected.
>
> If you can't avoid colon, one thing you can do is define a wrapper type 
> that isn't interpreted as container of objects each of which is to be 
> assigned to an index in `A[:]`, as well as an appropriate convert method:
>
> julia> type ArrayWrapper{T, N} 
> A::Array{T, N} 
> end
>
> julia> Base.convert{T, N}(::Type{Array{T, N}}, X::ArrayWrapper{T, N}) = X.A
> convert (generic function with 700 methods)
>
> julia> A[:] = ArrayWrapper([1, 2, 3])
> ArrayWrapper{Int64,1}([1,2,3])
>
> julia> A
> 1-element Array{Array{Int64,1},1}:
> [1,2,3]
>
>
> On Tuesday, July 28, 2015 at 4:06:59 AM UTC-4, Linus Härenstam-Nielsen 
> wrote:
>>
>> I'm implementing a setindex! method for an object with a field of type 
>> Matrix{Vector{Float64}} (a matrix of vectors) and I've run into a problem 
>> with getting the Colon() index to work properly. It comes down to this:
>>
>> julia> A = Array(Vector{Int}, 1)
>> 1-element Array{Array{Int64,1},1}:
>>  #undef
>>
>> julia> A[:] = [1,2,3]
>> ERROR: DimensionMismatch("tried to assign 3 elements to 1 destinations")
>>  in throw_setindex_mismatch at operators.jl:226
>>
>> Since the element I'm trying to assign is a vector setindex! calls the 
>> wrong method for my purposes. What I would like is for the resulting array 
>> to be:
>>
>> julia> A
>> 1-element Array{Array{Int64,1},1}:
>>  [1,2,3]
>>
>> Is there a way to get around this? I would change the datatype to 
>> Array{Float64, 3} if I could but other functions rely on the current 
>> structure.
>>
>

Re: [julia-users] Reinterpreting bits types with rem?

[Galen Lynch]

Awesome, thanks for your reply!

C cast does a type conversion on the value, right? For example, you could 
cast an integer 1 into a float 1.0 with cast. It seems like Julia's rem is 
doing something a little different, as doing `1 % Float32` is invalid.

I don't see a method for rem that applies to `Ptr`. Where do you see it? 
>

Ah, you're right, I was reading over it too quickly and misunderstood the 
code. Here's the line I was thinking of (in isostream.jl, line 169)
```
function read{T<:Union{UInt16, Int16, UInt32, Int32, UInt64, Int64}}(s
::IOStream, ::Type{T}) ccall(:jl_ios_get_nbyte_int, UInt64, (Ptr{Void}, 
Csize_t), s.ios, sizeof(T)) % T end ``` Thanks again!
On Tuesday, July 28, 2015 at 9:18:07 AM UTC-4, Yichao Yu wrote:
>
> On Tue, Jul 28, 2015 at 9:02 AM, Galen Lynch  > wrote: 
> > Does rem(x, bitsT) or x % bitsT reinterpret the bits in variable x as a 
> bits 
>
> AFAICT, `rem` is basically doing the C cast. 
>
> > type T, and is this "in place"? I noticed that in some places when Julia 
>
> Bitstype are immutable so this is never in place. However, it doesn't 
> need any boxing either. It should be as efficient as when you write a 
> c cast in c. 
>
> ```julia 
> julia> @code_llvm rem(1, UInt32) 
>
> define i32 @julia_rem_20919(i64, %jl_value_t*) { 
> top: 
>  %2 = trunc i64 %0 to i32 
>  ret i32 %2 
> } 
> ``` 
>
> > gets a pointer from ccall it uses " % T" after the ccall,  presumably to 
> > give Julia information about its type (boxing it?). Simple tests, such 
> as 
>
> I don't see a method for rem that applies to `Ptr`. Where do you see it? 
>
> > typemax(UInt32) % Int32 seem to behave like reinterpreting the 
> underlying 
> > bits. 
>

[julia-users] Julia parallelilisation performance not scaling as expected

[Nikos Gianniotis]

Dear all, 

I am trying to understand how to use parallelisation in Julia on a toy 
example so that I can then use it properly on my machine learning code, in 
particular when it comes to gradient parallelisation. The toy problem 
follows below. I am working with Julia version 0.3.10.


   1. What I am basically doing is create a rather large matrix X. The 
   expensive function f is multiplying the matrix with its transpose, 
   calculating the eigenvalues and summing them.
   2. I am aware that data movement is an issue, so I move the large matrix 
   X to all available workers.
   3. I make function f visible to all workers.
   4. I compare a serial loop, a kind of parallel loop and a pmap.

I have timed the three loops and these are my results.
The results are listed in the order of serial loop, parallel loop and pmap.

For 1 core:
elapsed time: 1.655914423 seconds (128659112 bytes allocated, 1.27% gc time)
elapsed time: 1.772206383 seconds (129083420 bytes allocated, 3.82% gc time)
elapsed time: 1.696328198 seconds (128663232 bytes allocated, 1.26% gc time)

For 2 cores:
elapsed time: 5.212182485 seconds (257439664 bytes allocated, 1.22% gc time)
elapsed time: 3.240600779 seconds (19024 bytes allocated)
elapsed time: 3.209254358 seconds (22632 bytes allocated)

For 3 cores:
elapsed time: 8.250848434 seconds (426313044 bytes allocated, 1.32% gc time)
elapsed time: 5.814770536 seconds (4136208 bytes allocated)
elapsed time: 4.953485727 seconds (7037788 bytes allocated)

For 4 cores:
elapsed time: 10.365841923 seconds (514755200 bytes allocated, 1.18% gc 
time)
elapsed time: 5.40863 seconds (39960 bytes allocated)
elapsed time: 5.577246135 seconds (38560 bytes allocated)

For 5 cores:
elapsed time: 13.007625341 seconds (643413000 bytes allocated, 1.23% gc 
time)
elapsed time: 6.075477789 seconds (59492 bytes allocated)
elapsed time: 6.021519196 seconds (46968 bytes allocated)

For 6 cores:
elapsed time: 15.61624446 seconds (772070736 bytes allocated, 1.15% gc time)
elapsed time: 6.95443167 seconds (73816 bytes allocated)
elapsed time: 6.975629252 seconds (55248 bytes allocated)


As is evident(?) this is not the scaling behaviour one would expect for 
independent tasks run in parallel.

Any guesses as to what I might be doing wrong? Or is this perhaps a bad 
example?

All help is appreciated, thanks very much in advance.
Cheers,
N.




*CODE FOLLOWS BELOW BUT ALSO ATTACHED*


# create some (fairly) big matrix
N = 2000
X = randn(N,N);

# send matrix X to all workers
Xref = Array(RemoteRef, nworkers())
for (index,id) in enumerate(workers())
  Xref[index] = @spawnat id X
end

# create function that operates on X and visiable to all workers
@everywhere f = x -> sum(eig(x*x')[1])

#
# serial loop
#
acc_serial = 0

@time for ii=1:nworkers()
  acc_serial += f(X)
end

#
# parallel loop
#
acc_par = 0

@time begin

  aux = Array(RemoteRef, nworkers())
  for (ii,id) in enumerate(workers())
aux[ii] = @spawnat id f(fetch(Xref[ii]))
  end

  for ii=1:nworkers()
acc_par += fetch(aux[ii])
  end

end

#
# pmap
#
@time out = pmap( r -> f(fetch(r)), Xref)



exp2.jl
Description: Binary data

[julia-users] Re: Where to get general offline help with Julia?

[Tom Breloff]

Hi Joe.  I take it you haven't gotten enough help on this forum?  You could 
post a more complete example of what you're trying to port, and also what 
progress you've made.  Github gists are a good way to put lots of code in 
one place.  It might be that you're missing a simple/key concept which will 
help move you forward, in which case we need more info/code to help you.

If you try that and don't get a satisfactory response, you could support 
the guys at Julia Computing LLC (http://juliacomputing.com/) for some 
training/consulting.

On Tuesday, July 28, 2015 at 8:34:18 AM UTC-4, Joe Tusek wrote:
>
> Its embarrassing but where can you ask for some to provide offline 
> assistance with porting over Matlab code to Julia, its exhausted me for now 
> but I still need to get the code working?
>

Re: [julia-users] Reinterpreting bits types with rem?

[Yichao Yu]

On Tue, Jul 28, 2015 at 9:02 AM, Galen Lynch  wrote:
> Does rem(x, bitsT) or x % bitsT reinterpret the bits in variable x as a bits

AFAICT, `rem` is basically doing the C cast.

> type T, and is this "in place"? I noticed that in some places when Julia

Bitstype are immutable so this is never in place. However, it doesn't
need any boxing either. It should be as efficient as when you write a
c cast in c.

```julia
julia> @code_llvm rem(1, UInt32)

define i32 @julia_rem_20919(i64, %jl_value_t*) {
top:
 %2 = trunc i64 %0 to i32
 ret i32 %2
}
```

> gets a pointer from ccall it uses " % T" after the ccall,  presumably to
> give Julia information about its type (boxing it?). Simple tests, such as

I don't see a method for rem that applies to `Ptr`. Where do you see it?

> typemax(UInt32) % Int32 seem to behave like reinterpreting the underlying
> bits.

[julia-users] Reinterpreting bits types with rem?

[Galen Lynch]

Does rem(x, bitsT) or x % bitsT reinterpret the bits in variable x as a 
bits type T, and is this "in place"? I noticed that in some places when 
Julia gets a pointer from ccall it uses " % T" after the ccall,  presumably 
to give Julia information about its type (boxing it?). Simple tests, such 
as typemax(UInt32) % Int32 seem to behave like reinterpreting the 
underlying bits.

[julia-users] Re: setindex! for matrix of vectors

[David Gold]

That error makes sense to me, insofar as `A[:]` is not a scalar entry but a 
whole vector. So assigning the vector `[1, 2, 3]` to `A[:]` is interpreted 
as, "put all the things from this vector into that vector". But by that 
logic, `A[:] = [[1, 2, 3],]` ought to work, and it doesn't. Of course, 
scalar assignment works as expected.

If you can't avoid colon, one thing you can do is define a wrapper type 
that isn't interpreted as container of objects each of which is to be 
assigned to an index in `A[:]`, as well as an appropriate convert method:

julia> type ArrayWrapper{T, N} 
A::Array{T, N} 
end

julia> Base.convert{T, N}(::Type{Array{T, N}}, X::ArrayWrapper{T, N}) = X.A
convert (generic function with 700 methods)

julia> A[:] = ArrayWrapper([1, 2, 3])
ArrayWrapper{Int64,1}([1,2,3])

julia> A
1-element Array{Array{Int64,1},1}:
[1,2,3]


On Tuesday, July 28, 2015 at 4:06:59 AM UTC-4, Linus Härenstam-Nielsen 
wrote:
>
> I'm implementing a setindex! method for an object with a field of type 
> Matrix{Vector{Float64}} (a matrix of vectors) and I've run into a problem 
> with getting the Colon() index to work properly. It comes down to this:
>
> julia> A = Array(Vector{Int}, 1)
> 1-element Array{Array{Int64,1},1}:
>  #undef
>
> julia> A[:] = [1,2,3]
> ERROR: DimensionMismatch("tried to assign 3 elements to 1 destinations")
>  in throw_setindex_mismatch at operators.jl:226
>
> Since the element I'm trying to assign is a vector setindex! calls the 
> wrong method for my purposes. What I would like is for the resulting array 
> to be:
>
> julia> A
> 1-element Array{Array{Int64,1},1}:
>  [1,2,3]
>
> Is there a way to get around this? I would change the datatype to 
> Array{Float64, 3} if I could but other functions rely on the current 
> structure.
>

[julia-users] Where to get general offline help with Julia?

[Joe Tusek]

Its embarrassing but where can you ask for some to provide offline 
assistance with porting over Matlab code to Julia, its exhausted me for now 
but I still need to get the code working?

Re: [julia-users] Juno - Orphan messages W7-64

[Mike Innes]

I've seen this before a couple of times but it shouldn't happen too often.
If it does, your best bet is to just close and open the current editor.

Unfortunately, there have been a few issues like this with Light Table
recently – it's not getting much maintenance effort. We're working on ways
of moving forward IDE-wise and will have more concrete plans to announce
soon.

On Tue, 28 Jul 2015 at 11:45 Joe Tusek  wrote:

> In Juno when I get errors in my code I get pink message boxes either
> inline or at the end or both. But after a while I get an accumulation of
> boxes and I cannot clear them. They just stack up and clutter the editor
> space. Right clicking on the older ones only gives an evaluate and other
> not useful options. If I inspect the box and remove it right away without
> leaving it there, then it appear to not be a problem. In general, a lack of
> an ability to close any message box or any pop-up at will seems
> undesirable.
>

[julia-users] Juno - Orphan messages W7-64

[Joe Tusek]

In Juno when I get errors in my code I get pink message boxes either inline 
or at the end or both. But after a while I get an accumulation of boxes and 
I cannot clear them. They just stack up and clutter the editor space. Right 
clicking on the older ones only gives an evaluate and other not useful 
options. If I inspect the box and remove it right away without leaving it 
there, then it appear to not be a problem. In general, a lack of an ability 
to close any message box or any pop-up at will seems undesirable. 

[julia-users] Re: History file in Ubuntu

[Konstantinos Prokopidis]

Thank you very much! It was a hidden file in home directory

[julia-users] Re: History file in Ubuntu

[Kaj Wiik]

Hi!

I have it in $HOME/.julia_history as you assumed. Note that it will be 
written (created) when julia exits. So start julia, do something and exit 
and the file should be there.

Kaj


On Tuesday, July 28, 2015 at 10:46:46 AM UTC+3, Konstantinos Prokopidis 
wrote:
>
>
>
> Hello,
> I just installed julia 0.3.10 in Ubuntu 14.04 LTS. I can't find the 
> history file (.julia_history) in order to delete or rename it. I got a 
> message that .julia_history file left over from a 
> older version of Julia. Where is the history file in Ubuntu?
>
> Thanks in advance
>

[julia-users] setindex! for matrix of vectors

[Linus Härenstam-Nielsen]

I'm implementing a setindex! method for an object with a field of type 
Matrix{Vector{Float64}} (a matrix of vectors) and I've run into a problem 
with getting the Colon() index to work properly. It comes down to this:

julia> A = Array(Vector{Int}, 1)
1-element Array{Array{Int64,1},1}:
 #undef

julia> A[:] = [1,2,3]
ERROR: DimensionMismatch("tried to assign 3 elements to 1 destinations")
 in throw_setindex_mismatch at operators.jl:226

Since the element I'm trying to assign is a vector setindex! calls the 
wrong method for my purposes. What I would like is for the resulting array 
to be:

julia> A
1-element Array{Array{Int64,1},1}:
 [1,2,3]

Is there a way to get around this? I would change the datatype to 
Array{Float64, 3} if I could but other functions rely on the current 
structure.

[julia-users] History file in Ubuntu

[Konstantinos Prokopidis]

Hello,
I just installed julia 0.3.10 in Ubuntu 14.04 LTS. I can't find the history 
file (.julia_history) in order to delete or rename it. I got a message that 
.julia_history file left over from a 
older version of Julia. Where is the history file in Ubuntu?

Thanks in advance

Re: [julia-users] typealias constructors

[Vincent Lostanlen]

Errata : here is a MWE that actually works.


immutable Literal
symbol::Symbol
level::Int
end
typealias SymbolInt @compat(Tuple{Symbol,Int})
Literal(tup::SymbolInt) = Literal(tup[1], tup[2])
Literal(sym::Symbol) = Literal(sym, 1)

typealias MyList LinkedList{Literal}
MyList() = nil(Literal)
MyList(head, tail...) = cons(Literal(head), MyList(tail...))



After running this on v0.4, MyList(:a, (:b, 2)) yields
list(Literal(:a,1), Literal(:b,2))
which is exactly what I want: a list of Literals that support mixed syntax 
for element construction.
Is it possible to do this on prior versions ?

Vincent.

Le lundi 27 juillet 2015 19:45:52 UTC+2, Vincent Lostanlen a écrit :
>
> Is there a way to make this backwards compatible with latest v0.3 ? I find 
> typealias constructors extremely handy to extend the behavior of existing 
> recursive constructors (LinkedList here).
> Here is a minimal use case requiring DataStructures and Compat:
>
> immutable Literal
> symbol::Symbol
> level::Int
> end
> typealias SymbolInt @compat(Tuple{Symbol,Int})
> Literal(tup::SymbolInt) = Literal(tup[1], tup[2])
> Literal(sym::Symbol) = Literal(sym, 1)
>
> typealias MyList LinkedList{Literal}
> MyList() = nil(Literal)
> MyList(head::Literal, tail...) = cons(head, VariableKey(tail...))
> MyList(head::Union(SymbolInt,Symbol), tail...) = cons(Literal(head), 
> VariableKey(tail...))
>
> On v0.4, this code makes the MyList type a synonym of LinkedList{Literal}, 
> without having to explicitly construct a Literal object for every element 
> in the list a priori.
> What can I do ?
>
> Vincent.
>
> Le samedi 2 mai 2015 20:43:58 UTC+2, Mauro a écrit :
>>
>> You need to be on 0.4 to do this. 
>>
>> On Sat, 2015-05-02 at 20:40, Krishna Subramanian  
>> wrote: 
>> > I would like to know how to do something like this- 
>> > typealias Corpus Array{Int,1} 
>> > 
>> > and write a constructor for it. Currently, if I do - 
>> > 
>> > Corpus() = Array(Int,0) 
>> > 
>> > I get- 
>> > 
>> > ERROR: cannot define function Corpus; it already has a value 
>> > 
>> > I am sure others have encountered this problem before. I went through 
>> > https://github.com/JuliaLang/julia/issues/1470 but I am still not able 
>> to 
>> > figure out what is the issue involved. 
>> > 
>> > Thanks, 
>> > Krishna 
>>
>>