Re: [julia-users] Problems using PyCall and Igraph

[Charles Novaes de Santana]

Thanks Seth, for your suggestion. I will take a look at LightGraphs.jl to
see if it has all the features I need. It would be great if I could use
only julia code (without using python libraries) in my project.

Best,

Charles

On 11 July 2015 at 05:45, Seth  wrote:

> Hi Charles,
>
> igraph is indeed very good, but you might want to look at some
> Julia-native graph libraries. Graphs.jl and LightGraphs.jl are available,
> and the latter performs very favorably compared with igraph.
>
> On Friday, July 10, 2015 at 4:57:36 PM UTC-7, Charles Santana wrote:
>>
>> Hi again,
>>
>> Just to say that I have installed the nightly version of julia
>> (0.4.0-dev+5920 (2015-07-10) and checked out the master branch of PyCall,
>> by running:
>>
>> Pkg.rm("PyCall")
>> Pkg.add("PyCall")
>> Pkg.checkout("PyCall")
>>
>> Now my python-igraph library seems to be working perfectly. I could
>> successfully run this toy example:
>>
>> ```
>> julia> using PyCall
>> julia> @pyimport igraph
>> julia> gg = igraph.Graph()
>> julia> g = gg[:Barabasi](5)
>> julia> g[:degree]()
>> 5-element Array{Any,1}:
>>  3
>>  1
>>  1
>>  2
>>  1
>>
>> ```
>>
>> I will start working with python-igraph, but I will also take a look at
>> Cxx.jl to see if I can use it as an alternative. Thanks a lot for your help
>> and your advice!
>>
>> Best,
>>
>> Charles
>>
>> On 11 July 2015 at 01:37, Yichao Yu  wrote:
>>
>>> On Fri, Jul 10, 2015 at 7:16 PM, Charles Novaes de Santana
>>>  wrote:
>>> > Thanks for your answer, Yichao! I am installing the nightly version of
>>> julia
>>> > and I will try the master version of PyCall.
>>> >
>>> > I was trying to wrap C++-Igraph into my julia code by using Cpp.jl,
>>> however
>>> > it seems to be a bit tricky because my c++ codes are not that simple.
>>> Do you
>>> > (or anybody else) recomend another way to wrap c++ code into julia? I
>>> took a
>>> > look at Cxx.jl and it seems to be more intuitive to use, but I didn't
>>> try it
>>> > yet.
>>>
>>> If it only has c++ interface (or you need to wrap the c++ interface)
>>> I'd probably recommand sticking to the python interface for now and
>>> use Cxx.jl once LLVM3.7 is out (and possibly after julia master
>>> swiches to it).
>>>
>>> If you want to compile julia and llvm yourself, you can try Cxx.jl now
>>> too.
>>>
>>> >
>>> > Best,
>>> >
>>> > Charles
>>> >
>>> > On 11 July 2015 at 00:39, Yichao Yu  wrote:
>>> >>
>>> >> On Fri, Jul 10, 2015 at 6:07 PM, Charles Novaes de Santana
>>> >>  wrote:
>>> >> > Dear Julians,
>>> >> >
>>> >> > Igraph is an amazing library to work with graphs, currently
>>> available
>>> >> > for R,
>>> >> > C/C++ and Python (http://igraph.org). I am trying to use it with
>>> Julia
>>> >> > by
>>> >> > using PyCall but I am facing some issues very similar to the ones
>>> >> > related in
>>> >> > the following links:
>>> >> >
>>> >> > https://github.com/JuliaLang/pyjulia/issues/32
>>> >> >
>>> >> > https://github.com/stevengj/PyCall.jl/issues/95
>>> >> >
>>> >> > https://github.com/stevengj/PyCall.jl/issues/96
>>> >> >
>>> >> > I just tried to run the following  commands:
>>> >> >
>>> >> > julia> using PyCall
>>> >> >
>>> >> > julia> @pyimport igraph
>>> >> >
>>> >> > And got the following error:
>>> >> >
>>> >> > signal (11): Segmentation fault
>>> >> > PyType_Ready at /usr/lib/x86_64-linux-gnu/libpython2.7.so (unknown
>>> line)
>>> >> > call at /home/cdesantana/.julia/v0.4/PyCall/src/pytype.jl:73
>>> >> > pyjlwrap_type at
>>> /home/cdesantana/.julia/v0.4/PyCall/src/pytype.jl:415
>>> >> > pyinitialize at
>>> /home/cdesantana/.julia/v0.4/PyCall/src/pyinit.jl:289
>>> >> > jlcall_pyinitialize_42896 at  (unknown line)
>>> >> > jl_apply_generic at
>>> >> > /home/cdesantana/Downloads/julia/usr/bin/../lib/libjulia.so (unknown
>>> >> > line)
>>> >> > pyinitialize at
>>> /home/cdesantana/.julia/v0.4/PyCall/src/pyinit.jl:329
>>> >> > jlcall_pyinitialize_42814 at  (unknown line)
>>> >> > jl_apply_generic at
>>> >> > /home/cdesantana/Downloads/julia/usr/bin/../lib/libjulia.so (unknown
>>> >> > line)
>>> >> > pyimport at /home/cdesantana/.julia/v0.4/PyCall/src/PyCall.jl:111
>>> >> > jl_apply_generic at
>>> >> > /home/cdesantana/Downloads/julia/usr/bin/../lib/libjulia.so (unknown
>>> >> > line)
>>> >> > unknown function (ip: -775406212)
>>> >> > unknown function (ip: -775409006)
>>> >> > unknown function (ip: -775406239)
>>> >> > unknown function (ip: -775409006)
>>> >> > unknown function (ip: -775409505)
>>> >> > unknown function (ip: -775404607)
>>> >> > unknown function (ip: -775403490)
>>> >> > unknown function (ip: -775333218)
>>> >> > jl_toplevel_eval_in at
>>> >> > /home/cdesantana/Downloads/julia/usr/bin/../lib/libjulia.so (unknown
>>> >> > line)
>>> >> > eval_user_input at REPL.jl:54
>>> >> > jlcall_eval_user_input_42620 at  (unknown line)
>>> >> > jl_apply_generic at
>>> >> > /home/cdesantana/Downloads/julia/usr/bin/../lib/libjulia.so (unknown
>>> >> > line)
>>> >> > anonymous at task.jl:83
>>> >> > unknown function (ip: -775379519)
>>> >> > unknown f

Re: [julia-users] Re: is there compile-time dispatch on constants from a v0.4 @enum

[Jeffrey Sarnoff]

Val{} is a most helpful facility.
Why are enums not Val{} wrapped internally and that hidden with show, so 
enumerated values could be used this way directly?

Given the frequent use of Val{true} and Val{false} when explaining how/why 
to use Val{}, it seems likely those values will get named.
Without knowing if these names are in use or are to be used in another 
context, I have been writing

const False = Val{false}
const True  = Val{true}

Should the corresponding types also be named?

const FALSE = Type{False}
const TRUE  = Type{True}

There are conventions and practices in place of which I am unware;
I am advocating for names, whatever names are most appropriate.

On Friday, July 10, 2015 at 7:49:19 PM UTC-4, Tom Breloff wrote:
>
> Awesome! I didn't know about Val... thanks Kevin. 
>
> On Friday, July 10, 2015 at 5:02:49 PM UTC-4, Kevin Squire wrote:
>>
>> It actually exists in Julia v0.4, as the `Val` type:
>>
>> julia> @enum Fruit apple orange banana
>>
>> julia> apple
>> apple::Fruit
>>
>> julia> isbits(apple)
>> true
>>
>> julia> function what_am_i{T}(::Val{T})
>>   println("I'm a $T, of type $(typeof(T))")
>>end
>> what_am_i (generic function with 1 method)
>>
>> julia> what_am_i(Val{apple}())
>> I'm a apple, of type Fruit
>>
>> julia> what_am_i(Val{orange}())
>> I'm a orange, of type Fruit
>>
>> Cheers,
>>Kevin
>>
>> On Fri, Jul 10, 2015 at 1:57 PM, Tom Breloff  wrote:
>>
>>> As far as I know, this would require the ability to dispatch on values 
>>> in general, since enum values are just const instances of an immutable 
>>> type.  I know this feature has been requested (and I'd certainly make use 
>>> of it as well), but I'm not sure I'd expect it anytime soon.
>>>
>>>
>>> On Friday, July 10, 2015 at 4:38:15 PM UTC-4, Jeffrey Sarnoff wrote:

 Or, is dispatch on enum values planned?
 Can I tell when a function parameter will dispatch on its arg value at 
 compile-time?
 thanks.

>>>
>>

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

[Charles Novaes de Santana]

Hi folks,

Following the suggestion of Seth (
https://groups.google.com/forum/#!topic/julia-users/Ftdo2LmxC-g) I am
trying to use LightGraphs.jl to read my graph files.

My graphs are in GML format (
http://gephi.github.io/users/supported-graph-formats/gml-format/). However,
as far as I understand, LightGraphs.jl can not read graphs in this format.

I just found this thread talking about the creation of a GraphsIO.jl and
its integration with Graphs.jl and LightGraphs.jl (
https://github.com/JuliaLang/Graphs.jl/issues/37) Do you have any news
about it? How can I read GML files to work with LightGraphs.jl?

Thanks for any help!

Charles

-- 
Um axé! :)

--
Charles Novaes de Santana, PhD
http://www.imedea.uib-csic.es/~charles

[julia-users] Re: Workaround for a PosDefException in eigs?

[Christoph Ortner]

I am curious where your problem comes from. If A and B are both stiffness 
matrices (as opposed to A stiffness and B sparse) then the associated 
eigenvalue problem (in the limit h \to 0) is in general ill-posed. So I am 
first of all a little surprised that Matlab gives you a "correct" answer to 
begin with. Did you check that ARPACK actually converges with some 
confidence? Did you compare against a full solver `eig`? This should be 
easy about to, say 4k x 4k but probably will still be ok for larger 
matrices as well.

Christoph

Re: [julia-users] Workaround for a PosDefException in eigs?

[Tim Holy]

Hi Stef,

On Friday, July 10, 2015 12:34:47 PM Stef Kynaston wrote:
> In Matlab, doing
> 
> [v, lambda] = eigs(A, B, 1, sigma),
> 
>  
> where 1 specifies the number of eigenvalues, and sigma specifies the shift 
> (I use 1e-12 here, to avoid the zero eigenvalues) returns the "correct" 
> solution.

I wonder if you can do something similar in julia; generalized eigenvalue 
problems can be mapped to "ordinary" eigenvalue problems using Cholesky 
factorization of B. Julia's cholfact, for sparse inputs, accepts a shift 
keyword that adds to the diagonal (just like your sigma). You could play with 
this and see how far it can take you?

--Tim

Re: [julia-users] Re: is there compile-time dispatch on constants from a v0.4 @enum

[Tim Holy]

On Saturday, July 11, 2015 03:01:55 AM Jeffrey Sarnoff wrote:
> Val{} is a most helpful facility.
> Why are enums not Val{} wrapped internally and that hidden with show, so
> enumerated values could be used this way directly?

Julia compiles separate versions of functions for separate input types, and 
Val{1} is a different type than Val{2}. In many cases the overhead of 
compilation is far worse than the cost of the run-time value-check.

You can amuse yourself by seeing how slow things are, and how quickly your 
machine runs out of memory, by repeatedly calling some method with Val{rand()} 
:-). Contrast calling a similar method with just rand(), and you'll begin to 
appreciate the trade-offs here.

--Tim

[julia-users] SilverFrost Fortran

[LarryD]

I'm just starting to learn Julia, so I apologize for dumb questions.  Does 
anybody have experience calling stuff written in SilverFrost Fortran from 
Julia? Thanks.

LarryD

Re: [julia-users] SilverFrost Fortran

[Stefan Karpinski]

In general, the only issues with calling Fortran involve calling convention
incompatibility with C. There's a fairly old issue about implementing fcall
 (cf ccall), which natively
emits calls using the Fortran calling convention. Have you tried calling
code compiled with this compiler and had problems?

On Saturday, July 11, 2015, LarryD  wrote:

> I'm just starting to learn Julia, so I apologize for dumb questions.  Does
> anybody have experience calling stuff written in SilverFrost Fortran from
> Julia? Thanks.
>
> LarryD
>
>

Re: [julia-users] Problems using PyCall and Igraph

[Seth]

Charles,

LightGraphs has an active dev community so if there's something you need 
that's not yet there, let us know (via issues). We also welcome PRs :)

Seth.

On Saturday, July 11, 2015 at 2:44:54 AM UTC-7, Charles Santana wrote:
>
> Thanks Seth, for your suggestion. I will take a look at LightGraphs.jl to 
> see if it has all the features I need. It would be great if I could use 
> only julia code (without using python libraries) in my project.
>
> Best,
>
> Charles
>
> On 11 July 2015 at 05:45, Seth > 
> wrote:
>
>> Hi Charles,
>>
>> igraph is indeed very good, but you might want to look at some 
>> Julia-native graph libraries. Graphs.jl and LightGraphs.jl are available, 
>> and the latter performs very favorably compared with igraph.
>>
>> On Friday, July 10, 2015 at 4:57:36 PM UTC-7, Charles Santana wrote:
>>>
>>> Hi again,
>>>
>>> Just to say that I have installed the nightly version of julia 
>>> (0.4.0-dev+5920 (2015-07-10) and checked out the master branch of PyCall, 
>>> by running:
>>>
>>> Pkg.rm("PyCall")
>>> Pkg.add("PyCall")
>>> Pkg.checkout("PyCall")
>>>
>>> Now my python-igraph library seems to be working perfectly. I could 
>>> successfully run this toy example:
>>>
>>> ```
>>> julia> using PyCall
>>> julia> @pyimport igraph
>>> julia> gg = igraph.Graph()
>>> julia> g = gg[:Barabasi](5)
>>> julia> g[:degree]()
>>> 5-element Array{Any,1}:
>>>  3
>>>  1
>>>  1
>>>  2
>>>  1
>>>
>>> ```
>>>
>>> I will start working with python-igraph, but I will also take a look at 
>>> Cxx.jl to see if I can use it as an alternative. Thanks a lot for your help 
>>> and your advice!
>>>
>>> Best,
>>>
>>> Charles
>>>
>>> On 11 July 2015 at 01:37, Yichao Yu  wrote:
>>>
 On Fri, Jul 10, 2015 at 7:16 PM, Charles Novaes de Santana
  wrote:
 > Thanks for your answer, Yichao! I am installing the nightly version 
 of julia
 > and I will try the master version of PyCall.
 >
 > I was trying to wrap C++-Igraph into my julia code by using Cpp.jl, 
 however
 > it seems to be a bit tricky because my c++ codes are not that simple. 
 Do you
 > (or anybody else) recomend another way to wrap c++ code into julia? I 
 took a
 > look at Cxx.jl and it seems to be more intuitive to use, but I didn't 
 try it
 > yet.

 If it only has c++ interface (or you need to wrap the c++ interface)
 I'd probably recommand sticking to the python interface for now and
 use Cxx.jl once LLVM3.7 is out (and possibly after julia master
 swiches to it).

 If you want to compile julia and llvm yourself, you can try Cxx.jl now 
 too.

 >
 > Best,
 >
 > Charles
 >
 > On 11 July 2015 at 00:39, Yichao Yu  wrote:
 >>
 >> On Fri, Jul 10, 2015 at 6:07 PM, Charles Novaes de Santana
 >>  wrote:
 >> > Dear Julians,
 >> >
 >> > Igraph is an amazing library to work with graphs, currently 
 available
 >> > for R,
 >> > C/C++ and Python (http://igraph.org). I am trying to use it with 
 Julia
 >> > by
 >> > using PyCall but I am facing some issues very similar to the ones
 >> > related in
 >> > the following links:
 >> >
 >> > https://github.com/JuliaLang/pyjulia/issues/32
 >> >
 >> > https://github.com/stevengj/PyCall.jl/issues/95
 >> >
 >> > https://github.com/stevengj/PyCall.jl/issues/96
 >> >
 >> > I just tried to run the following  commands:
 >> >
 >> > julia> using PyCall
 >> >
 >> > julia> @pyimport igraph
 >> >
 >> > And got the following error:
 >> >
 >> > signal (11): Segmentation fault
 >> > PyType_Ready at /usr/lib/x86_64-linux-gnu/libpython2.7.so 
 (unknown line)
 >> > call at /home/cdesantana/.julia/v0.4/PyCall/src/pytype.jl:73
 >> > pyjlwrap_type at 
 /home/cdesantana/.julia/v0.4/PyCall/src/pytype.jl:415
 >> > pyinitialize at 
 /home/cdesantana/.julia/v0.4/PyCall/src/pyinit.jl:289
 >> > jlcall_pyinitialize_42896 at  (unknown line)
 >> > jl_apply_generic at
 >> > /home/cdesantana/Downloads/julia/usr/bin/../lib/libjulia.so 
 (unknown
 >> > line)
 >> > pyinitialize at 
 /home/cdesantana/.julia/v0.4/PyCall/src/pyinit.jl:329
 >> > jlcall_pyinitialize_42814 at  (unknown line)
 >> > jl_apply_generic at
 >> > /home/cdesantana/Downloads/julia/usr/bin/../lib/libjulia.so 
 (unknown
 >> > line)
 >> > pyimport at /home/cdesantana/.julia/v0.4/PyCall/src/PyCall.jl:111
 >> > jl_apply_generic at
 >> > /home/cdesantana/Downloads/julia/usr/bin/../lib/libjulia.so 
 (unknown
 >> > line)
 >> > unknown function (ip: -775406212)
 >> > unknown function (ip: -775409006)
 >> > unknown function (ip: -775406239)
 >> > unknown function (ip: -775409006)
 >> > unknown function (ip: -775409505)
 >> > unknown function (ip: -775404607)
 >> > unknown function (ip: -775403490)
 >> > unknown function (ip: -775333218)
 >>

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

[Seth]

Hi Charles,

You're correct; for persistence, LightGraphs currently supports an internal 
graph representation and GraphML. If you can convert to GraphML you're in 
luck; otherwise, if you open up an issue someone might be able to code 
something up.

The quickest thing, perhaps, would be to import the gml into NetworkX 
(http://networkx.github.io) and then write it out as GraphML, which you 
should then be able to use in LightGraphs.

Seth.


On Saturday, July 11, 2015 at 3:48:52 AM UTC-7, Charles Santana wrote:
>
> Hi folks,
>
> Following the suggestion of Seth (
> https://groups.google.com/forum/#!topic/julia-users/Ftdo2LmxC-g) I am 
> trying to use LightGraphs.jl to read my graph files. 
>
> My graphs are in GML format (
> http://gephi.github.io/users/supported-graph-formats/gml-format/). 
> However, as far as I understand, LightGraphs.jl can not read graphs in this 
> format.
>
> I just found this thread talking about the creation of a GraphsIO.jl and 
> its integration with Graphs.jl and LightGraphs.jl (
> https://github.com/JuliaLang/Graphs.jl/issues/37) Do you have any news 
> about it? How can I read GML files to work with LightGraphs.jl?
>
> Thanks for any help!
>
> Charles
>
> -- 
> Um axé! :)
>
> --
> Charles Novaes de Santana, PhD
> http://www.imedea.uib-csic.es/~charles
>  

Re: [julia-users] Re: is there compile-time dispatch on constants from a v0.4 @enum

[Jeffrey Sarnoff]

thanks for the perspective, Tim .. 
do we have a feel for how many Val{s} is too many when the function gets 
slammed with invocations every now and again?

returning to some future enum realization, where any enumerand plopped into 
a call generates a partially dispached specialization
  (an inside-out and rightside-left take on currying), would doing that 
with an 2..12-valued enum be worthwhile for small functions
  -- functions that do some parrying and then call others for most of the 
work; or is there something about the nature of Julia's
  compiling process that compilation time reaches through thin functions 
into those that they call?


On Saturday, July 11, 2015 at 9:24:43 AM UTC-4, Tim Holy wrote:
>
> On Saturday, July 11, 2015 03:01:55 AM Jeffrey Sarnoff wrote: 
> > Val{} is a most helpful facility. 
> > Why are enums not Val{} wrapped internally and that hidden with show, so 
> > enumerated values could be used this way directly? 
>
> Julia compiles separate versions of functions for separate input types, 
> and 
> Val{1} is a different type than Val{2}. In many cases the overhead of 
> compilation is far worse than the cost of the run-time value-check. 
>
> You can amuse yourself by seeing how slow things are, and how quickly your 
> machine runs out of memory, by repeatedly calling some method with 
> Val{rand()} 
> :-). Contrast calling a similar method with just rand(), and you'll begin 
> to 
> appreciate the trade-offs here. 
>
> --Tim 
>
>

Re: [julia-users] Re: Juliacon 2015 videos?

[Ismael VC]

@Viral thank you for the update! What I want is to be able to subtitle the
videos, that's all.

On Fri, Jul 10, 2015 at 9:52 PM, Viral Shah  wrote:

> We have to work through all these details still.
>
> -viral
>
>
> On Friday, July 10, 2015 at 11:19:31 PM UTC+5:30, Ismael VC wrote:
>>
>> Please could anyone tell me what's the situation with the videos
>> copyrights would I be allowed to translate them into Spanish?
>>
>> El miércoles, 1 de julio de 2015, 7:07:18 (UTC-5), Hans-Peter escribió:
>>>
>>> Will there be videos of the 2015 Juliacon? Where... :-)
>>> Thanks.
>>>
>>

Re: [julia-users] Re: Juliacon 2015 videos?

[Ismael VC]

Also while I wait for this news I'd like to know which license is used
currently for the videos that are already at the Julia Youtube channel. If
it's ok I would also like to provide translated subtitles for some of these
videos. I'm assuming this is something we all want as a community, I'm I
right?

@sorami are you guys at also interested in this? Id like to know which
other stuff would you or anybody else expect to be part of "juila-i10n".

Is there anyone else interested in translating julia resources to other
languages?

On Sat, Jul 11, 2015 at 9:29 AM, Ismael VC  wrote:

> @Viral thank you for the update! What I want is to be able to subtitle the
> videos, that's all.
>
> On Fri, Jul 10, 2015 at 9:52 PM, Viral Shah  wrote:
>
>> We have to work through all these details still.
>>
>> -viral
>>
>>
>> On Friday, July 10, 2015 at 11:19:31 PM UTC+5:30, Ismael VC wrote:
>>>
>>> Please could anyone tell me what's the situation with the videos
>>> copyrights would I be allowed to translate them into Spanish?
>>>
>>> El miércoles, 1 de julio de 2015, 7:07:18 (UTC-5), Hans-Peter escribió:

 Will there be videos of the 2015 Juliacon? Where... :-)
 Thanks.

>>>
>

Re: [julia-users] Re: Juliacon 2015 videos?

[Ismael VC]

Everyone, please feel free to come and join us at the Gitter channel
**julia-i18n** for discussions regarding the internationalization of Julia:

* https://gitter.im/JuliaLangEs/julia-i18n

On Sat, Jul 11, 2015 at 9:46 AM, Ismael VC  wrote:

> Also while I wait for this news I'd like to know which license is used
> currently for the videos that are already at the Julia Youtube channel. If
> it's ok I would also like to provide translated subtitles for some of these
> videos. I'm assuming this is something we all want as a community, I'm I
> right?
>
> @sorami are you guys at also interested in this? Id like to know which
> other stuff would you or anybody else expect to be part of "juila-i10n".
>
> Is there anyone else interested in translating julia resources to other
> languages?
>
> On Sat, Jul 11, 2015 at 9:29 AM, Ismael VC 
> wrote:
>
>> @Viral thank you for the update! What I want is to be able to subtitle
>> the videos, that's all.
>>
>> On Fri, Jul 10, 2015 at 9:52 PM, Viral Shah  wrote:
>>
>>> We have to work through all these details still.
>>>
>>> -viral
>>>
>>>
>>> On Friday, July 10, 2015 at 11:19:31 PM UTC+5:30, Ismael VC wrote:

 Please could anyone tell me what's the situation with the videos
 copyrights would I be allowed to translate them into Spanish?

 El miércoles, 1 de julio de 2015, 7:07:18 (UTC-5), Hans-Peter escribió:
>
> Will there be videos of the 2015 Juliacon? Where... :-)
> Thanks.
>

>>
>

Re: [julia-users] Juliacon 2015 videos?

[Viral Shah]

I am pretty sure that JuliaCon 2014 videos are under some sort of Creative 
Commons, but can’t quite remember which exact one. Perhaps someone else may 
know.

It would be great to have the spanish and other subtitles.

-viral



> On 11-Jul-2015, at 8:16 pm, Ismael VC  wrote:
> 
> Also while I wait for this news I'd like to know which license is used 
> currently for the videos that are already at the Julia Youtube channel. If 
> it's ok I would also like to provide translated subtitles for some of these 
> videos. I'm assuming this is something we all want as a community, I'm I 
> right?
> 
> @sorami are you guys at also interested in this? Id like to know which other 
> stuff would you or anybody else expect to be part of "juila-i10n". 
> 
> Is there anyone else interested in translating julia resources to other 
> languages?  
> 
> On Sat, Jul 11, 2015 at 9:29 AM, Ismael VC  wrote:
> @Viral thank you for the update! What I want is to be able to subtitle the 
> videos, that's all.
> 
> On Fri, Jul 10, 2015 at 9:52 PM, Viral Shah  wrote:
> We have to work through all these details still. 
> 
> -viral
> 
> 
> On Friday, July 10, 2015 at 11:19:31 PM UTC+5:30, Ismael VC wrote:
> Please could anyone tell me what's the situation with the videos copyrights 
> would I be allowed to translate them into Spanish?
> 
> El miércoles, 1 de julio de 2015, 7:07:18 (UTC-5), Hans-Peter escribió:
> Will there be videos of the 2015 Juliacon? Where... :-)
> Thanks.
> 
> 

Re: [julia-users] Juliacon 2015 videos?

[Ismael VC]

I was also specially interested in translating David Sanders *Introduction
to Julia* at SciPy 2014. I tried to get in contact with Enthought since
January but I never got a reply: 😢

 Message: I’d like add translated captions into Spanish to your Julia
YouTube videos, and I was wondering how to go about it.

I’ve seen a few on line tools, but I can’t import your video, from here for
example:
http://captiontube.appspot.com
I get: Please enter a valid URL for this YouTube video.
Note: if you do not own the video and it is private or cannot be embedded,
you will not be able to import it. If you own the video, close this dialog
and choose Personal Video to import it.

bvIt’s supposed to allow me to import it so I can translate it and send the
translations via e-mail to theEnthought YouTube account.

Thank you very much!

I just got this from their bot:

We have received your support request (# 44258) and are reviewing it.

​

On Sat, Jul 11, 2015 at 10:56 AM, Viral Shah  wrote:

> I am pretty sure that JuliaCon 2014 videos are under some sort of Creative
> Commons, but can’t quite remember which exact one. Perhaps someone else may
> know.
>
> It would be great to have the spanish and other subtitles.
>
> -viral
>
>
>
> > On 11-Jul-2015, at 8:16 pm, Ismael VC  wrote:
> >
> > Also while I wait for this news I'd like to know which license is used
> currently for the videos that are already at the Julia Youtube channel. If
> it's ok I would also like to provide translated subtitles for some of these
> videos. I'm assuming this is something we all want as a community, I'm I
> right?
> >
> > @sorami are you guys at also interested in this? Id like to know which
> other stuff would you or anybody else expect to be part of "juila-i10n".
> >
> > Is there anyone else interested in translating julia resources to other
> languages?
> >
> > On Sat, Jul 11, 2015 at 9:29 AM, Ismael VC 
> wrote:
> > @Viral thank you for the update! What I want is to be able to subtitle
> the videos, that's all.
> >
> > On Fri, Jul 10, 2015 at 9:52 PM, Viral Shah  wrote:
> > We have to work through all these details still.
> >
> > -viral
> >
> >
> > On Friday, July 10, 2015 at 11:19:31 PM UTC+5:30, Ismael VC wrote:
> > Please could anyone tell me what's the situation with the videos
> copyrights would I be allowed to translate them into Spanish?
> >
> > El miércoles, 1 de julio de 2015, 7:07:18 (UTC-5), Hans-Peter escribió:
> > Will there be videos of the 2015 Juliacon? Where... :-)
> > Thanks.
> >
> >
>
>

[julia-users] 3D plots

[Juan Carlos Cuevas Bautista]

Hi Everybody,

I am new in Julia and I trying to do a 3D plot. I have 3 different arrays 
of data and I want to
plot them in each axis. To do this I am using the function plot3D from 
pyplot. So far the code
is working but I want to change one of the axis for a different scale, for 
instance 'log'. This 
is the part that I haven't accomplished, here is a fragment of my code

h2=figure();
plot3D(xdata1,ydata1,zdata1);
plot3D(xdata2,ydata2,zdata2);
set_xscale("log");   #not working this option
#xscale("log");#not working this option
xlabel(L"$y^+$");
ylabel(L"$\lambda^+$");
zlabel(L"$f^+$");
close(h2);

I am guessing if it works similar to Matlab, in that case it would be 
something like
h3=get_axis.h2
h3.set_xscale("log")

but it doesn't work neither and I haven't found enough documentation in the 
mplot3d tutorial.

Thank you very much for your help

Re: [julia-users] SilverFrost Fortran

[Tony Kelman]

I've never heard of that compiler, which surprises me a little. It looks 
like it's primarily for 32 bit Windows, so you'll need to use a 32 bit 
version of Julia to call into shared libraries built using that compiler. 
If you have access to the Fortran source you could also try rebuilding with 
the more common open-source MinGW-w64 version of gfortran, for either 32 or 
64 bit Windows. If you only have access to compiled binaries, are they 
shared libraries (dlls) or static libraries? If they're dll's, you can try 
looking at them using Dependency Walker to see what the exported symbol 
names are, then call them according to the "interfacing with C and Fortran" 
documentation. If you only have static libraries, you could try calling the 
linker to build a shared library out of them.


On Saturday, July 11, 2015 at 6:36:30 AM UTC-7, Stefan Karpinski wrote:
>
> In general, the only issues with calling Fortran involve calling 
> convention incompatibility with C. There's a fairly old issue about 
> implementing fcall  (cf 
> ccall), which natively emits calls using the Fortran calling convention. 
> Have you tried calling code compiled with this compiler and had problems?
>
> On Saturday, July 11, 2015, LarryD > 
> wrote:
>
>> I'm just starting to learn Julia, so I apologize for dumb questions.  
>> Does anybody have experience calling stuff written in SilverFrost Fortran 
>> from Julia? Thanks.
>>
>> LarryD
>>
>>

[julia-users] Re: Condition Number of a Matrix

[Jared Crean]

Hello Andreas,
Thanks, that clears it up.

Jared Crean

On Tuesday, July 7, 2015 at 4:33:52 PM UTC-4, Jared Crean wrote:
>
> Hello,
> I am working with some poorly conditioned matrices, and I computed the 
> condition number using the cond() function and by comparing the maximum and 
> minimum singular values from svd(), and got very different answers.  The 
> matrix is attached.
>
> From svdvals, used by cond(), the max and min are  8.488228999798525e18, 
> 2.3929633941941788e-61,
> From svd, the are 8.488228999798525e18, 169.86022318633755
>
> Except for the first three, all the singular values reported by svd and 
> svdvals are different.  Are the two functions using different methods to 
> calculate the singular values?
>
>   Jared Crean
>

[julia-users] Running Shell Script

[Jared Crean]

Hello,
I am trying to run a shell command through julia but am getting 
errors.  For example


julia> run(`source ./use_petsc.jl`)
ERROR: could not spawn `source ./use_petsc.jl`: no such file or directory 
(ENOENT)
 in _jl_spawn at process.jl:225
 in spawn at process.jl:355
 in spawn at process.jl:396
 in run at ./process.jl:485

I tried breaking up the command into two interpolations as described here : 
http://stackoverflow.com/questions/24682182/julia-unable-to-run-command-with-arguments-through-string-variable
 
, but that didn't work either.

I know there are other ways of setting environmental variables, but it is 
important for the project I am working on to use shell scripts.

Jared Crean

[julia-users] Re: Running Shell Script

[Tony Kelman]

The uv spawn API doesn't go through bash so it won't handle bash builtins. 
You can run some scripts via bash -c, but that usually won't persist any 
environment changes after bash exits. If this is a Julia script, can't you 
include it?


On Saturday, July 11, 2015 at 10:56:49 AM UTC-7, Jared Crean wrote:
>
> Hello,
> I am trying to run a shell command through julia but am getting 
> errors.  For example
>
>
> julia> run(`source ./use_petsc.jl`)
> ERROR: could not spawn `source ./use_petsc.jl`: no such file or directory 
> (ENOENT)
>  in _jl_spawn at process.jl:225
>  in spawn at process.jl:355
>  in spawn at process.jl:396
>  in run at ./process.jl:485
>
> I tried breaking up the command into two interpolations as described here 
> : 
> http://stackoverflow.com/questions/24682182/julia-unable-to-run-command-with-arguments-through-string-variable
>  
> , but that didn't work either.
>
> I know there are other ways of setting environmental variables, but it is 
> important for the project I am working on to use shell scripts.
>
> Jared Crean
>

[julia-users] how should I assign load(filepathname, varname_string) to varname given as a string

[Jeffrey Sarnoff]

I have been trying to loop over variable names available as an ASCIIString 
vector, using each to generate the corresponding jld datafile path+name and 
load_ing() the datafile into  its original variable name .. should this be 
done with string->symbol manipulation and/or is a macro required to effect 
an applicative assignment operator? I need some guidance on how to do it. 

[julia-users] Re: max function on sparse matrices

[Tony Kelman]

https://github.com/JuliaLang/julia/issues/12118


On Friday, July 10, 2015 at 7:50:23 PM UTC-7, Viral Shah wrote:
>
> Could you please file an issue?
>
> -viral
>
> On Saturday, July 11, 2015 at 12:28:52 AM UTC+5:30, Huda Nassar wrote:
>>
>> *julia> **A = sprand(5,5,2/5)*
>>
>> *5x5 sparse matrix with 9 Float64 entries:*
>>
>> *[3, 1]  =  0.640396*
>>
>> *[3, 2]  =  0.873544*
>>
>> *[3, 3]  =  0.278582*
>>
>> *[4, 3]  =  0.751313*
>>
>> *[1, 4]  =  0.644883*
>>
>> *[2, 4]  =  0.0778264*
>>
>> *[3, 4]  =  0.848185*
>>
>> *[2, 5]  =  0.0856352*
>>
>> *[3, 5]  =  0.553206*
>>
>> *julia> **B = sprand(5,5,2/5)*
>>
>> *5x5 sparse matrix with 9 Float64 entries:*
>>
>> *[2, 1]  =  0.404673*
>>
>> *[3, 1]  =  0.736787*
>>
>> *[4, 1]  =  0.953803*
>>
>> *[1, 2]  =  0.0951856*
>>
>> *[4, 2]  =  0.519675*
>>
>> *[1, 3]  =  0.0135403*
>>
>> *[4, 3]  =  0.303399*
>>
>> *[1, 5]  =  0.702557*
>>
>> *[4, 5]  =  0.596537*
>>
>> *julia> **C = max(A,B)*
>>
>> *5x5 Array{Float64,2}:*
>>
>> * 0.0   0.0951856  0.0135403  0.644883   0.702557*
>>
>> * 0.404673  0.00.00.0778264  0.0856352*
>>
>> * 0.736787  0.873544   0.278582   0.848185   0.553206*
>>
>> * 0.953803  0.519675   0.751313   0.00.596537*
>>
>> * 0.0   0.00.00.00.0  *
>>
>> Isn't this an undesired behavior of max() when called on 2 sparse 
>> matrices? Shouldn't the output be sparse as well?
>>
>

[julia-users] Re: how should I assign load(filepathname, varname_string) to varname given as a string

[Scott Jones]

Why are you limiting it to an ASCIIString?  variable names in Julia 
frequently have Unicode characters.

On Saturday, July 11, 2015 at 4:06:43 PM UTC-4, Jeffrey Sarnoff wrote:
>
> I have been trying to loop over variable names available as an ASCIIString 
> vector, using each to generate the corresponding jld datafile path+name and 
> load_ing() the datafile into  its original variable name .. should this be 
> done with string->symbol manipulation and/or is a macro required to effect 
> an applicative assignment operator? I need some guidance on how to do it. 
>

Re: [julia-users] Performance question on a dictionary of arrays

[Mauro]

Two things:

- call your functions once before timing them so JIT-compilation is not
  included in the @time

- @time needs a warm-up too, so I usually do:
  @time 1

- currently methods not defined in global scope are (often) slower.
  Your let-block means that you are in a local scope.  This not-so-good
  performance stems from Julia struggling with type inference and it
  doesn't know what types are used. This means it has to box the values
  which leads to the allocations you see (why straight arrays work ok, I
  don't know)

After these two modifications I get on 0.3.9:

elapsed time: 0.000502229 seconds (13880 bytes allocated)  # the @time 1 warm-up
pass array
elapsed time: 0.002038221 seconds (80 bytes allocated)

Get array from typed dictionary
elapsed time: 0.002790512 seconds (80 bytes allocated)

Get array from untyped dictionary
elapsed time: 0.549008381 seconds (268783784 bytes allocated, 14.63% gc time)

work with typed dictionary
elapsed time: 0.181315189 seconds (80 bytes allocated)

work with untyped dictionary
elapsed time: 0.86460421 seconds (268783784 bytes allocated, 9.26% gc time)

get array from typed dict and call scale1!
elapsed time: 0.001979506 seconds (96 bytes allocated)

get array from untyped dict and call scale1!
elapsed time: 0.002014811 seconds (96 bytes allocated)

Is that in-line with your expectations?  If not, please report back.

On Fri, 2015-07-10 at 23:07, Jeremy Kozdon  wrote:
> Hello all,
>
> The following minimal example is confusing me. In each case the same 
> operations are performed, in several cases it seems that a copy of the 
> array seems to be made even though the original array is the one getting 
> modified.
>
> Any assistance as to what I am doing incorrectly would be appreciated (my 
> preference would be to do something like scale2! and not have to use 
> scale4! as a work around).
>
> let
>   function scale1!(f, a)
> for n = 1:length(f)
>   f[n] = f[n] * a
> end
>   end
>
>   function scale2!(V, a)
> f = V["f"]
> for n = 1:length(f)
>   f[n] = f[n] * a
> end
>   end
>
>   function scale3!(V, a)
> for n = 1:length(V["f"])
>   V["f"][n] = V["f"][n] * a
> end
>   end
>
>   function scale4!(f, a)
> f = V["f"]
> scale1!(f,a)
>   end
>
>   f = ones(4,60)
>   a = 2.
>
>   # Typed dictionary
>   V = Dict{String,Array{Float64,2}}()
>   V["f"] = f
>
>   # untyped dictionary
>   U = Dict()
>   U["f"] = f
>
>   println("pass array")
>   @time scale1!(f,a)
>   println()
>
>   println("Get array from typed dictionary")
>   @time scale2!(V,a)
>   println()
>
>   println("Get array from untyped dictionary")
>   @time scale2!(U,a)
>   println()
>
>   println("work with typed dictionary")
>   @time scale3!(V,a)
>   println()
>
>   println("work with untyped dictionary")
>   @time scale3!(U,a)
>   println()
>
>   println("get array from typed dict and call scale1!")
>   @time scale4!(V,a)
>   println()
>
>   println("get array from untyped dict and call scale1!")
>   @time scale4!(U,a)
> end
>
>
> 'The output I get for Julia 0.3.10 is
>
> pass array
> elapsed time: 0.00631541 seconds (108104 bytes allocated)
>
> Get array from typed dictionary
> elapsed time: 0.769137049 seconds (230636428 bytes allocated, 13.57% gc 
> time)
>
> Get array from untyped dictionary
> elapsed time: 0.689766861 seconds (230487160 bytes allocated, 16.58% gc 
> time)
>
> work with typed dictionary
> elapsed time: 0.218875407 seconds (167668 bytes allocated)
>
> work with untyped dictionary
> elapsed time: 1.057047219 seconds (268889924 bytes allocated, 13.12% gc 
> time)
>
> get array from typed dict and call scale1!
> elapsed time: 0.006385067 seconds (27196 bytes allocated)
>
> get array from untyped dict and call scale1!
> elapsed time: 0.005792765 seconds (26724 bytes allocated)
>
>
> The output I get for Julia 0.4.0-dev is
>
> pass array
>6.036 milliseconds (2148 allocations: 104 KB)
>
> Get array from typed dictionary
>  565.849 milliseconds (12000 k allocations: 220 MB, 3.33% gc time)
>
> Get array from untyped dictionary
>  569.234 milliseconds (12000 k allocations: 220 MB, 3.17% gc time)
>
> work with typed dictionary
>  255.653 milliseconds (3513 allocations: 161 KB)
>
> work with untyped dictionary
>  836.564 milliseconds (14401 k allocations: 256 MB, 2.30% gc time)
>
> get array from typed dict and call scale1!
>5.984 milliseconds (544 allocations: 28558 bytes)
>
> get array from untyped dict and call scale1!
>5.180 milliseconds (539 allocations: 28014 bytes)

Re: [julia-users] Re: is there compile-time dispatch on constants from a v0.4 @enum

[Jameson Nash]

i suspect that ideal number is around 2 or 3.

you should make singleton types instead of using the enum macro if you want
to dispatch on the result. the enum macro exists for exactly the reason
that typically you don't want the the compiler to try to attempt method
specialization on values. you may think my estimate sounds low, but
remember that there is a potential exponential explosion of type signature
combinations, so you want the base numbers to be really small. (e.g
f(::Val{<:Bool}) describes 2 methods, f(::Val{<:Bool}, ::Val{<:Bool},
Val{<:Bool}) describes 8 methodes).

the compiler currently is incredibly dumb when it comes to handling lots of
relatively unique values that the user decided to call types. instead, it
trusts that the user provided only types that provide important descriptive
or optimization benefits. since the compile overhead seems to be somewhere
around 10_000x the cost of running a function, you should typically opt for
the runtime branch.

Val{true} and Val{false} seem like a bad idea to me. This implies a 2x
increase in compile time and memory usage across the board, but I suspect
it will often run slower than the runtime branch. The runtime performance
cost of the code branch should be pretty nearly zero-cost (due to
pipelining and branch prediction). But if you ever get to a point in the
program where you don't write exactly "Val{true}" for "Val{false}", but
instead try to compute this from a function, you are forcing the full cost
of a dynamic function lookup (until the compiler gets smarter and turns
this into a nest of non-zero cost branch-and-join phi node -- essentially
trying to turn `Val{false}` back into `false`). And if you were intending
to dispatch differently on `Val{true}` vs. `Val{false}`, it seems much
clearer to me to give these methods unique names.

On Sat, Jul 11, 2015 at 10:28 AM Jeffrey Sarnoff 
wrote:

> thanks for the perspective, Tim ..
> do we have a feel for how many Val{s} is too many when the function gets
> slammed with invocations every now and again?
>
> returning to some future enum realization, where any enumerand plopped
> into a call generates a partially dispached specialization
>   (an inside-out and rightside-left take on currying), would doing that
> with an 2..12-valued enum be worthwhile for small functions
>   -- functions that do some parrying and then call others for most of the
> work; or is there something about the nature of Julia's
>   compiling process that compilation time reaches through thin functions
> into those that they call?
>
>
> On Saturday, July 11, 2015 at 9:24:43 AM UTC-4, Tim Holy wrote:
>>
>> On Saturday, July 11, 2015 03:01:55 AM Jeffrey Sarnoff wrote:
>> > Val{} is a most helpful facility.
>> > Why are enums not Val{} wrapped internally and that hidden with show,
>> so
>> > enumerated values could be used this way directly?
>>
>> Julia compiles separate versions of functions for separate input types,
>> and
>> Val{1} is a different type than Val{2}. In many cases the overhead of
>> compilation is far worse than the cost of the run-time value-check.
>>
>> You can amuse yourself by seeing how slow things are, and how quickly
>> your
>> machine runs out of memory, by repeatedly calling some method with
>> Val{rand()}
>> :-). Contrast calling a similar method with just rand(), and you'll begin
>> to
>> appreciate the trade-offs here.
>>
>> --Tim
>>
>>

Re: [julia-users] Re: how should I assign load(filepathname, varname_string) to varname given as a string

[Jameson Nash]

A macro can't do this since it is strictly a pure source transform (it
cannot access values or variables). `eval` is essentially an escape hatch
to allow you to do anything, including this, but only in the global scope
(and it's generally not recommended).

it was a design decision in julia not to allow this in local scope. there
are much better ways of solving the problem that don't cause issues for
type inference. I recommend the following solution (in v0.4 syntax):

Dict{AbstractString, Any}( [ name => jld_load(joinpath(path, name*".jld))
for name in list ] )

(not tested, so please forgive any typos)


On Sat, Jul 11, 2015 at 5:26 PM Scott Jones 
wrote:

> Why are you limiting it to an ASCIIString?  variable names in Julia
> frequently have Unicode characters.
>
>
> On Saturday, July 11, 2015 at 4:06:43 PM UTC-4, Jeffrey Sarnoff wrote:
>>
>> I have been trying to loop over variable names available as an
>> ASCIIString vector, using each to generate the corresponding jld datafile
>> path+name and load_ing() the datafile into  its original variable name ..
>> should this be done with string->symbol manipulation and/or is a macro
>> required to effect an applicative assignment operator? I need some guidance
>> on how to do it.
>>
>

[julia-users] Too many packages?

[Burak Budanur]

I heard a lot about Julia language over the last year and last week 
had a conversation with a colleague, who attended Juliacon and was 
quite impressed. We talked about possibly moving some of our fluid 
dynamics projects to Julia, so that for a new student who is joining
the project it would be much easier to start without going through 
learning c++ and/or fortran. 


I am a physicist and most of my day job is some form of scientific 
computing. My current default working environment is python 
(numpy, scipy, sympy, matplotlib) + fortran (f2py) when some part 
of my code needs to speed up. Yesterday I decided to start a a 
new, relatively easy project as a simple example for an upcoming 
paper. So I thought this might be a good occasion to start 
learning Julia language to code a simple dynamical systems toolbox 
in it, which might be useful for other people as well. 


Basic functionality I need from the language are these:


- Symbolic differentiation (for computation of Jacobians)
- Numerical integration of ODEs (a general purpose integrator, such as
lsoda from odepack, wrapped in scipy.integrate.odeint)
- Linear algebra functions
- Interpolation
- Plotting in 2D and 3D


After reading The Julia Express and parts of the documentation, I 
thought that such a project is not a good investment, at least for 
now. The reason is all the functionality I listed above are provided
by external packages, partially excluding linear algebra functions.
I'm aware that I can use specific packages for all the functionality
I mentioned above, but each such package is maintained by different
people, and they can change or become obsolete. I can also find some
Fortran/C code, and include in Julia, and have all these 
functionality, but then what is the advantage of using Julia, as 
opposed to, say, python?


In a more general sense, I am a little bit turned off by the 
presence of an external package for almost every task I need to 
do. I can understand this kind of structure in python as it is a 
general purpose language. But since Julia is a language 
specifically for scientific computation, I'd be happy to have 
something like the basic functionality of MATLAB in the main 
language. 


I understand that Julia is under development and there is a lot to
change and to be added, but I am wondering what is the Julia's future 
directions regarding these issues? I did some search, but could not 
find an answer to this question, so I apologize if this was already 
answered elsewhere. 
I heard a lot about Julia language over the last year and last week 
had a conversation with a colleague, who attended Juliacon and was 
quite impressed. We talked about possibly moving some of our fluid 
dynamics projects to Julia, so that for a new student who is joining
the project it would be much easier to start without going through 
learning c++ and/or fortran. 

I am a physicist and most of my day job is some form of scientific 
computing. My current default working environment is python 
(numpy, scipy, sympy, matplotlib) + fortran (f2py) when some part 
of my code needs to speed up. Yesterday I decided to start a a 
new, relatively easy project as a simple example for an upcoming 
paper. So I thought this might be a good occasion to start 
learning Julia language to code a simple dynamical systems toolbox 
in it, which might be useful for other people as well. 

Basic functionality I need from the language are these:

- Symbolic differentiation (for computation of Jacobians)
- Numerical integration of ODEs (a general purpose integrator, such as
lsoda from odepack, wrapped in scipy.integrate.odeint)
- Linear algebra functions
- Interpolation
- Plotting in 2D and 3D

After reading The Julia Express and parts of the documentation, I 
thought that such a project is not a good investment, at least for 
now. The reason is all the functionality I listed above are provided
by external packages, partially excluding linear algebra functions.
I'm aware that I can use specific packages for all the functionality
I mentioned above, but each such package is maintained by different
people, and they can change or become obsolete. I can also find some
Fortran/C code, and include in Julia, and have all these 
functionality, but then what is the advantage of using Julia, as 
opposed to, say, python?

In a more general sense, I am a little bit turned off by the 
presence of an external package for almost every task I need to 
do. I can understand this kind of structure in python as it is a 
general purpose language. But since Julia is a language 
specifically for scientific computation, I'd be happy to have 
something like the basic functionality of MATLAB in the main 
language. 

I understand that Julia is under development and there is a lot to
change and to be added, but I am wondering what is the Julia's future 
directions regarding these issues? I did some search, but could not 
find an answer to this question, so I apologize if this was already 
answ

[julia-users] Re: Juno LightTable Freezes Using images.jl

['wade' via julia-users]

Will,
How did you solve this?

Thanks,
Wade


On Thursday, April 2, 2015 at 7:49:18 PM UTC-4, will ship wrote:
>
> So have discovered weird behaviour in Juno LightTable (which I have been 
> using without issue for sometime now)..
>
> When using Images.jl package with following code
>
> using Images, Color, FixedPointNumbers, ImageView
>
> img=imread(1.png")
> show(img)
>
> props=properties(img)
> A=data(img)
>
> Julia spins then crashes on trying to assign data(img) to A..
>
> The same exact code works fine in Julia from the command line...
>
> Using LightTable 9.1 and Julia 0.3.1 
>
> Any help greatly appreciated
>
> Cheers Will
>
>

[julia-users] Re: Too many packages?

[John Myles White]

I think most of have the opposite desire: we're trying to move more 
functionality out of the core language and into packages.

 -- John

On Sunday, July 12, 2015 at 3:03:31 AM UTC+2, Burak Budanur wrote:
>
> I heard a lot about Julia language over the last year and last week 
> had a conversation with a colleague, who attended Juliacon and was 
> quite impressed. We talked about possibly moving some of our fluid 
> dynamics projects to Julia, so that for a new student who is joining
> the project it would be much easier to start without going through 
> learning c++ and/or fortran. 
>
>
> I am a physicist and most of my day job is some form of scientific 
> computing. My current default working environment is python 
> (numpy, scipy, sympy, matplotlib) + fortran (f2py) when some part 
> of my code needs to speed up. Yesterday I decided to start a a 
> new, relatively easy project as a simple example for an upcoming 
> paper. So I thought this might be a good occasion to start 
> learning Julia language to code a simple dynamical systems toolbox 
> in it, which might be useful for other people as well. 
>
>
> Basic functionality I need from the language are these:
>
>
> - Symbolic differentiation (for computation of Jacobians)
> - Numerical integration of ODEs (a general purpose integrator, such as
> lsoda from odepack, wrapped in scipy.integrate.odeint)
> - Linear algebra functions
> - Interpolation
> - Plotting in 2D and 3D
>
>
> After reading The Julia Express and parts of the documentation, I 
> thought that such a project is not a good investment, at least for 
> now. The reason is all the functionality I listed above are provided
> by external packages, partially excluding linear algebra functions.
> I'm aware that I can use specific packages for all the functionality
> I mentioned above, but each such package is maintained by different
> people, and they can change or become obsolete. I can also find some
> Fortran/C code, and include in Julia, and have all these 
> functionality, but then what is the advantage of using Julia, as 
> opposed to, say, python?
>
>
> In a more general sense, I am a little bit turned off by the 
> presence of an external package for almost every task I need to 
> do. I can understand this kind of structure in python as it is a 
> general purpose language. But since Julia is a language 
> specifically for scientific computation, I'd be happy to have 
> something like the basic functionality of MATLAB in the main 
> language. 
>
>
> I understand that Julia is under development and there is a lot to
> change and to be added, but I am wondering what is the Julia's future 
> directions regarding these issues? I did some search, but could not 
> find an answer to this question, so I apologize if this was already 
> answered elsewhere. 
> I heard a lot about Julia language over the last year and last week 
> had a conversation with a colleague, who attended Juliacon and was 
> quite impressed. We talked about possibly moving some of our fluid 
> dynamics projects to Julia, so that for a new student who is joining
> the project it would be much easier to start without going through 
> learning c++ and/or fortran. 
>
> I am a physicist and most of my day job is some form of scientific 
> computing. My current default working environment is python 
> (numpy, scipy, sympy, matplotlib) + fortran (f2py) when some part 
> of my code needs to speed up. Yesterday I decided to start a a 
> new, relatively easy project as a simple example for an upcoming 
> paper. So I thought this might be a good occasion to start 
> learning Julia language to code a simple dynamical systems toolbox 
> in it, which might be useful for other people as well. 
>
> Basic functionality I need from the language are these:
>
> - Symbolic differentiation (for computation of Jacobians)
> - Numerical integration of ODEs (a general purpose integrator, such as
> lsoda from odepack, wrapped in scipy.integrate.odeint)
> - Linear algebra functions
> - Interpolation
> - Plotting in 2D and 3D
>
> After reading The Julia Express and parts of the documentation, I 
> thought that such a project is not a good investment, at least for 
> now. The reason is all the functionality I listed above are provided
> by external packages, partially excluding linear algebra functions.
> I'm aware that I can use specific packages for all the functionality
> I mentioned above, but each such package is maintained by different
> people, and they can change or become obsolete. I can also find some
> Fortran/C code, and include in Julia, and have all these 
> functionality, but then what is the advantage of using Julia, as 
> opposed to, say, python?
>
> In a more general sense, I am a little bit turned off by the 
> presence of an external package for almost every task I need to 
> do. I can understand this kind of structure in python as it is a 
> general purpose language. But since Julia is a language 
> specifically for scientific computa

[julia-users] Re: Too many packages?

[Matt Bauman]

One of the most powerful features of Julia is that packages (and user code in 
general) aren't at a major disadvantage to code included in Julia itself. 0.4 
promises to make this even better with precompilation and documentation. 

Many of the folks who have spearheaded the big packages are also contributors 
to Julia itself. And many of the core developers help out with package 
development. So the lines between user, package developer, and Julia developer 
are all a little blurry. Also note that many packages aren't owned by just one 
person - organizations have formed to help ensure packages are well-supported. 

I think the general direction is towards moving more functionality out of base, 
but to also provide a default set of preinstalled packages. That way the core 
language remains small, but the default user experience is rich and featureful.

Re: [julia-users] Re: is there compile-time dispatch on constants from a v0.4 @enum

[Jeffrey Sarnoff]

consider me better informed -- thank you Jameson

On Saturday, July 11, 2015 at 7:56:07 PM UTC-4, Jameson wrote:
>
> i suspect that ideal number is around 2 or 3.
>
> you should make singleton types instead of using the enum macro if you 
> want to dispatch on the result. the enum macro exists for exactly the 
> reason that typically you don't want the the compiler to try to attempt 
> method specialization on values. you may think my estimate sounds low, but 
> remember that there is a potential exponential explosion of type signature 
> combinations, so you want the base numbers to be really small. (e.g 
> f(::Val{<:Bool}) describes 2 methods, f(::Val{<:Bool}, ::Val{<:Bool}, 
> Val{<:Bool}) describes 8 methodes).
>
> the compiler currently is incredibly dumb when it comes to handling lots 
> of relatively unique values that the user decided to call types. instead, 
> it trusts that the user provided only types that provide important 
> descriptive or optimization benefits. since the compile overhead seems to 
> be somewhere around 10_000x the cost of running a function, you should 
> typically opt for the runtime branch.
>
> Val{true} and Val{false} seem like a bad idea to me. This implies a 2x 
> increase in compile time and memory usage across the board, but I suspect 
> it will often run slower than the runtime branch. The runtime performance 
> cost of the code branch should be pretty nearly zero-cost (due to 
> pipelining and branch prediction). But if you ever get to a point in the 
> program where you don't write exactly "Val{true}" for "Val{false}", but 
> instead try to compute this from a function, you are forcing the full cost 
> of a dynamic function lookup (until the compiler gets smarter and turns 
> this into a nest of non-zero cost branch-and-join phi node -- essentially 
> trying to turn `Val{false}` back into `false`). And if you were intending 
> to dispatch differently on `Val{true}` vs. `Val{false}`, it seems much 
> clearer to me to give these methods unique names.
>
> On Sat, Jul 11, 2015 at 10:28 AM Jeffrey Sarnoff  > wrote:
>
>> thanks for the perspective, Tim .. 
>> do we have a feel for how many Val{s} is too many when the function gets 
>> slammed with invocations every now and again?
>>
>> returning to some future enum realization, where any enumerand plopped 
>> into a call generates a partially dispached specialization
>>   (an inside-out and rightside-left take on currying), would doing that 
>> with an 2..12-valued enum be worthwhile for small functions
>>   -- functions that do some parrying and then call others for most of the 
>> work; or is there something about the nature of Julia's
>>   compiling process that compilation time reaches through thin functions 
>> into those that they call?
>>
>>
>> On Saturday, July 11, 2015 at 9:24:43 AM UTC-4, Tim Holy wrote:
>>>
>>> On Saturday, July 11, 2015 03:01:55 AM Jeffrey Sarnoff wrote: 
>>> > Val{} is a most helpful facility. 
>>> > Why are enums not Val{} wrapped internally and that hidden with show, 
>>> so 
>>> > enumerated values could be used this way directly? 
>>>
>>> Julia compiles separate versions of functions for separate input types, 
>>> and 
>>> Val{1} is a different type than Val{2}. In many cases the overhead of 
>>> compilation is far worse than the cost of the run-time value-check. 
>>>
>>> You can amuse yourself by seeing how slow things are, and how quickly 
>>> your 
>>> machine runs out of memory, by repeatedly calling some method with 
>>> Val{rand()} 
>>> :-). Contrast calling a similar method with just rand(), and you'll 
>>> begin to 
>>> appreciate the trade-offs here. 
>>>
>>> --Tim 
>>>
>>>

Re: [julia-users] Re: how should I assign load(filepathname, varname_string) to varname given as a string

[Jeffrey Sarnoff]

ok, I appreciate the clarity

On Saturday, July 11, 2015 at 8:02:01 PM UTC-4, Jameson wrote:
>
> A macro can't do this since it is strictly a pure source transform (it 
> cannot access values or variables). `eval` is essentially an escape hatch 
> to allow you to do anything, including this, but only in the global scope 
> (and it's generally not recommended).
>
> it was a design decision in julia not to allow this in local scope. there 
> are much better ways of solving the problem that don't cause issues for 
> type inference. I recommend the following solution (in v0.4 syntax):
>
> Dict{AbstractString, Any}( [ name => jld_load(joinpath(path, name*".jld)) 
> for name in list ] )
>
> (not tested, so please forgive any typos)
> 
>
> On Sat, Jul 11, 2015 at 5:26 PM Scott Jones  > wrote:
>
>> Why are you limiting it to an ASCIIString?  variable names in Julia 
>> frequently have Unicode characters.
>>
>>
>> On Saturday, July 11, 2015 at 4:06:43 PM UTC-4, Jeffrey Sarnoff wrote:
>>>
>>> I have been trying to loop over variable names available as an 
>>> ASCIIString vector, using each to generate the corresponding jld datafile 
>>> path+name and load_ing() the datafile into  its original variable name .. 
>>> should this be done with string->symbol manipulation and/or is a macro 
>>> required to effect an applicative assignment operator? I need some guidance 
>>> on how to do it. 
>>>
>>

Re: [julia-users] Re: how should I assign load(filepathname, varname_string) to varname given as a string

[Jeffrey Sarnoff]

The decision to use ASCII strings is one that  [image: Homepage] made for 
me.
The task that led to this question is organize and store (as a compressed 
jld) IANA standard timezone names and city names as given therein and to 
automatically reintroduce them as just as they were as internal constants 
for a packaged module when others use that facility.  I can hardcode them 
into a subfile, and probably will.  I have to do much the same thing with 
many preprocessed numerical vectors, and those must live in compressed jld 
files because, most of the time almost all of it will not be used (and it 
is inappropriate to precensor the coverage).


On Saturday, July 11, 2015 at 11:26:26 PM UTC-4, Jeffrey Sarnoff wrote:
>
> ok, I appreciate the clarity
>
> On Saturday, July 11, 2015 at 8:02:01 PM UTC-4, Jameson wrote:
>>
>> A macro can't do this since it is strictly a pure source transform (it 
>> cannot access values or variables). `eval` is essentially an escape hatch 
>> to allow you to do anything, including this, but only in the global scope 
>> (and it's generally not recommended).
>>
>> it was a design decision in julia not to allow this in local scope. there 
>> are much better ways of solving the problem that don't cause issues for 
>> type inference. I recommend the following solution (in v0.4 syntax):
>>
>> Dict{AbstractString, Any}( [ name => jld_load(joinpath(path, name*".jld)) 
>> for name in list ] )
>>
>> (not tested, so please forgive any typos)
>> 
>>
>> On Sat, Jul 11, 2015 at 5:26 PM Scott Jones  
>> wrote:
>>
>>> Why are you limiting it to an ASCIIString?  variable names in Julia 
>>> frequently have Unicode characters.
>>>
>>>
>>> On Saturday, July 11, 2015 at 4:06:43 PM UTC-4, Jeffrey Sarnoff wrote:

 I have been trying to loop over variable names available as an 
 ASCIIString vector, using each to generate the corresponding jld datafile 
 path+name and load_ing() the datafile into  its original variable name .. 
 should this be done with string->symbol manipulation and/or is a macro 
 required to effect an applicative assignment operator? I need some 
 guidance 
 on how to do it. 

>>>

Re: [julia-users] Re: how should I assign load(filepathname, varname_string) to varname given as a string

[Jeffrey Sarnoff]

Jameson, in v0.4 is it best not to care about adding a layer of 
consolidation that is purely artifact --  If so, well ok and yuk.

Some of these named variables are better presented as Dicts of subDicts as 
 that well reflects intrinsic intension. 
Other of these named variables are more as rooms in a house, they have 
proximity in common without commonality of purpose.

Is there a way of doing as you suggest without forcing externally 
accessible data vectors to intradict?


On Saturday, July 11, 2015 at 8:02:01 PM UTC-4, Jameson wrote:
>
> A macro can't do this since it is strictly a pure source transform (it 
> cannot access values or variables). `eval` is essentially an escape hatch 
> to allow you to do anything, including this, but only in the global scope 
> (and it's generally not recommended).
>
> it was a design decision in julia not to allow this in local scope. there 
> are much better ways of solving the problem that don't cause issues for 
> type inference. I recommend the following solution (in v0.4 syntax):
>
> Dict{AbstractString, Any}( [ name => jld_load(joinpath(path, name*".jld)) 
> for name in list ] )
>
> (not tested, so please forgive any typos)
> 
>
> On Sat, Jul 11, 2015 at 5:26 PM Scott Jones  > wrote:
>
>> Why are you limiting it to an ASCIIString?  variable names in Julia 
>> frequently have Unicode characters.
>>
>>
>> On Saturday, July 11, 2015 at 4:06:43 PM UTC-4, Jeffrey Sarnoff wrote:
>>>
>>> I have been trying to loop over variable names available as an 
>>> ASCIIString vector, using each to generate the corresponding jld datafile 
>>> path+name and load_ing() the datafile into  its original variable name .. 
>>> should this be done with string->symbol manipulation and/or is a macro 
>>> required to effect an applicative assignment operator? I need some guidance 
>>> on how to do it. 
>>>
>>