Re: [julia-users] Help creating an IDL wrapper using Clang.jl

[Luke Stagner]

You have no idea how happy this make me. 

I was able to get it running fairly quickly on linux. This is what I did

```
shell> export JL_IDL_TYPE=CALLABLE

julia> push!(Libdl.DL_LOAD_PATH, "/path/to/idl/idl84/bin/bin.linux.x86_64")
1-element Array{String,1}:
 "/path/to/idl/idl84/bin/bin.linux.x86_64"

julia> import IDLCall; idl = IDLCall
IDL Version 8.4 (linux x86_64 m64). (c) 2014, Exelis Visual Information 
Solutions, Inc.
Installation number: 284-1-.
Licensed for use by: Company I work for

IDLCall

julia> x = rand(3)
3-element Array{Float64,1}:
 0.227855
 0.209709
 0.260878

julia> idl.put_var(x,"x")

julia> idl.execute("print,x")
  0.22785452  0.20970923  0.26087754

IDL> print,x
  0.22785452  0.20970923  0.26087754

IDL> x=indgen(10)

IDL> plot,x,x
```

Generally the library directory will always be in the same directory as the 
IDL executable.

-Luke

On Wednesday, September 21, 2016 at 9:34:49 PM UTC-7, Bob Nnamtrop wrote:
>
> Yes, sorry for the delay, I have uploaded some code to github. See: 
> https://github.com/BobPortmann/IDLCall.jl.git. I have added some notes 
> there to get you started. No doubt they are too short and you may have to 
> look into the code to get things working. I do want to polish this up, so 
> please provide feedback here or preferably on a github issue. The code 
> should work on julia 0.4 or 0.5. I have only tested using IDL 8.5 on OSX.
>
> Bob
>
> On Wed, Sep 21, 2016 at 3:23 AM, Luke Stagner <lstag...@gmail.com 
> > wrote:
>
>> Are you still planning on releasing your IDL wrapper? I would still very 
>> much like to use it.
>>
>> -Luke
>>
>> On Friday, August 5, 2016 at 10:19:16 AM UTC-7, Bob Nnamtrop wrote:
>>>
>>> I have written a (pretty) complete wrapper for IDL (years ago actually), 
>>> but have not uploaded to github. I'll try to do that this weekend (and put 
>>> an update here). I wrote it for my own use and have been waiting for Julia 
>>> to mature to promote it to the IDL community. I originally wrote it for 
>>> Callable IDL and later switched to IDL RPC because of some library 
>>> conflicts I ran into using Callable IDL. It should not be hard to make the 
>>> Callable part work again. Of course, if you are on windows only Callable 
>>> IDL is supported by IDL, unfortunately. I have also implemented a REPL 
>>> interface to IDL from julia, which is really nice in practice. I originally 
>>> implemented the REPL in Julia 0.3 which was rather difficult, but it is 
>>> easy in 0.4. Note also that my package does not use Clang.jl but instead 
>>> hand written wrappers. This is no problem for IDL since the c interface to 
>>> IDL is very limited (basically you can pass in variables and call IDL 
>>> commands from strings; that is about it). It would be awesome if IDL would 
>>> expose more of the c interface like they did in the python library they 
>>> provide in recent versions. Maybe if julia picks up traction they will do 
>>> this.
>>>
>>> Bob
>>>
>>> On Thu, Aug 4, 2016 at 12:14 PM, Luke Stagner <lstag...@gmail.com> 
>>> wrote:
>>>
>>>> Its possible to call IDL from C code (Callable IDL) 
>>>> <http://www.harrisgeospatial.com/docs/callableidl.html> so I figured I 
>>>> could do the same from Julia.
>>>>
>>>> I have been trying to use Clang.jl to automatically create the wrapper 
>>>> but I am running into some issues. 
>>>>
>>>> This project is a bit above my level of expertise and I would 
>>>> appreciate any help
>>>>
>>>> My current progress can be found at 
>>>> https://github.com/lstagner/JulianInsurgence
>>>>
>>>> and the output from my wrapper attempt (wrap_idl.jl 
>>>> <https://github.com/lstagner/JulianInsurgence/blob/master/wrap_idl.jl>) 
>>>>  is located here 
>>>> <https://github.com/lstagner/JulianInsurgence/blob/master/output.txt>
>>>>
>>>> I am using current Clang.jl master and Julia
>>>> julia> versioninfo()
>>>> Julia Version 0.5.0-rc0+193
>>>> Commit ff1b65c* (2016-08-04 04:14 UTC)
>>>> Platform Info:
>>>>   System: Linux (x86_64-unknown-linux-gnu)
>>>>   CPU: Intel(R) Xeon(R) CPU E5-2680 v3 @ 2.50GHz
>>>>   WORD_SIZE: 64
>>>>   BLAS: libmkl_rt
>>>>   LAPACK: libmkl_rt
>>>>   LIBM: libopenlibm
>>>>   LLVM: libLLVM-3.7.1 (ORCJIT, haswell)
>>>>
>>>>
>>>>
>>>>
>>>
>

Re: [julia-users] Does Julia 0.5 leak memory?

[Luke Stagner]

In trying to create a reduced test case I figured out the source of my 
memory leak. It wasn't caused by Julia but by an external library I was 
calling (Sundials.jl). Pulling the dev version of Sundials.jl fixed the 
issue for me. 

K Leo, if you are using any external library, that may be the cause of the 
memory leak you are seeing.

-Luke

On Wednesday, September 21, 2016 at 5:52:23 PM UTC-7, Yichao Yu wrote:
>
> On Wed, Sep 21, 2016 at 8:50 PM, Yichao Yu <yyc...@gmail.com > 
> wrote: 
> > On Mon, Sep 19, 2016 at 9:14 PM, Luke Stagner <lstag...@gmail.com 
> > wrote: 
> >> I actually ran into this issue too. I have a routine that calculates 
> fast 
> >> ion orbits that uses a lot of memory (90%). Here is the code (sorry its 
> not 
> >> very clean).  I tried to run the function `make_distribution_file` in a 
> loop 
> >> in julia but it never released the memory between calls. I tried 
> inserting 
> >> `gc()` manually but that didn't do anything either. 
> > 
> > I don't have time currently but I'll try to reproduce it in a few days. 
> > What's your versioninfo() and how did you install julia? 
>
> In the mean time, I would also appreciate if you can reduce it a 
> little, especially if you can remove some of the external 
> dependencies. 
>
> > 
> >> 
> >> -Luke 
> >> 
> >> 
> >> On Monday, September 19, 2016 at 3:08:52 PM UTC-7, K leo wrote: 
> >>> 
> >>> The only package used (at the global level) is DataFrames.  Does that 
> not 
> >>> release memory? 
> >>> 
> >>> On Tuesday, September 20, 2016 at 6:05:58 AM UTC+8, K leo wrote: 
> >>>> 
> >>>> No.  After myfunction() finished and I am at the REPL prompt, top 
> shows 
> >>>> Julia taking 49%.  And after I did gc(), it shows Julia taking 48%. 
> >>>> 
> >>>> On Tuesday, September 20, 2016 at 4:05:56 AM UTC+8, Randy Zwitch 
> wrote: 
> >>>>> 
> >>>>> Does the problem go away if you run gc()? 
> >>>>> 
> >>>>> 
> >>>>> 
> >>>>> On Monday, September 19, 2016 at 3:55:14 PM UTC-4, K leo wrote: 
> >>>>>> 
> >>>>>> Thanks for the suggestion about valgrind. 
> >>>>>> 
> >>>>>> Can someone please let me first understand the expected behaviour 
> for 
> >>>>>> memory usage. 
> >>>>>> 
> >>>>>> Let's say when I first starts Julia REPL it takes 5% of RAM 
> (according 
> >>>>>> to top).  Then I include "myfile.jl" and run myfunction().  During 
> the 
> >>>>>> execution of myfunction(), memory allocation of Julia reaches 40% 
> of RAM 
> >>>>>> (again according to top).  Say running myfunction() involves no 
> allocation 
> >>>>>> of global objects - all object used are local.  Then when 
> myfunction() 
> >>>>>> finished and I am at the REPL prompt, should top show the memory 
> usage of 
> >>>>>> Julia drops down to the previous level (5% of RAM)?  My current 
> observation 
> >>>>>> is that it doesn't.  Is this the expected behaviour? 
> >>>>>> 
> >> 
>

[julia-users] Re: Does Julia 0.5 leak memory?

[Luke Stagner]

I just tried my code again using the 0.5 release and the memory is still 
not releasing. I thought maybe it was caused by using HDF5 but even if i 
commented out that bit of the code it still doesn't free up the memory.

-Luke

On Wednesday, September 21, 2016 at 6:53:07 AM UTC-7, Páll Haraldsson wrote:
>
> On Sunday, September 18, 2016 at 12:53:19 PM UTC, K leo wrote:
>
>> Any thoughts on what might be the culprit?
>>
>>   | | |_| | | | (_| |  |  Version 0.5.0-rc4+0 (2016-09-09 01:43 UTC)
>>  _/ |\__'_|_|_|\__'_|  |  Official http://julialang.org/ release
>>
>
> You say 0.5 in the title (when 0.5 wasn't out). Your later posts are after 
> 0.5 is out. Maybe it doesn't matter, I don't know, maybe the final version 
> is identical (except for versioninfo function..), I just do not know that 
> for a fact, so might as well upgrade just in case.
>
> -- 
> Palli.
>
>
>
>

Re: [julia-users] Help creating an IDL wrapper using Clang.jl

[Luke Stagner]

Are you still planning on releasing your IDL wrapper? I would still very 
much like to use it.

-Luke

On Friday, August 5, 2016 at 10:19:16 AM UTC-7, Bob Nnamtrop wrote:
>
> I have written a (pretty) complete wrapper for IDL (years ago actually), 
> but have not uploaded to github. I'll try to do that this weekend (and put 
> an update here). I wrote it for my own use and have been waiting for Julia 
> to mature to promote it to the IDL community. I originally wrote it for 
> Callable IDL and later switched to IDL RPC because of some library 
> conflicts I ran into using Callable IDL. It should not be hard to make the 
> Callable part work again. Of course, if you are on windows only Callable 
> IDL is supported by IDL, unfortunately. I have also implemented a REPL 
> interface to IDL from julia, which is really nice in practice. I originally 
> implemented the REPL in Julia 0.3 which was rather difficult, but it is 
> easy in 0.4. Note also that my package does not use Clang.jl but instead 
> hand written wrappers. This is no problem for IDL since the c interface to 
> IDL is very limited (basically you can pass in variables and call IDL 
> commands from strings; that is about it). It would be awesome if IDL would 
> expose more of the c interface like they did in the python library they 
> provide in recent versions. Maybe if julia picks up traction they will do 
> this.
>
> Bob
>
> On Thu, Aug 4, 2016 at 12:14 PM, Luke Stagner <lstag...@gmail.com 
> > wrote:
>
>> Its possible to call IDL from C code (Callable IDL) 
>> <http://www.harrisgeospatial.com/docs/callableidl.html> so I figured I 
>> could do the same from Julia.
>>
>> I have been trying to use Clang.jl to automatically create the wrapper 
>> but I am running into some issues. 
>>
>> This project is a bit above my level of expertise and I would appreciate 
>> any help
>>
>> My current progress can be found at 
>> https://github.com/lstagner/JulianInsurgence
>>
>> and the output from my wrapper attempt (wrap_idl.jl 
>> <https://github.com/lstagner/JulianInsurgence/blob/master/wrap_idl.jl>) 
>>  is located here 
>> <https://github.com/lstagner/JulianInsurgence/blob/master/output.txt>
>>
>> I am using current Clang.jl master and Julia
>> julia> versioninfo()
>> Julia Version 0.5.0-rc0+193
>> Commit ff1b65c* (2016-08-04 04:14 UTC)
>> Platform Info:
>>   System: Linux (x86_64-unknown-linux-gnu)
>>   CPU: Intel(R) Xeon(R) CPU E5-2680 v3 @ 2.50GHz
>>   WORD_SIZE: 64
>>   BLAS: libmkl_rt
>>   LAPACK: libmkl_rt
>>   LIBM: libopenlibm
>>   LLVM: libLLVM-3.7.1 (ORCJIT, haswell)
>>
>>
>>
>>
>

Re: [julia-users] Does Julia 0.5 leak memory?

[Luke Stagner]

I actually ran into this issue too. I have a routine that calculates fast 
ion orbits that uses a lot of memory (90%). Here is the code 
 (sorry 
its not very clean).  I tried to run the function `make_distribution_file` 
in a loop in julia but it never released the memory between calls. I tried 
inserting `gc()` manually but that didn't do anything either.

-Luke 

On Monday, September 19, 2016 at 3:08:52 PM UTC-7, K leo wrote:
>
> The only package used (at the global level) is DataFrames.  Does that not 
> release memory?
>
> On Tuesday, September 20, 2016 at 6:05:58 AM UTC+8, K leo wrote:
>>
>> No.  After myfunction() finished and I am at the REPL prompt, top shows 
>> Julia taking 49%.  And after I did gc(), it shows Julia taking 48%. 
>>
>> On Tuesday, September 20, 2016 at 4:05:56 AM UTC+8, Randy Zwitch wrote:
>>>
>>> Does the problem go away if you run gc()?
>>>
>>>
>>>
>>> On Monday, September 19, 2016 at 3:55:14 PM UTC-4, K leo wrote:

 Thanks for the suggestion about valgrind.

 Can someone please let me first understand the expected behaviour for 
 memory usage.

 Let's say when I first starts Julia REPL it takes 5% of RAM (according 
 to top).  Then I include "myfile.jl" and run myfunction().  During the 
 execution of myfunction(), memory allocation of Julia reaches 40% of RAM 
 (again according to top).  Say running myfunction() involves no allocation 
 of global objects - all object used are local.  Then when myfunction() 
 finished and I am at the REPL prompt, should top show the memory usage of 
 Julia drops down to the previous level (5% of RAM)?  My current 
 observation 
 is that it doesn't.  Is this the expected behaviour?

Re: [julia-users] Help creating an IDL wrapper using Clang.jl

[Luke Stagner]

This is awesome. I would love to take a look at what you did and how you 
did it. Once 0.5 is released I think Julia would be in a mature enough 
state to promote it to the IDL community. Unless I am mistaken I do not 
think there are many major breaking changes that are planned.

-Luke
 
On Friday, August 5, 2016 at 10:19:16 AM UTC-7, Bob Nnamtrop wrote:
>
> I have written a (pretty) complete wrapper for IDL (years ago actually), 
> but have not uploaded to github. I'll try to do that this weekend (and put 
> an update here). I wrote it for my own use and have been waiting for Julia 
> to mature to promote it to the IDL community. I originally wrote it for 
> Callable IDL and later switched to IDL RPC because of some library 
> conflicts I ran into using Callable IDL. It should not be hard to make the 
> Callable part work again. Of course, if you are on windows only Callable 
> IDL is supported by IDL, unfortunately. I have also implemented a REPL 
> interface to IDL from julia, which is really nice in practice. I originally 
> implemented the REPL in Julia 0.3 which was rather difficult, but it is 
> easy in 0.4. Note also that my package does not use Clang.jl but instead 
> hand written wrappers. This is no problem for IDL since the c interface to 
> IDL is very limited (basically you can pass in variables and call IDL 
> commands from strings; that is about it). It would be awesome if IDL would 
> expose more of the c interface like they did in the python library they 
> provide in recent versions. Maybe if julia picks up traction they will do 
> this.
>
> Bob
>
> On Thu, Aug 4, 2016 at 12:14 PM, Luke Stagner <lstag...@gmail.com 
> > wrote:
>
>> Its possible to call IDL from C code (Callable IDL) 
>> <http://www.harrisgeospatial.com/docs/callableidl.html> so I figured I 
>> could do the same from Julia.
>>
>> I have been trying to use Clang.jl to automatically create the wrapper 
>> but I am running into some issues. 
>>
>> This project is a bit above my level of expertise and I would appreciate 
>> any help
>>
>> My current progress can be found at 
>> https://github.com/lstagner/JulianInsurgence
>>
>> and the output from my wrapper attempt (wrap_idl.jl 
>> <https://github.com/lstagner/JulianInsurgence/blob/master/wrap_idl.jl>) 
>>  is located here 
>> <https://github.com/lstagner/JulianInsurgence/blob/master/output.txt>
>>
>> I am using current Clang.jl master and Julia
>> julia> versioninfo()
>> Julia Version 0.5.0-rc0+193
>> Commit ff1b65c* (2016-08-04 04:14 UTC)
>> Platform Info:
>>   System: Linux (x86_64-unknown-linux-gnu)
>>   CPU: Intel(R) Xeon(R) CPU E5-2680 v3 @ 2.50GHz
>>   WORD_SIZE: 64
>>   BLAS: libmkl_rt
>>   LAPACK: libmkl_rt
>>   LIBM: libopenlibm
>>   LLVM: libLLVM-3.7.1 (ORCJIT, haswell)
>>
>>
>>
>>
>

[julia-users] Help creating an IDL wrapper using Clang.jl

[Luke Stagner]

Its possible to call IDL from C code (Callable IDL) 
 so I figured I 
could do the same from Julia.

I have been trying to use Clang.jl to automatically create the wrapper but 
I am running into some issues. 

This project is a bit above my level of expertise and I would appreciate 
any help

My current progress can be found at 
https://github.com/lstagner/JulianInsurgence

and the output from my wrapper attempt (wrap_idl.jl 
)  is 
located here 


I am using current Clang.jl master and Julia
julia> versioninfo()
Julia Version 0.5.0-rc0+193
Commit ff1b65c* (2016-08-04 04:14 UTC)
Platform Info:
  System: Linux (x86_64-unknown-linux-gnu)
  CPU: Intel(R) Xeon(R) CPU E5-2680 v3 @ 2.50GHz
  WORD_SIZE: 64
  BLAS: libmkl_rt
  LAPACK: libmkl_rt
  LIBM: libopenlibm
  LLVM: libLLVM-3.7.1 (ORCJIT, haswell)

[julia-users] Re: Tail indexing

[Luke Stagner]

Ah so thats what its called. Thanks for the links. I do hope that gets into 
Base.


On Tuesday, March 22, 2016 at 5:19:36 AM UTC-7, mschauer wrote:
>
>
> Hello,
> there is relevant discussion and a sketch how to implement something like 
> this at
>
> http://stackoverflow.com/questions/30159815/is-there-a-julia-equivalent-to-numpys-ellipsis-slicing-syntax/30163887#30163887
> and
> https://github.com/JuliaLang/julia/issues/5405
>
>
> Am Dienstag, 22. März 2016 13:10:56 UTC+1 schrieb Luke Stagner:
>>
>> Hello,
>>
>> I've recently come across a situation where I needed to index an array 
>> a[:,:,i,j]
>>
>> without having to know how many colons I needed.
>>
>> I accomplished this with the following code.
>> function recursive_slicedim(A,dims,inds)
>> d_len = length(dims)
>> s = slicedim(A,dims[d_len],inds[d_len])
>> if d_len != 1
>> return recursive_slicedim(s,dims[1:d_len-1],inds[1:d_len-1])
>> else
>> return s
>> end
>> end
>>
>> function tail_index(A,inds)
>> s_len = length(size(A))
>> i_len = length(inds)
>> dims = tuple([s_len - i for i=i_len-1:-1:0]...)
>>
>> return squeeze(recursive_slicedim(A,dims,inds),dims)
>> end
>>
>> a = rand(2,2,2,2)
>> tail_index(a,(1,2)) == a[:,:,1,2]
>>
>> b = rand(2,2,2)
>> tail_index(b,(1,2)) == b[:,1,2]
>>
>> Does something like this already exist in Base? 
>> How would I go about writing some syntactic sugar for this function?
>> Something like 
>> a[*,1,2] == last_index(a,(1,2))
>>
>>
>>
>>

[julia-users] Tail indexing

[Luke Stagner]

Hello,

I've recently come across a situation where I needed to index an array 
a[:,:,i,j]

without having to know how many colons I needed.

I accomplished this with the following code.
function recursive_slicedim(A,dims,inds)
d_len = length(dims)
s = slicedim(A,dims[d_len],inds[d_len])
if d_len != 1
return recursive_slicedim(s,dims[1:d_len-1],inds[1:d_len-1])
else
return s
end
end

function tail_index(A,inds)
s_len = length(size(A))
i_len = length(inds)
dims = tuple([s_len - i for i=i_len-1:-1:0]...)

return squeeze(recursive_slicedim(A,dims,inds),dims)
end

a = rand(2,2,2,2)
tail_index(a,(1,2)) == a[:,:,1,2]

b = rand(2,2,2)
tail_index(b,(1,2)) == b[:,1,2]

Does something like this already exist in Base? 
How would I go about writing some syntactic sugar for this function?
Something like 
a[*,1,2] == last_index(a,(1,2))

Re: [julia-users] Re: error: haskey of NULL PyObject ?

[Luke Stagner]

It will only work if you installed from source(I.e cloned the main Julia
repository and manually compiled). If you did that the directory would
usually be in your home directory.
On Nov 4, 2015 2:10 PM, <le...@neilson-levin.org> wrote:

> I have setup PyCall using a system Python (2.7.10).  I get ERROR:
> ArgumentError: haskey of NULL PyObject
>  in plot at C:\Users\Lewis\.julia\v0.4\PyPlot\src\PyPlot.jl:457
>
> Matplotlib works fine in IPython.
>
> I'm stuck.  Which directory needs git clean?
>
> On Wednesday, November 4, 2015 at 2:03:32 PM UTC-8, Luke Stagner wrote:
>>
>> I noticed it happened after I updated anaconda. Perhaps something went
>> wrong there
>>
>>
>> On 11/04/2015 02:01 PM, le...@neilson-levin.org wrote:
>>
>> I have the same problem.  I am going back to using a system Python and
>> giving up on conda.  Works fine on Mac (par for the course that things tend
>> to work on Mac).  I previously had Julia using matplotlib using WinPython.
>> Wanted to try the conda approach.  Too many problems, though.  Hours later
>> after uninstalling .julia and uninstalling Julia itself and starting over
>> still can't get it to build and run.
>>
>> On Tuesday, November 3, 2015 at 5:16:45 AM UTC-8, jda wrote:
>>>
>>> Nope, still the same haskey of NULL error.
>>>
>>
>>

Re: [julia-users] Re: error: haskey of NULL PyObject ?

[Luke Stagner]

I recently had a similar error. To fix it I had to do 
git clean -xdf

in the julia repository if you installed from source

I found the fix in this PyCall issue 
https://github.com/stevengj/PyCall.jl/issues/65


On Wednesday, November 4, 2015 at 11:58:53 AM UTC-8, Tom Breloff wrote:
>
> You probably have a corrupted cache from whatever you were manually 
> changing.  I recommend just deleting your "~/.julia/v0.4" and starting 
> again.  I just did this on my windows machine (just to make sure it's not a 
> Plots issue) and after doing only "Pkg.add("Plots"); using Plots" it 
> completes without error.
>
> I don't think you necessarily need to be on master for PyCall/PyPlot.  
> After starting fresh, try just `Pkg.add("PyCall"); Pkg.add("PyPlot")` and 
> see if that works for you.
>
> On Wed, Nov 4, 2015 at 2:34 PM, jda  
> wrote:
>
>> I did Pkg.checkout("PyCall"); Pkg.build("PyCall") and PyCall is now 
>> version 1.1.2 master.  The using Plots command still gives the error:
>>
>>   
>> ERROR:  ArgumentError:  Docile not found in path
>>   in require at loading.jl:233
>>   in stale_cachefile at loading.jl:439
>>   in recompile_stale at loading.jl:457
>>   in _require_from_serialized at loading.jl:83
>>   in _require_from_serialized at loading.jl:109
>>   in require at loading.jl:219
>>
>>
>

Re: [julia-users] Re: error: haskey of NULL PyObject ?

[Luke Stagner]

I noticed it happened after I updated anaconda. Perhaps something went 
wrong there



On 11/04/2015 02:01 PM, le...@neilson-levin.org wrote:
I have the same problem.  I am going back to using a system Python and 
giving up on conda.  Works fine on Mac (par for the course that things 
tend to work on Mac).  I previously had Julia using matplotlib using 
WinPython.  Wanted to try the conda approach.  Too many problems, 
though.  Hours later after uninstalling .julia and uninstalling Julia 
itself and starting over still can't get it to build and run.


On Tuesday, November 3, 2015 at 5:16:45 AM UTC-8, jda wrote:

Nope, still the same haskey of NULL error.

Re: [julia-users] Nicer syntax collect(linspace(0,1,n))?

[Luke Stagner]

Sorry to dredge up this issue again but was there any reason for the return 
type of linspace to be LinSpace instead of FloatRange. They are seemingly 
indistinguishable.


On Friday, October 9, 2015 at 3:31:31 AM UTC-7, Stefan Karpinski wrote:
>
> It's amazing how often the problem is the way something is printed.
>
> On Fri, Oct 9, 2015 at 8:26 AM, Art Kuo  
> wrote:
>
>> Oh, clearly I did not understand show(). I've ported the changes to 
>> writemime instead, and as a bonus figured out how to automatically format 
>> for screen width (using Base.print_matrix_row).
>>
>> Just to recap: There is little or no problem with linspace or range being 
>> an object rather than array as far as execution goes. The only issue seems 
>> to be "unexpected" output at the REPL, where a user probably just wants to 
>> check what the range looks like, not its definition. Solution is to alter 
>> the REPL display to do that and provide the type information so the user 
>> doesn't think it's an array. The original show() behavior is retained, you 
>> can also dump() to see details of the range. I plan to submit a pull 
>> request.
>>
>> On Wednesday, October 7, 2015 at 10:55:05 PM UTC-4, Steven G. Johnson 
>> wrote:
>>>
>>> Note, however, that this "display" output should probably be a method of 
>>> writemime(io::IO, ::MIME"text/plain", x).  The show(io, x) for ranges 
>>> should continue to be the compact output.
>>>
>>
>

Re: [julia-users] Nicer syntax collect(linspace(0,1,n))?

[Luke Stagner]

My main objection is that changing the behaviour of linspace is superfluous 
considering linrange already existed. If the goal was to encourage users to 
use a range instead of an array that should of been done through 
documentation through something like a best practices section (e.g. Use 
linrange instead of linspace).  


On Wednesday, September 30, 2015 at 12:27:02 PM UTC-7, Matt Bauman wrote:
>
> There can be reasons where a special read-only `Ones` array type is 
> beneficial: http://stackoverflow.com/a/30968709/176071.  It's just five 
> lines of code, and Julia/LLVM is able to optimize it such that 
> multiplication is totally elided.  It's pretty cool.  But as others said, 
> these functions are fairly well entrenched in creating mutable arrays.  The 
> output from linspace, however, isn't typically mutated.
>
> Back to linspace, I'm still curious to hear more reasons for the strong 
> dislike.  Is it because of how it behaves?  Or how it performs?  Or how 
> it's displayed (which is also valid)?
>

[julia-users] Re: Will Julia likely ever allow negative indexing of arrays

[Luke Stagner]

Nice to see more plasma physicists using Julia. 

a=0.0
>
You could just do 
a[:] = 0.0

to set all the elements to zero or you could do 
a=zeros(n)

In regards to the negative indexing I think that while negative indexing 
may not be a part of base you should be able to replicate the effect with a 
package e.g. https://github.com/simonster/TwoBasedIndexing.jl

[julia-users] Re: Nicer syntax collect(linspace(0,1,n))?

[Luke Stagner]

I'm not sure what version of Julia you are using but in Julia 0.3.9 x = 
linspace(0,1,N) does return a linearly spaced N-element array of floats 
from 0-1 



On Tuesday, September 29, 2015 at 3:44:43 PM UTC-7, feza wrote:
>
> In matlab  x = linspace(0,1,n)  creates a vector of floats of length n. In 
> julia it seems like the only way to do this is to use x = collect( 
> linspace(0,1,n) ) . Is there a nicer syntax? I do mainly numeric computing 
> and I find this quite common in my code.
>
> Thanks.
>

Re: [julia-users] Nicer syntax collect(linspace(0,1,n))?

[Luke Stagner]

Personally I don't like the behaviour. (Perhaps I am just too used to 
numpy/matlab convention). Also we already had linrange (although curiously 
not logrange) if we wanted to use a range.


On Tuesday, September 29, 2015 at 5:59:52 PM UTC-7, Stefan Karpinski wrote:
>
> I'm curious why you need a vector rather than an object. Do you mutate it 
> after creating it? Having linspace return an object instead of a vector was 
> a bit of a unclear judgement call so getting feedback would be good.
>
> On Tuesday, September 29, 2015, Patrick Kofod Mogensen <
> patrick@gmail.com > wrote:
>
>> No:
>>
>> julia> logspace(0,3,5)
>> 5-element Array{Float64,1}:
>> 1.0
>> 5.62341
>>31.6228 
>>   177.828  
>>  1000.0   
>>
>> On Tuesday, September 29, 2015 at 8:50:47 PM UTC-4, Luke Stagner wrote:
>>>
>>> Thats interesting. Does logspace also return a range?
>>>
>>> On Tuesday, September 29, 2015 at 5:43:28 PM UTC-7, Chris wrote:
>>>>
>>>> In 0.4 the linspace function returns a range object, and you need to 
>>>> use collect() to expand it. I'm also interested in nicer syntax.
>>>
>>>

Re: [julia-users] Nicer syntax collect(linspace(0,1,n))?

[Luke Stagner]

A range should act (for the most part) exactly like an array. For example 
indexing into a range is identical (syntax-wise) to indexing an array. What 
I am concerned about is performance. For instance if I had a range that has 
a large amount of elements would indexing into it be slower then indexing 
into an array? Wouldn't the range have to compute the value every single 
time instead of just doing a memory lookup? Or is the calculation of 
elements trivial and the memory savings make up for it?

Performance questions aside, having linspace return a range instead of an 
array just feels like a change for changes sake. I don't see a good reason 
for displacing the behaviour of linspace for a behaviour that already 
realized in linrange. 

-Luke 

On Tuesday, September 29, 2015 at 6:13:37 PM UTC-7, Chris wrote:
>
> For me, I think I just expect a vector from experience, and I could 
> probably just change the way I work with a little effort.
>
> One exception (I think) is that I often do numerical integration over a 
> range of values, and I need the results at every value. I'm not sure if 
> there's a way to do that with range objects only.
>
> On Tue, Sep 29, 2015, 20:59 Stefan Karpinski <ste...@karpinski.org 
> > wrote:
>
>> I'm curious why you need a vector rather than an object. Do you mutate it 
>> after creating it? Having linspace return an object instead of a vector was 
>> a bit of a unclear judgement call so getting feedback would be good.
>>
>> On Tuesday, September 29, 2015, Patrick Kofod Mogensen <
>> patrick@gmail.com > wrote:
>>
>>> No:
>>>
>>> julia> logspace(0,3,5)
>>> 5-element Array{Float64,1}:
>>> 1.0
>>> 5.62341
>>>31.6228 
>>>   177.828  
>>>  1000.0   
>>>
>>> On Tuesday, September 29, 2015 at 8:50:47 PM UTC-4, Luke Stagner wrote:
>>>>
>>>> Thats interesting. Does logspace also return a range?
>>>>
>>>> On Tuesday, September 29, 2015 at 5:43:28 PM UTC-7, Chris wrote:
>>>>>
>>>>> In 0.4 the linspace function returns a range object, and you need to 
>>>>> use collect() to expand it. I'm also interested in nicer syntax.
>>>>
>>>>

Re: [julia-users] Nicer syntax collect(linspace(0,1,n))?

[Luke Stagner]

A range should act (for the most part) exactly like an array. For example 
indexing into a range is identical (syntax-wise) to indexing an array. What 
I am concerned about is performance. For instance if I had a range that has 
a large amount of elements would indexing into it be slower then indexing 
into an array? Wouldn't the range have to compute the value every single 
time instead of just doing a memory lookup? Or is the calculation of 
elements trivial and the memory savings make up for it?

Performance questions aside, having linspace return a range instead of an 
array just feels like a change for changes sake. I don't see a good reason 
for displacing the behaviour of linspace for a behaviour that already 
realized in linrange. 

-Luke 

On Tuesday, September 29, 2015 at 6:13:37 PM UTC-7, Chris wrote:
>
> For me, I think I just expect a vector from experience, and I could 
> probably just change the way I work with a little effort.
>
> One exception (I think) is that I often do numerical integration over a 
> range of values, and I need the results at every value. I'm not sure if 
> there's a way to do that with range objects only.
>
> On Tue, Sep 29, 2015, 20:59 Stefan Karpinski <ste...@karpinski.org 
> > wrote:
>
>> I'm curious why you need a vector rather than an object. Do you mutate it 
>> after creating it? Having linspace return an object instead of a vector was 
>> a bit of a unclear judgement call so getting feedback would be good.
>>
>> On Tuesday, September 29, 2015, Patrick Kofod Mogensen <
>> patrick@gmail.com > wrote:
>>
>>> No:
>>>
>>> julia> logspace(0,3,5)
>>> 5-element Array{Float64,1}:
>>> 1.0
>>> 5.62341
>>>31.6228 
>>>   177.828  
>>>  1000.0   
>>>
>>> On Tuesday, September 29, 2015 at 8:50:47 PM UTC-4, Luke Stagner wrote:
>>>>
>>>> Thats interesting. Does logspace also return a range?
>>>>
>>>> On Tuesday, September 29, 2015 at 5:43:28 PM UTC-7, Chris wrote:
>>>>>
>>>>> In 0.4 the linspace function returns a range object, and you need to 
>>>>> use collect() to expand it. I'm also interested in nicer syntax.
>>>>
>>>>

[julia-users] Re: Plasma Actuator Simulation

[Luke Stagner]

Ok...wow...I am not surprised it is slow. Well here is what you could try. 

1. Wrap everything into a function. Julia has difficulty with globals.
2. You are defining pointless functions in a loop. You can easily change 
the code to exclude them
3. In your loops you are accessing arrays in row major. This will cause 
alot of cache misses in a column major language like Julia
4. I don't think you need to code up your own version of the gauss seidel 
method. There are plenty of built in ways to solve a system of linear 
equations in Julia.

Fix those things and it should run faster

-Luke 
On Monday, September 28, 2015 at 7:14:32 PM UTC-7, Marius wrote:
>
> Hi everybody,
>
> I wrote a simulation code for Plasma Actuator. This is based on my 
> previous code written in Python and uses Suzen model combined with 
> Navier-Stokes equations. It's about 5 times faster than Python but still 
> simulation takes days to finish. I am new to Julia and I tried to follow 
> the performance tips but so far this is how much I could do. Any 
> suggestions for improving speed are highly appreciated. This is the code:
>
>
> using PyPlot
> using PyCall
>
> const nx=441
> const ny=441
> const nt=100
> const Length=0.011#11 mm
> const dx=Length/(nx-1)
> const dy=Length/(ny-1)
> x=linspace(-Length/2,Length/2,nx)
> y=linspace(-Length/2,Length/2,ny)
> 
> phi1 = zeros(ny,nx) #potential
> eps=zeros(ny,nx)#permitivity
> roc=ones(ny,nx)#charge
> ld=ones(ny,nx)#Debye length
> ### All Electrodes 
> # initial boundary conditions
> phi1[221:222,49:57]=1400.0
> phi1[218:219,57:97]=0.0
> #phi1[221:222,97:105]=0.0
> phi1[221:222,145:153]=1400.0
> phi1[218:219,153:193]=0.0
> #phi1[221:222,193:201]=0.0
> #phi1[221:222,241:249]=0.0
> phi1[218:219,249:289]=0.0
> phi1[221:222,289:297]=1400.0
> #phi1[221:222,337:345]=0.0
> phi1[218:219,345:385]=0.0
> phi1[221:222,385:393]=1400.0
> eps[1:220,:]=2.7
> eps[221:end,:]=1.0
>
> eps[221:221,:]=(eps[222:222,1:end].*eps[220:220,1:end])./(((dx/(2*dx))*eps[222:222,1:end])+
> (((dx/(2*dx))*eps[220:220,1:end])))
> ###
> #convergence parameters
> to1=1e-8
> ###Gauss-Seidel solver
> max_phi1_diff=1
> while max_phi1_diff > to1
>   phi1_old=copy(phi1)
>   phi1[2:nx-1,2:ny-1]=((eps[2:nx-1,2:ny-1].*((phi1[3:nx,2:ny-1]/(dx^2))+
> 
> (phi1[2:nx-1,3:ny]/(dy^2)))+((eps[1:nx-2,2:ny-1].*phi1[1:nx-2,2:ny-1])/(dx^2))+
> 
> ((eps[2:nx-1,1:ny-2].*phi1[2:nx-1,1:ny-2]/(dy^2)./(((eps[2:nx-1,2:ny-1]+
> eps[1:nx-2,2:ny-1])/(dx^2))+
> ((eps[2:nx-1,2:ny-1]+eps[2:nx-1,1:ny-2])/(dy^2)))
>   phi1[end,:]=phi1[end-1,:]
>   phi1[1,:]=phi1[2,:]
>   phi1[:,end]=phi1[:,end-1]
>   phi1[:,1]=phi1[:,2]
>   phi1[221:222,49:57]=1400.0
>   phi1[218:219,57:97]=0.0
>   #phi1[221:222,97:105]=0.0
>   phi1[221:222,145:153]=1400.0
>   phi1[218:219,153:193]=0.0
>   #phi1[221:222,193:201]=0.0
>   #phi1[221:222,241:249]=0.0
>   phi1[218:219,249:289]=0.0
>   phi1[221:222,289:297]=1400.0
>   #phi1[221:222,337:345]=0.0
>   phi1[218:219,345:385]=0.0
>   phi1[221:222,385:393]=1400.0
>   eps[1:220,:]=2.7
>   eps[221:end,:]=1.0
>   phi1_diff = phi1.-phi1_old
>   max_phi1_diff=maximum(abs(phi1_diff))
> end
>
> fig = plt.figure(figsize = (11,7), dpi=100)
> plt.contourf(x*1000,y*1000,phi1,50)
> cbar = plt.colorbar()
> savefig("wflow1368AC29SeptemberElectricField.png")
>  CHARGE  
> ld[221:end,:]=0.00017 #Debye lenght
> ld[1:220,:]=1.0#Debye lenght
> roc[218:219,57:97]=0.00750
> roc[218:219,153:193]=0.00750
> roc[218:219,249:289]=0.00750
> roc[218:219,345:385]=0.00750
> eps[1:220,:]=2.7
> eps[221:end,:]=1.0
>
> eps[221:221,:]=(eps[222:222,1:end].*eps[220:220,1:end])./(((dx/(2*dx))*eps[222:222,1:end])+
> (((dx/(2*dx))*eps[220:220,1:end])))
> roc[:,end] =0
> roc[end,:] = 0
> roc[:,1] =0
> roc[1,:] = 0
> #convergence parameters
> to1=1e-8
> ###Gauss-Seidel solver
> max_roc_diff=1
> while max_roc_diff > to1
>   roc_old=copy(roc)
>   
> roc[2:nx-1,2:ny-1]=((eps[2:nx-1,2:ny-1].*((roc[3:nx,2:ny-1]/(dx^2)).+(roc[2:nx-1,3:ny]/dy^2)))+
> ((eps[1:nx-2,2:ny-1].*roc[1:nx-2,2:ny-1])/dx^2)+
> 
> ((eps[2:nx-1,1:ny-2].*roc[2:nx-1,1:ny-2])/dy^2))./(((eps[2:nx-1,2:ny-1].+eps[1:nx-2,2:ny-1])/dx^2)+
> 
> ((eps[2:nx-1,2:ny-1]+eps[2:nx-1,1:ny-2])/dy^2)+(1./(ld[2:nx-1,2:ny-1].^2)))
>   ld[221:end,:]=0.00017 #charge
>   ld[1:220,:]=1.0#Debye lenght
>   roc[218:219,57:97]=0.00750
>   roc[218:219,153:193]=0.00750
>   roc[218:219,249:289]=0.00750
>   roc[218:219,345:385]=0.00750
>   roc_diff = roc.-roc_old
>   max_roc_diff=maximum(abs(roc_diff))
> end
>
> fig = plt.figure(figsize = (11,7), dpi=100)
> plt.contourf(x*1000,y*1000,roc,50)
> cbar = plt.colorbar()
> savefig("wflow1368AC29SeptemberCharge.png")
> # BODY FORCE ###
> 

Re: [julia-users] Re: @sprintf with a format string

[Luke Stagner]

Would it be possible to rewrite @printf as a generated function instead of 
a macro. That way the calling syntax would be more familiar.

On Tuesday, September 22, 2015 at 1:07:23 PM UTC-7, Stefan Karpinski wrote:
>
> Possible, but I don't relish the thought of forever explaining to people 
> that they need to use printf with or without the @ depending on if they 
> want it to be fast or flexible. If you really don't care about speed, you 
> can just do this right now:
>
> printf(fmt::AbstractString, args...) = @eval @printf($(bytestring(fmt)), 
> $(args...))
>
>
> But actually don't do that because it's so horrifically slow and 
> inefficient I just can't.
>
> On Tue, Sep 22, 2015 at 3:57 PM, Daniel Carrera  > wrote:
>
>>
>> On 22 September 2015 at 20:40, Stefan Karpinski > > wrote:
>>
>>> I think that before any further discussion takes place of how easy or 
>>> hard implementing a high-performance printf is, anyone who'd like to 
>>> comment should spend some time perusing GNU libc's vfprintf 
>>> implementation 
>>> .
>>>  
>>> This code is neither easy nor trivial – it's batsh*t crazy.
>>>
>>
>> That is insane... 2388 lines, half of it macros, and I have no idea how 
>> it works.
>>
>>  
>>
>>> And we want to match its performance yet be much more flexible and 
>>> generic. The current printf implementation does just that, while being 
>>> somewhat less insane GNU's printf code. If someone has bright ideas for how 
>>> to *also* allow runtime format specification without sacrificing 
>>> performance or generality, I'm all ears.
>>>
>>
>>
>> This might be a stupid question, but what's the harm in sacrificing 
>> performance as long as we keep the current @sprintf for scenarios that call 
>> for performance? I don't always need printf() to be fast.
>>
>>
>>  
>>
>>> I have some thoughts, but they're just that – thoughts. One option is to 
>>> change the design and avoid printf-style formatting altogether. But then 
>>> I'm sure I'll never hear the end of it with people kvetching about how we 
>>> don't have printf.
>>>
>>
>> Probably. Everyone is used to printf and they are comfortable with it.
>>
>> Daniel.
>>
>
>

Re: [julia-users] Re: ANN: ApproxFun v0.0.8 with (experimental) nonlinear ODE solver

[Luke Stagner]

Nice! What were you stuck using Matlab or IDL (IDL for me). I looked up 
your masters thesis and it looks like we are in the same sub-field 
(Energetic Particles). For my Ph.D thesis work I need to calculate orbits 
in Constants of motion space so my plan was to write up some routines that 
can handle magnetic equilibriums (read EFIT files, switching from different 
flux coordinates, those sort of things) and implement this[1,2] guiding 
center code in Julia. Are you still working in the field? 

[1] Ellison, C. Leland, et al. "Development of variational guiding center 
algorithms for parallel calculations in experimental magnetic equilibria." 
*Plasma 
Physics and Controlled Fusion* 57.5 (2015): 054007.

[2] https://github.com/lellison/NCSI_Basic

On Thursday, September 17, 2015 at 12:06:06 AM UTC-7, Tomas Lycken wrote:
>
> Luke,
>
> I finished my Masters' Thesis work this past spring working with a C++ 
> simulation for fusion plasma physics applications - during most of that 
> time, I was clenching my teeth wishing I was allowed to use Julia 
> instead. If you want any help with your Fusion Plasma Physics toolbox, ping 
> me (@tlycken) on Github and I'll jump in where I can :)
>
> // T
>
> On Thursday, September 17, 2015 at 8:17:45 AM UTC+2, Sheehan Olver wrote:
>>
>> On what kind of domain?  
>>
>>
>> On 17 Sep 2015, at 12:07 pm, Luke Stagner <lstag...@gmail.com> wrote:
>>
>> It's actually a 2D non-linear, elliptic PDE (psi is a function of R,Z). 
>> I'm thinking about created a Julia library for fusion/plasma physics and 
>> the ability to quickly calculate magnetic equilibrium would be a killer 
>> feature. 
>>
>>
>> On Wednesday, September 16, 2015 at 6:46:09 PM UTC-7, Sheehan Olver wrote:
>>>
>>>
>>> I’m having trouble reading the formulae, but I guess its a nonlinear PDE 
>>> in 3D?   Right now the package can only do nonlinear ODEs and linear PDEs 
>>> on rectangles and disks.  We’ll hopefully eventually extend it to nonlinear 
>>> PDEs, and 3D PDEs.
>>>
>>>
>>>
>>>
>>>
>>> On 17 Sep 2015, at 11:40 am, Luke Stagner <lstag...@gmail.com> wrote:
>>>
>>> Can this package be used to solve the Grad-Shafranov equation 
>>> <https://en.wikipedia.org/wiki/Grad%E2%80%93Shafranov_equation>? 
>>>
>>>
>>> On Wednesday, September 16, 2015 at 3:33:22 PM UTC-7, Sheehan Olver 
>>> wrote:
>>>>
>>>>
>>>> ApproxFun is a package for approximating and solving differential 
>>>> equations. ApproxFun v0.0.8 Adds (experimental) support for solving 
>>>> nonlinear ODEs, using Newton iteration and automatic differentiation.  The 
>>>> following example solves and plots a singularly perturbed nonlinear 
>>>> two-point boundary value problem
>>>>
>>>> x=Fun()
>>>> u0=0.x  # The initial guess for Newton iteration
>>>>
>>>> N=u->[u[-1.]-1.,u[1.]+0.5,0.001u''+6*(1-x^2)*u'+u^2-1.]
>>>> u=newton(N,u0)
>>>>
>>>> ApproxFun.plot(u)  # Requires PyPlot or Gadfly
>>>>
>>>>
>>>>
>>>> Note: previous support for approximating functions on a disk has been 
>>>> moved to a separate package:
>>>>
>>>>  https://github.com/ApproxFun/DiskFun.jl
>>>>
>>>> And this will be the last version to support Julia 0.3!  
>>>>
>>>>
>>>
>>

Re: [julia-users] Re: ANN: ApproxFun v0.0.8 with (experimental) nonlinear ODE solver

[Luke Stagner]

The Grad-Shafranov equation is typically solved in toroidal 
coordinates(R,Z,phi) assuming toroidal symmetry. Some equilibrium codes use 
conformal mapping to solve the equations[1,2]. Using this technique, the 
(arbitrarily shaped) cross section of the last closed flux surface is 
mapped to a circular disk (Hence why I think ApproxFun.jl/DiskFun.jl could 
be used).

[1] http://fusionwiki.ciemat.es/wiki/HBT
[2] Goedbloed, J. P. "Conformal mapping methods in two-dimensional 
magnetohydrodynamics." *Computer Physics Communications* 24.3 (1981): 
311-321.


On Wednesday, September 16, 2015 at 11:17:45 PM UTC-7, Sheehan Olver wrote:
>
> On what kind of domain?  
>
>
> On 17 Sep 2015, at 12:07 pm, Luke Stagner <lstag...@gmail.com 
> > wrote:
>
> It's actually a 2D non-linear, elliptic PDE (psi is a function of R,Z). 
> I'm thinking about created a Julia library for fusion/plasma physics and 
> the ability to quickly calculate magnetic equilibrium would be a killer 
> feature. 
>
>
> On Wednesday, September 16, 2015 at 6:46:09 PM UTC-7, Sheehan Olver wrote:
>>
>>
>> I’m having trouble reading the formulae, but I guess its a nonlinear PDE 
>> in 3D?   Right now the package can only do nonlinear ODEs and linear PDEs 
>> on rectangles and disks.  We’ll hopefully eventually extend it to nonlinear 
>> PDEs, and 3D PDEs.
>>
>>
>>
>>
>>
>> On 17 Sep 2015, at 11:40 am, Luke Stagner <lstag...@gmail.com> wrote:
>>
>> Can this package be used to solve the Grad-Shafranov equation 
>> <https://en.wikipedia.org/wiki/Grad%E2%80%93Shafranov_equation>? 
>>
>>
>> On Wednesday, September 16, 2015 at 3:33:22 PM UTC-7, Sheehan Olver wrote:
>>>
>>>
>>> ApproxFun is a package for approximating and solving differential 
>>> equations. ApproxFun v0.0.8 Adds (experimental) support for solving 
>>> nonlinear ODEs, using Newton iteration and automatic differentiation.  The 
>>> following example solves and plots a singularly perturbed nonlinear 
>>> two-point boundary value problem
>>>
>>> x=Fun()
>>> u0=0.x  # The initial guess for Newton iteration
>>>
>>> N=u->[u[-1.]-1.,u[1.]+0.5,0.001u''+6*(1-x^2)*u'+u^2-1.]
>>> u=newton(N,u0)
>>>
>>> ApproxFun.plot(u)  # Requires PyPlot or Gadfly
>>>
>>>
>>>
>>> Note: previous support for approximating functions on a disk has been 
>>> moved to a separate package:
>>>
>>>  https://github.com/ApproxFun/DiskFun.jl
>>>
>>> And this will be the last version to support Julia 0.3!  
>>>
>>>
>>
>

[julia-users] Re: ANN: ApproxFun v0.0.8 with (experimental) nonlinear ODE solver

[Luke Stagner]

Can this package be used to solve the Grad-Shafranov equation 
? 


On Wednesday, September 16, 2015 at 3:33:22 PM UTC-7, Sheehan Olver wrote:
>
>
> ApproxFun is a package for approximating and solving differential 
> equations. ApproxFun v0.0.8 Adds (experimental) support for solving 
> nonlinear ODEs, using Newton iteration and automatic differentiation.  The 
> following example solves and plots a singularly perturbed nonlinear 
> two-point boundary value problem
>
> x=Fun()
> u0=0.x  # The initial guess for Newton iteration
>
> N=u->[u[-1.]-1.,u[1.]+0.5,0.001u''+6*(1-x^2)*u'+u^2-1.]
> u=newton(N,u0)
>
> ApproxFun.plot(u)  # Requires PyPlot or Gadfly
>
>
>
> Note: previous support for approximating functions on a disk has been 
> moved to a separate package:
>
>  https://github.com/ApproxFun/DiskFun.jl
>
> And this will be the last version to support Julia 0.3!  
>
>

Re: [julia-users] Re: ANN: ApproxFun v0.0.8 with (experimental) nonlinear ODE solver

[Luke Stagner]

It's actually a 2D non-linear, elliptic PDE (psi is a function of R,Z). I'm 
thinking about created a Julia library for fusion/plasma physics and the 
ability to quickly calculate magnetic equilibrium would be a killer 
feature. 


On Wednesday, September 16, 2015 at 6:46:09 PM UTC-7, Sheehan Olver wrote:
>
>
> I’m having trouble reading the formulae, but I guess its a nonlinear PDE 
> in 3D?   Right now the package can only do nonlinear ODEs and linear PDEs 
> on rectangles and disks.  We’ll hopefully eventually extend it to nonlinear 
> PDEs, and 3D PDEs.
>
>
>
>
>
> On 17 Sep 2015, at 11:40 am, Luke Stagner <lstag...@gmail.com 
> > wrote:
>
> Can this package be used to solve the Grad-Shafranov equation 
> <https://en.wikipedia.org/wiki/Grad%E2%80%93Shafranov_equation>? 
>
>
> On Wednesday, September 16, 2015 at 3:33:22 PM UTC-7, Sheehan Olver wrote:
>>
>>
>> ApproxFun is a package for approximating and solving differential 
>> equations. ApproxFun v0.0.8 Adds (experimental) support for solving 
>> nonlinear ODEs, using Newton iteration and automatic differentiation.  The 
>> following example solves and plots a singularly perturbed nonlinear 
>> two-point boundary value problem
>>
>> x=Fun()
>> u0=0.x  # The initial guess for Newton iteration
>>
>> N=u->[u[-1.]-1.,u[1.]+0.5,0.001u''+6*(1-x^2)*u'+u^2-1.]
>> u=newton(N,u0)
>>
>> ApproxFun.plot(u)  # Requires PyPlot or Gadfly
>>
>>
>>
>> Note: previous support for approximating functions on a disk has been 
>> moved to a separate package:
>>
>>  https://github.com/ApproxFun/DiskFun.jl
>>
>> And this will be the last version to support Julia 0.3!  
>>
>>
>

[julia-users] Re: Finding the index of a type member

[Luke Stagner]

Firstly, instead of using ```symbol("is_continuous")``` you can use the 
colon notation ```:is_continuous```. Secondly, you can do element wise 
comparison by using ```.==``` operator. This will return a BitArray. You 
can then find where the BitArray is true by using the ```find``` function 
which returns an array of indices.

So for your case all you would need to do is
```
index = find(fn .== :is_continuous)
```

On Wednesday, September 9, 2015 at 6:01:47 PM UTC-7, J Luis wrote:
>
> So I need to find position of a certain type member in a type. Easy, I 
> though
>
> julia> fn = fieldnames(GMT_PALETTE)
> 9-element Array{Symbol,1}:
>  :n_headers
>  :n_colors
>  :alloc_level
>  :auto_scale
>  :model
>  :is_gray
>  :is_bw
>  :is_continuous
>  :z_unit_to_meter
>
> julia> search(fn,"is_continuous")
> ERROR: MethodError: `search` has no method matching 
> search(::Array{Symbol,1}, ::ASCIIString)
> Closest candidates are:
>   search(::AbstractString, ::AbstractString)
>   search(::AbstractString, ::AbstractString, ::Integer)
>
> Went to the docs and found the "symbol" function and though, ok now it 
> will work 
>
> julia> search(fn,symbol("is_continuous"))
> ERROR: MethodError: `search` has no method matching 
> search(::Array{Symbol,1}, ::Symbol)
>
> Ok, I can do a loop over the number of elements and ask
>
> fn[k] == symbol("is_continuous")
>
> but isn't there a more compact way of do this ? 
>
> (I confess this parts of Julia are annoying)
>
> Thanks
>

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

[Luke Stagner]

Perhaps they are planning to upload the videos when 0.4 gets released in 
order to maximize the media impact.

On Wednesday, August 12, 2015 at 5:58:50 PM UTC-7, ron...@gmail.com wrote:

 Five weeks later – still processing the videos?

 On Thursday, July 2, 2015 at 2:11:52 AM UTC-7, Stefan Karpinski wrote:

 The AV crew was actually paid and they're actively working on the videos, 
 so that should be done soonish. Will let everyone know once it's done, of 
 course. I'm eager to see them too since the conference was 1.5 track and I 
 couldn't see all of the talks!

 On Wed, Jul 1, 2015 at 8:52 AM, Randy Zwitch randy@fuqua.duke.edu 
 wrote:

 They were all recorded. Be patient, everyone is a volunteer :)

 On Wednesday, July 1, 2015 at 8:07:18 AM UTC-4, Hans-Peter wrote:

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

[julia-users] Re: Irregular Interpolation

[Luke Stagner]

I wrote some code that did Polyharmonic (Thin-plate) splines feel free to 
use them https://github.com/tlycken/Interpolations.jl/issues/6

On Wednesday, July 29, 2015 at 6:16:59 AM UTC-7, Jude wrote:

 Hi,

 I have been using the fantastic grid package by Tim Holy for the past 
 while but I really need to allow for a non-equally spaced grids. It is 
 important to have a bunch of points at some parts of the grid but not at 
 others. I was wondering if anyone knows of any package that allows for 
 irregular interpolation. I know it is possible to do this using Tim's 
 package for one dimension but I want to interpolate in 3 dimensions. Has 
 there been any new packages developed lately or does anyone know a fast way 
 to do this?

 Thank you

Re: [julia-users] Juliacon 2015 videos?

[Luke Stagner]

?

On Saturday, July 11, 2015 at 9:11:15 AM UTC-7, Ismael VC wrote:

 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 vi...@mayin.org 
 javascript: 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 ismael...@gmail.com 
 javascript: 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 ismael...@gmail.com 
 javascript: 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 vi...@mayin.org 
 javascript: 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] Re: 4D interpolation from scattered points

[Luke Stagner]

You can use Polyharmonic Splines 
http://nbviewer.ipython.org/gist/lstagner/04a05b120e0be7de9915


On Wednesday, May 13, 2015 at 5:33:08 AM UTC-7, Yakir Gagnon wrote:

 I have a bunch (~1000) of x,y,z and a corresponding value, V. One unique V 
 for each x,y,z. I want to interpolate and extrapolate wildly (so I really 
 don't care about how accurate or correct it is). The x,y,z I have are not 
 regularly spaced or anything. They're scattered across some range (they all 
 share similar ranges), and I want to know what value (i.e. new V) I should 
 be getting at new and regularly spaced x,y,z. I think Matlab's griddata 
 would do what I want.
 I tired following the lower-level functionality from Grid.jl, 
 Interpolations.jl, and Dierckx.jl, but couldn't figure out how to get this 
 to work. 
 I think I need to fit some curve to my scattered points and then use that 
 to find the values at the new xyz (at least that's how I think griddata 
 works)... Any good simple ideas out there?

Re: [julia-users] Re: Thin Plate Splines

[Luke Stagner]

Here is the beginning of a package 
http://nbviewer.ipython.org/gist/lstagner/04a05b120e0be7de9915

-Luke

On Wednesday, May 13, 2015 at 1:03:34 AM UTC-7, René Donner wrote:

  Thin plate splines are just a special case of Polyharmonic Splines. 
 Would there be interest of expanding this script into a package? 

 Yes please, that would be great to have! 

  
  -Luke 
  
  On Wednesday, May 13, 2015 at 12:26:12 AM UTC-7, Jan Kybic wrote: 
  I have a set of irregularly gridded data (x,y,z) and I am trying to 
 create an interpolating surface using Thin Plate Splines. I couldn't find 
 any existing Julia routines so I thought I'd just do it my self. Here is my 
 implementation. As you can see its wrong. I been staring at it for a while 
 now and I am beginning to think I must be hitting some sort of bug or quirk 
 of the language. It either that or I did something wrong. If I get this to 
 work I was thinking about incorporating it into one of the existing 
 interpolation packages. 
  
  Can anyone figure out why this is not working? 
  
  
   Hello. I have never seen the formulas you are using to find 'a' and 'b' 
 and I do not have the time to check. Provided they are correct, I would 
 suspect numerical problems - it is often not a good idea to calculate a 
 matrix inverse explicitely and the TPS matrix is ill-conditioned for even a 
 moderate number of points. I am attaching my Matlab implementation - you 
 see that I am solving the linear system by SVD, which is more stable. It 
 should be trivial to translate to Julia. Hope this helps. 
  
  Jan 

[julia-users] Thin Plate Splines

[Luke Stagner]

Hello all,

I have a set of irregularly gridded data (x,y,z) and I am trying to create 
an interpolating surface using Thin Plate Splines. I couldn't find any 
existing Julia routines so I thought I'd just do it my self. Here is my 
implementation 
http://nbviewer.ipython.org/urls/gist.githubusercontent.com/lstagner/89964e63557ddb831e72/raw/49049103742450d80ee28d8876fa1a8b8037f970/tps.ipynb.
 
As you can see its wrong. I been staring at it for a while now and I am 
beginning to think I must be hitting some sort of bug or quirk of the 
language. It either that or I did something wrong. If I get this to work I 
was thinking about incorporating it into one of the existing interpolation 
packages.

Can anyone figure out why this is not working?

Sources:
http://www.geometrictools.com/Documentation/ThinPlateSplines.pdf
http://user.engineering.uiowa.edu/~aip/papers/bookstein-89.pdf

Re: [julia-users] Re: Getting people to switch to Julia - tales of no(?) success

[Luke Stagner]

Robert,
Although it is still under development it looks like 
https://github.com/tknopp/Julietta.jl might be just what your looking for. 
At the very least you should keep an eye on it. 

On Wednesday, March 4, 2015 at 1:41:39 PM UTC-8, Robert wrote:

 Dear Mike, thanks a lot for your reply! I will study Juno again, in a 
 couple of days when I calmed down from my frustrating 2 weeks to get 
 started with Julia. I here would like to express to you my big THANK YOU! I 
 really appreciate your efforts in the Juno development, and with my (only) 
 two years of more serious programming experience (mainly MATLAB, some few 
 Python, some few C++) I am absolutely aware about the high quality of your 
 work.
 My problem with Juno actually is a problem with the concept of the Light 
 Table user interface, and not with your Juno plugin: to me it appears that 
 you can only use LightTable effective, if you learned about a bunch of 
 shortcuts and are able to handle in your head the work you want to do so 
 much that you don't worry anymore about the tool (the editor) to be 
 configured to the one or the other appearance. Like it is also with using a 
 shell, a bash shell, or the windows command line. But if your brain (I 
 actually speak here about _my_ brain) is not as good in abstracting and 
 memorizing things, then a visual guidance helps a lot(!) to still get 
 complicated tasks done. This visual guidance is missing in LightTable, 
 subsequently is missing in Juno. It has a good reason that the graphical 
 user interface with mouse control has been developed, and especially that 
 it became such a success: click on a drop down menu to see what 
 possibilities are offered by the software, call it by a click, and by time 
 use the shortcut for that function, or rightclick somewhere for a context 
 menu and proceed alike. Tile a tab horizontally and keep visible some 
 example text i.e. in the upper part while typing far away in the file in 
 the lower part of the tiled tab. Write at a place which appears at a 
 certain position on your computer screen, and receive some ouptut always at 
 some other certain position at the screen, without the output affecting the 
 position on the screen where you would like to just go ahead with writing 
 something more. That is a perfectly foreseeable and and guiding behaviour, 
 and is what makes the other IDEs (Visual Study, Eclipse, Spyder) so 
 successful, if not speaking about their powerful engines to take work load 
 regarding house keeping the project and build process automation off from 
 the user. Well, Juno at LightTable is a powerful engine as well, but the 
 frontend of LightTable is - let´s say much different. I know that there are 
 also the emacs and the vim users, and LightTable might be an interesting 
 tool for those users. But there are also many people who are not so much in 
 favour with emacs or vim, using those editors only if no other option is 
 available, and the same people might then not be so much in favour with a 
 LightTable based IDE neither. Although the interactive engine of Juno is 
 impressive, I just couldn't get warm with the allover (almost) mouse-less 
 design of LightTable and the at the same time vast amount of vertical 
 scrolling needed. While I am absolutely aware about LightTable being an 
 extremely powerful tool for many programmers, I still would wish to find 
 enhanced Julia handling by a SPYDER or MATLAB alike IDE. Fortunately for 
 LightTable liking programmers you made Juno available, and I see that it is 
 some great work. Unfortunately nothing alike is available for SPYDER by 
 now. 
 O.K., I will take a break now for some days, and next week pick up again 
 the fight for setting up a for me comfortable Julia programming environment.

[julia-users] Re: Why does my Julia code run so slow?

[Luke Stagner]

You may want to try using a profiler. I recently used the ProfileView.jl 
https://github.com/timholy/ProfileView.jl package to great success. 

On Friday, February 20, 2015 at 11:53:56 PM UTC-8, Zhixuan Yang wrote:

 After recompiled an native arch version of Julia and OpenBLAS, it's about 
 8x slower than the C code and I think it's near to the  highest performance 
 my code can achieve. After all, the C code was optimized intensively in the 
 cache level and all loops were unrolled. But my Julia code is much more 
 flexible and extensible. 

 Maybe I should try to use more computers. Currently my code is paralleled 
 by using pmap(). I hope the communication overhead will not be a new 
 bottleneck if I run on a local network cluster.

 Thanks for your help! 

 Regards, Yang Zhixuan

 在 2015年2月21日星期六 UTC+8下午2:23:37，Viral Shah写道：

 So, where is the performance now compared to the C program? I don't think 
 MKL will give you much if you were on the order of 100x slower to start 
 with.

 -viral

 On Friday, February 20, 2015 at 8:19:50 PM UTC+5:30, Zhixuan Yang wrote:

 Mauro, Sean, and Tim, thanks for your help. 

 Following your suggestions, I removed keyword arguments and split the 
 function to avoid conditional statements. These helped a bit. 

 But I got a surprising result after replacing BLAS functions with simple 
 for loops, for loops is about 1.5x faster than BLAS calls. My Julia is 
 compiled on my computer with the default configuration (the versioninfo() 
 is listed below). Do you think it will help to compile a Julia with a 
 faster and more optimized BLAS implementation such as Intel's MKL? 

 Julia Version 0.3.6-pre+70
 Commit 638fa02 (2015-02-12 13:59 UTC)
 Platform Info:
  System: Darwin (x86_64-apple-darwin14.1.0)
  CPU: Intel(R) Core(TM) i7-4650U CPU @ 1.70GHz
  WORD_SIZE: 64
  BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Haswell)
  LAPACK: libopenblas
  LIBM: libopenlibm
  LLVM: libLLVM-3.3


 Regards, Yang Zhixuan

 在 2015年2月19日星期四 UTC+8下午10:51:20，Zhixuan Yang写道：

 Hello everyone, 

 Recently I'm working on my first Julia project, a word embedding 
 training program similar to Google's word2vec 
 https://code.google.com/p/word2vec/ (the code of word2vec is indeed 
 very high-quality, but I want to add more features, so I decided to write 
 a 
 new one). Thanks to Julia's expressiveness, it cost me less than 2 days to 
 write the entire program. But it runs really slow, about 100x slower than 
 the C code of word2vec (the algorithm is the same).  I've been trying to 
 optimize my code for several days (adding type annotations, using BLAS to 
 do computation, eliminating memory allocations ...), but it is still 30x 
 slower than the C code. 

 The critical part of my program is the following function (it also 
 consumes most of the time according to the profiling result):

 function train_one(c :: LinearClassifier, x :: Array{Float64}, y :: 
 Int64; α :: Float64 = 0.025, input_gradient :: Union(Nothing, 
 Array{Float64}) = nothing)
 predict!(c, x)
 c.outputs[y] -= 1

 if input_gradient != nothing
 # input_gradient = ( c.weights * outputs' )'
 BLAS.gemv!('N', α, c.weights, c.outputs, 1.0, input_gradient)
 end

 # c.weights -= α * x' * outputs;
 BLAS.ger!(-α, vec(x), c.outputs, c.weights)
 end

 function predict!(c :: LinearClassifier, x :: Array{Float64})
 c.outputs = vec(softmax(x * c.weights))
 end

 type LinearClassifier
 k :: Int64 # number of outputs
 n :: Int64 # number of inputs
 weights :: Array{Float64, 2} # k * n weight matrix

 outputs :: Vector{Float64}
 end

 And the entire program can be found here 
 https://github.com/yangzhixuan/embed. Could you please check my code 
 and tell me what I can do to get performance comparable to C. 

 Regards.
 Yang Zhixuan

[julia-users] [PyCall] Converting PyObject to Array

[Luke Stagner]

Forgive me if this is a basic question. I have a matrix stored in an IDL 
save file. I have been trying to read it in using PyCall and 
scipy.io.readsav

julia using PyCall

julia @pyimport scipy.io as io

julia a=io.readsav(weight_and_dist.sav)
/usr/lib/python2.7/dist-packages/scipy/io/idl.py:167: UserWarning: warning: 
empty strings are now set to '' instead of None
  warnings.warn(warning: empty strings are now set to '' instead of None)
Dict{Any,Any} with 8 entries:
  w_matrix = PyObject array([[  1.68552301e-101,   2.356978…
  m02_fbm  = PyObject rec.array([ (array([[  1.34499655e+10…
  pitch= PyObject array([-0.8998, -0.7005, -0.5…
  mean_fbm = PyObject array([[  1.31980645e+10,   3.3166579…
  v17_fbm  = PyObject rec.array([ (array([[  1.30541168e+10…
  energy   = PyObject array([  5.,  15.,  25.,  35.,  45., …
  m10_fbm  = PyObject rec.array([ (array([[  1.26698307e+10…
  p2_fbm   = PyObject rec.array([ (array([[  1.36183452e+10…

julia w_matrix = a[w_matrix]
PyObject array([[  1.68552301e-101,   2.35697831e-066,   3.61510788e-046, 
...,
  3.25287399e+003,   6.30708487e+003,   6.26874721e+003],
   [  3.42516635e-103,   9.95975928e-068,   2.55145289e-047, ...,
  2.85362314e+003,   5.95774610e+003,   6.24852521e+003],
   [  6.73923741e-105,   4.07514829e-069,   1.74358145e-048, ...,
  2.47492336e+003,   5.58385846e+003,   6.20714822e+003],
   ..., 
   [  0.e+000,   0.e+000,   0.e+000, ...,
  4.78256276e-049,   6.15881422e-073,   2.18231882e-100],
   [  0.e+000,   0.e+000,   0.e+000, ...,
  2.07619108e-050,   1.37890846e-074,   2.53424699e-102],
   [  0.e+000,   0.e+000,   0.e+000, ...,
  8.63614392e-052,   2.95848174e-076,   2.81982090e-104]])

julia w = convert(Array{Float64,2},w_matrix)
ERROR: PyError (PyFloat_AsDouble) type 'exceptions.TypeError'
TypeError('only length-1 arrays can be converted to Python scalars',)

 in pyerr_check at /home/lstagner/.julia/v0.4/PyCall/src/exception.jl:58
 in convert at /home/lstagner/.julia/v0.4/PyCall/src/conversions.jl:75
 in py2array at /home/lstagner/.julia/v0.4/PyCall/src/conversions.jl:339
 in convert at /home/lstagner/.julia/v0.4/PyCall/src/numpy.jl:430

julia w = convert(Array{Float64,2},w_matrix)
ERROR: PyError (PyFloat_AsDouble) type 'exceptions.TypeError'
TypeError('only length-1 arrays can be converted to Python scalars',)

 in pyerr_check at /home/lstagner/.julia/v0.4/PyCall/src/exception.jl:58
 in convert at /home/lstagner/.julia/v0.4/PyCall/src/conversions.jl:75
 in py2array at /home/lstagner/.julia/v0.4/PyCall/src/conversions.jl:339
 in convert at /home/lstagner/.julia/v0.4/PyCall/src/numpy.jl:430


Could someone direct me towards the correct way to convert PyObjects to 
Arrays.

[julia-users] Re: [PyCall] Converting PyObject to Array

[Luke Stagner]

Yes, the examples work for me. 

Here is the IDL save file that I used. (700kB). 

http://www.filedropper.com/weightanddist


On Wednesday, November 12, 2014 4:46:07 PM UTC-8, Steven G. Johnson wrote:



 On Wednesday, November 12, 2014 4:21:12 PM UTC-5, Luke Stagner wrote:

 Forgive me if this is a basic question. I have a matrix stored in an IDL 
 save file. I have been trying to read it in using PyCall and 
 scipy.io.readsav


 I can't reproduce your problem:

 julia o1 = PyObject(rand(2,3))
 PyObject array([[ 0.33150974,  0.89636836,  0.68890329],
[ 0.63132778,  0.36191286,  0.15337456]])

 julia convert(Matrix{Float64}, o1)
 2x3 Array{Float64,2}:
  0.33151   0.896368  0.688903
  0.631328  0.361913  0.153375

 julia o2 = pyeval([[  1.68552301e-101,   2.35697831e-066,   
 3.61510788e-04], [  3.42516635e-103,   9.95975928e-068,   
 2.55145289e-04]], PyObject)
 PyObject [[1.68552301e-101, 2.35697831e-66, 0.000361510788], 
 [3.42516635e-103, 9.95975928e-68, 0.000255145289]]

 julia convert(Matrix{Float64}, o2)
 2x3 Array{Float64,2}:
  1.68552e-101  2.35698e-66  0.000361511
  3.42517e-103  9.95976e-68  0.000255145
  
 Do the above examples work for you?

[julia-users] Re: [PyCall] Converting PyObject to Array

[Luke Stagner]

Sure thing

https://github.com/stevengj/PyCall.jl/issues/99

On Wednesday, November 12, 2014 6:58:59 PM UTC-8, Steven G. Johnson wrote:

 Can you file an issue at PyCall.jl?

Re: [julia-users] Re: Jupyter project

[Luke Stagner]

The is also the alchemical symbol for oil 
http://www.fileformat.info/info/unicode/char/1f746/index.htm ༜ 

[julia-users] Self-referential type array

[Luke Stagner]

Hello all,

I know it is possible to have a self-referential type like the following

type SelfRef
   obj::SelfRef
   SelfRef() = (x=new(); x.obj=x)
end

what I want to do is have obj be an array of type SelfRef so I can make a 
tree-like structure. I tried the following

type SelfRef
   obj::Array{SelfRef,0}
   SelfRef() = (x=new(); x.obj=Array(x,0))
end

but that throws the following error (on nightly)
julia a=SelfRef()
ERROR: no method Array{T,N}(SelfRef)
 in SelfRef at none:3

Is there anyway I can make this work? 

Re: [julia-users] Self-referential type array

[Luke Stagner]

I think an even better definition would be
julia type SelfRef
   objs::Array{SelfRef,1}
   function SelfRef()
   x = new()
   x.objs = SelfRef[]
   return x
   end
   end

julia x=SelfRef()
SelfRef([])

julia push!(x.objs,SelfRef())
1-element Array{SelfRef,1}:
 SelfRef([])

julia x
SelfRef([SelfRef([])])


That way the first element of objs doesn't loop back around to itself.

On Wednesday, June 18, 2014 2:08:15 PM UTC-7, Stefan Karpinski wrote:

 Right, this definition is better:

 julia type SelfRef
objs::Array{SelfRef,1}
function SelfRef()
x = new()
x.objs = [x]
return x
end
end

 julia x = SelfRef()
 SelfRef([SelfRef(#= circular reference =#)])


 We don't enforce that constructors actually return the appropriate type.


 On Wed, Jun 18, 2014 at 4:58 PM, Luke Stagner lstag...@gmail.com 
 javascript: wrote:

 Thanks Stefan, although I feel like 
 julia x = SelfRef()
 1-element Array{SelfRef,1}:
  SelfRef([SelfRef(#= circular reference =#)])

 Should not return an array of type SelfRef. It should return just an 
 instance of itself
 As it stands, to get the behavior I want I need to call it like
 julia x=SelfRef()[1]
 SelfRef([SelfRef(#= circular reference =#)])

 julia x.objs
 1-element Array{SelfRef,1}:
  SelfRef([SelfRef(#= circular reference =#)])

 julia push!(x.objs,SelfRef()[1])
 2-element Array{SelfRef,1}:
  SelfRef([SelfRef(#= circular reference =#),SelfRef([SelfRef(#= circular 
 reference =#)])])
  SelfRef([SelfRef(#= circular reference =#)]) 


 On Wednesday, June 18, 2014 12:24:34 PM UTC-7, Stefan Karpinski wrote:

 This works:

 julia type SelfRef
objs::Array{SelfRef,1}
function SelfRef()
x = new()
x.objs = [x]
end
end

 julia x = SelfRef()
 1-element Array{SelfRef,1}:
  SelfRef([SelfRef(#= circular reference =#)])


 A couple of points:

 The type Array{SelfRef,0} is a zero-dimensional array of SelfRef 
 objects, not a zero-length one-dimensional array of SelfRef objects. The 
 type of a one-dimensional array of SelfRef objects is Array{SelfRef,1} – 
 aka Vector{SelfRef}.

 The first argument to the Array constructor is always a type, whereas x 
 is an instance of type SelfRef. Writing [x] gives a vector of type SelfRef 
 containing just x.

  

 On Wed, Jun 18, 2014 at 4:32 AM, Luke Stagner lstag...@gmail.com 
 wrote:

 Hello all,

 I know it is possible to have a self-referential type like the following

 type SelfRef
obj::SelfRef
SelfRef() = (x=new(); x.obj=x)
 end

 what I want to do is have obj be an array of type SelfRef so I can make 
 a tree-like structure. I tried the following

 type SelfRef
obj::Array{SelfRef,0}
SelfRef() = (x=new(); x.obj=Array(x,0))
 end

 but that throws the following error (on nightly)
 julia a=SelfRef()
 ERROR: no method Array{T,N}(SelfRef)
  in SelfRef at none:3

 Is there anyway I can make this work?