Re: [julia-users] Arrays as streams / consuming data with take et al

[Yichao Yu]

On Mon, Nov 9, 2015 at 8:04 AM, andrew cooke  wrote:
>
> https://github.com/andrewcooke/StatefulIterators.jl

FYI, one way to make this more efficient is to parametrize the
iterator. You could easily do this for Array's. In the more general
case, you needs type inference to get the type right for a
non-type-stable iterator (iterator with a type unstable index...) but
it's generally a bad idea to write code that calls type inference
directly.

>
>
> On Monday, 9 November 2015 06:24:14 UTC-3, andrew cooke wrote:
>>
>> thanks!
>>
>> On Sunday, 8 November 2015 22:40:53 UTC-3, Yichao Yu wrote:
>>>
>>> On Sun, Nov 8, 2015 at 8:11 PM, andrew cooke  wrote:
>>> > I'd like to be able to use take() and all the other iterator tools with
>>> > a
>>> > stream of data backed by an array (or string).
>>> >
>>> > By that I mean I'd like to be able to do something like:
>>> >
>>> >> stream = XXX([1,2,3,4,5])
>>> >> collect(take(stream, 3))
>>> > [1,2,3]
>>> >> collect(take(stream, 2))
>>> > [4,5]
>>> >
>>> > Is this possible?  I can find heavyweight looking streams for IO, and I
>>> > can
>>> > find lightweight iterables without state.  But I can't seem to find the
>>> > particular mix described above.
>>>
>>> Jeff's conclusion @ JuliaCon is that it seems impossible to implement
>>> this (stateful iterator) currently in a generic and performant way so
>>> I doubt you will find it in a generic iterator library (that works not
>>> only on arrays). A version that works only on Arrays should be simple
>>> enough to implement and doesn't sound useful enough to be in an
>>> exported API so I guess you probably should just implement your own.
>>>
>>> Ref
>>> https://groups.google.com/forum/?fromgroups=#!searchin/julia-users/iterator/julia-users/t4ZieI2_iwI/3NTw1k406qkJ
>>>
>>> >
>>> > (I think I can see how to write it myself; I'm asking if it already
>>> > exists -
>>> > seems like it should, but I can't find the right words to search for).
>>> >
>>> > Thanks,
>>> > Andrew
>>> >

Re: [julia-users] Arrays as streams / consuming data with take et al

[andrew cooke]

https://github.com/andrewcooke/StatefulIterators.jl

On Monday, 9 November 2015 06:24:14 UTC-3, andrew cooke wrote:
>
> thanks!
>
> On Sunday, 8 November 2015 22:40:53 UTC-3, Yichao Yu wrote:
>>
>> On Sun, Nov 8, 2015 at 8:11 PM, andrew cooke  wrote: 
>> > I'd like to be able to use take() and all the other iterator tools with 
>> a 
>> > stream of data backed by an array (or string). 
>> > 
>> > By that I mean I'd like to be able to do something like: 
>> > 
>> >> stream = XXX([1,2,3,4,5]) 
>> >> collect(take(stream, 3)) 
>> > [1,2,3] 
>> >> collect(take(stream, 2)) 
>> > [4,5] 
>> > 
>> > Is this possible?  I can find heavyweight looking streams for IO, and I 
>> can 
>> > find lightweight iterables without state.  But I can't seem to find the 
>> > particular mix described above. 
>>
>> Jeff's conclusion @ JuliaCon is that it seems impossible to implement 
>> this (stateful iterator) currently in a generic and performant way so 
>> I doubt you will find it in a generic iterator library (that works not 
>> only on arrays). A version that works only on Arrays should be simple 
>> enough to implement and doesn't sound useful enough to be in an 
>> exported API so I guess you probably should just implement your own. 
>>
>> Ref 
>> https://groups.google.com/forum/?fromgroups=#!searchin/julia-users/iterator/julia-users/t4ZieI2_iwI/3NTw1k406qkJ
>>  
>>
>> > 
>> > (I think I can see how to write it myself; I'm asking if it already 
>> exists - 
>> > seems like it should, but I can't find the right words to search for). 
>> > 
>> > Thanks, 
>> > Andrew 
>> > 
>>
>

[julia-users] Using Meshes.ji

[Ashley Kleinhans]

Hi,

I am new at this - but have decided that Julia is my language of choice. So 
I begin silly question stage: 

Could someone talk me through how to access and display an .obj file? 

I have gotten so far:

using Meshes
using PyPlot
using FileIO
using MeshIO

obj = load(filename)
vts = obj.vertices 


Which gives me: 

502-element Array{FixedSizeArrays.Point{3,Float32},1}:



One example point being: 

Point(0.00117,-0.02631,0.03907)

   

  

How do I access the verticies to use them with plot? 

-A

[julia-users] Re: ANN: Julia 0.4.1 and 0.3.12 released

[Tony Kelman]

>From extracting them and looking around via windirstat or du --max-depth=N, 
most of the difference is due to the newer bundled version of Git in 0.4.1. 
Hopefully this will fix more issues than it might cause, but let me know if 
anything seems out of the ordinary. It looks like the embedded copy of Git 
2.x is smaller after extracting than 1.x was, but it doesn't compress as 
well.

There also appears to be an extra copy of the docs sitting in share, that 
might be a leftover from nightly builds (which run on the same buildbots) 
since they might build the docs into a different folder structure and I 
forgot to completely clear out the buildbots before building the release 
binaries (or I just didn't want them to take as long to build from scratch).


On Monday, November 9, 2015 at 12:47:50 PM UTC-8, bernhard wrote:
>
> Out of curiosity: why is this release 54mb (up from 40mb for 0.4). I am 
> referring to the file size of the Win 64bit binaries here.
>
> Am Montag, 9. November 2015 20:37:48 UTC+1 schrieb Tony Kelman:
>>
>> Hello all! The latest bugfix releases of both 0.4.x and 0.3.x Julia lines 
>> have been released. Binaries are available from the usual place 
>>  (see Old releases 
>>  for 0.3.12), and as is 
>> typical with such things, please report all issues to either the issue 
>> tracker , or email the 
>> julia-users list. (If you respond to this message on julia-users, please do 
>> not cc julia-news which is intended to be low-volume.)
>>
>> These are bugfix releases. 0.3.12 is likely to be the last release in the 
>> 0.3.x line unless any critical bugs or regressions are identified. To see 
>> the list of bugs fixed since 0.3.11, see this commit log 
>> . Bugfix 
>> backports to the 0.4.x line will be continuing with a target of one point 
>> release per month. See this commit log 
>>  for the 
>> list of bugs fixed between 0.4.0 and 0.4.1. If you are a package author and 
>> want to rely on functionality that did not work in 0.4.0 but does work in 
>> 0.4.1 in your package, please be sure to change the minimum julia version 
>> in your REQUIRE file to 0.4.1 accordingly. If you're not sure about this, 
>> you can test your package specifically against 0.4.0 on Travis and/or 
>> locally.
>>
>> These are recommended upgrades for anyone using previous releases, and 
>> should act as drop-in replacements for their respective minor-version 
>> predecessors. If 0.3.12 introduces any regressions relative to any previous 
>> 0.3.x release, or if 0.4.1 introduces any regressions relative to 0.4.0, 
>> please let us know.
>>
>> -Tony
>>
>>

[julia-users] Re: Escher Spinner

[Brandon Miller]

That example was exactly what I needed.  I rewrote logic and implemented a 
busy signal as you recommended.  After much reading on Reactive.jl I have a 
working spinner using the same technique as you used for enabling/disabling 
the button in mc.jl.  Thank's for the help (and for contributing Escher to 
OS).

On Sunday, November 8, 2015 at 1:51:02 PM UTC-5, Shashi Gowda wrote:
>
>
>
> On Saturday, November 7, 2015 at 4:21:09 AM UTC+5:30, Brandon Miller wrote:
>>
>> Code snippet: https://gist.github.com/r2dbg/14189258e9daee2cece6
>>
>> I'd like for the spinner on line 23 to spin while do_work() is running 
>> and stop after do_work returns.  However, I can't seem to find a good way 
>> to do this.  The form is blocking until all fields in plugsampler() are 
>> fulfilled.
>>
>
> Take a look at how the mc.jl example does something similar: 
> https://github.com/shashi/Escher.jl/blob/master/examples/mc.jl#L24-L35
>
> I think a better abstraction is possible for this though. A way to make a 
> busy-signal for another signal?
>

[julia-users] Re: Google releases TensorFlow as open source

[Phil Tomson]

Looks like they used SWIG to create the Python bindings.  I don't see Julia 
listed as an output target for SWIG.



On Monday, November 9, 2015 at 1:02:36 PM UTC-8, Phil Tomson wrote:
>
> Google has released it's deep learning library called TensorFlow as open 
> source code:
>
> https://github.com/tensorflow/tensorflow
>
> They include Python bindings, Any ideas about how easy/difficult it would 
> be to create Julia bindings?
>
> Phil
>

Re: [julia-users] Do I have simd?

[DNF]

On Monday, November 9, 2015 at 10:14:24 PM UTC+1, DNF wrote:
>
> Thanks a lot. That indeed works.
>

Oh, and by "that", I mean installing the Julia 0.4.1 app. 

Re: [julia-users] Do I have simd?

[Rob J. Goedman]

Great! 

I just removed all of /usr/local/Cellar, did a full 'brew install julia’, but 
it still fails.

Will file an issue.

Regards,
Rob

> On Nov 9, 2015, at 1:15 PM, DNF  wrote:
> 
> On Monday, November 9, 2015 at 10:14:24 PM UTC+1, DNF wrote:
> Thanks a lot. That indeed works.
> 
> Oh, and by "that", I mean installing the Julia 0.4.1 app. 


On Nov 9, 2015, at 12:56 PM, Rob J. Goedman  wrote:

Hi DNF,

Those instructions (if they help in all cases) only work if you build Julia 
yourself by cloning the Julia git repository. You have installed julia via 
homebrew.
Unfortunately that route doesn’t work for me:

```
rob$ /usr/local/bin/julia
Illegal instruction: 4
```

I expect that maybe this problem is due to older stuff left behind somewhere 
(/usr/local/Cellar?).

Just now I installed Julia 0.4.1 from julialang.org/downloads 
 and then moved the Julia-0.4.1.app to 
/Applications (after double clicking the Julia disk). That gave me simd without 
any problems. Maybe you could try that route?

Regards,
Rob

Re: [julia-users] Do I have simd?

[DNF]

Thanks a lot. That indeed works. The speedup is not particularly large, and 
varies quite a bit, from 1.5 to 3 times speedup. But it *is* working, and 
code_llvm reports a vector block.

Though performance isn't all that impressive, at least I know there is 
nothing fundamentally stopping the SIMD optimizations from happening.


On Monday, November 9, 2015 at 9:57:12 PM UTC+1, Rob J Goedman wrote:
>
> Just now I installed Julia 0.4.1 from julialang.org/downloads and then 
> moved the Julia-0.4.1.app to /Applications (after double clicking the Julia 
> disk). That gave me simd without any problems. Maybe you could try that 
> route?
>

[julia-users] libgit2 and proxies

[Tony Kelman]

Your colleague also hit this https://github.com/JuliaLang/julia/issues/13472

It should be possible to work around by commenting out a restrictive pkg-config 
path setting in one of the makefiles and rebuilding libgit2 with libcurl 
support. We could remove the setting if many people are hitting this, but it 
was added to fix a libgit2 build problem caused by pkg-config picking up too 
many incompatible libraries on mac.

[julia-users] Re: Distribute a Julia application without exposing the cose

[Lee Bates]

>
> Hi Palli,
>

I have taken your advice and started looking at using Escher and a server 
(and possibly a virtual machine if the user requires the computations are 
done locally).

As for compiling the code; I have managed to compile a julia script that 
solves an LP using JuMP and Cbc (I hadn't switched from "using" to "import" 
for including the packages). However the executable requires a lot of dlls 
some of which are linked through a fixed location (eg. 
C:\...\WinRPM\deps\usr\x86_64-w64-mingw32\sys-root\mingw\bin\libCbcSolver-3.dll).
 
This makes distributing the executable difficult using the current build 
script.

Thanks for the advice.
Lee

[julia-users] Re: libgit2 and proxies

[Kiran Pamnany]

Thanks Tony!

Re: [julia-users] Using Meshes.ji

[Steve Kelly]

The faces can be accessed with faces(load("foo.obj")) or mesh.faces.

Probably the easiest way to display the mesh at this point is with
ThreeJS.jl:
https://github.com/rohitvarkey/ThreeJS.jl/blob/master/examples/mesh.jl.
This approach should work in IJulia and Blink.

GLVisualize has some good demos and a much more responsive backend, but it
needs some work to run in OpenGL < 3.3 and the working commits aren't on
Metadata yet. Meshes is kind of a weird state right now, and most of the
functionality can be had with GeometryTypes, Meshing, and MeshIO. We have
been working the past few months to finish the coupling between data
structures for geometry and visualization. It would be great to hear your
application, and see if we could achieve something in the short term that
would work for you. Personally I use Meshlab when I do solid modelling in
Julia which slows down my iteration time, and it would be nice to have a
mesh viewer in the workflow.

Best,
Steve
On Nov 9, 2015 9:55 AM, "Ashley Kleinhans" 
wrote:

> Hi,
>
> I am new at this - but have decided that Julia is my language of choice.
> So I begin silly question stage:
>
> Could someone talk me through how to access and display an .obj file?
>
> I have gotten so far:
>
> using Meshes
> using PyPlot
> using FileIO
> using MeshIO
>
> obj = load(filename)
> vts = obj.vertices
>
>
> Which gives me:
>
> 502-element Array{FixedSizeArrays.Point{3,Float32},1}:
>
>
>
> One example point being:
>
> Point(0.00117,-0.02631,0.03907)
>
>
>
>
>
> How do I access the verticies to use them with plot?
>
> -A
>
>
>

Re: [julia-users] Array comprehension cannot detect type?

[rizalzaf]

It does work.

Thank you so much Glen.

Rizal

On Mon, Nov 9, 2015 at 10:53 AM, Glen O  wrote:

> Does the assertion form work any better?
>
> K=[dot(X[:,i],X[:,j])::Float64 for i=1:5, j=1:5]
>
>
>
> On Tuesday, 10 November 2015 02:51:35 UTC+10, rizal zaini wrote:
>>
>> When I put that code inside a function, I got the same behavior.
>>
>> For single process, K = Float64[dot(X[:,i], X[:,j]) for i=1:5, j=1:5] does
>> the job.
>> But for parallel I got error: "ERROR: malformed @parallel loop"
>>
>> Rizal
>>
>> On Mon, Nov 9, 2015 at 10:48 AM, Kristoffer Carlsson 
>> wrote:
>>
>>> Don't run the code in global scope or alternatively be explicit about
>>> the type you want, for example Float64[]
>>>
>>> On Monday, November 9, 2015 at 5:42:15 PM UTC+1, rizal zaini wrote:

 My concern is also on parallel code:

 julia> K = @parallel [dot(X[:,i], X[:,j]) for i=1:5, j=1:5] 5x5
 DArray{Any,2,Array{Any,2}}: 1.35134 1.36439 1.28474 1.13181 1.07863 1.36439
 1.40077 1.25708 1.22365 1.08332 1.28474 1.25708 1.54494 0.95311 1.15779
 1.13181 1.22365 0.95311 1.70348 1.30076 1.07863 1.08332 1.15779 1.30076
 1.34577

 I expect to get  a DArray{Float64,2,Array{Float64,2}} rather than
 DArray{Any,2,Array{Any,2}}

 Please help.

 Rizal

 On Mon, Nov 9, 2015 at 9:11 AM, rizal zaini  wrote:

> Hi all
>
> I want to create matrix containing dot products
>
> julia> X = rand(5,5)
> 5x5 Array{Float64,2}:
>  0.274799   0.564619  0.915595  0.341059  0.57361
>  0.0806822  0.293939  0.379279  0.608582  0.652441
>  0.264678   0.532751  0.289088  0.457759  0.492777
>  0.338560.495587  0.499099  0.548237  0.402534
>  0.686305   0.168385  0.83220.605532  0.518693
>
> julia>  K = [dot(X[:,i], X[:,j]) for i=1:5, j=1:5]
> 5x5 Array{Any,2}:
>  0.737716  0.603229  1.09884  0.865174  0.832958
>  0.603229  0.962978  1.16994  0.988988  1.06501
>  1.09884   1.16994   2.00739  1.45298   1.54767
>  0.865174  0.988988  1.45298  1.36347   1.35304
>  0.832958  1.06501   1.54767  1.35304   1.42861
>
> I expect to get an Array{Float64,2}, but what I got is Array{Any,2}.
> How to get Array{Float64,2} using Array comprehension?
>
> Thanks before
> Rizal
>


>>

[julia-users] Re: DataFrame to JSON

[JobJob]

It doesn't pretty print, but is there anything wrong with this:

using JSON
json([[string(col)=> df[col][row] for col in names(df)] for row in 
1:nrow(df)])

Just to break it down, this part creates the dictionary for each row:
 
[string(col)=> df[col][row] for col in names(df)]

and it's repeated over each row to create the array of Dicts.

and of course json() converts the array of dicts to valid json (which is 
not that hard to get wrong when done by hand).

On Monday, 9 November 2015 06:11:17 UTC+2, Eric Forgy wrote:
>
> Hi,
>
> I need to serialize a DataFrame to JSON. I have read this:
>
>- https://github.com/JuliaStats/DataFrames.jl/issues/184
>
> but my case is a little different.
>
> If my DataFrame looks like this:
>
> julia> df
> 8x2 DataFrames.DataFrame
> | Row | A | B   |
> |-|---|-|
> | 1   | 1 | "M" |
> | 2   | 2 | "F" |
> | 3   | 3 | "F" |
> | 4   | 4 | "M" |
> | 5   | 5 | "F" |
> | 6   | 6 | "M" |
> | 7   | 7 | "M" |
> | 8   | 8 | "F" |
>
>
> Then I need my JSON to look like this (in order to talk to another API):
>
> [
>
> {"A": 1, "B": "M"},
>
> {"A": 2, "B": "F"}, 
>
> {"A": 3, "B": "F"},
>
> {"A": 4, "B": "M"},
>
> {"A": 5, "B": "F"},
>
> {"A": 6, "B": "M"},
>
> {"A": 7, "B": "M"},
>
> {"A": 8, "B": "F"},
>
> ]
>
>
> In Matlab, I would create an array of "structs". In Julia, I'm thinking I 
> would need to dynamically create a type
>
> immutable row
> A::Int
> B::AbstractString
> end
>
>  
> based on the names in the DataFrame, which should be generic and not 
> confined to two. Then I would construct an array of "row"s and finally 
> using JSON.jl, serialize via JSON.json.
>
> Is there a better/easier way to do this?
>
> Thank you.
>

[julia-users] PyPlot won't close first figure drawn

[lewis]

Not getting any answers to a weird problem.

PyPlot won't close the first figure it creates.  Subsequent figures can be 
created and closed.  gcf will not return a valid id for the first figure 
drawn.  plt[:get_fignums]() won't return a value for the first figure 
(e.g.--the first figure is not included in the returned vector of figures). 
 The only way to close the orphaned figure is to exit Julia.  Further if 
you click on the figure window and try to manually close it you will get an 
infinite spinning beach ball.  You can, however, switch back to Julia repl, 
which is happily running just fine.

This is part of a script that draws figures with interactive on and clears 
them with a user prompt. It is sort of annoying that the first one can 
never be closed.  The same symptom can be observed using Julia 
interactively:

using PyPlot
plot(1:5)  # -> figure draws fine in a tk window
close() # -> nothing happens
scatter(rand(25),rand(25)) # -> draws just fine
close() #-> closes the scatter as you'd expect and only the first figure 
remains
close() # -> nothing happens

You can explicitly create the first figure with figure() or figure(1) and 
the same problem occurs.

Environment:
os x 10.11.1 ("el capitan")
python 2.7.10 from www.python.org
matplotlib 1.5.0 and dependencies (via pip)
numpy 1.10.1 (via pip)
Julia 0.4.0
latest PyCall & PyPlot (with backend :tk)
xquartz 2.7.8 (latest per "upgrade..." on about box)
tk 8.5.18 (latest from ActiveState)

This does not occur when conda installs its own Python--same version, 
except built by Continuum, with equivalent versions of all Python packages 
 I don't consider just using conda an appropriate solution, as that seems 
to be avoiding finding an answer.  As of 2 weeks ago there was no problem 
so something (not clear what) changed in the mean time.  There is a path to 
this Python as: /Library/Frameworks/Python.framework/Versions/2.7/bin which 
is the first directory in PATH. (Note: this is NOT the system python which 
is at /system/library/...).  Also, I can't switch to Winston or Gadfly as I 
need surface plots and contour plots--PyPlot to matplotlib is the only way 
to create these from Julia that I am aware of.

When installing PyCall and PyPlot the comment output identifies this 
version of Python.

I am trying to sort out the figure logic in PyPlot.jl but it is hard for me 
to figure (no pun intended) it out.

Of course, I'll provide any and all additional information about my 
configuration, etc and can try other things to help diagnose this weird 
thing.

Thanks,
Lewis

[julia-users] Re: no one knows this.....

[lewis]

Thanks!

On Thursday, October 29, 2015 at 8:22:32 PM UTC-7, Steven G. Johnson wrote:
>
> A direct translation of the Python code works fine for me (with the 
> default TkAgg backend on MacOS):
>
> one = figure(1)
> plot(1:4)
> two = figure(2)
> scatter(randn(25),randn(25))
> figure(1)
> title("Title")
>
> wm = get_current_fig_manager()
> wm[:window][:attributes]("-topmost", 1)
> wm[:window][:attributes]("-topmost", 0)
>
>
> Everyone using PyPlot and PyCall should read this sentence from the PyCall 
> README five times:
>
> The biggest diffence from Python is that object attributes/members are 
> accessed with o[:attribute] rather than o.attribute
>
>

Re: [julia-users] Arrays as streams / consuming data with take et al

[andrew cooke]

hmmm.  maybe i'm doing it wrong as that only gives a factor of 2 speedup.

anyway, it's all i need for now, i may return to this later.

thanks again,
andrew

On Monday, 9 November 2015 14:11:55 UTC-3, andrew cooke wrote:
>
>
> yes, i'm about to do it for arrays (i don't care about performance right 
> now, but i want to implement read with type conversion and so need the 
> types).
>
> On Monday, 9 November 2015 11:20:47 UTC-3, Yichao Yu wrote:
>>
>> On Mon, Nov 9, 2015 at 8:04 AM, andrew cooke  wrote: 
>> > 
>> > https://github.com/andrewcooke/StatefulIterators.jl 
>>
>> FYI, one way to make this more efficient is to parametrize the 
>> iterator. You could easily do this for Array's. In the more general 
>> case, you needs type inference to get the type right for a 
>> non-type-stable iterator (iterator with a type unstable index...) but 
>> it's generally a bad idea to write code that calls type inference 
>> directly. 
>>
>> > 
>> > 
>> > On Monday, 9 November 2015 06:24:14 UTC-3, andrew cooke wrote: 
>> >> 
>> >> thanks! 
>> >> 
>> >> On Sunday, 8 November 2015 22:40:53 UTC-3, Yichao Yu wrote: 
>> >>> 
>> >>> On Sun, Nov 8, 2015 at 8:11 PM, andrew cooke  
>> wrote: 
>> >>> > I'd like to be able to use take() and all the other iterator tools 
>> with 
>> >>> > a 
>> >>> > stream of data backed by an array (or string). 
>> >>> > 
>> >>> > By that I mean I'd like to be able to do something like: 
>> >>> > 
>> >>> >> stream = XXX([1,2,3,4,5]) 
>> >>> >> collect(take(stream, 3)) 
>> >>> > [1,2,3] 
>> >>> >> collect(take(stream, 2)) 
>> >>> > [4,5] 
>> >>> > 
>> >>> > Is this possible?  I can find heavyweight looking streams for IO, 
>> and I 
>> >>> > can 
>> >>> > find lightweight iterables without state.  But I can't seem to find 
>> the 
>> >>> > particular mix described above. 
>> >>> 
>> >>> Jeff's conclusion @ JuliaCon is that it seems impossible to implement 
>> >>> this (stateful iterator) currently in a generic and performant way so 
>> >>> I doubt you will find it in a generic iterator library (that works 
>> not 
>> >>> only on arrays). A version that works only on Arrays should be simple 
>> >>> enough to implement and doesn't sound useful enough to be in an 
>> >>> exported API so I guess you probably should just implement your own. 
>> >>> 
>> >>> Ref 
>> >>> 
>> https://groups.google.com/forum/?fromgroups=#!searchin/julia-users/iterator/julia-users/t4ZieI2_iwI/3NTw1k406qkJ
>>  
>> >>> 
>> >>> > 
>> >>> > (I think I can see how to write it myself; I'm asking if it already 
>> >>> > exists - 
>> >>> > seems like it should, but I can't find the right words to search 
>> for). 
>> >>> > 
>> >>> > Thanks, 
>> >>> > Andrew 
>> >>> > 
>>
>

[julia-users] Re: PyPlot won't close first figure drawn

[Ethan Anderes]

I have noticed something similar. 

For example, if I do:

julia> using PyPlot

julia> figure(1)

julia> plot(sin(1:10))

julia> figure(2)

julia> plot(cos(1:10))

then close the first figure (by clicking the red button with my mouse) I 
get a spinning beach ball. I’m on OSX 10.11.1 using Anaconda python. PyPlot 
is at version "PyPlot"=>v"2.1.1+" and my system info is

julia> versioninfo()
Julia Version 0.4.1-pre+16
Commit 2cdef5d (2015-10-24 06:33 UTC)
Platform Info:
  System: Darwin (x86_64-apple-darwin15.0.0)
  CPU: Intel(R) Core(TM) i7-4850HQ CPU @ 2.30GHz
  WORD_SIZE: 64
  BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Haswell)
  LAPACK: libopenblas64_
  LIBM: libopenlibm
  LLVM: libLLVM-3.3


​

[julia-users] Re: Type stability with eigs

[David Gleich]

Thanks. I'll do that. Might try hacking a bit to see if I can work around 
it by directly calling ARPACK too.

David

On Monday, November 9, 2015 at 3:28:11 AM UTC-5, Tomas Lycken wrote:
>
> This actually seems to be a type instability issue in Base.eigs:
>
> julia> @code_warntype eigs(A)
> Variables:
>   A::SparseMatrixCSC{Float64,Int64}
>
> Body:
>   begin
>   $(Expr(:line, 50, symbol("linalg/arnoldi.jl"), symbol("")))
>   GenSym(8) = 
> (top(ccall))(:jl_alloc_array_1d,(top(apply_type))(Base.Array,Any,1)::Type{Array{Any,1}},(top(svec))(Base.Any,Base.Int)::SimpleVector,Array{Any,1},0,0,0)::Array{Any,1}
>   GenSym(9) = GenSym(8)
>   return 
> (Base.LinAlg.__eigs#221__)(GenSym(9),A::SparseMatrixCSC{Float64,Int64})::Tuple
>   end::Tuple
>
> julia> @code_warntype eigs(Symmetric(A))
> Variables:
>   A::Symmetric{Float64,SparseMatrixCSC{Float64,Int64}}
>
> Body:
>   begin
>   $(Expr(:line, 50, symbol("linalg/arnoldi.jl"), symbol("")))
>   GenSym(8) = 
> (top(ccall))(:jl_alloc_array_1d,(top(apply_type))(Base.Array,Any,1)::Type{Array{Any,1}},(top(svec))(Base.Any,Base.Int)::SimpleVector,Array{Any,1},0,0,0)::Array{Any,1}
>   GenSym(9) = GenSym(8)
>   return 
> (Base.LinAlg.__eigs#221__)(GenSym(9),A::Symmetric{Float64,SparseMatrixCSC{Float64,Int64}})::Tuple
>   end::Tuple
>
> I can’t find anything on the issue tracker about it, so it might be a good 
> idea to file a new issue .
>
> // t
>
> On Saturday, November 7, 2015 at 5:25:30 PM UTC+1, David Gleich wrote:
>
> I'm trying to get a type-stable output from a symmetric sparse eigenvalue 
>> problem.
>>
>> Any ideas why neither of these ideas work to give me a deterministic 
>> return of Array{Float64,1} ?
>>
>> n = 500; A = sparse(1:n-1,2:n,1.,n,n); A = A + A'
>> @show issym(A)
>> function myeig1(A::SparseMatrixCSC{Float64,Int64})
>>d,V = eigs(A;tol=1e-4)
>>return d
>> end
>>
>> function myeig2(A::SparseMatrixCSC{Float64,Int64})
>>d,V = eigs(Symmetric(A);tol=1e-4)
>>return d
>> end
>>
>> @code_warntype myeig1(A)
>> @code_warntype myeig2(A)
>>
>> Thanks,
>> David Gleich
>>
> ​
>

[julia-users] Array comprehension cannot detect type?

[rizal zaini]

Hi all

I want to create matrix containing dot products

julia> X = rand(5,5)
5x5 Array{Float64,2}:
 0.274799   0.564619  0.915595  0.341059  0.57361
 0.0806822  0.293939  0.379279  0.608582  0.652441
 0.264678   0.532751  0.289088  0.457759  0.492777
 0.338560.495587  0.499099  0.548237  0.402534
 0.686305   0.168385  0.83220.605532  0.518693

julia>  K = [dot(X[:,i], X[:,j]) for i=1:5, j=1:5]
5x5 Array{Any,2}:
 0.737716  0.603229  1.09884  0.865174  0.832958
 0.603229  0.962978  1.16994  0.988988  1.06501
 1.09884   1.16994   2.00739  1.45298   1.54767
 0.865174  0.988988  1.45298  1.36347   1.35304
 0.832958  1.06501   1.54767  1.35304   1.42861

I expect to get an Array{Float64,2}, but what I got is Array{Any,2}. 
How to get Array{Float64,2} using Array comprehension?

Thanks before
Rizal

Re: [julia-users] Array comprehension cannot detect type?

[Kristoffer Carlsson]

Don't run the code in global scope or alternatively be explicit about the 
type you want, for example Float64[]

On Monday, November 9, 2015 at 5:42:15 PM UTC+1, rizal zaini wrote:
>
> My concern is also on parallel code: 
>
> julia> K = @parallel [dot(X[:,i], X[:,j]) for i=1:5, j=1:5] 5x5 
> DArray{Any,2,Array{Any,2}}: 1.35134 1.36439 1.28474 1.13181 1.07863 1.36439 
> 1.40077 1.25708 1.22365 1.08332 1.28474 1.25708 1.54494 0.95311 1.15779 
> 1.13181 1.22365 0.95311 1.70348 1.30076 1.07863 1.08332 1.15779 1.30076 
> 1.34577
>
> I expect to get  a DArray{Float64,2,Array{Float64,2}} rather than 
> DArray{Any,2,Array{Any,2}}
>
> Please help. 
>
> Rizal
>
> On Mon, Nov 9, 2015 at 9:11 AM, rizal zaini  > wrote:
>
>> Hi all
>>
>> I want to create matrix containing dot products
>>
>> julia> X = rand(5,5)
>> 5x5 Array{Float64,2}:
>>  0.274799   0.564619  0.915595  0.341059  0.57361
>>  0.0806822  0.293939  0.379279  0.608582  0.652441
>>  0.264678   0.532751  0.289088  0.457759  0.492777
>>  0.338560.495587  0.499099  0.548237  0.402534
>>  0.686305   0.168385  0.83220.605532  0.518693
>>
>> julia>  K = [dot(X[:,i], X[:,j]) for i=1:5, j=1:5]
>> 5x5 Array{Any,2}:
>>  0.737716  0.603229  1.09884  0.865174  0.832958
>>  0.603229  0.962978  1.16994  0.988988  1.06501
>>  1.09884   1.16994   2.00739  1.45298   1.54767
>>  0.865174  0.988988  1.45298  1.36347   1.35304
>>  0.832958  1.06501   1.54767  1.35304   1.42861
>>
>> I expect to get an Array{Float64,2}, but what I got is Array{Any,2}. 
>> How to get Array{Float64,2} using Array comprehension?
>>
>> Thanks before
>> Rizal
>>
>
>

Re: [julia-users] Re: CUDART and CURAND problem on running the same "do" loop twice

[Joaquim Masset Lacombe Dias Garcia]

if I load:

using CUDArt
using CURAND

and then I run either:

d_a = curand(Float64, 1000);
a = to_host(d_a);

OR:

result = devices(dev->capability(dev)[1]>=2) do devlist
end

I can repeat the block as many time I want.

However if I run both combined (or alternatedly in any order):
d_a = curand(Float64, 1000);
a = to_host(d_a);
result = devices(dev->capability(dev)[1]>=2) do devlist
end

I get the error:


WARNING: CUDA error triggered from:

LoadError: "unspecified launch failure"
while loading In[3], in expression starting on line 2

 in checkerror at 
C:\Users\joaquimgarcia\.julia\v0.4\CUDArt\src\libcudart-6.5.jl:16


 in checkerror at 
C:\Users\joaquimgarcia\.julia\v0.4\CUDArt\src\libcudart-6.5.jl:15
 in copy! at C:\Users\joaquimgarcia\.julia\v0.4\CUDArt\src\arrays.jl:152
 in to_host at C:\Users\joaquimgarcia\.julia\v0.4\CUDArt\src\arrays.jl:87
 in include_string at loading.jl:266
 in execute_request_0x535c5df2 at 
C:\Users\joaquimgarcia\.julia\v0.4\IJulia\src\execute_request.jl:177
 in eventloop at C:\Users\joaquimgarcia\.julia\v0.4\IJulia\src\IJulia.jl:141
 in anonymous at task.jl:447




I will file this as an issue in CURAND

Re: [julia-users] Array comprehension cannot detect type?

[John Gibson]

I'm no Julia expert, but I'm pretty certain this fall under the category 
"If you Julia to optimize, put your code in a function."

 gibson@timaeus$ ~/packages/julia-0.4.0/bin/julia
   _
   _   _ _(_)_ |  A fresh approach to technical computing
  (_) | (_) (_)|  Documentation: http://docs.julialang.org
   _ _   _| |_  __ _   |  Type "?help" for help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 0.4.0 (2015-10-08 06:20 UTC)
 _/ |\__'_|_|_|\__'_|  |  Official http://julialang.org/ release
|__/   |  x86_64-unknown-linux-gnu

julia> X = rand(2,2)
2x2 Array{Float64,2}:
 0.713809  0.0650767
 0.916874  0.111741 

julia> K = [dot(X[:,i], X[:,j]) for i=1:2, j=1:2]
2x2 Array{Any,2}:
 1.35018   0.148905 
 0.148905  0.0167211

julia> f(X) = [dot(X[:,i], X[:,j]) for i=1:2, j=1:2]
f (generic function with 1 method)

julia> f(X)
2x2 Array{Float64,2}:
 1.35018   0.148905 
 0.148905  0.0167211

John



On Monday, November 9, 2015 at 11:42:15 AM UTC-5, rizal zaini wrote:
>
> My concern is also on parallel code: 
>
> julia> K = @parallel [dot(X[:,i], X[:,j]) for i=1:5, j=1:5] 5x5 
> DArray{Any,2,Array{Any,2}}: 1.35134 1.36439 1.28474 1.13181 1.07863 1.36439 
> 1.40077 1.25708 1.22365 1.08332 1.28474 1.25708 1.54494 0.95311 1.15779 
> 1.13181 1.22365 0.95311 1.70348 1.30076 1.07863 1.08332 1.15779 1.30076 
> 1.34577
>
> I expect to get  a DArray{Float64,2,Array{Float64,2}} rather than 
> DArray{Any,2,Array{Any,2}}
>
> Please help. 
>
> Rizal
>
> On Mon, Nov 9, 2015 at 9:11 AM, rizal zaini  > wrote:
>
>> Hi all
>>
>> I want to create matrix containing dot products
>>
>> julia> X = rand(5,5)
>> 5x5 Array{Float64,2}:
>>  0.274799   0.564619  0.915595  0.341059  0.57361
>>  0.0806822  0.293939  0.379279  0.608582  0.652441
>>  0.264678   0.532751  0.289088  0.457759  0.492777
>>  0.338560.495587  0.499099  0.548237  0.402534
>>  0.686305   0.168385  0.83220.605532  0.518693
>>
>> julia>  K = [dot(X[:,i], X[:,j]) for i=1:5, j=1:5]
>> 5x5 Array{Any,2}:
>>  0.737716  0.603229  1.09884  0.865174  0.832958
>>  0.603229  0.962978  1.16994  0.988988  1.06501
>>  1.09884   1.16994   2.00739  1.45298   1.54767
>>  0.865174  0.988988  1.45298  1.36347   1.35304
>>  0.832958  1.06501   1.54767  1.35304   1.42861
>>
>> I expect to get an Array{Float64,2}, but what I got is Array{Any,2}. 
>> How to get Array{Float64,2} using Array comprehension?
>>
>> Thanks before
>> Rizal
>>
>
>

Re: [julia-users] Arrays as streams / consuming data with take et al

[andrew cooke]

yes, i'm about to do it for arrays (i don't care about performance right 
now, but i want to implement read with type conversion and so need the 
types).

On Monday, 9 November 2015 11:20:47 UTC-3, Yichao Yu wrote:
>
> On Mon, Nov 9, 2015 at 8:04 AM, andrew cooke  > wrote: 
> > 
> > https://github.com/andrewcooke/StatefulIterators.jl 
>
> FYI, one way to make this more efficient is to parametrize the 
> iterator. You could easily do this for Array's. In the more general 
> case, you needs type inference to get the type right for a 
> non-type-stable iterator (iterator with a type unstable index...) but 
> it's generally a bad idea to write code that calls type inference 
> directly. 
>
> > 
> > 
> > On Monday, 9 November 2015 06:24:14 UTC-3, andrew cooke wrote: 
> >> 
> >> thanks! 
> >> 
> >> On Sunday, 8 November 2015 22:40:53 UTC-3, Yichao Yu wrote: 
> >>> 
> >>> On Sun, Nov 8, 2015 at 8:11 PM, andrew cooke  
> wrote: 
> >>> > I'd like to be able to use take() and all the other iterator tools 
> with 
> >>> > a 
> >>> > stream of data backed by an array (or string). 
> >>> > 
> >>> > By that I mean I'd like to be able to do something like: 
> >>> > 
> >>> >> stream = XXX([1,2,3,4,5]) 
> >>> >> collect(take(stream, 3)) 
> >>> > [1,2,3] 
> >>> >> collect(take(stream, 2)) 
> >>> > [4,5] 
> >>> > 
> >>> > Is this possible?  I can find heavyweight looking streams for IO, 
> and I 
> >>> > can 
> >>> > find lightweight iterables without state.  But I can't seem to find 
> the 
> >>> > particular mix described above. 
> >>> 
> >>> Jeff's conclusion @ JuliaCon is that it seems impossible to implement 
> >>> this (stateful iterator) currently in a generic and performant way so 
> >>> I doubt you will find it in a generic iterator library (that works not 
> >>> only on arrays). A version that works only on Arrays should be simple 
> >>> enough to implement and doesn't sound useful enough to be in an 
> >>> exported API so I guess you probably should just implement your own. 
> >>> 
> >>> Ref 
> >>> 
> https://groups.google.com/forum/?fromgroups=#!searchin/julia-users/iterator/julia-users/t4ZieI2_iwI/3NTw1k406qkJ
>  
> >>> 
> >>> > 
> >>> > (I think I can see how to write it myself; I'm asking if it already 
> >>> > exists - 
> >>> > seems like it should, but I can't find the right words to search 
> for). 
> >>> > 
> >>> > Thanks, 
> >>> > Andrew 
> >>> > 
>

[julia-users] Re: Array comprehension cannot detect type?

[Glen O]

As far as I'm aware, there are two nice ways to tell the comprehension the 
type that is going to be returned.

Option 1: Tell it the type of the comprehension:

K = Float64[dot(X[:,i], X[:,j]) for i=1:5, j=1:5]


Option 2: Assert the type of the return of "dot"

K = [dot(X[:,i],X[:,j])::Float64 for i=1:5, j=1:5]

As far as I can tell, they'll do the same thing.

On Tuesday, 10 November 2015 02:37:17 UTC+10, rizal zaini wrote:
>
> Hi all
>
> I want to create matrix containing dot products
>
> julia> X = rand(5,5)
> 5x5 Array{Float64,2}:
>  0.274799   0.564619  0.915595  0.341059  0.57361
>  0.0806822  0.293939  0.379279  0.608582  0.652441
>  0.264678   0.532751  0.289088  0.457759  0.492777
>  0.338560.495587  0.499099  0.548237  0.402534
>  0.686305   0.168385  0.83220.605532  0.518693
>
> julia>  K = [dot(X[:,i], X[:,j]) for i=1:5, j=1:5]
> 5x5 Array{Any,2}:
>  0.737716  0.603229  1.09884  0.865174  0.832958
>  0.603229  0.962978  1.16994  0.988988  1.06501
>  1.09884   1.16994   2.00739  1.45298   1.54767
>  0.865174  0.988988  1.45298  1.36347   1.35304
>  0.832958  1.06501   1.54767  1.35304   1.42861
>
> I expect to get an Array{Float64,2}, but what I got is Array{Any,2}. 
> How to get Array{Float64,2} using Array comprehension?
>
> Thanks before
> Rizal
>

Re: [julia-users] Array comprehension cannot detect type?

[rizalzaf]

When I put that code inside a function, I got the same behavior.

For single process, K = Float64[dot(X[:,i], X[:,j]) for i=1:5, j=1:5] does
the job.
But for parallel I got error: "ERROR: malformed @parallel loop"

Rizal

On Mon, Nov 9, 2015 at 10:48 AM, Kristoffer Carlsson 
wrote:

> Don't run the code in global scope or alternatively be explicit about the
> type you want, for example Float64[]
>
> On Monday, November 9, 2015 at 5:42:15 PM UTC+1, rizal zaini wrote:
>>
>> My concern is also on parallel code:
>>
>> julia> K = @parallel [dot(X[:,i], X[:,j]) for i=1:5, j=1:5] 5x5
>> DArray{Any,2,Array{Any,2}}: 1.35134 1.36439 1.28474 1.13181 1.07863 1.36439
>> 1.40077 1.25708 1.22365 1.08332 1.28474 1.25708 1.54494 0.95311 1.15779
>> 1.13181 1.22365 0.95311 1.70348 1.30076 1.07863 1.08332 1.15779 1.30076
>> 1.34577
>>
>> I expect to get  a DArray{Float64,2,Array{Float64,2}} rather than
>> DArray{Any,2,Array{Any,2}}
>>
>> Please help.
>>
>> Rizal
>>
>> On Mon, Nov 9, 2015 at 9:11 AM, rizal zaini  wrote:
>>
>>> Hi all
>>>
>>> I want to create matrix containing dot products
>>>
>>> julia> X = rand(5,5)
>>> 5x5 Array{Float64,2}:
>>>  0.274799   0.564619  0.915595  0.341059  0.57361
>>>  0.0806822  0.293939  0.379279  0.608582  0.652441
>>>  0.264678   0.532751  0.289088  0.457759  0.492777
>>>  0.338560.495587  0.499099  0.548237  0.402534
>>>  0.686305   0.168385  0.83220.605532  0.518693
>>>
>>> julia>  K = [dot(X[:,i], X[:,j]) for i=1:5, j=1:5]
>>> 5x5 Array{Any,2}:
>>>  0.737716  0.603229  1.09884  0.865174  0.832958
>>>  0.603229  0.962978  1.16994  0.988988  1.06501
>>>  1.09884   1.16994   2.00739  1.45298   1.54767
>>>  0.865174  0.988988  1.45298  1.36347   1.35304
>>>  0.832958  1.06501   1.54767  1.35304   1.42861
>>>
>>> I expect to get an Array{Float64,2}, but what I got is Array{Any,2}.
>>> How to get Array{Float64,2} using Array comprehension?
>>>
>>> Thanks before
>>> Rizal
>>>
>>
>>

Re: [julia-users] Array comprehension cannot detect type?

[Glen O]

Does the assertion form work any better?

K=[dot(X[:,i],X[:,j])::Float64 for i=1:5, j=1:5]



On Tuesday, 10 November 2015 02:51:35 UTC+10, rizal zaini wrote:
>
> When I put that code inside a function, I got the same behavior.
>
> For single process, K = Float64[dot(X[:,i], X[:,j]) for i=1:5, j=1:5] does 
> the job.
> But for parallel I got error: "ERROR: malformed @parallel loop"
>
> Rizal
>
> On Mon, Nov 9, 2015 at 10:48 AM, Kristoffer Carlsson  > wrote:
>
>> Don't run the code in global scope or alternatively be explicit about the 
>> type you want, for example Float64[]
>>
>> On Monday, November 9, 2015 at 5:42:15 PM UTC+1, rizal zaini wrote:
>>>
>>> My concern is also on parallel code: 
>>>
>>> julia> K = @parallel [dot(X[:,i], X[:,j]) for i=1:5, j=1:5] 5x5 
>>> DArray{Any,2,Array{Any,2}}: 1.35134 1.36439 1.28474 1.13181 1.07863 1.36439 
>>> 1.40077 1.25708 1.22365 1.08332 1.28474 1.25708 1.54494 0.95311 1.15779 
>>> 1.13181 1.22365 0.95311 1.70348 1.30076 1.07863 1.08332 1.15779 1.30076 
>>> 1.34577
>>>
>>> I expect to get  a DArray{Float64,2,Array{Float64,2}} rather than 
>>> DArray{Any,2,Array{Any,2}}
>>>
>>> Please help. 
>>>
>>> Rizal
>>>
>>> On Mon, Nov 9, 2015 at 9:11 AM, rizal zaini  wrote:
>>>
 Hi all

 I want to create matrix containing dot products

 julia> X = rand(5,5)
 5x5 Array{Float64,2}:
  0.274799   0.564619  0.915595  0.341059  0.57361
  0.0806822  0.293939  0.379279  0.608582  0.652441
  0.264678   0.532751  0.289088  0.457759  0.492777
  0.338560.495587  0.499099  0.548237  0.402534
  0.686305   0.168385  0.83220.605532  0.518693

 julia>  K = [dot(X[:,i], X[:,j]) for i=1:5, j=1:5]
 5x5 Array{Any,2}:
  0.737716  0.603229  1.09884  0.865174  0.832958
  0.603229  0.962978  1.16994  0.988988  1.06501
  1.09884   1.16994   2.00739  1.45298   1.54767
  0.865174  0.988988  1.45298  1.36347   1.35304
  0.832958  1.06501   1.54767  1.35304   1.42861

 I expect to get an Array{Float64,2}, but what I got is Array{Any,2}. 
 How to get Array{Float64,2} using Array comprehension?

 Thanks before
 Rizal

>>>
>>>
>

Re: [julia-users] Arrays as streams / consuming data with take et al

[Dan]

XXX in your questions = chain.
Or more clearly:
julia> stream = chain([1,2,3,4,5])
Iterators.Chain(Any[[1,2,3,4,5]])

julia> collect(take(stream, 3))
3-element Array{Any,1}:
 1
 2
 3


On Monday, November 9, 2015 at 7:47:51 PM UTC+2, andrew cooke wrote:
>
>
> hmmm.  maybe i'm doing it wrong as that only gives a factor of 2 speedup.
>
> anyway, it's all i need for now, i may return to this later.
>
> thanks again,
> andrew
>
> On Monday, 9 November 2015 14:11:55 UTC-3, andrew cooke wrote:
>>
>>
>> yes, i'm about to do it for arrays (i don't care about performance right 
>> now, but i want to implement read with type conversion and so need the 
>> types).
>>
>> On Monday, 9 November 2015 11:20:47 UTC-3, Yichao Yu wrote:
>>>
>>> On Mon, Nov 9, 2015 at 8:04 AM, andrew cooke  wrote: 
>>> > 
>>> > https://github.com/andrewcooke/StatefulIterators.jl 
>>>
>>> FYI, one way to make this more efficient is to parametrize the 
>>> iterator. You could easily do this for Array's. In the more general 
>>> case, you needs type inference to get the type right for a 
>>> non-type-stable iterator (iterator with a type unstable index...) but 
>>> it's generally a bad idea to write code that calls type inference 
>>> directly. 
>>>
>>> > 
>>> > 
>>> > On Monday, 9 November 2015 06:24:14 UTC-3, andrew cooke wrote: 
>>> >> 
>>> >> thanks! 
>>> >> 
>>> >> On Sunday, 8 November 2015 22:40:53 UTC-3, Yichao Yu wrote: 
>>> >>> 
>>> >>> On Sun, Nov 8, 2015 at 8:11 PM, andrew cooke  
>>> wrote: 
>>> >>> > I'd like to be able to use take() and all the other iterator tools 
>>> with 
>>> >>> > a 
>>> >>> > stream of data backed by an array (or string). 
>>> >>> > 
>>> >>> > By that I mean I'd like to be able to do something like: 
>>> >>> > 
>>> >>> >> stream = XXX([1,2,3,4,5]) 
>>> >>> >> collect(take(stream, 3)) 
>>> >>> > [1,2,3] 
>>> >>> >> collect(take(stream, 2)) 
>>> >>> > [4,5] 
>>> >>> > 
>>> >>> > Is this possible?  I can find heavyweight looking streams for IO, 
>>> and I 
>>> >>> > can 
>>> >>> > find lightweight iterables without state.  But I can't seem to 
>>> find the 
>>> >>> > particular mix described above. 
>>> >>> 
>>> >>> Jeff's conclusion @ JuliaCon is that it seems impossible to 
>>> implement 
>>> >>> this (stateful iterator) currently in a generic and performant way 
>>> so 
>>> >>> I doubt you will find it in a generic iterator library (that works 
>>> not 
>>> >>> only on arrays). A version that works only on Arrays should be 
>>> simple 
>>> >>> enough to implement and doesn't sound useful enough to be in an 
>>> >>> exported API so I guess you probably should just implement your own. 
>>> >>> 
>>> >>> Ref 
>>> >>> 
>>> https://groups.google.com/forum/?fromgroups=#!searchin/julia-users/iterator/julia-users/t4ZieI2_iwI/3NTw1k406qkJ
>>>  
>>> >>> 
>>> >>> > 
>>> >>> > (I think I can see how to write it myself; I'm asking if it 
>>> already 
>>> >>> > exists - 
>>> >>> > seems like it should, but I can't find the right words to search 
>>> for). 
>>> >>> > 
>>> >>> > Thanks, 
>>> >>> > Andrew 
>>> >>> > 
>>>
>>

[julia-users] Re: ANN: Julia 0.4.1 and 0.3.12 released

[bernhard]

Out of curiosity: why is this release 54mb (up from 40mb for 0.4). I am 
referring to the file size of the Win 64bit binaries here.

Am Montag, 9. November 2015 20:37:48 UTC+1 schrieb Tony Kelman:
>
> Hello all! The latest bugfix releases of both 0.4.x and 0.3.x Julia lines 
> have been released. Binaries are available from the usual place 
>  (see Old releases 
>  for 0.3.12), and as is 
> typical with such things, please report all issues to either the issue 
> tracker , or email the 
> julia-users list. (If you respond to this message on julia-users, please do 
> not cc julia-news which is intended to be low-volume.)
>
> These are bugfix releases. 0.3.12 is likely to be the last release in the 
> 0.3.x line unless any critical bugs or regressions are identified. To see 
> the list of bugs fixed since 0.3.11, see this commit log 
> . Bugfix 
> backports to the 0.4.x line will be continuing with a target of one point 
> release per month. See this commit log 
>  for the list 
> of bugs fixed between 0.4.0 and 0.4.1. If you are a package author and want 
> to rely on functionality that did not work in 0.4.0 but does work in 0.4.1 
> in your package, please be sure to change the minimum julia version in your 
> REQUIRE file to 0.4.1 accordingly. If you're not sure about this, you can 
> test your package specifically against 0.4.0 on Travis and/or locally.
>
> These are recommended upgrades for anyone using previous releases, and 
> should act as drop-in replacements for their respective minor-version 
> predecessors. If 0.3.12 introduces any regressions relative to any previous 
> 0.3.x release, or if 0.4.1 introduces any regressions relative to 0.4.0, 
> please let us know.
>
> -Tony
>
>

Re: [julia-users] Arrays as streams / consuming data with take et al

[Dan]

the example with `pull` before, traverses the iterator's beginning twice... 
what one probably wants is:

julia> function pull(itr,n::Int)
   state = start(itr)
   head = eltype(itr)[]
   while n>0 && !done(itr,state)
   val,state = next(itr,state)
   push!(head,val)
   n-=1
   end
   (head,rest(itr,state))
   end
pull (generic function with 2 methods)


julia> head,tail = pull([1,2,3,4,5],3)
([1,2,3],Base.Rest{Array{Int64,1},Int64}([1,2,3,4,5],4))


julia> collect(tail)
2-element Array{Any,1}:
 4
 5


note the first call already pulls the first 3 elements and collects them 
into an array (one can't get to the next elements without first reading the 
head.

On Monday, November 9, 2015 at 10:39:48 PM UTC+2, andrew cooke wrote:
>
>
> oh that's interesting.  this is from 
> https://github.com/JuliaLang/Iterators.jl i guess.
>
> it doesn't support read though (which i didn't realise i needed when i 
> first asked).
>
> i'll add a warning to StatefulIterators pointing people to this.
>
> thanks,
> andrew
>
> On Monday, 9 November 2015 17:07:52 UTC-3, Dan wrote:
>>
>> XXX in your questions = chain.
>> Or more clearly:
>> julia> stream = chain([1,2,3,4,5])
>> Iterators.Chain(Any[[1,2,3,4,5]])
>>
>> julia> collect(take(stream, 3))
>> 3-element Array{Any,1}:
>>  1
>>  2
>>  3
>>
>>
>> On Monday, November 9, 2015 at 7:47:51 PM UTC+2, andrew cooke wrote:
>>>
>>>
>>> hmmm.  maybe i'm doing it wrong as that only gives a factor of 2 speedup.
>>>
>>> anyway, it's all i need for now, i may return to this later.
>>>
>>> thanks again,
>>> andrew
>>>
>>> On Monday, 9 November 2015 14:11:55 UTC-3, andrew cooke wrote:


 yes, i'm about to do it for arrays (i don't care about performance 
 right now, but i want to implement read with type conversion and so need 
 the types).

 On Monday, 9 November 2015 11:20:47 UTC-3, Yichao Yu wrote:
>
> On Mon, Nov 9, 2015 at 8:04 AM, andrew cooke  
> wrote: 
> > 
> > https://github.com/andrewcooke/StatefulIterators.jl 
>
> FYI, one way to make this more efficient is to parametrize the 
> iterator. You could easily do this for Array's. In the more general 
> case, you needs type inference to get the type right for a 
> non-type-stable iterator (iterator with a type unstable index...) but 
> it's generally a bad idea to write code that calls type inference 
> directly. 
>
> > 
> > 
> > On Monday, 9 November 2015 06:24:14 UTC-3, andrew cooke wrote: 
> >> 
> >> thanks! 
> >> 
> >> On Sunday, 8 November 2015 22:40:53 UTC-3, Yichao Yu wrote: 
> >>> 
> >>> On Sun, Nov 8, 2015 at 8:11 PM, andrew cooke  
> wrote: 
> >>> > I'd like to be able to use take() and all the other iterator 
> tools with 
> >>> > a 
> >>> > stream of data backed by an array (or string). 
> >>> > 
> >>> > By that I mean I'd like to be able to do something like: 
> >>> > 
> >>> >> stream = XXX([1,2,3,4,5]) 
> >>> >> collect(take(stream, 3)) 
> >>> > [1,2,3] 
> >>> >> collect(take(stream, 2)) 
> >>> > [4,5] 
> >>> > 
> >>> > Is this possible?  I can find heavyweight looking streams for 
> IO, and I 
> >>> > can 
> >>> > find lightweight iterables without state.  But I can't seem to 
> find the 
> >>> > particular mix described above. 
> >>> 
> >>> Jeff's conclusion @ JuliaCon is that it seems impossible to 
> implement 
> >>> this (stateful iterator) currently in a generic and performant way 
> so 
> >>> I doubt you will find it in a generic iterator library (that works 
> not 
> >>> only on arrays). A version that works only on Arrays should be 
> simple 
> >>> enough to implement and doesn't sound useful enough to be in an 
> >>> exported API so I guess you probably should just implement your 
> own. 
> >>> 
> >>> Ref 
> >>> 
> https://groups.google.com/forum/?fromgroups=#!searchin/julia-users/iterator/julia-users/t4ZieI2_iwI/3NTw1k406qkJ
>  
> >>> 
> >>> > 
> >>> > (I think I can see how to write it myself; I'm asking if it 
> already 
> >>> > exists - 
> >>> > seems like it should, but I can't find the right words to search 
> for). 
> >>> > 
> >>> > Thanks, 
> >>> > Andrew 
> >>> > 
>

Re: [julia-users] Arrays as streams / consuming data with take et al

[Dan]

Hmmm... maybe there is an issue with the following:
  | | |_| | | | (_| |  |  Version 0.5.0-dev+1137 (2015-11-04 03:36 UTC)
 _/ |\__'_|_|_|\__'_|  |  Commit 95b7080 (5 days old master)
|__/   |  x86_64-linux-gnu


julia> collect(1:3)
3-element Array{Int64,1}:
 1
 2
 3


julia> collect(rest(1:3,start(1:3)))
3-element Array{Any,1}:
 1
 2
 3


Shouldn't the type of both arrays be the same? (the latter defined in 
non-global context still yield Any Array).

On Monday, November 9, 2015 at 10:45:12 PM UTC+2, Dan wrote:
>
> the example with `pull` before, traverses the iterator's beginning 
> twice... what one probably wants is:
>
> julia> function pull(itr,n::Int)
>state = start(itr)
>head = eltype(itr)[]
>while n>0 && !done(itr,state)
>val,state = next(itr,state)
>push!(head,val)
>n-=1
>end
>(head,rest(itr,state))
>end
> pull (generic function with 2 methods)
>
>
> julia> head,tail = pull([1,2,3,4,5],3)
> ([1,2,3],Base.Rest{Array{Int64,1},Int64}([1,2,3,4,5],4))
>
>
> julia> collect(tail)
> 2-element Array{Any,1}:
>  4
>  5
>
>
> note the first call already pulls the first 3 elements and collects them 
> into an array (one can't get to the next elements without first reading the 
> head.
>
> On Monday, November 9, 2015 at 10:39:48 PM UTC+2, andrew cooke wrote:
>>
>>
>> oh that's interesting.  this is from 
>> https://github.com/JuliaLang/Iterators.jl i guess.
>>
>> it doesn't support read though (which i didn't realise i needed when i 
>> first asked).
>>
>> i'll add a warning to StatefulIterators pointing people to this.
>>
>> thanks,
>> andrew
>>
>> On Monday, 9 November 2015 17:07:52 UTC-3, Dan wrote:
>>>
>>> XXX in your questions = chain.
>>> Or more clearly:
>>> julia> stream = chain([1,2,3,4,5])
>>> Iterators.Chain(Any[[1,2,3,4,5]])
>>>
>>> julia> collect(take(stream, 3))
>>> 3-element Array{Any,1}:
>>>  1
>>>  2
>>>  3
>>>
>>>
>>> On Monday, November 9, 2015 at 7:47:51 PM UTC+2, andrew cooke wrote:


 hmmm.  maybe i'm doing it wrong as that only gives a factor of 2 
 speedup.

 anyway, it's all i need for now, i may return to this later.

 thanks again,
 andrew

 On Monday, 9 November 2015 14:11:55 UTC-3, andrew cooke wrote:
>
>
> yes, i'm about to do it for arrays (i don't care about performance 
> right now, but i want to implement read with type conversion and so need 
> the types).
>
> On Monday, 9 November 2015 11:20:47 UTC-3, Yichao Yu wrote:
>>
>> On Mon, Nov 9, 2015 at 8:04 AM, andrew cooke  
>> wrote: 
>> > 
>> > https://github.com/andrewcooke/StatefulIterators.jl 
>>
>> FYI, one way to make this more efficient is to parametrize the 
>> iterator. You could easily do this for Array's. In the more general 
>> case, you needs type inference to get the type right for a 
>> non-type-stable iterator (iterator with a type unstable index...) but 
>> it's generally a bad idea to write code that calls type inference 
>> directly. 
>>
>> > 
>> > 
>> > On Monday, 9 November 2015 06:24:14 UTC-3, andrew cooke wrote: 
>> >> 
>> >> thanks! 
>> >> 
>> >> On Sunday, 8 November 2015 22:40:53 UTC-3, Yichao Yu wrote: 
>> >>> 
>> >>> On Sun, Nov 8, 2015 at 8:11 PM, andrew cooke  
>> wrote: 
>> >>> > I'd like to be able to use take() and all the other iterator 
>> tools with 
>> >>> > a 
>> >>> > stream of data backed by an array (or string). 
>> >>> > 
>> >>> > By that I mean I'd like to be able to do something like: 
>> >>> > 
>> >>> >> stream = XXX([1,2,3,4,5]) 
>> >>> >> collect(take(stream, 3)) 
>> >>> > [1,2,3] 
>> >>> >> collect(take(stream, 2)) 
>> >>> > [4,5] 
>> >>> > 
>> >>> > Is this possible?  I can find heavyweight looking streams for 
>> IO, and I 
>> >>> > can 
>> >>> > find lightweight iterables without state.  But I can't seem to 
>> find the 
>> >>> > particular mix described above. 
>> >>> 
>> >>> Jeff's conclusion @ JuliaCon is that it seems impossible to 
>> implement 
>> >>> this (stateful iterator) currently in a generic and performant 
>> way so 
>> >>> I doubt you will find it in a generic iterator library (that 
>> works not 
>> >>> only on arrays). A version that works only on Arrays should be 
>> simple 
>> >>> enough to implement and doesn't sound useful enough to be in an 
>> >>> exported API so I guess you probably should just implement your 
>> own. 
>> >>> 
>> >>> Ref 
>> >>> 
>> https://groups.google.com/forum/?fromgroups=#!searchin/julia-users/iterator/julia-users/t4ZieI2_iwI/3NTw1k406qkJ
>>  
>> >>> 
>> >>> > 
>> >>> > (I think I can see how to write it myself; I'm asking if it 
>> already 
>> >>> > exists - 
>> >>> > 

Re: [julia-users] Arrays as streams / consuming data with take et al

[Dan]

ouch... my suggestion takes care of the first output, but the second output 
repeats the start of the sequence. but `chain` is a useful method to 
convert an array to an iterable. anyway, I've concocted a method to 
generate the desired behavior:

julia> function pull(itr,n)
   state = start(itr)
   for i=1:n state = next(itr,state)[2] ; end
   (take(itr,n),rest(itr,state))
   end
pull (generic function with 1 method)


julia> stream = 1:5
1:5


julia> head, tail = pull(stream,3)
(Base.Take{UnitRange{Int64}}(1:5,3),Base.Rest{UnitRange{Int64},Int64}(1:5,4
))


julia> collect(head)
3-element Array{Int64,1}:
 1
 2
 3


julia> collect(tail)
2-element Array{Any,1}:
 4
 5

the idea is to use the defined `pull` function to generate the head and 
tail iterators. this must be so, since the state of the iterators after the 
first few elements must be remembered somewhere.

On Monday, November 9, 2015 at 10:07:52 PM UTC+2, Dan wrote:
>
> XXX in your questions = chain.
> Or more clearly:
> julia> stream = chain([1,2,3,4,5])
> Iterators.Chain(Any[[1,2,3,4,5]])
>
> julia> collect(take(stream, 3))
> 3-element Array{Any,1}:
>  1
>  2
>  3
>
>
> On Monday, November 9, 2015 at 7:47:51 PM UTC+2, andrew cooke wrote:
>>
>>
>> hmmm.  maybe i'm doing it wrong as that only gives a factor of 2 speedup.
>>
>> anyway, it's all i need for now, i may return to this later.
>>
>> thanks again,
>> andrew
>>
>> On Monday, 9 November 2015 14:11:55 UTC-3, andrew cooke wrote:
>>>
>>>
>>> yes, i'm about to do it for arrays (i don't care about performance right 
>>> now, but i want to implement read with type conversion and so need the 
>>> types).
>>>
>>> On Monday, 9 November 2015 11:20:47 UTC-3, Yichao Yu wrote:

 On Mon, Nov 9, 2015 at 8:04 AM, andrew cooke  
 wrote: 
 > 
 > https://github.com/andrewcooke/StatefulIterators.jl 

 FYI, one way to make this more efficient is to parametrize the 
 iterator. You could easily do this for Array's. In the more general 
 case, you needs type inference to get the type right for a 
 non-type-stable iterator (iterator with a type unstable index...) but 
 it's generally a bad idea to write code that calls type inference 
 directly. 

 > 
 > 
 > On Monday, 9 November 2015 06:24:14 UTC-3, andrew cooke wrote: 
 >> 
 >> thanks! 
 >> 
 >> On Sunday, 8 November 2015 22:40:53 UTC-3, Yichao Yu wrote: 
 >>> 
 >>> On Sun, Nov 8, 2015 at 8:11 PM, andrew cooke  
 wrote: 
 >>> > I'd like to be able to use take() and all the other iterator 
 tools with 
 >>> > a 
 >>> > stream of data backed by an array (or string). 
 >>> > 
 >>> > By that I mean I'd like to be able to do something like: 
 >>> > 
 >>> >> stream = XXX([1,2,3,4,5]) 
 >>> >> collect(take(stream, 3)) 
 >>> > [1,2,3] 
 >>> >> collect(take(stream, 2)) 
 >>> > [4,5] 
 >>> > 
 >>> > Is this possible?  I can find heavyweight looking streams for IO, 
 and I 
 >>> > can 
 >>> > find lightweight iterables without state.  But I can't seem to 
 find the 
 >>> > particular mix described above. 
 >>> 
 >>> Jeff's conclusion @ JuliaCon is that it seems impossible to 
 implement 
 >>> this (stateful iterator) currently in a generic and performant way 
 so 
 >>> I doubt you will find it in a generic iterator library (that works 
 not 
 >>> only on arrays). A version that works only on Arrays should be 
 simple 
 >>> enough to implement and doesn't sound useful enough to be in an 
 >>> exported API so I guess you probably should just implement your 
 own. 
 >>> 
 >>> Ref 
 >>> 
 https://groups.google.com/forum/?fromgroups=#!searchin/julia-users/iterator/julia-users/t4ZieI2_iwI/3NTw1k406qkJ
  
 >>> 
 >>> > 
 >>> > (I think I can see how to write it myself; I'm asking if it 
 already 
 >>> > exists - 
 >>> > seems like it should, but I can't find the right words to search 
 for). 
 >>> > 
 >>> > Thanks, 
 >>> > Andrew 
 >>> > 

>>>

Re: [julia-users] Arrays as streams / consuming data with take et al

[andrew cooke]

oh, ok :o(

On Monday, 9 November 2015 17:36:13 UTC-3, Dan wrote:
>
> ouch... my suggestion takes care of the first output, but the second 
> output repeats the start of the sequence. but `chain` is a useful method to 
> convert an array to an iterable. anyway, I've concocted a method to 
> generate the desired behavior:
>
> julia> function pull(itr,n)
>state = start(itr)
>for i=1:n state = next(itr,state)[2] ; end
>(take(itr,n),rest(itr,state))
>end
> pull (generic function with 1 method)
>
>
> julia> stream = 1:5
> 1:5
>
>
> julia> head, tail = pull(stream,3)
> (Base.Take{UnitRange{Int64}}(1:5,3),Base.Rest{UnitRange{Int64},Int64}(1:5,
> 4))
>
>
> julia> collect(head)
> 3-element Array{Int64,1}:
>  1
>  2
>  3
>
>
> julia> collect(tail)
> 2-element Array{Any,1}:
>  4
>  5
>
> the idea is to use the defined `pull` function to generate the head and 
> tail iterators. this must be so, since the state of the iterators after the 
> first few elements must be remembered somewhere.
>
> On Monday, November 9, 2015 at 10:07:52 PM UTC+2, Dan wrote:
>>
>> XXX in your questions = chain.
>> Or more clearly:
>> julia> stream = chain([1,2,3,4,5])
>> Iterators.Chain(Any[[1,2,3,4,5]])
>>
>> julia> collect(take(stream, 3))
>> 3-element Array{Any,1}:
>>  1
>>  2
>>  3
>>
>>
>> On Monday, November 9, 2015 at 7:47:51 PM UTC+2, andrew cooke wrote:
>>>
>>>
>>> hmmm.  maybe i'm doing it wrong as that only gives a factor of 2 speedup.
>>>
>>> anyway, it's all i need for now, i may return to this later.
>>>
>>> thanks again,
>>> andrew
>>>
>>> On Monday, 9 November 2015 14:11:55 UTC-3, andrew cooke wrote:


 yes, i'm about to do it for arrays (i don't care about performance 
 right now, but i want to implement read with type conversion and so need 
 the types).

 On Monday, 9 November 2015 11:20:47 UTC-3, Yichao Yu wrote:
>
> On Mon, Nov 9, 2015 at 8:04 AM, andrew cooke  
> wrote: 
> > 
> > https://github.com/andrewcooke/StatefulIterators.jl 
>
> FYI, one way to make this more efficient is to parametrize the 
> iterator. You could easily do this for Array's. In the more general 
> case, you needs type inference to get the type right for a 
> non-type-stable iterator (iterator with a type unstable index...) but 
> it's generally a bad idea to write code that calls type inference 
> directly. 
>
> > 
> > 
> > On Monday, 9 November 2015 06:24:14 UTC-3, andrew cooke wrote: 
> >> 
> >> thanks! 
> >> 
> >> On Sunday, 8 November 2015 22:40:53 UTC-3, Yichao Yu wrote: 
> >>> 
> >>> On Sun, Nov 8, 2015 at 8:11 PM, andrew cooke  
> wrote: 
> >>> > I'd like to be able to use take() and all the other iterator 
> tools with 
> >>> > a 
> >>> > stream of data backed by an array (or string). 
> >>> > 
> >>> > By that I mean I'd like to be able to do something like: 
> >>> > 
> >>> >> stream = XXX([1,2,3,4,5]) 
> >>> >> collect(take(stream, 3)) 
> >>> > [1,2,3] 
> >>> >> collect(take(stream, 2)) 
> >>> > [4,5] 
> >>> > 
> >>> > Is this possible?  I can find heavyweight looking streams for 
> IO, and I 
> >>> > can 
> >>> > find lightweight iterables without state.  But I can't seem to 
> find the 
> >>> > particular mix described above. 
> >>> 
> >>> Jeff's conclusion @ JuliaCon is that it seems impossible to 
> implement 
> >>> this (stateful iterator) currently in a generic and performant way 
> so 
> >>> I doubt you will find it in a generic iterator library (that works 
> not 
> >>> only on arrays). A version that works only on Arrays should be 
> simple 
> >>> enough to implement and doesn't sound useful enough to be in an 
> >>> exported API so I guess you probably should just implement your 
> own. 
> >>> 
> >>> Ref 
> >>> 
> https://groups.google.com/forum/?fromgroups=#!searchin/julia-users/iterator/julia-users/t4ZieI2_iwI/3NTw1k406qkJ
>  
> >>> 
> >>> > 
> >>> > (I think I can see how to write it myself; I'm asking if it 
> already 
> >>> > exists - 
> >>> > seems like it should, but I can't find the right words to search 
> for). 
> >>> > 
> >>> > Thanks, 
> >>> > Andrew 
> >>> > 
>

Re: [julia-users] Do I have simd?

[Rob J. Goedman]

Hi DNF,

Those instructions (if they help in all cases) only work if you build Julia 
yourself by cloning the Julia git repository. You have installed julia via 
homebrew.
Unfortunately that route doesn’t work for me:

```
rob$ /usr/local/bin/julia
Illegal instruction: 4
```

I expect that maybe this problem is due to older stuff left behind somewhere 
(/usr/local/Cellar?).

Just now I installed Julia 0.4.1 from julialang.org/downloads and then moved 
the Julia-0.4.1.app to /Applications (after double clicking the Julia disk). 
That gave me simd without any problems. Maybe you could try that route?

Regards,
Rob

———

On Nov 9, 2015, at 11:47 AM, DNF  wrote:

Thank you very much for taking the time to look into this, Rob.

My understanding now is that this is something that has to do with the build 
process of Julia, or perhaps with what version of openblas is being used. Am I 
getting that correctly? Do you think this something I could address to the 
maintainer of homebrew-julia?

I see that you are running some 'make' commands. Is 'make' something I run 
after git pulling directly from the main julia git repository, or does it 
somehow work with homebrew as well?


> On Nov 8, 2015, at 2:51 PM, Rob J. Goedman  wrote:
> 
> On another, slightly older system, I noticed similar (approximately 
> identical) timings for the simd.jl test script using Julia 0.5:
> 
> julia> include("/Users/rob/Projects/Julia/Rob/Julia/simd.jl")
> 
> Julia Version 0.5.0-dev+720
> Commit 5920633* (2015-10-11 15:15 UTC)
> Platform Info:
>   System: Darwin (x86_64-apple-darwin15.0.0)
>   CPU: Intel(R) Core(TM) i7-3720QM CPU @ 2.60GHz
>   WORD_SIZE: 64
>   BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Sandybridge)
>   LAPACK: libopenblas64_
>   LIBM: libopenlibm
>   LLVM: libLLVM-3.3
> 
> First call to timeit(1000,1000):
> 
> GFlop= 0.6092165323090373
> GFlop (SIMD) = 0.4607065672339039
> 
> Second call to timeit(1000,1000):
> 
> GFlop= 0.5935117884795207
> GFlop (SIMD) = 0.42286883095163036
> 
> On that same system Julia 0.4 (installed from the Julia site) did show 
> improved Gflop numbers and about a 6x improvement with simd.
> 
> To see if that would help with Julia 0.5, I did (in the cloned julia 
> directory, in a terminal):
> 
> git pull https://github.com/JuliaLang/julia 
>  master
> make -j 4
> 
> Lots of compile messages/warnings, but in the end:
> 
> clang: error: linker command failed with exit code 1 (use -v to see 
> invocation)
> make[3]: *** [libopenblas64_p-r0.2.15.dylib] Error 1
> make[2]: *** [shared] Error 2
> *** Clean the OpenBLAS build with 'make -C deps clean-openblas'. Rebuild with 
> 'make OPENBLAS_USE_THREAD=0 if OpenBLAS had trouble linking libpthread.so, 
> and with 'make OPENBLAS_TARGET_ARCH=NEHALEM' if there were errors building 
> SandyBridge support. Both these options can also be used simultaneously. ***
> make[1]: *** [build/openblas/libopenblas64_.dylib] Error 1
> make: *** [julia-deps] Error 2
> 
> I tried:
> 
> brew update
> brew upgrade
> make -C deps clean-openblas
> make -j 4
> 
> and running the simd.jl script now shows:
> 
> julia> include("/Users/rob/Projects/Julia/Rob/Julia/simd.jl")
> 
> Julia Version 0.5.0-dev+1195
> Commit 68667a3* (2015-11-08 21:05 UTC)
> Platform Info:
>   System: Darwin (x86_64-apple-darwin15.0.0)
>   CPU: Intel(R) Core(TM) i7-3720QM CPU @ 2.60GHz
>   WORD_SIZE: 64
>   BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Sandybridge)
>   LAPACK: libopenblas64_
>   LIBM: libopenlibm
>   LLVM: libLLVM-3.3
> 
> First call to timeit(1000,1000):
> 
> GFlop= 1.4006308441321973
> GFlop (SIMD) = 13.561988458747821
> 
> Second call to timeit(1000,1000):
> 
> GFlop= 2.300048186009497
> GFlop (SIMD) = 12.8439991844
> 
> 
> Not sure if this helps or is even the right way to remedy this.
> 
> Regards,
> Rob
> 
> 
> 
> 
> 
> 
>> On Nov 6, 2015, at 5:35 PM, Rob J. Goedman > > wrote:
>> 
>> Thanks Seth,
>> 
>> That's the end of my first attempt to figure out what’s happening here. Back 
>> to the drawing board!
>> 
>> Regards,
>> Rob
>> 
>>> On Nov 6, 2015, at 4:53 PM, Seth >> > wrote:
>>> 
>>> Hi Rob,
>>> 
>>> I built it (and openblas) myself (via git clone) since I'm testing out 
>>> Cxx.jl. Xcode is Version 7.1 (7B91b).
>>> 
>>> Seth.
>>> 
>>> 
>>> On Friday, November 6, 2015 at 3:54:04 PM UTC-8, Rob J Goedman wrote:
>>> Seth,
>>> 
>>> You must have built  Julia 0.4.1-pre yourself. Did you use brew?
>>> 
>>> It looks like you are on Yosemite and picked up a newer libLLVM. Which 
>>> Xcode are you using?
>>> In the Julia.rb formula there is a test ENV.compiler, could it be clang is 
>>> not being used? 
>>> 
>>> Rob
>>> 
 On Nov 6, 2015, at 3:01 PM, Seth  
 wrote:

[julia-users] ANN: Julia 0.4.1 and 0.3.12 released

[Tony Kelman]

Hello all! The latest bugfix releases of both 0.4.x and 0.3.x Julia lines 
have been released. Binaries are available from the usual place 
 (see Old releases 
 for 0.3.12), and as is 
typical with such things, please report all issues to either the issue 
tracker , or email the 
julia-users list. (If you respond to this message on julia-users, please do 
not cc julia-news which is intended to be low-volume.)

These are bugfix releases. 0.3.12 is likely to be the last release in the 
0.3.x line unless any critical bugs or regressions are identified. To see 
the list of bugs fixed since 0.3.11, see this commit log 
. Bugfix 
backports to the 0.4.x line will be continuing with a target of one point 
release per month. See this commit log 
 for the list 
of bugs fixed between 0.4.0 and 0.4.1. If you are a package author and want 
to rely on functionality that did not work in 0.4.0 but does work in 0.4.1 
in your package, please be sure to change the minimum julia version in your 
REQUIRE file to 0.4.1 accordingly. If you're not sure about this, you can 
test your package specifically against 0.4.0 on Travis and/or locally.

These are recommended upgrades for anyone using previous releases, and 
should act as drop-in replacements for their respective minor-version 
predecessors. If 0.3.12 introduces any regressions relative to any previous 
0.3.x release, or if 0.4.1 introduces any regressions relative to 0.4.0, 
please let us know.

-Tony

[julia-users] libgit2 and proxies

[Kiran Pamnany]

Anyone seen this?

julia> Pkg.init()
INFO: Initializing package repository /home/kpamnany/.julia/v0.5
INFO: Cloning METADATA from https://github.com/JuliaLang/METADATA.jl
ERROR: GitError(Code:ERROR, Class:Net, SSL error: error:140E0114:SSL 
routines:SSL_shutdown:uninitialized)
 [inlined code] from ./libgit2/error.jl:98
 in clone at ./libgit2/repository.jl:189
 in clone at ./libgit2.jl:310
 in anonymous at ./pkg/dir.jl:49
 in cd at ./file.jl:22
 in init at ./pkg/dir.jl:47
 in init at ./pkg.jl:22
 in eval at ./boot.jl:264

I have proxies set up correctly; I can git clone 
https://github.com/JuliaLang/METADATA.jl from the command line just fine.

IIRC, this didn't happen before libgit2. Does it honor proxies?

Re: [julia-users] Re: The growth of Julia userbase

[Ken B]

Here's a nice comparison of languages used in github repo's and Julia is 
#43 out of 50:
http://githut.info/

On Thursday, 5 November 2015 02:50:43 UTC+1, Iain Dunning wrote:
>
> Some more data, from pkg.julialang.org web analytics: 
> In January there were 3.5k "users", which ramped up to 5k by March, and 
> then held there roughly before spiking up to nearly 6k in October - maybe 
> the 0.4 release?
>
> Theres also the number of packages themselves:
> 300 packages ~ April 2014
> 400 packages ~ October 2014
> 500 packages ~ February 2015
> 600 packages ~ June 2015
> 700 packages ~ October 2014
> It does look roughly superlinear to me.
>
>
> On Wednesday, November 4, 2015 at 4:35:18 PM UTC-5, Milan Bouchet-Valat 
> wrote:
>>
>> Le mercredi 04 novembre 2015 à 20:49 +, Ben Ward a écrit : 
>> > Could anyone who can see it tell me the current figures? Or see to 
>> > making this data public? It seems an odd thing to keep private - I 
>> > would presume growth figures were something to show off. 
>> Unfortunately, the graphs only cover about 10 days. There are a little 
>> more than 1,000 unique visitor each day, and about 10,000 since 10/22. 
>>
>> Some time ago, I posted the evolution of the number of Debian users who 
>> have enabled popcon and have Julia installed. The absolute value is not 
>> representative of anything, but the growth is exponential : 
>> https://qa.debian.org/popcon.php?package=julia 
>>
>> You can also look at the number of stars attributed by users to Julia 
>> packages : 
>> http://pkg.julialang.org/pulse 
>>
>>
>> Regards 
>>
>>
>> > On Wed, Nov 4, 2015 at 7:28 PM, Luthaf  wrote: 
>> > > These graphs are not available for people who are not (Github) 
>> > > collaborator for the julia repository. 
>> > > 
>> > > Tony Kelman a écrit : 
>> > > > There are some interesting numbers at 
>> > > > https://github.com/JuliaLang/julia/graphs/traffic 
>> > > > 
>> > > > Elliot Saba also did some scraping of the AWS download logs for 
>> > > > binaries and shared the aggregate numbers (broken down by 
>> > > > platform) privately with a few people, it may be worth sharing 
>> > > > those publicly. 
>> > > > 
>> > > > 
>> > > > On Wednesday, November 4, 2015 at 8:26:19 AM UTC-8, Ben Ward 
>> > > > wrote: 
>> > > > Hi all, 
>> > > > 
>> > > > I was wondering are there any metrics or stats available that 
>> > > > show how the user-base of Julia has grown over the last few 
>> > > > years, and what it's size is now? 
>> > > > 
>> > > > Many Thanks, 
>> > > > Ben W. 
>>
>

Re: [julia-users] Re: The growth of Julia userbase

[Cedric St-Jean]

https://groups.google.com/forum/#!aboutgroup/julia-users has one year of 
data.

On Monday, November 9, 2015 at 6:10:41 PM UTC-5, Ken B wrote:
>
> Here's a nice comparison of languages used in github repo's and Julia is 
> #43 out of 50:
> http://githut.info/
>
> On Thursday, 5 November 2015 02:50:43 UTC+1, Iain Dunning wrote:
>>
>> Some more data, from pkg.julialang.org web analytics: 
>> In January there were 3.5k "users", which ramped up to 5k by March, and 
>> then held there roughly before spiking up to nearly 6k in October - maybe 
>> the 0.4 release?
>>
>> Theres also the number of packages themselves:
>> 300 packages ~ April 2014
>> 400 packages ~ October 2014
>> 500 packages ~ February 2015
>> 600 packages ~ June 2015
>> 700 packages ~ October 2014
>> It does look roughly superlinear to me.
>>
>>
>> On Wednesday, November 4, 2015 at 4:35:18 PM UTC-5, Milan Bouchet-Valat 
>> wrote:
>>>
>>> Le mercredi 04 novembre 2015 à 20:49 +, Ben Ward a écrit : 
>>> > Could anyone who can see it tell me the current figures? Or see to 
>>> > making this data public? It seems an odd thing to keep private - I 
>>> > would presume growth figures were something to show off. 
>>> Unfortunately, the graphs only cover about 10 days. There are a little 
>>> more than 1,000 unique visitor each day, and about 10,000 since 10/22. 
>>>
>>> Some time ago, I posted the evolution of the number of Debian users who 
>>> have enabled popcon and have Julia installed. The absolute value is not 
>>> representative of anything, but the growth is exponential : 
>>> https://qa.debian.org/popcon.php?package=julia 
>>>
>>> You can also look at the number of stars attributed by users to Julia 
>>> packages : 
>>> http://pkg.julialang.org/pulse 
>>>
>>>
>>> Regards 
>>>
>>>
>>> > On Wed, Nov 4, 2015 at 7:28 PM, Luthaf  wrote: 
>>> > > These graphs are not available for people who are not (Github) 
>>> > > collaborator for the julia repository. 
>>> > > 
>>> > > Tony Kelman a écrit : 
>>> > > > There are some interesting numbers at 
>>> > > > https://github.com/JuliaLang/julia/graphs/traffic 
>>> > > > 
>>> > > > Elliot Saba also did some scraping of the AWS download logs for 
>>> > > > binaries and shared the aggregate numbers (broken down by 
>>> > > > platform) privately with a few people, it may be worth sharing 
>>> > > > those publicly. 
>>> > > > 
>>> > > > 
>>> > > > On Wednesday, November 4, 2015 at 8:26:19 AM UTC-8, Ben Ward 
>>> > > > wrote: 
>>> > > > Hi all, 
>>> > > > 
>>> > > > I was wondering are there any metrics or stats available that 
>>> > > > show how the user-base of Julia has grown over the last few 
>>> > > > years, and what it's size is now? 
>>> > > > 
>>> > > > Many Thanks, 
>>> > > > Ben W. 
>>>
>>

[julia-users] Re: DataFrame to JSON

[Eric Forgy]

Hi JobJob,

I like that too. Thanks!

When I got my df2json working, the next thing I naturally did was try 
JSON.parse(json) and saw I got back an array of Dicts, so thought 
constructing an array of Dicts from a DataFrame could also be a way to go, 
but couldn't get it to work. Your solution nicely solves that problem :)

It also gives a good clue how to go the other way. I'll also need to go 
from an array of Dicts (parsed from the above) to a DataFrame.

Thanks both. This is a good learning experience I'll share with my team.


On Tuesday, November 10, 2015 at 2:19:48 AM UTC+8, JobJob wrote:
>
> It doesn't pretty print, but is there anything wrong with this:
>
> using JSON
> json([[string(col)=> df[col][row] for col in names(df)] for row in 
> 1:nrow(df)])
>
> Just to break it down, this part creates the dictionary for each row:
>  
> [string(col)=> df[col][row] for col in names(df)]
>
> and it's repeated over each row to create the array of Dicts.
>
> and of course json() converts the array of dicts to valid json (which is 
> not that hard to get wrong when done by hand).
>
> On Monday, 9 November 2015 06:11:17 UTC+2, Eric Forgy wrote:
>>
>> Hi,
>>
>> I need to serialize a DataFrame to JSON. I have read this:
>>
>>- https://github.com/JuliaStats/DataFrames.jl/issues/184
>>
>> but my case is a little different.
>>
>> If my DataFrame looks like this:
>>
>> julia> df
>> 8x2 DataFrames.DataFrame
>> | Row | A | B   |
>> |-|---|-|
>> | 1   | 1 | "M" |
>> | 2   | 2 | "F" |
>> | 3   | 3 | "F" |
>> | 4   | 4 | "M" |
>> | 5   | 5 | "F" |
>> | 6   | 6 | "M" |
>> | 7   | 7 | "M" |
>> | 8   | 8 | "F" |
>>
>>
>> Then I need my JSON to look like this (in order to talk to another API):
>>
>> [
>>
>> {"A": 1, "B": "M"},
>>
>> {"A": 2, "B": "F"}, 
>>
>> {"A": 3, "B": "F"},
>>
>> {"A": 4, "B": "M"},
>>
>> {"A": 5, "B": "F"},
>>
>> {"A": 6, "B": "M"},
>>
>> {"A": 7, "B": "M"},
>>
>> {"A": 8, "B": "F"},
>>
>> ]
>>
>>
>> In Matlab, I would create an array of "structs". In Julia, I'm thinking I 
>> would need to dynamically create a type
>>
>> immutable row
>> A::Int
>> B::AbstractString
>> end
>>
>>  
>> based on the names in the DataFrame, which should be generic and not 
>> confined to two. Then I would construct an array of "row"s and finally 
>> using JSON.jl, serialize via JSON.json.
>>
>> Is there a better/easier way to do this?
>>
>> Thank you.
>>
>

[julia-users] Google releases TensorFlow as open source

[Phil Tomson]

Google has released it's deep learning library called TensorFlow as open 
source code:

https://github.com/tensorflow/tensorflow

They include Python bindings, Any ideas about how easy/difficult it would 
be to create Julia bindings?

Phil

Re: [julia-users] Arrays as streams / consuming data with take et al

[andrew cooke]

thanks!

On Sunday, 8 November 2015 22:40:53 UTC-3, Yichao Yu wrote:
>
> On Sun, Nov 8, 2015 at 8:11 PM, andrew cooke  > wrote: 
> > I'd like to be able to use take() and all the other iterator tools with 
> a 
> > stream of data backed by an array (or string). 
> > 
> > By that I mean I'd like to be able to do something like: 
> > 
> >> stream = XXX([1,2,3,4,5]) 
> >> collect(take(stream, 3)) 
> > [1,2,3] 
> >> collect(take(stream, 2)) 
> > [4,5] 
> > 
> > Is this possible?  I can find heavyweight looking streams for IO, and I 
> can 
> > find lightweight iterables without state.  But I can't seem to find the 
> > particular mix described above. 
>
> Jeff's conclusion @ JuliaCon is that it seems impossible to implement 
> this (stateful iterator) currently in a generic and performant way so 
> I doubt you will find it in a generic iterator library (that works not 
> only on arrays). A version that works only on Arrays should be simple 
> enough to implement and doesn't sound useful enough to be in an 
> exported API so I guess you probably should just implement your own. 
>
> Ref 
> https://groups.google.com/forum/?fromgroups=#!searchin/julia-users/iterator/julia-users/t4ZieI2_iwI/3NTw1k406qkJ
>  
>
> > 
> > (I think I can see how to write it myself; I'm asking if it already 
> exists - 
> > seems like it should, but I can't find the right words to search for). 
> > 
> > Thanks, 
> > Andrew 
> > 
>

Re: [julia-users] Arrays as streams / consuming data with take et al

[andrew cooke]

yeah, that's the problem with types and iters.

this is why i had to add read() to StatefulIterators.jl

it seems to me that the problem is related to the lack of a typed generic 
container type.  but i guess it must be more complex than that.

andrew


On Monday, 9 November 2015 17:58:39 UTC-3, Dan wrote:
>
> Hmmm... maybe there is an issue with the following:
>   | | |_| | | | (_| |  |  Version 0.5.0-dev+1137 (2015-11-04 03:36 UTC)
>  _/ |\__'_|_|_|\__'_|  |  Commit 95b7080 (5 days old master)
> |__/   |  x86_64-linux-gnu
>
>
> julia> collect(1:3)
> 3-element Array{Int64,1}:
>  1
>  2
>  3
>
>
> julia> collect(rest(1:3,start(1:3)))
> 3-element Array{Any,1}:
>  1
>  2
>  3
>
>
> Shouldn't the type of both arrays be the same? (the latter defined in 
> non-global context still yield Any Array).
>
> On Monday, November 9, 2015 at 10:45:12 PM UTC+2, Dan wrote:
>>
>> the example with `pull` before, traverses the iterator's beginning 
>> twice... what one probably wants is:
>>
>> julia> function pull(itr,n::Int)
>>state = start(itr)
>>head = eltype(itr)[]
>>while n>0 && !done(itr,state)
>>val,state = next(itr,state)
>>push!(head,val)
>>n-=1
>>end
>>(head,rest(itr,state))
>>end
>> pull (generic function with 2 methods)
>>
>>
>> julia> head,tail = pull([1,2,3,4,5],3)
>> ([1,2,3],Base.Rest{Array{Int64,1},Int64}([1,2,3,4,5],4))
>>
>>
>> julia> collect(tail)
>> 2-element Array{Any,1}:
>>  4
>>  5
>>
>>
>> note the first call already pulls the first 3 elements and collects them 
>> into an array (one can't get to the next elements without first reading the 
>> head.
>>
>> On Monday, November 9, 2015 at 10:39:48 PM UTC+2, andrew cooke wrote:
>>>
>>>
>>> oh that's interesting.  this is from 
>>> https://github.com/JuliaLang/Iterators.jl i guess.
>>>
>>> it doesn't support read though (which i didn't realise i needed when i 
>>> first asked).
>>>
>>> i'll add a warning to StatefulIterators pointing people to this.
>>>
>>> thanks,
>>> andrew
>>>
>>> On Monday, 9 November 2015 17:07:52 UTC-3, Dan wrote:

 XXX in your questions = chain.
 Or more clearly:
 julia> stream = chain([1,2,3,4,5])
 Iterators.Chain(Any[[1,2,3,4,5]])

 julia> collect(take(stream, 3))
 3-element Array{Any,1}:
  1
  2
  3


 On Monday, November 9, 2015 at 7:47:51 PM UTC+2, andrew cooke wrote:
>
>
> hmmm.  maybe i'm doing it wrong as that only gives a factor of 2 
> speedup.
>
> anyway, it's all i need for now, i may return to this later.
>
> thanks again,
> andrew
>
> On Monday, 9 November 2015 14:11:55 UTC-3, andrew cooke wrote:
>>
>>
>> yes, i'm about to do it for arrays (i don't care about performance 
>> right now, but i want to implement read with type conversion and so need 
>> the types).
>>
>> On Monday, 9 November 2015 11:20:47 UTC-3, Yichao Yu wrote:
>>>
>>> On Mon, Nov 9, 2015 at 8:04 AM, andrew cooke  
>>> wrote: 
>>> > 
>>> > https://github.com/andrewcooke/StatefulIterators.jl 
>>>
>>> FYI, one way to make this more efficient is to parametrize the 
>>> iterator. You could easily do this for Array's. In the more general 
>>> case, you needs type inference to get the type right for a 
>>> non-type-stable iterator (iterator with a type unstable index...) 
>>> but 
>>> it's generally a bad idea to write code that calls type inference 
>>> directly. 
>>>
>>> > 
>>> > 
>>> > On Monday, 9 November 2015 06:24:14 UTC-3, andrew cooke wrote: 
>>> >> 
>>> >> thanks! 
>>> >> 
>>> >> On Sunday, 8 November 2015 22:40:53 UTC-3, Yichao Yu wrote: 
>>> >>> 
>>> >>> On Sun, Nov 8, 2015 at 8:11 PM, andrew cooke  
>>> wrote: 
>>> >>> > I'd like to be able to use take() and all the other iterator 
>>> tools with 
>>> >>> > a 
>>> >>> > stream of data backed by an array (or string). 
>>> >>> > 
>>> >>> > By that I mean I'd like to be able to do something like: 
>>> >>> > 
>>> >>> >> stream = XXX([1,2,3,4,5]) 
>>> >>> >> collect(take(stream, 3)) 
>>> >>> > [1,2,3] 
>>> >>> >> collect(take(stream, 2)) 
>>> >>> > [4,5] 
>>> >>> > 
>>> >>> > Is this possible?  I can find heavyweight looking streams for 
>>> IO, and I 
>>> >>> > can 
>>> >>> > find lightweight iterables without state.  But I can't seem to 
>>> find the 
>>> >>> > particular mix described above. 
>>> >>> 
>>> >>> Jeff's conclusion @ JuliaCon is that it seems impossible to 
>>> implement 
>>> >>> this (stateful iterator) currently in a generic and performant 
>>> way so 
>>> >>> I doubt you will find it in a generic iterator library (that 
>>> works not 
>>> >>> only on arrays). A version that works only on Arrays should be 
>>> simple 

[julia-users] Re: DataFrame to JSON

[Eric Forgy]

That is truly beautiful! Thank you Tomas

On Monday, November 9, 2015 at 5:01:10 PM UTC+8, Tomas Lycken wrote:
>
> I’d try to use the built-in tools for iterating and transforming stuff to 
> make the code a little terser and easier to read:
>
> function df2json(df)
> io = IOBuffer()
> write(io, "[\n")
> write(io, join(map(row -> "{\"A\": $(row[:A]), \"B\": \"$(row[:B])\"}", 
> eachrow(d)), ",\n"))
> write(io, "\n]\n")
> json = takebuf_string(io)
> close(io)
> json
> end
>
> The keys here is to use the map and eachrow functions to get rid of the 
> for loops, and to build each item with string interpolation, which makes it 
> easier to see what the result will be.
> Note that I end the entire message with a newline; I think this is good 
> practice in any string buffer protocol.
>
> Next, I’d split the handling of the IO buffer away from the rest:
>
> function df2json(df)
> io = IOBuffer()
> df2json(io, df)
> json = takebuf_string(io)
> close(io)
> json
> end
>
> function df2json(io::IO, df)
> write(io, "[\n")
> write(io, join(map(row -> "{\"A\": $(row[:A]), \"B\": \"$(row[:B])\"}", 
> eachrow(d)), ",\n"))
> write(io, "\n]\n")
> end
>
> I’d also make pretty-printing optional, to make it possible to write the 
> JSON as compact as possible too:
>
> function df2json(df; pretty_print::Bool=false)
> io = IOBuffer()
> df2json(io, df; pretty_print=pretty_print)
> json = takebuf_string(io)
> close(io)
> json
> end
>
> function df2json(io::IO, df; pretty_print::Bool=false)
> write(io, "[")
> pretty_print && write(io, "\n")
> separator = "," * (pretty_print ? "\n\t" : "")
> space = pretty_print ? " " : ""
> write(io, join(map(row -> 
> "{\"A\":$space$(row[:A]),$space\"B\":$space\"$(row[:B])\"}", eachrow(d)), 
> separator))
> pretty_print && write(io, "\n")
> write(io, "]")
> write(io, "\n")
> end
>
> Now, this allows you to print the message either for human reading:
>
> julia> d = DataFrame(A=1:10, B=map(x -> x > 0.5 ? "F" : "M", rand(10)))
> 10x2 DataFrames.DataFrame
> | Row | A  | B   |
> |-||-|
> | 1   | 1  | "M" |
> | 2   | 2  | "M" |
> | 3   | 3  | "M" |
> | 4   | 4  | "M" |
> | 5   | 5  | "F" |
> | 6   | 6  | "F" |
> | 7   | 7  | "F" |
> | 8   | 8  | "M" |
> | 9   | 9  | "F" |
> | 10  | 10 | "F" |
>
> julia> println(df2json(d; pretty_print=true));
> [
> {"A": 1, "B": "M"},
> {"A": 2, "B": "M"},
> {"A": 3, "B": "M"},
> {"A": 4, "B": "M"},
> {"A": 5, "B": "F"},
> {"A": 6, "B": "F"},
> {"A": 7, "B": "F"},
> {"A": 8, "B": "M"},
> {"A": 9, "B": "F"},
> {"A": 10, "B": "F"}
> ]
>
> or for minimizing network overhead:
>
> julia> println(df2json(d))
> [{"A":1,"B":"M"},{"A":2,"B":"M"},{"A":3,"B":"M"},{"A":4,"B":"M"},{"A":5,"B":"F"},{"A":6,"B":"F"},{"A":7,"B":"F"},{"A":8,
> "B":"M"},{"A":9,"B":"F"},{"A":10,"B":"F"}]
>
> // T
>
> On Monday, November 9, 2015 at 6:12:31 AM UTC+1, Eric Forgy wrote:
>
> This is embarrassing since I'm just learning, but in the interest of 
>> getting feedback and improving my Julia coding skills, here is what I did:
>>
>> function df2json(df::DataFrame)
>>
>> nrow,ncol = size(df)
>>
>> io = IOBuffer();
>> write(io,"[\n")
>> for irow = 1:nrow
>>   irow == nrow ? eor = "" : eor = ","
>>   write(io,"{")
>>   for icol = 1:ncol
>> icol == ncol ? eoe = "" : eoe = ","
>> sym = names(df)[icol]
>> name = string(sym)
>> if isa(value,Number)
>>   write(io,"\""*name*"\":"*string(df[irow,sym])*eoe)
>> else
>>   write(io,"\""*name*"\":\""*df[irow,sym]*"\""*eoe)
>> end
>>   end
>>   write(io,"}"*eor*"\n")
>> end
>> write(io,"]\n")
>>
>> json = takebuf_string(io)
>> close(io)
>> json
>> end
>>
>>
>> Any thoughts/suggestions? Thank you.
>>
> ​
>

[julia-users] Re: Type stability with eigs

[Tomas Lycken]

This actually seems to be a type instability issue in Base.eigs:

julia> @code_warntype eigs(A)
Variables:
  A::SparseMatrixCSC{Float64,Int64}

Body:
  begin
  $(Expr(:line, 50, symbol("linalg/arnoldi.jl"), symbol("")))
  GenSym(8) = 
(top(ccall))(:jl_alloc_array_1d,(top(apply_type))(Base.Array,Any,1)::Type{Array{Any,1}},(top(svec))(Base.Any,Base.Int)::SimpleVector,Array{Any,1},0,0,0)::Array{Any,1}
  GenSym(9) = GenSym(8)
  return 
(Base.LinAlg.__eigs#221__)(GenSym(9),A::SparseMatrixCSC{Float64,Int64})::Tuple
  end::Tuple

julia> @code_warntype eigs(Symmetric(A))
Variables:
  A::Symmetric{Float64,SparseMatrixCSC{Float64,Int64}}

Body:
  begin
  $(Expr(:line, 50, symbol("linalg/arnoldi.jl"), symbol("")))
  GenSym(8) = 
(top(ccall))(:jl_alloc_array_1d,(top(apply_type))(Base.Array,Any,1)::Type{Array{Any,1}},(top(svec))(Base.Any,Base.Int)::SimpleVector,Array{Any,1},0,0,0)::Array{Any,1}
  GenSym(9) = GenSym(8)
  return 
(Base.LinAlg.__eigs#221__)(GenSym(9),A::Symmetric{Float64,SparseMatrixCSC{Float64,Int64}})::Tuple
  end::Tuple

I can’t find anything on the issue tracker about it, so it might be a good 
idea to file a new issue .

// t

On Saturday, November 7, 2015 at 5:25:30 PM UTC+1, David Gleich wrote:

I'm trying to get a type-stable output from a symmetric sparse eigenvalue 
> problem.
>
> Any ideas why neither of these ideas work to give me a deterministic 
> return of Array{Float64,1} ?
>
> n = 500; A = sparse(1:n-1,2:n,1.,n,n); A = A + A'
> @show issym(A)
> function myeig1(A::SparseMatrixCSC{Float64,Int64})
>d,V = eigs(A;tol=1e-4)
>return d
> end
>
> function myeig2(A::SparseMatrixCSC{Float64,Int64})
>d,V = eigs(Symmetric(A);tol=1e-4)
>return d
> end
>
> @code_warntype myeig1(A)
> @code_warntype myeig2(A)
>
> Thanks,
> David Gleich
>
​

[julia-users] Re: Type stability with eigs

[Kristoffer Carlsson]

eig had the same problem before: https://github.com/JuliaLang/julia/issues/12304

[julia-users] Re: DataFrame to JSON

[Tomas Lycken]

I’d try to use the built-in tools for iterating and transforming stuff to 
make the code a little terser and easier to read:

function df2json(df)
io = IOBuffer()
write(io, "[\n")
write(io, join(map(row -> "{\"A\": $(row[:A]), \"B\": \"$(row[:B])\"}", 
eachrow(d)), ",\n"))
write(io, "\n]\n")
json = takebuf_string(io)
close(io)
json
end

The keys here is to use the map and eachrow functions to get rid of the for 
loops, and to build each item with string interpolation, which makes it 
easier to see what the result will be.
Note that I end the entire message with a newline; I think this is good 
practice in any string buffer protocol.

Next, I’d split the handling of the IO buffer away from the rest:

function df2json(df)
io = IOBuffer()
df2json(io, df)
json = takebuf_string(io)
close(io)
json
end

function df2json(io::IO, df)
write(io, "[\n")
write(io, join(map(row -> "{\"A\": $(row[:A]), \"B\": \"$(row[:B])\"}", 
eachrow(d)), ",\n"))
write(io, "\n]\n")
end

I’d also make pretty-printing optional, to make it possible to write the 
JSON as compact as possible too:

function df2json(df; pretty_print::Bool=false)
io = IOBuffer()
df2json(io, df; pretty_print=pretty_print)
json = takebuf_string(io)
close(io)
json
end

function df2json(io::IO, df; pretty_print::Bool=false)
write(io, "[")
pretty_print && write(io, "\n")
separator = "," * (pretty_print ? "\n\t" : "")
space = pretty_print ? " " : ""
write(io, join(map(row -> 
"{\"A\":$space$(row[:A]),$space\"B\":$space\"$(row[:B])\"}", eachrow(d)), 
separator))
pretty_print && write(io, "\n")
write(io, "]")
write(io, "\n")
end

Now, this allows you to print the message either for human reading:

julia> d = DataFrame(A=1:10, B=map(x -> x > 0.5 ? "F" : "M", rand(10)))
10x2 DataFrames.DataFrame
| Row | A  | B   |
|-||-|
| 1   | 1  | "M" |
| 2   | 2  | "M" |
| 3   | 3  | "M" |
| 4   | 4  | "M" |
| 5   | 5  | "F" |
| 6   | 6  | "F" |
| 7   | 7  | "F" |
| 8   | 8  | "M" |
| 9   | 9  | "F" |
| 10  | 10 | "F" |

julia> println(df2json(d; pretty_print=true));
[
{"A": 1, "B": "M"},
{"A": 2, "B": "M"},
{"A": 3, "B": "M"},
{"A": 4, "B": "M"},
{"A": 5, "B": "F"},
{"A": 6, "B": "F"},
{"A": 7, "B": "F"},
{"A": 8, "B": "M"},
{"A": 9, "B": "F"},
{"A": 10, "B": "F"}
]

or for minimizing network overhead:

julia> println(df2json(d))
[{"A":1,"B":"M"},{"A":2,"B":"M"},{"A":3,"B":"M"},{"A":4,"B":"M"},{"A":5,"B":"F"},{"A":6,"B":"F"},{"A":7,"B":"F"},{"A":8,
"B":"M"},{"A":9,"B":"F"},{"A":10,"B":"F"}]

// T

On Monday, November 9, 2015 at 6:12:31 AM UTC+1, Eric Forgy wrote:

This is embarrassing since I'm just learning, but in the interest of 
> getting feedback and improving my Julia coding skills, here is what I did:
>
> function df2json(df::DataFrame)
>
> nrow,ncol = size(df)
>
> io = IOBuffer();
> write(io,"[\n")
> for irow = 1:nrow
>   irow == nrow ? eor = "" : eor = ","
>   write(io,"{")
>   for icol = 1:ncol
> icol == ncol ? eoe = "" : eoe = ","
> sym = names(df)[icol]
> name = string(sym)
> if isa(value,Number)
>   write(io,"\""*name*"\":"*string(df[irow,sym])*eoe)
> else
>   write(io,"\""*name*"\":\""*df[irow,sym]*"\""*eoe)
> end
>   end
>   write(io,"}"*eor*"\n")
> end
> write(io,"]\n")
>
> json = takebuf_string(io)
> close(io)
> json
> end
>
>
> Any thoughts/suggestions? Thank you.
>
​

Re: [julia-users] Re: The growth of Julia userbase

[Seth]

If I'm reading the graphs correctly, the underlying data is a year old.

On Monday, November 9, 2015 at 3:10:41 PM UTC-8, Ken B wrote:
>
> Here's a nice comparison of languages used in github repo's and Julia is 
> #43 out of 50:
> http://githut.info/
>
> On Thursday, 5 November 2015 02:50:43 UTC+1, Iain Dunning wrote:
>>
>> Some more data, from pkg.julialang.org web analytics: 
>> In January there were 3.5k "users", which ramped up to 5k by March, and 
>> then held there roughly before spiking up to nearly 6k in October - maybe 
>> the 0.4 release?
>>
>> Theres also the number of packages themselves:
>> 300 packages ~ April 2014
>> 400 packages ~ October 2014
>> 500 packages ~ February 2015
>> 600 packages ~ June 2015
>> 700 packages ~ October 2014
>> It does look roughly superlinear to me.
>>
>>
>> On Wednesday, November 4, 2015 at 4:35:18 PM UTC-5, Milan Bouchet-Valat 
>> wrote:
>>>
>>> Le mercredi 04 novembre 2015 à 20:49 +, Ben Ward a écrit : 
>>> > Could anyone who can see it tell me the current figures? Or see to 
>>> > making this data public? It seems an odd thing to keep private - I 
>>> > would presume growth figures were something to show off. 
>>> Unfortunately, the graphs only cover about 10 days. There are a little 
>>> more than 1,000 unique visitor each day, and about 10,000 since 10/22. 
>>>
>>> Some time ago, I posted the evolution of the number of Debian users who 
>>> have enabled popcon and have Julia installed. The absolute value is not 
>>> representative of anything, but the growth is exponential : 
>>> https://qa.debian.org/popcon.php?package=julia 
>>>
>>> You can also look at the number of stars attributed by users to Julia 
>>> packages : 
>>> http://pkg.julialang.org/pulse 
>>>
>>>
>>> Regards 
>>>
>>>
>>> > On Wed, Nov 4, 2015 at 7:28 PM, Luthaf  wrote: 
>>> > > These graphs are not available for people who are not (Github) 
>>> > > collaborator for the julia repository. 
>>> > > 
>>> > > Tony Kelman a écrit : 
>>> > > > There are some interesting numbers at 
>>> > > > https://github.com/JuliaLang/julia/graphs/traffic 
>>> > > > 
>>> > > > Elliot Saba also did some scraping of the AWS download logs for 
>>> > > > binaries and shared the aggregate numbers (broken down by 
>>> > > > platform) privately with a few people, it may be worth sharing 
>>> > > > those publicly. 
>>> > > > 
>>> > > > 
>>> > > > On Wednesday, November 4, 2015 at 8:26:19 AM UTC-8, Ben Ward 
>>> > > > wrote: 
>>> > > > Hi all, 
>>> > > > 
>>> > > > I was wondering are there any metrics or stats available that 
>>> > > > show how the user-base of Julia has grown over the last few 
>>> > > > years, and what it's size is now? 
>>> > > > 
>>> > > > Many Thanks, 
>>> > > > Ben W. 
>>>
>>