[julia-users] Problems with Memoize in Julia 0.5.0

[Ed Scheinerman]

Hello,

I use memoization frequently and have run into two problems with the move 
to Julia 0.5.0. 

The first is not too serious and I hope can be fixed readily.  The first 
time I memoize a function, a warning is generated like this:

julia> using Memoize

julia> @memoize f(a) = a+1
WARNING: symbol is deprecated, use Symbol instead.
 in depwarn(::String, ::Symbol) at ./deprecated.jl:64
 in symbol(::String, ::Vararg{String,N}) at ./deprecated.jl:30
 in @memoize(::Expr, ::Vararg{Expr,N}) at 
/Users/ers/.julia/v0.5/Memoize/src/Memoize.jl:14
 in eval(::Module, ::Any) at ./boot.jl:234
 in eval(::Module, ::Any) at 
/Applications/Julia-0.5.app/Contents/Resources/julia/lib/julia/sys.dylib:?
 in eval_user_input(::Any, ::Base.REPL.REPLBackend) at ./REPL.jl:64
 in macro expansion at ./REPL.jl:95 [inlined]
 in (::Base.REPL.##3#4{Base.REPL.REPLBackend})() at ./event.jl:68
while loading no file, in expression starting on line 0
(::#28#f) (generic function with 1 method)


More significantly, if I want multiple dispatch on a function name, the 
second instance creates a problem and the definition is rejected. Here I 
define a factorial function that always returns a BigInt. The first 
function definition succeeds but the second one fails:

julia> @memoize function Factorial(n::Integer)
 if n<0
   throw(DomainError())
 end
 if n==0 || n==1
   return big(1)
 end
 return n * Factorial(n-1)
   end
(::#35#Factorial) (generic function with 1 method)

julia> @memoize function Factorial(n::Integer,k::Integer)
 if n<0 || k<0 || k > n
   throw(DomainError())
 end

 if k==n
   return big(1)
 end

 return n * Factorial(n-1,k)
   end
ERROR: cannot define function Factorial; it already has a value
 in macro expansion; at /Users/ers/.julia/v0.5/Memoize/src/Memoize.jl:103 
[inlined]
 in anonymous at ./:?

julia> Factorial(10)  # this works
3628800

julia> Factorial(10,2) # but this doesn't
ERROR: MethodError: no method matching (::##35#Factorial#2)(::Int64, 
::Int64)
Closest candidates are:
  #35#Factorial(::Integer) at 
/Users/ers/.julia/v0.5/Memoize/src/Memoize.jl:113

Re: [julia-users] Suddenly PyPlot giving me grief

[Ed Scheinerman]

Not a permanent fix, but the Qt4Agg backend works just fine. You just have 
to add 

backend : Qt4Aggto 

~/.matplotlib/matplotlibrc.

This suggestion worked for me. The file matplotlibrc didn't exist but I 
just created it and added that single line.


On Wednesday, July 13, 2016 at 10:26:26 AM UTC-4, Steven G. Johnson wrote:
>
> See also:
>
> https://github.com/stevengj/PyPlot.jl/issues/164
>
> So far, the workarounds have been using a different backend (Qt4Agg 
> instead of TkAgg) or using a different Python distro (homebrew).
>
> I'm guessing that some library was recently updated in Anaconda, and 
> unfortunately conflicts with the Tk library that comes with MacOS X.   
> Probably there is some library-path environment variable that could fix the 
> problem.   Or maybe we could manually dlopen the desired library to work 
> around the problem?
>

Re: [julia-users] Suddenly PyPlot giving me grief

[Ed Scheinerman]

One more thought for Mac experts. Based on this message:

Class TKApplication is implemented in both 
/System/Library/Frameworks/Tk.framework/Versions/8.5/Tk and 
/Users/ers/.julia/v0.4/Conda/deps/usr/lib/libtk8.5.dylib. One of the two will 
be used. Which one is undefined.

Does it make sense to delete the folder /System/Library/Frameworks/Tk.framework 
or will that mess other stuff up?

I’ve not had this problem on my Linux computer. 



> On Jul 13, 2016, at 10:12, Ed Scheinerman <edward.scheiner...@gmail.com> 
> wrote:
> 
> Sigh, yes I tried that.
> 
>> On Jul 13, 2016, at 09:04, Tom Breloff <t...@breloff.com> wrote:
>> 
>> Have you tried using the conda local install?
>> 
>> ENV["PYTHON"] = ""
>> Pkg.build("PyPlot")
>> 
>> Also it's not a real solution, but you could try Plots.jl with a different 
>> backend. It sounds like you have a system library clash of some sort, and in 
>> my experience those sorts of bugs will easily sink a week of debugging with 
>> no good solution. 
> 

—
Ed Scheinerman
edward.scheiner...@gmail.com

Re: [julia-users] Suddenly PyPlot giving me grief

[Ed Scheinerman]

Sigh, yes I tried that.

> On Jul 13, 2016, at 09:04, Tom Breloff  wrote:
> 
> Have you tried using the conda local install?
> 
> ENV["PYTHON"] = ""
> Pkg.build("PyPlot")
> 
> Also it's not a real solution, but you could try Plots.jl with a different 
> backend. It sounds like you have a system library clash of some sort, and in 
> my experience those sorts of bugs will easily sink a week of debugging with 
> no good solution. 

[julia-users] Re: Suddenly PyPlot giving me grief

[Ed Scheinerman]

And when I do a simple "using PyPlot" I get these errors. Someone, please 
help :-(


julia> using PyPlot

objc[83239]: Class TKApplication is implemented in both 
/System/Library/Frameworks/Tk.framework/Versions/8.5/Tk and 
/Users/ers/.julia/v0.4/Conda/deps/usr/lib/libtk8.5.dylib. One of the two 
will be used. Which one is undefined.

objc[83239]: Class TKMenu is implemented in both 
/System/Library/Frameworks/Tk.framework/Versions/8.5/Tk and 
/Users/ers/.julia/v0.4/Conda/deps/usr/lib/libtk8.5.dylib. One of the two 
will be used. Which one is undefined.

objc[83239]: Class TKContentView is implemented in both 
/System/Library/Frameworks/Tk.framework/Versions/8.5/Tk and 
/Users/ers/.julia/v0.4/Conda/deps/usr/lib/libtk8.5.dylib. One of the two 
will be used. Which one is undefined.

objc[83239]: Class TKWindow is implemented in both 
/System/Library/Frameworks/Tk.framework/Versions/8.5/Tk and 
/Users/ers/.julia/v0.4/Conda/deps/usr/lib/libtk8.5.dylib. One of the two 
will be used. Which one is undefined.


julia> plot([1,2],[1,3])

Exception in Tkinter callback

Traceback (most recent call last):

  File 
"/Users/ers/.julia/v0.4/Conda/deps/usr/lib/python2.7/lib-tk/Tkinter.py", 
line 1537, in __call__

return self.func(*args)

  File 
"/Users/ers/.julia/v0.4/Conda/deps/usr/lib/python2.7/site-packages/matplotlib/backends/backend_tkagg.py",
 
line 283, in resize

self.show()

  File 
"/Users/ers/.julia/v0.4/Conda/deps/usr/lib/python2.7/site-packages/matplotlib/backends/backend_tkagg.py",
 
line 355, in draw

tkagg.blit(self._tkphoto, self.renderer._renderer, colormode=2)

  File 
"/Users/ers/.julia/v0.4/Conda/deps/usr/lib/python2.7/site-packages/matplotlib/backends/tkagg.py",
 
line 30, in blit

id(data), colormode, id(bbox_array))

TclError

julia(83239,0x7fff7ce8a000) malloc: *** error for object 0x7fe0916936d0: 
pointer being freed was not allocated

*** set a breakpoint in malloc_error_break to debug


signal (6): Abort trap: 6

__pthread_kill at /usr/lib/system/libsystem_kernel.dylib (unknown line)

Abort trap: 6



On Wednesday, July 13, 2016 at 8:37:28 AM UTC-4, Ed Scheinerman wrote:
>
>
>
> On Tuesday, July 12, 2016 at 8:16:03 AM UTC-4, David P. Sanders wrote:
>>
>> As a quick solution, I would suggest deleting or renaming ~/.julia/v0.4 
>> and reinstalling all the packages.
>>
>>
>>
> Good suggestion, minor hassle. Did it and the problem is not solved. I got 
> this today:
>
> Exception in Tkinter callback
>
> Traceback (most recent call last):
>
>   File 
> "/Users/ers/.julia/v0.4/Conda/deps/usr/lib/python2.7/lib-tk/Tkinter.py", 
> line 1537, in __call__
>
> return self.func(*args)
>
>   File 
> "/Users/ers/.julia/v0.4/Conda/deps/usr/lib/python2.7/site-packages/matplotlib/backends/backend_tkagg.py",
>  
> line 283, in resize
>
> self.show()
>
>   File 
> "/Users/ers/.julia/v0.4/Conda/deps/usr/lib/python2.7/site-packages/matplotlib/backends/backend_tkagg.py",
>  
> line 355, in draw
>
> tkagg.blit(self._tkphoto, self.renderer._renderer, colormode=2)
>
>   File 
> "/Users/ers/.julia/v0.4/Conda/deps/usr/lib/python2.7/site-packages/matplotlib/backends/tkagg.py",
>  
> line 30, in blit
>
> id(data), colormode, id(bbox_array))
>
> TclError
>
>
> julia(82876,0x7fff7ce8a000) malloc: *** error for object 0x7fefddbb2ad0: 
> pointer being freed was not allocated
>
> *** set a breakpoint in malloc_error_break to debug
>
>
> signal (6): Abort trap: 6
>
> __pthread_kill at /usr/lib/system/libsystem_kernel.dylib (unknown line)
> Abort trap: 6 
>

[julia-users] Re: Suddenly PyPlot giving me grief

[Ed Scheinerman]

On Tuesday, July 12, 2016 at 8:16:03 AM UTC-4, David P. Sanders wrote:
>
> As a quick solution, I would suggest deleting or renaming ~/.julia/v0.4 
> and reinstalling all the packages.
>
>
>
Good suggestion, minor hassle. Did it and the problem is not solved. I got 
this today:

Exception in Tkinter callback

Traceback (most recent call last):

  File 
"/Users/ers/.julia/v0.4/Conda/deps/usr/lib/python2.7/lib-tk/Tkinter.py", 
line 1537, in __call__

return self.func(*args)

  File 
"/Users/ers/.julia/v0.4/Conda/deps/usr/lib/python2.7/site-packages/matplotlib/backends/backend_tkagg.py",
 
line 283, in resize

self.show()

  File 
"/Users/ers/.julia/v0.4/Conda/deps/usr/lib/python2.7/site-packages/matplotlib/backends/backend_tkagg.py",
 
line 355, in draw

tkagg.blit(self._tkphoto, self.renderer._renderer, colormode=2)

  File 
"/Users/ers/.julia/v0.4/Conda/deps/usr/lib/python2.7/site-packages/matplotlib/backends/tkagg.py",
 
line 30, in blit

id(data), colormode, id(bbox_array))

TclError


julia(82876,0x7fff7ce8a000) malloc: *** error for object 0x7fefddbb2ad0: 
pointer being freed was not allocated

*** set a breakpoint in malloc_error_break to debug


signal (6): Abort trap: 6

__pthread_kill at /usr/lib/system/libsystem_kernel.dylib (unknown line)
Abort trap: 6 

[julia-users] Suddenly PyPlot giving me grief

[Ed Scheinerman]

I've suddenly been having a great deal of trouble with PyPlot on Julia 
0.4.6 on Mac. 

Here's one sort of problem I've gotten:

julia> plot([1,2],[1,3])

ERROR: ArgumentError: haskey of NULL PyObject

 in haskey at /Users/ers/.julia/v0.4/PyCall/src/PyCall.jl:292

 in plot at /Users/ers/.julia/v0.4/PyPlot/src/PyPlot.jl:381


I tried reinstalling PyPlot, PyCall, Conda and I get this:


julia> using PyPlot

objc[75453]: Class TKApplication is implemented in both 
/System/Library/Frameworks/Tk.framework/Versions/8.5/Tk and 
/Users/ers/.julia/v0.4/Conda/deps/usr/lib/libtk8.5.dylib. One of the two 
will be used. Which one is undefined.

objc[75453]: Class TKMenu is implemented in both 
/System/Library/Frameworks/Tk.framework/Versions/8.5/Tk and 
/Users/ers/.julia/v0.4/Conda/deps/usr/lib/libtk8.5.dylib. One of the two 
will be used. Which one is undefined.

objc[75453]: Class TKContentView is implemented in both 
/System/Library/Frameworks/Tk.framework/Versions/8.5/Tk and 
/Users/ers/.julia/v0.4/Conda/deps/usr/lib/libtk8.5.dylib. One of the two 
will be used. Which one is undefined.

objc[75453]: Class TKWindow is implemented in both 
/System/Library/Frameworks/Tk.framework/Versions/8.5/Tk and 
/Users/ers/.julia/v0.4/Conda/deps/usr/lib/libtk8.5.dylib. One of the two 
will be used. Which one is undefined.

/Users/ers/.julia/v0.4/Conda/deps/usr/lib/python2.7/site-packages/matplotlib/font_manager.py:273:
 
UserWarning: Matplotlib is building the font cache using fc-list. This may 
take a moment.

  warnings.warn('Matplotlib is building the font cache using fc-list. This 
may take a moment.')


julia> plot([1,2],[1,3])

Exception in Tkinter callback

Traceback (most recent call last):

  File 
"/Users/ers/.julia/v0.4/Conda/deps/usr/lib/python2.7/lib-tk/Tkinter.py", 
line 1537, in __call__

return self.func(*args)

  File 
"/Users/ers/.julia/v0.4/Conda/deps/usr/lib/python2.7/site-packages/matplotlib/backends/backend_tkagg.py",
 
line 283, in resize

self.show()

  File 
"/Users/ers/.julia/v0.4/Conda/deps/usr/lib/python2.7/site-packages/matplotlib/backends/backend_tkagg.py",
 
line 355, in draw

tkagg.blit(self._tkphoto, self.renderer._renderer, colormode=2)

  File 
"/Users/ers/.julia/v0.4/Conda/deps/usr/lib/python2.7/site-packages/matplotlib/backends/tkagg.py",
 
line 30, in blit

id(data), colormode, id(bbox_array))

TclError

julia(75453,0x7fff7ce8a000) malloc: *** error for object 0x7ff91bd574d0: 
pointer being freed was not allocated

*** set a breakpoint in malloc_error_break to debug


signal (6): Abort trap: 6

__pthread_kill at /usr/lib/system/libsystem_kernel.dylib (unknown line)

Abort trap: 6


I can't plot anything now. 


Help! 


Thanks.

[julia-users] Re: Trouble with PyPlot

[Ed Scheinerman]

It seems, perhaps, that the problem is actually with PyCall. Other packages 
that I regularly use are now causing problems ...


On Wednesday, May 25, 2016 at 8:22:07 AM UTC-4, Ed Scheinerman wrote:
>
> I use PyPlot a lot with my Julia work so I've got a big problem in that 
> PyPlot has suddenly stopped working after the latest Pkg.update()
>
> julia> using PyPlot
>
> INFO: Precompiling module PyPlot... 
> ERROR: LoadError: InitError: cfunction: pyjlwrap_repr does not return 
>  in __init__ at /Users/ers/.julia/v0.4/PyCall/src/pyinit.jl:88 
>  in _require_from_serialized at loading.jl:84 
>  in _require_from_serialized at /Applications/Julia-0.4.5.app/Contents/
> Resources/julia/lib/julia/sys.dylib 
>  in require at /Applications/Julia-0.4.5.app/Contents/Resources/julia/lib/
> julia/sys.dylib 
>  in include at /Applications/Julia-0.4.5.app/Contents/Resources/julia/lib/
> julia/sys.dylib 
>  in include_from_node1 at /Applications/Julia-0.4.5.app/Contents/Resources
> /julia/lib/julia/sys.dylib 
>  [inlined code] from none:2 
>  in anonymous at no file:0 
>  in process_options at /Applications/Julia-0.4.5.app/Contents/Resources/
> julia/lib/julia/sys.dylib 
>  in _start at /Applications/Julia-0.4.5.app/Contents/Resources/julia/lib/
> julia/sys.dylib 
> during initialization of module PyCall 
> while loading /Users/ers/.julia/v0.4/PyPlot/src/PyPlot.jl, in expression 
> starting on line 5 
> ERROR: Failed to precompile PyPlot to /Users/ers/.julia/lib/v0.4/PyPlot.ji 
>
>  in error at /Applications/Julia-0.4.5.app/Contents/Resources/julia/lib/
> julia/sys.dylib 
>  in compilecache at loading.jl:400 
>  in require at /Applications/Julia-0.4.5.app/Contents/Resources/julia/lib/
> julia/sys.dylib
> Enter code here...
>
>
>

[julia-users] Trouble with PyPlot

[Ed Scheinerman]

I use PyPlot a lot with my Julia work so I've got a big problem in that 
PyPlot has suddenly stopped working after the latest Pkg.update()

julia> using PyPlot

INFO: Precompiling module PyPlot... 
ERROR: LoadError: InitError: cfunction: pyjlwrap_repr does not return 
 in __init__ at /Users/ers/.julia/v0.4/PyCall/src/pyinit.jl:88 
 in _require_from_serialized at loading.jl:84 
 in _require_from_serialized at /Applications/Julia-0.4.5.app/Contents/
Resources/julia/lib/julia/sys.dylib 
 in require at /Applications/Julia-0.4.5.app/Contents/Resources/julia/lib/
julia/sys.dylib 
 in include at /Applications/Julia-0.4.5.app/Contents/Resources/julia/lib/
julia/sys.dylib 
 in include_from_node1 at /Applications/Julia-0.4.5.app/Contents/Resources/
julia/lib/julia/sys.dylib 
 [inlined code] from none:2 
 in anonymous at no file:0 
 in process_options at /Applications/Julia-0.4.5.app/Contents/Resources/
julia/lib/julia/sys.dylib 
 in _start at /Applications/Julia-0.4.5.app/Contents/Resources/julia/lib/
julia/sys.dylib 
during initialization of module PyCall 
while loading /Users/ers/.julia/v0.4/PyPlot/src/PyPlot.jl, in expression 
starting on line 5 
ERROR: Failed to precompile PyPlot to /Users/ers/.julia/lib/v0.4/PyPlot.ji 
 in error at /Applications/Julia-0.4.5.app/Contents/Resources/julia/lib/
julia/sys.dylib 
 in compilecache at loading.jl:400 
 in require at /Applications/Julia-0.4.5.app/Contents/Resources/julia/lib/
julia/sys.dylib
Enter code here...

[julia-users] Re: Complex infinity

[Ed Scheinerman]

I've posted a proposed solution 
here: https://github.com/scheinerman/RiemannComplexNumbers.jl.git


On Saturday, January 10, 2015 at 8:55:09 AM UTC-5, Ed Scheinerman wrote:

 Is there a way to have a single complex infinity? This may come at the 
 cost of computational efficiency I suppose, but I can think of situations 
 where all of the following give the same result:

 julia (1+1im)/0
 Inf + Inf*im

 julia 1im/0
 NaN + Inf*im

 julia 1/0 + im
 Inf + 1.0im

 It would be nice (sometimes) if these were all the same ComplexInf, say. 
 Perhaps there's an extended complex numbers module for this sort of work? 

[julia-users] Re: Complex infinity

[Ed Scheinerman]

And here are additional unfortunate behaviors with complex arithmetic as 
currently implemented. 

First, dividing nonzero by zero should give an infinite result. It does for 
real, but not complex:

julia 1/0
Inf

julia 1/(0+0*im)   # Should be some form of infinity
NaN + NaN*im


Second: Dividing by infinity (expect inf/inf) should give 0, but this is 
inconsistent:

julia 1/Inf
0.0

julia 1/(Inf*im)
0.0 - 0.0im

julia 1/(Inf+Inf*im)   # should be complex zero
NaN + NaN*im




On Saturday, January 10, 2015 at 8:55:09 AM UTC-5, Ed Scheinerman wrote:

 Is there a way to have a single complex infinity? This may come at the 
 cost of computational efficiency I suppose, but I can think of situations 
 where all of the following give the same result:

 julia (1+1im)/0
 Inf + Inf*im

 julia 1im/0
 NaN + Inf*im

 julia 1/0 + im
 Inf + 1.0im

 It would be nice (sometimes) if these were all the same ComplexInf, say. 
 Perhaps there's an extended complex numbers module for this sort of work? 

[julia-users] Re: Complex infinity

[Ed Scheinerman]

Wow! Thanks everyone for the thoughtful replies. It seems that the way to 
go is to create an alternative to Complex{T} types in which there is but a 
single ComplexInfinity. This would be an interesting project but I'm not a 
top-notch coder ... perhaps someone would like to take it on. When they do, 
creating polynomial and rational function types that properly handle 
complex infinity would be good too. That way f(x) =(2x-1)/(x+1) would 
evaluate f(Inf) as 2. :-)

On Saturday, January 10, 2015 at 7:55:09 AM UTC-6, Ed Scheinerman wrote:

 Is there a way to have a single complex infinity? This may come at the 
 cost of computational efficiency I suppose, but I can think of situations 
 where all of the following give the same result:

 julia (1+1im)/0
 Inf + Inf*im

 julia 1im/0
 NaN + Inf*im

 julia 1/0 + im
 Inf + 1.0im

 It would be nice (sometimes) if these were all the same ComplexInf, say. 
 Perhaps there's an extended complex numbers module for this sort of work? 

Re: [julia-users] Re: Complex infinity

[Ed Scheinerman]

OK. Perhaps I'll give this a whirl. Any suggestions for a name for such a 
type. ExtendedComplex or RiemannComplex seem too long, but CompleX (with 
the X for extended) seems too cryptic. 


On Sunday, January 11, 2015 at 10:02:19 AM UTC-6, tshort wrote:

 Speaking as someone who's also not a top-notch coder, it might be easier 
 than you think. It's so easy to create types in Julia that with a few 
 basics and some Googling, you can do quite a bit. You can also start small 
 just to experiment.

 On Sun, Jan 11, 2015 at 8:44 AM, Ed Scheinerman edward.sc...@gmail.com 
 javascript: wrote:

 Wow! Thanks everyone for the thoughtful replies. It seems that the way to 
 go is to create an alternative to Complex{T} types in which there is but a 
 single ComplexInfinity. This would be an interesting project but I'm not a 
 top-notch coder ... perhaps someone would like to take it on. When they do, 
 creating polynomial and rational function types that properly handle 
 complex infinity would be good too. That way f(x) =(2x-1)/(x+1) would 
 evaluate f(Inf) as 2. :-)


 On Saturday, January 10, 2015 at 7:55:09 AM UTC-6, Ed Scheinerman wrote:

 Is there a way to have a single complex infinity? This may come at the 
 cost of computational efficiency I suppose, but I can think of situations 
 where all of the following give the same result:

 julia (1+1im)/0
 Inf + Inf*im

 julia 1im/0
 NaN + Inf*im

 julia 1/0 + im
 Inf + 1.0im

 It would be nice (sometimes) if these were all the same ComplexInf, say. 
 Perhaps there's an extended complex numbers module for this sort of work? 

[julia-users] Types that behave like functions: can I define f(x) using something like getindex

[Ed Scheinerman]

I'm working on a type that will have a function-like behavior, so I'd like 
to write f(x) to evaluate the function f at x. I could define 
getindex(f::MyType,x::Number) so f[x] would behave as desired, but it would 
be aesthetically pleasing to be able to type f(x) in this case. Is there a 
way to have something like a function_call I could define to make this 
happen? Or perhaps this already exists in Julia and I just can't find it. 

Re: [julia-users] Types that behave like functions: can I define f(x) using something like getindex

[Ed Scheinerman]

Great. I'll wait for a stable 0.4. Thanks for the speedy reply.

On Saturday, January 10, 2015 at 8:06:45 AM UTC-6, Mike Innes wrote:

 You can override the `call` function to do just this, but the behaviour is 
 new to 0.4.

 On 10 January 2015 at 14:04, Ed Scheinerman edward.sc...@gmail.com 
 javascript: wrote:

 I'm working on a type that will have a function-like behavior, so I'd 
 like to write f(x) to evaluate the function f at x. I could define 
 getindex(f::MyType,x::Number) so f[x] would behave as desired, but it 
 would be aesthetically pleasing to be able to type f(x) in this case. Is 
 there a way to have something like a function_call I could define to 
 make this happen? Or perhaps this already exists in Julia and I just can't 
 find it. 

[julia-users] Complex infinity

[Ed Scheinerman]

Is there a way to have a single complex infinity? This may come at the cost 
of computational efficiency I suppose, but I can think of situations where 
all of the following give the same result:

julia (1+1im)/0
Inf + Inf*im

julia 1im/0
NaN + Inf*im

julia 1/0 + im
Inf + 1.0im

It would be nice (sometimes) if these were all the same ComplexInf, say. 
Perhaps there's an extended complex numbers module for this sort of work? 

[julia-users] Re: Julia v0.3.4

[Ed Scheinerman]

I had a (fixable) problem installing on my Macbook Air. Upon first launch 
in a terminal window I got this error:

Warning: error initializing module LinAlg:

ErrorException(error compiling __init__: error compiling check_blas: error 
compiling openblas_get_config: could not load module libopenblas: 
dlopen(libopenblas.dylib, 1): Library not loaded: 
/usr/local/Cellar/gcc/4.9.2_1/lib/gcc/4.9/libquadmath.0.dylib

  Referenced from: 
/Applications/Julia-0.3.4.app/Contents/Resources/julia/lib/julia//libgfortran.3.dylib

  Reason: image not found)


Julia then started up but (not surprisingly) it wouldn't invert a matrix. 
The reference to cellar suggested a homebrew fix so I did 

$ brew install homebrew/science/openblas

and relaunched Julia. All seems fine now. My Julia 0.3.3 worked fine. I 
think making the distribution self-contained would be preferable. Or might 
there be something odd with my setup?





On Friday, December 26, 2014 6:43:42 AM UTC-5, Elliot Saba wrote:

 Hello all!  The latest bugfix release of the 0.3.X Julia line has been 
 released.  Binaries are available from the usual place 
 http://julialang.org/downloads/, and as is typical with such things, 
 please report all issues to either the issue tracker 
 https://github.com/JuliaLang/julia/issues, or email this list.

 As this is a bugfix release, there are not too many new big-item features 
 to announce, but if you are interested in the bugs fixed since 0.3.3, this 
 commit log https://github.com/JuliaLang/julia/compare/v0.3.3...v0.3.4 
 should 
 give you an idea of the effort put in by our team of backporters, as they 
 faithfully toiled to bring you an extremely early 2015 Christmas present.

 This is a recommended upgrade for anyone using any of the previous 0.3.x 
 releases, and should act as a drop-in replacement for any of the 0.3.x 
 line. We would like to get feedback if someone has a correctly working 
 program that doesn't work after this upgrade.

 Happy Hacking,
 -E

[julia-users] Text editor for Julia: SynWrite

[Alex Ed]

https://lh5.googleusercontent.com/-wzSwF_SQXtY/VHpi0c3VLhI/AC0/cdthfbVtPmc/s1600/ju.png
SynWrite editor supports Julia lexer. You need to call Options - Addons 
manager - Install, type Julia at the dialog, and select Lexer Julia 
item to install.
Call J lexer via statusbar clicking (if file ext is not JL) or it's called 
automatical.

Tree with funcs is here (left panel called Tree).
Multi-carets like in Sublime Text, also here


http://www.uvviewsoft.com/synwrite/download.html 

[julia-users] Re: Oddness in Graphs.jl

[Ed Scheinerman]

Hi all,

I have found the Graphs.jl package difficult to work with, so I've been 
(slowly) putting together a SimpleGraphs.jl package available 
here: https://github.com/scheinerman/SimpleGraphs.jl 

It's probably not as full featured as the Graphs.jl package, but it's 
easier (at least for me) to use. 

Please note that it is a work in progress, but I welcome contributions.

-Ed

On Friday, November 21, 2014 6:56:06 PM UTC-5, Dahua Lin wrote:

 This is something related to the vertex indexing mechanism. Please file an 
 issue on Graphs.jl. We may discuss how to solve this over there.

 Dahua

 On Saturday, November 22, 2014 6:39:47 AM UTC+8, Richard Futrell wrote:

 Hi all,

 Is this expected behavior? It was surprising to me. On 0.4.0-dev+1745, 
 pulled today, but I had noticed it previously.

 julia using Graphs

 # make a graph and add an edge...

 julia g1 = graph([1, 2], Edge{Int}[])
 Directed Graph (2 vertices, 0 edges)

 julia add_edge!(g1, 1, 2)
 edge [1]: 1 -- 2

 julia edges(g1)
 1-element Array{Edge{Int64},1}:
  edge [1]: 1 -- 2

 # OK, all is well.
 # But how about this graph:

 julia g2 = graph([2, 3], Edge{Int}[])
 Directed Graph (2 vertices, 0 edges)

 julia add_edge!(g2, 2, 3)
 ERROR: BoundsError()
  in add_edge! at /Users/canjo/.julia/v0.4/Graphs/src/graph.jl:87
  in add_edge! at /Users/canjo/.julia/v0.4/Graphs/src/graph.jl:98

 # Despite giving me an error, it did in fact succesfully add the edge:

 julia edges(g2)
 1-element Array{Edge{Int64},1}:
  edge [1]: 2 -- 3

 What's going on here?

 thanks, Richard

[julia-users] Re: Oddness in Graphs.jl

[Ed Scheinerman]

That'd be great. And what I think I'd like to do is to write some 
converters that will take one of my SimpleGraph objects and return 
something that Graphs.jl provides. 

On Saturday, November 22, 2014 9:34:47 AM UTC-5, Dahua Lin wrote:

 I guess we really need some examples on Graphs.jl to make the learning 
 curve less steep.

 Dahua


 On Saturday, November 22, 2014 9:20:10 PM UTC+8, Ed Scheinerman wrote:

 Hi all,

 I have found the Graphs.jl package difficult to work with, so I've been 
 (slowly) putting together a SimpleGraphs.jl package available here: 
 https://github.com/scheinerman/SimpleGraphs.jl 

 It's probably not as full featured as the Graphs.jl package, but it's 
 easier (at least for me) to use. 

 Please note that it is a work in progress, but I welcome contributions.

 -Ed

 On Friday, November 21, 2014 6:56:06 PM UTC-5, Dahua Lin wrote:

 This is something related to the vertex indexing mechanism. Please file 
 an issue on Graphs.jl. We may discuss how to solve this over there.

 Dahua

 On Saturday, November 22, 2014 6:39:47 AM UTC+8, Richard Futrell wrote:

 Hi all,

 Is this expected behavior? It was surprising to me. On 0.4.0-dev+1745, 
 pulled today, but I had noticed it previously.

 julia using Graphs

 # make a graph and add an edge...

 julia g1 = graph([1, 2], Edge{Int}[])
 Directed Graph (2 vertices, 0 edges)

 julia add_edge!(g1, 1, 2)
 edge [1]: 1 -- 2

 julia edges(g1)
 1-element Array{Edge{Int64},1}:
  edge [1]: 1 -- 2

 # OK, all is well.
 # But how about this graph:

 julia g2 = graph([2, 3], Edge{Int}[])
 Directed Graph (2 vertices, 0 edges)

 julia add_edge!(g2, 2, 3)
 ERROR: BoundsError()
  in add_edge! at /Users/canjo/.julia/v0.4/Graphs/src/graph.jl:87
  in add_edge! at /Users/canjo/.julia/v0.4/Graphs/src/graph.jl:98

 # Despite giving me an error, it did in fact succesfully add the edge:

 julia edges(g2)
 1-element Array{Edge{Int64},1}:
  edge [1]: 2 -- 3

 What's going on here?

 thanks, Richard

[julia-users] Re: Current state of 3rd party APIs in Julia?

[Ed]

Please?

On Friday, September 19, 2014 11:37:21 AM UTC-6, Ed wrote:

 Hello, I was wondering if anybody knows what's the current state of the 
 connectors between Julia and postgres, Amazon S3, and Google Storage and 
 Google BigQuery? Do they just work, or are they buggy, or completely 
 unusable/not built yet?

[julia-users] Difficulty with DisjointSets from DataStructures

[Ed Scheinerman]

I ran into the following problem creating partitions of objects of varying 
types. I'm using the DisjointSets structure found in the DataStructures 
module. 

This code runs fine:

using DataStructures

elements = [alpha, beta, gamma, delta]

parts = DisjointSets{ASCIIString}(elements)# this is the line I will 
alter
println(Before: number of parts is ,num_groups(parts))
union!(parts,alpha, beta)
println(After:  number of parts is ,num_groups(parts))

The output is what I expect:

Before: number of parts is 4
After:  number of parts is 3


However, if we change parts to hold objects of Any type we have a problem. 
Change the assignment of parts to this:

parts = DisjointSets{Any}(elements)

Then this is what happens:

Before: number of parts is 4
ERROR: `union!` has no method matching union!(::DisjointSets{Any}, 
::ASCIIString, ::ASCIIString)

By the way, it doesn't help to define elements like this: elements = 
{alpha, beta, gamma, delta}

Is it necessary for union! to check/assert the types of its 2nd and 3rd 
arguments??

[julia-users] Current state of 3rd party APIs in Julia?

[Ed]

Hello, I was wondering if anybody knows what's the current state of the 
connectors between Julia and postgres, Amazon S3, and Google Storage and 
Google BigQuery? Do they just work, or are they buggy, or completely 
unusable/not built yet?

Re: [julia-users] Failed attempt to publish a package

[Ed Scheinerman]

Thank you for these detailed instructions. I *think* I've done all the
steps correctly.

On Mon, Sep 8, 2014 at 4:32 PM, Isaiah Norton isaiah.nor...@gmail.com
wrote:


 But I don't understand what to do or what this exactly means.


 I thought we had a guide for this somewhere, but I can't find it right
 now. So here is a quick shot at outlining the steps.

 Right now the git commit representing that Tag 0.0.1 message in your
 output log only lives on your own computer. By forking the main METADATA
 repository, you can create a personal copy (of METADATA.jl) under your
 GitHub account. Once that copy exists, you can push your local changes to
 your copy (just like any other GitHub project). The trick is that GitHub
 keeps track of the difference between your fork and the master repository,
 and provides a nice button to make a request to merge your changes. That's
 all a pull request is. There are also some buttons for METADATA admins to
 merge those changes, which makes the workflow convenient all around and
 also facilitates some nice things like automatic testing integration.

 1) go to http://github.com/JuliaLang/METADATA.jl and create your own fork:

 [image: Inline image 1]
 This will create a personal clone of the METADATA repository under your
 github account, so that you can commit to it.

 2) add your fork as a remote repository for the METADATA repository on
 your local computer (in the terminal):

 # cd /Users/ers/.julia/METADATA
 # git remote add ers *https://github.com/scheinerman/METADATA.jl.git
 https://github.com/scheinerman/METADATA.jl.git*

 3) push your changes to your fork:

 # git push ers metadata-v2

 4) If all of that works, then go back to the GitHub page for your fork,
 and click the pull request link:

 [image: Inline image 2]

 The next page should show a preview of the changes, which should only
 include the single commit with the message Tag 0.0.1, and then a Create
 Pull Request button at the bottom on the page.


 On Mon, Sep 8, 2014 at 3:39 PM, Ed Scheinerman 
 edward.scheiner...@gmail.com wrote:

 I tried following the instructions here:
 http://docs.julialang.org/en/release-0.3/manual/packages/#publishing-your-package
 to publish my Permutations module (available here: 
 https://github.com/scheinerman/Permutations.jl
 )

 Here's the output I got:

 julia Pkg.publish()
 INFO: Validating METADATA
 INFO: Pushing Permutations permanent tags: v0.0.1
 Permission denied (publickey).
 fatal: Could not read from remote repository.

 Please make sure you have the correct access rights
 and the repository exists.
 ERROR: failed process: Process(`git
 --work-tree=/Users/ers/.julia/v0.3/Permutations
 --git-dir=/Users/ers/.julia/v0.3/Permutations/.git push -q origin
 refs/tags/v0.0.1:refs/tags/v0.0.1`, ProcessExited(128)) [128]
  in wait at
 /Applications/Julia-0.3.0.app/Contents/Resources/julia/lib/julia/sys.dylib
 (repeats 2 times)
  in wait at task.jl:48
  in sync_end at
 /Applications/Julia-0.3.0.app/Contents/Resources/julia/lib/julia/sys.dylib
  in publish at pkg/entry.jl:319
  in anonymous at pkg/dir.jl:28
  in cd at
 /Applications/Julia-0.3.0.app/Contents/Resources/julia/lib/julia/sys.dylib
  in __cd#227__ at
 /Applications/Julia-0.3.0.app/Contents/Resources/julia/lib/julia/sys.dylib
  in publish at pkg.jl:57

 Help!? Thanks.

 PS I did read this on the Julia documentation page:

 For various reasons Pkg.publish() sometimes does not succeed. In those
 cases, you may make a pull request on GitHub, which is not difficult.

 But I don't understand what to do or what this exactly means.







-- 
Ed Scheinerman (e...@scheinerman.net)

[julia-users] Failed attempt to publish a package

[Ed Scheinerman]

I tried following the instructions here:  
http://docs.julialang.org/en/release-0.3/manual/packages/#publishing-your-package
to publish my Permutations module (available here: 
https://github.com/scheinerman/Permutations.jl 
)

Here's the output I got:

julia Pkg.publish()
INFO: Validating METADATA
INFO: Pushing Permutations permanent tags: v0.0.1
Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
ERROR: failed process: Process(`git 
--work-tree=/Users/ers/.julia/v0.3/Permutations 
--git-dir=/Users/ers/.julia/v0.3/Permutations/.git push -q origin 
refs/tags/v0.0.1:refs/tags/v0.0.1`, ProcessExited(128)) [128]
 in wait at 
/Applications/Julia-0.3.0.app/Contents/Resources/julia/lib/julia/sys.dylib 
(repeats 2 times)
 in wait at task.jl:48
 in sync_end at 
/Applications/Julia-0.3.0.app/Contents/Resources/julia/lib/julia/sys.dylib
 in publish at pkg/entry.jl:319
 in anonymous at pkg/dir.jl:28
 in cd at 
/Applications/Julia-0.3.0.app/Contents/Resources/julia/lib/julia/sys.dylib
 in __cd#227__ at 
/Applications/Julia-0.3.0.app/Contents/Resources/julia/lib/julia/sys.dylib
 in publish at pkg.jl:57

Help!? Thanks.

PS I did read this on the Julia documentation page:

For various reasons Pkg.publish() sometimes does not succeed. In those 
cases, you may make a pull request on GitHub, which is not difficult.

But I don't understand what to do or what this exactly means.

Re: [julia-users] @inbounds is broken?

[Ed Scheinerman]

I'd like to use @inbounds also to speed up code that I'm 100% sure has 
proper array indices. But I tried the following experiment and found no 
significant difference using or omitting @inbounds before the array access. 
What am I doing wrong? Or is bounds checking so super efficient that I 
shouldn't worry about it. 

Here's the code:

function filler(data::Array{Int,1}, n::Int, reps::Int=1000)
tic()
for r=1:reps
for k=1:n
data[k]=k
end
end
toc()
end


function fast_filler(data::Array{Int,1},n::Int, reps::Int=1000)
tic()
for r=1:reps
for k=1:n
@inbounds data[k]=k
end
end
toc()
end

n = 10*1000*1000 # 10 million
x = zeros(Int,n)
filler(x,n,1000)
fast_filler(x,n,1000)

Here's the output:

elapsed time: 12.622814907 seconds
elapsed time: 12.287447772 seconds




On Monday, August 4, 2014 1:56:51 PM UTC-4, Jacob Quinn wrote:

 Steve,

 `@inbounds` is certainly tricky because of the lack of documentation, 
 which I think is slightly on purpose as this is meant to be for more 
 advanced usage.

 The main insight to using `@inbounds` correctly is realizing that 
 `@inbounds expression` returns the value `nothing`. That's why your first 
 two examples don't seem to work. The value is indeed being calculated with 
 bounds checking off, but you're not assigning the value anywhere, so 
 `nothing` is the result of the expression. You can also do multi-line 
 turning off of bounds checking by using a `begin...end` block.

 Try the following: 

 function sqrtfirst{T}(a::Array{T, 1})
 @assert(size(a,1) = 1)
 @inbounds ans = sqrt(a[1])
 return ans
 end

 function sqrtfirst{T}(a::Array{T, 1})
 @assert(size(a,1) = 1)
 @inbounds begin
 # do several getindex, setindex! operations
 end
 return ans
 end

 Hope that helps!

 -Jacob


 On Mon, Aug 4, 2014 at 1:45 PM, vav...@uwaterloo.ca javascript: wrote:

 Dear Julia users,

 The usage of the @inbounds macro is not explained the manual, and its 
 syntax appears to be strange.  Consider the three functions at the end of 
 this posting.  Only the third one works -- why?

 In general, I think @inbounds is broken.  Besides the weird syntax, it 
 has two other issues.  First, there is no way to apply the macro to one 
 subscript operation but not another in a long expression (as far as I 
 know).  Second, it is not extensible in the sense that if programmer A 
 implements his/her own array-like structure with his/her own getindex and 
 setindex operations, he/she might like to have two versions of 
 getindex/setindex, one safe/slower and the other unsafe/faster, but there 
 is no way for programmer A to detect whether user B, a user of his/her new 
 array-like structure, has requested @inbounds or not.

 I would like to propose the following replacement for @inbounds, which 
 solves all three problems.  Instead of a macro, there should be two 
 different subscript operations, say a[1] and a[$ 1 $], where the first is 
 safe/slow and the second is unsafe/fast.  The compiler will compile the 
 first as getindex/setindex and the second as getindexUnsafe/setindexUnsafe.

 -- Steve Vavasis
  


 function sqrtfirst{T}(a::Array{T, 1})
 @assert(size(a,1) = 1)
 @inbounds sqrt(a[1])
 end

 function sqrtfirst{T}(a::Array{T, 1})
 @assert(size(a,1) = 1)
 return @inbounds sqrt(a[1])
 end

 function sqrtfirst{T}(a::Array{T, 1})
 @assert(size(a,1) = 1)
 @inbounds return sqrt(a[1])
 end

Re: [julia-users] @inbounds is broken?

[Ed Scheinerman]

The compiler can't know how far I will traverse the array. That's passed in
as an argument. I've run this short of the end (and past the end) and
timings are always the same.

On Friday, August 29, 2014, Johan Sigfrids johan.sigfr...@gmail.com wrote:

 I believe that for simple cases the compiler is smart enough to remove
 bound checking on its own. In that case adding @inbounds won't help.

 On Friday, August 29, 2014 8:03:35 PM UTC+3, Ed Scheinerman wrote:

 I'd like to use @inbounds also to speed up code that I'm 100% sure has
 proper array indices. But I tried the following experiment and found no
 significant difference using or omitting @inbounds before the array access.
 What am I doing wrong? Or is bounds checking so super efficient that I
 shouldn't worry about it.

 Here's the code:

 function filler(data::Array{Int,1}, n::Int, reps::Int=1000)
 tic()
 for r=1:reps
 for k=1:n
 data[k]=k
 end
 end
 toc()
 end


 function fast_filler(data::Array{Int,1},n::Int, reps::Int=1000)
 tic()
 for r=1:reps
 for k=1:n
 @inbounds data[k]=k
 end
 end
 toc()
 end

 n = 10*1000*1000 # 10 million
 x = zeros(Int,n)
 filler(x,n,1000)
 fast_filler(x,n,1000)

 Here's the output:

 elapsed time: 12.622814907 seconds
 elapsed time: 12.287447772 seconds




 On Monday, August 4, 2014 1:56:51 PM UTC-4, Jacob Quinn wrote:

 Steve,

 `@inbounds` is certainly tricky because of the lack of documentation,
 which I think is slightly on purpose as this is meant to be for more
 advanced usage.

 The main insight to using `@inbounds` correctly is realizing that
 `@inbounds expression` returns the value `nothing`. That's why your first
 two examples don't seem to work. The value is indeed being calculated with
 bounds checking off, but you're not assigning the value anywhere, so
 `nothing` is the result of the expression. You can also do multi-line
 turning off of bounds checking by using a `begin...end` block.

 Try the following:

 function sqrtfirst{T}(a::Array{T, 1})
 @assert(size(a,1) = 1)
 @inbounds ans = sqrt(a[1])
 return ans
 end

 function sqrtfirst{T}(a::Array{T, 1})
 @assert(size(a,1) = 1)
 @inbounds begin
 # do several getindex, setindex! operations
 end
 return ans
 end

 Hope that helps!

 -Jacob


 On Mon, Aug 4, 2014 at 1:45 PM, vav...@uwaterloo.ca wrote:

 Dear Julia users,

 The usage of the @inbounds macro is not explained the manual, and its
 syntax appears to be strange.  Consider the three functions at the end of
 this posting.  Only the third one works -- why?

 In general, I think @inbounds is broken.  Besides the weird syntax, it
 has two other issues.  First, there is no way to apply the macro to one
 subscript operation but not another in a long expression (as far as I
 know).  Second, it is not extensible in the sense that if programmer A
 implements his/her own array-like structure with his/her own getindex and
 setindex operations, he/she might like to have two versions of
 getindex/setindex, one safe/slower and the other unsafe/faster, but there
 is no way for programmer A to detect whether user B, a user of his/her new
 array-like structure, has requested @inbounds or not.

 I would like to propose the following replacement for @inbounds, which
 solves all three problems.  Instead of a macro, there should be two
 different subscript operations, say a[1] and a[$ 1 $], where the first is
 safe/slow and the second is unsafe/fast.  The compiler will compile the
 first as getindex/setindex and the second as getindexUnsafe/setindexUnsafe.

 -- Steve Vavasis



 function sqrtfirst{T}(a::Array{T, 1})
 @assert(size(a,1) = 1)
 @inbounds sqrt(a[1])
 end

 function sqrtfirst{T}(a::Array{T, 1})
 @assert(size(a,1) = 1)
 return @inbounds sqrt(a[1])
 end

 function sqrtfirst{T}(a::Array{T, 1})
 @assert(size(a,1) = 1)
 @inbounds return sqrt(a[1])
 end






-- 
Ed Scheinerman (e...@scheinerman.net)

[julia-users] Re: What's new in 0.3?

[Ed Scheinerman]

Thanks again for the pointer to the release notes. 

The issue I raised was not dealt with in the release notes: namely, 1:5 == 
[1:5] evaluates as true in Julia 0.2 but as false in Julia 0.3. 

I think the new behavior is a problem. I was happy with the old behavior, 
but if this is a bad idea for some reason, I would prefer that Julia raised 
an error in this situation rather than give a result that (in my opinion) 
is wrong. Certainly Julia compares objects of different type for equality 
(e.g. 0==0.0) so the fact that 1:5 and [1:5] are different types is not the 
issue. 
 


 On Saturday, August 23, 2014 9:06:50 AM UTC-4, Valentin Churavy wrote:

 There is https://github.com/JuliaLang/julia/blob/v0.3.0/NEWS.md 

 On Saturday, 23 August 2014 15:02:56 UTC+2, Ed Scheinerman wrote:

 Is there a document describing new features and significant changes 
 between versions 0.2 and 0.3? 

 One item I noticed is that in 0.2 the express 1:5 == [1:5] evaluated as 
 true, but in 0.3 it's false. 

Re: [julia-users] What's new in 0.3?

[Ed Scheinerman]

Given a choice between 1:10==[1:10] returning false or throwing an error,
I'd vote for error.


On Mon, Aug 25, 2014 at 12:06 PM, Stefan Karpinski ste...@karpinski.org
wrote:

 If you (or anyone) can come up with a clever scheme for hashing arrays and
 ranges so that 1:n and [1:n] hash the same but hash(1:n) isn't an O(n)
 operations, I'd be thrilled to switch this back. I could not figure out a
 good way to do this, however.


 On Mon, Aug 25, 2014 at 11:47 AM, Jacob Quinn quinn.jac...@gmail.com
 wrote:

 See this issue: https://github.com/JuliaLang/julia/issues/7867 and the
 discussion in https://github.com/JuliaLang/julia/issues/5778 for
 information on the change.

 -Jacob


 On Sat, Aug 23, 2014 at 9:02 AM, Ed Scheinerman 
 edward.scheiner...@gmail.com wrote:

 Is there a document describing new features and significant changes
 between versions 0.2 and 0.3?

 One item I noticed is that in 0.2 the express 1:5 == [1:5] evaluated as
 true, but in 0.3 it's false.






-- 
Ed Scheinerman (e...@scheinerman.net)

Re: [julia-users] Re: What's new in 0.3?

[Ed Scheinerman]

My bad. Didn't read this carefully enough to realize this comment applied
to my issue.


On Mon, Aug 25, 2014 at 11:47 AM, John Myles White johnmyleswh...@gmail.com
 wrote:

 The NEWS.md file does cover this:

 • Ranges and arrays with the same elements are now unequal. This allows
 hashing and comparing ranges to be faster. (#5778)

 On Aug 25, 2014, at 8:45 AM, Ed Scheinerman edward.scheiner...@gmail.com
 wrote:

  Thanks again for the pointer to the release notes.
 
  The issue I raised was not dealt with in the release notes: namely, 1:5
 == [1:5] evaluates as true in Julia 0.2 but as false in Julia 0.3.
 
  I think the new behavior is a problem. I was happy with the old
 behavior, but if this is a bad idea for some reason, I would prefer that
 Julia raised an error in this situation rather than give a result that (in
 my opinion) is wrong. Certainly Julia compares objects of different type
 for equality (e.g. 0==0.0) so the fact that 1:5 and [1:5] are different
 types is not the issue.
 
 
  On Saturday, August 23, 2014 9:06:50 AM UTC-4, Valentin Churavy wrote:
  There is https://github.com/JuliaLang/julia/blob/v0.3.0/NEWS.md
 
  On Saturday, 23 August 2014 15:02:56 UTC+2, Ed Scheinerman wrote:
  Is there a document describing new features and significant changes
 between versions 0.2 and 0.3?
 
  One item I noticed is that in 0.2 the express 1:5 == [1:5] evaluated as
 true, but in 0.3 it's false.




-- 
Ed Scheinerman (e...@scheinerman.net)

[julia-users] What's new in 0.3?

[Ed Scheinerman]

Is there a document describing new features and significant changes between 
versions 0.2 and 0.3? 

One item I noticed is that in 0.2 the express 1:5 == [1:5] evaluated as true, 
but in 0.3 it's false. 

[julia-users] Re: What's new in 0.3?

[Ed Scheinerman]

THANKS!

On Saturday, August 23, 2014 9:06:50 AM UTC-4, Valentin Churavy wrote:

 There is https://github.com/JuliaLang/julia/blob/v0.3.0/NEWS.md 

 On Saturday, 23 August 2014 15:02:56 UTC+2, Ed Scheinerman wrote:

 Is there a document describing new features and significant changes 
 between versions 0.2 and 0.3? 

 One item I noticed is that in 0.2 the express 1:5 == [1:5] evaluated as 
 true, but in 0.3 it's false. 

[julia-users] sizehint for Set objects

[Ed Scheinerman]

I work a good deal with Set objects. When I found the sizehint function, I 
thought this would be useful to use as the data structure supporting my 
sets would be pre-allocated to be large enough for what I anticipated 
putting therein. But sizehint doesn't apply to Set objects:

julia A = Set()
Set{Any}()

julia sizehint(A,1000)
ERROR: no method sizehint(Set{Any},Int64)

It appears that, under the hood, Set objects are built on top of Dict 
objects. So one can do this:

julia sizehint(A.dict,1000)
Dict{Any,Nothing}()

But if the implementation of Set changes, this breaks. 

So I'm voicing all this to request that sizehint(Set) be implemented. 

Re: [julia-users] sizehint for Set objects

[Ed Scheinerman]

Not a disappointment at all! I look forward to 0.3 being officially 
released. Thank you.


On Saturday, August 2, 2014 4:00:12 PM UTC-4, Kevin Squire wrote:

 (Hope this isn't a disappointment, but this was implemented already in 
 v0.3.)


 On Sat, Aug 2, 2014 at 10:59 AM, Ivar Nesje iva...@gmail.com 
 javascript: wrote:

 Note that we're not lazy, but we know that contributing to Julia is 
 highly addictive. We want more people to look at Base with a critical eye 
 in order to discover inconsistencies like this.

 If you don't want to try, the fix will be committed within an hour.

 Ivar

 kl. 18:30:55 UTC+2 lørdag 2. august 2014 skrev Stefan Karpinski følgende:

 Would you be willing to take a crack at making a pull request? This 
 should be a one-liner, somewhere in the base/set.jl file with the obvious 
 definition.


  On Sat, Aug 2, 2014 at 10:04 AM, Ed Scheinerman edward.sc...@gmail.com
  wrote:

 I work a good deal with Set objects. When I found the sizehint 
 function, I thought this would be useful to use as the data structure 
 supporting my sets would be pre-allocated to be large enough for what I 
 anticipated putting therein. But sizehint doesn't apply to Set objects:

 julia A = Set()
 Set{Any}()

 julia sizehint(A,1000)
 ERROR: no method sizehint(Set{Any},Int64)

 It appears that, under the hood, Set objects are built on top of Dict 
 objects. So one can do this:

 julia sizehint(A.dict,1000)
 Dict{Any,Nothing}()

 But if the implementation of Set changes, this breaks. 

 So I'm voicing all this to request that sizehint(Set) be implemented. 

Re: [julia-users] Permutation data type for Julia

[Ed Scheinerman]

Kevin: Thanks again. I have uploaded Permutations.jl to github but not yet
tagged and submitted. (I've also posted some other modules there I've been
working on.) Before tagging and submitting, I would like to create a
runtests.jl file in a test directory, but don't know how to structure that.
Perhaps you can provide me with a *simple* version so I can use that as a
template? -Ed


On Fri, Jul 25, 2014 at 12:07 AM, Kevin Squire kevin.squ...@gmail.com
wrote:




 On Thu, Jul 24, 2014 at 4:52 PM, Ed Scheinerman 
 edward.scheiner...@gmail.com wrote:

 Thanks Kevin.

 Sure. I’d be happy to do so. In a sense, this was a little project for me
 to learn how to work in Julia and practice for a more extensive package I’m
 doing for SimpleGraphs (that is not quite ready for prime time).  What do I
 need to do to be “in compliance”?


 :-) Not much, just some minor renaming/rearrangements.  Almost all of this
 is convention, but mostly just taken for the right way to do things:

 First, the best way to start a package (and maybe recreate this one) is
 probably to run Pkg.generate(MyPackage.jl).  This will create the basic
 package structure for you under .julia/v0.3 (or whatever version you're
 running), with the preferred directory structure and skeletons for all of
 the typical files you'll need/want.  You might just want to run this
 command to create a dummy package (or recreate this one) to see what it
 does.

 That aside, starting from your package:

 1. You probably noticed that packages can't contain types with the same
 name as the package, and you gave your package a lower-case name.  However,
 packages in Julia are upper case by convention, which causes problems when
 you have a package like Permutation with a type called Permutation.

 The solution that has emerged is to pluralize the package name (and module
 name).  So, `Permutations` and `module Permutations`.

 2. (Almost?) all package names have a .jl suffix.  Convention again, but
 it makes it really easy to find them on github and with Google, etc.  So
 the repository name on Github should be `Permutations.jl`.  (Your local
 copy will still be named Permutations, with no suffix.)

 3. This is taken care of by the first two points, but it's also pretty
 much necessary that the package, main source file and module have the same
 name (including case).  If you name the file Permutations.jl and put it
 in ~/.julia/v0.3/Permutations/src/, Julia will automatically find it when
 do `using Permutations` or `import Permutations`.  (No magic--that's the
 first place Julia looks.)

 4. If you want, you could create a test directory with a file called
 runtests.jl, which will run some basic tests on your code.  If you do,
 these tests will be run automatically, once per day (against the latest
 version of Julia).  May not mean much for Permutations.jl, but at least you
 would know if some change in Julia broke your code.

 5. While I appreciate latex as much as the next geek, it would probably be
 better to write your documentation using markdown, and perhaps as part of
 README.md for now.

 For your docs, in particular, this would be pretty trivial.  The only
 trick maybe is knowing that you can write verbatim blocks using triple
 backtics and (optionally) the language name:

 ```julia
 julia two_row(p)
 2x6 Array{Int64,2}:
  1  2  3  4  5  6
  4  1  3  2  6  5
 ```

 =

 Once you've made these changes, you can tag and submit a version in
 METADATA.jl.  Rather than discuss that in detail, I'll refer you to the
 docs, but if you have any questions, please feel free to write back here
 with questions or to ask for help.

 Packaging docs:

-
http://julia.readthedocs.org/en/latest/manual/packages/#package-development
-

 https://github.com/JuliaLang/julia/blob/kms/pkg_doc_updates/doc/manual/packages.rst#making-your-package-available

 The first link is the official docs. The second is part of a pull request
 that I hope gets integrated at some point, and which better explains the
 newer, easier (but still somewhat experimental) way of tagging packages in
 Julia v0.3.

 Hope this was helpful, and not too onerous.

 Cheers,
Kevin



 Best,
 Ed


 On Jul 24, 2014, at 2:06 PM, Kevin Squire kevin.squ...@gmail.com wrote:

 Dear Ed,

 Thank you for announcing this!  I don't have any projects right now
 that need permutations, but I have in the past, and while there is some
 support for permutations in mainline Julia, permutations as a data type are
 definitely useful!

 I'm wondering if you're interested in creating an official package out of
 this?  It would require a few small changes to follow Julia conventions,
 but would make it easier for people to test. What do you think?

 Cheers!
Kevin

 On Thursday, July 24, 2014, Ed Scheinerman edward.scheiner...@gmail.com
 wrote:

 Dear all,

 I've created a Permutation data type for Julia. A Permutation object
 represents a permutation of a finite set of the form {1,2,...,n

Re: [julia-users] Permutation data type for Julia

[Ed Scheinerman]

I've got the Permutations package on git now and available here:
https://github.com/scheinerman/Permutations.jl.git

But I've run into the following trouble when trying to publish. Here's what
I get (and I'm using Julia 0.2.1):

julia Pkg.register(Permutations)
INFO: Registering Permutations at git://
github.com/scheinerman/Permutations.jl.git
INFO: Committing METADATA for Permutations

julia Pkg.publish()
ERROR: METADATA is behind origin/metadata-v2 – run Pkg.update() before
publishing
 in publish at pkg/entry.jl:259
 in anonymous at pkg/dir.jl:28
 in cd at file.jl:22
 in cd at pkg/dir.jl:28
 in publish at pkg.jl:53

julia Pkg.update()
INFO: Updating METADATA...
INFO: Updating SimpleGraphs...
INFO: Updating ShowSet...
INFO: Updating Bijections...
INFO: Updating Permutations...
INFO: Computing changes...
INFO: No packages to install, update or remove.

julia Pkg.publish()
ERROR: METADATA is behind origin/metadata-v2 – run Pkg.update() before
publishing
 in publish at pkg/entry.jl:259
 in anonymous at pkg/dir.jl:28
 in cd at file.jl:22
 in cd at pkg/dir.jl:28
 in publish at pkg.jl:53

Suggestions?


On Sun, Jul 27, 2014 at 10:01 AM, Ed Scheinerman 
edward.scheiner...@gmail.com wrote:

 Kevin: Thanks again. I have uploaded Permutations.jl to github but not yet
 tagged and submitted. (I've also posted some other modules there I've been
 working on.) Before tagging and submitting, I would like to create a
 runtests.jl file in a test directory, but don't know how to structure that.
 Perhaps you can provide me with a *simple* version so I can use that as a
 template? -Ed


 On Fri, Jul 25, 2014 at 12:07 AM, Kevin Squire kevin.squ...@gmail.com
 wrote:




 On Thu, Jul 24, 2014 at 4:52 PM, Ed Scheinerman 
 edward.scheiner...@gmail.com wrote:

 Thanks Kevin.

 Sure. I’d be happy to do so. In a sense, this was a little project for
 me to learn how to work in Julia and practice for a more extensive package
 I’m doing for SimpleGraphs (that is not quite ready for prime time).  What
 do I need to do to be “in compliance”?


 :-) Not much, just some minor renaming/rearrangements.  Almost all of
 this is convention, but mostly just taken for the right way to do things:

 First, the best way to start a package (and maybe recreate this one) is
 probably to run Pkg.generate(MyPackage.jl).  This will create the basic
 package structure for you under .julia/v0.3 (or whatever version you're
 running), with the preferred directory structure and skeletons for all of
 the typical files you'll need/want.  You might just want to run this
 command to create a dummy package (or recreate this one) to see what it
 does.

 That aside, starting from your package:

 1. You probably noticed that packages can't contain types with the same
 name as the package, and you gave your package a lower-case name.  However,
 packages in Julia are upper case by convention, which causes problems when
 you have a package like Permutation with a type called Permutation.

 The solution that has emerged is to pluralize the package name (and
 module name).  So, `Permutations` and `module Permutations`.

 2. (Almost?) all package names have a .jl suffix.  Convention again,
 but it makes it really easy to find them on github and with Google, etc.
  So the repository name on Github should be `Permutations.jl`.  (Your local
 copy will still be named Permutations, with no suffix.)

 3. This is taken care of by the first two points, but it's also pretty
 much necessary that the package, main source file and module have the same
 name (including case).  If you name the file Permutations.jl and put it
 in ~/.julia/v0.3/Permutations/src/, Julia will automatically find it when
 do `using Permutations` or `import Permutations`.  (No magic--that's the
 first place Julia looks.)

 4. If you want, you could create a test directory with a file called
 runtests.jl, which will run some basic tests on your code.  If you do,
 these tests will be run automatically, once per day (against the latest
 version of Julia).  May not mean much for Permutations.jl, but at least you
 would know if some change in Julia broke your code.

 5. While I appreciate latex as much as the next geek, it would probably
 be better to write your documentation using markdown, and perhaps as part
 of README.md for now.

 For your docs, in particular, this would be pretty trivial.  The only
 trick maybe is knowing that you can write verbatim blocks using triple
 backtics and (optionally) the language name:

 ```julia
 julia two_row(p)
 2x6 Array{Int64,2}:
  1  2  3  4  5  6
  4  1  3  2  6  5
 ```

 =

 Once you've made these changes, you can tag and submit a version in
 METADATA.jl.  Rather than discuss that in detail, I'll refer you to the
 docs, but if you have any questions, please feel free to write back here
 with questions or to ask for help.

 Packaging docs:

-

 http://julia.readthedocs.org/en/latest/manual/packages/#package-development
-

 https://github.com

[julia-users] Permutation data type for Julia

[Ed Scheinerman]

Dear all,

I've created a Permutation data type for Julia. A Permutation object 
represents a permutation of a finite set of the form {1,2,...,n}. 
Operations include composition and inverses. Output is in disjoint cycle 
format. I hope someone finds this useful.

It's available for download from github:

https://github.com/scheinerman/Permutation.git

but all you need is the file permutation.jl (attached) and the brief 
instructions permutation.pdf (also attached).

-Ed Scheinerman




permutation.jl
Description: Binary data


permutation.pdf
Description: Adobe PDF document

Re: [julia-users] Permutation data type for Julia

[Ed Scheinerman]

Thanks Kevin.

Sure. I’d be happy to do so. In a sense, this was a little project for me to 
learn how to work in Julia and practice for a more extensive package I’m doing 
for SimpleGraphs (that is not quite ready for prime time).  What do I need to 
do to be “in compliance”?

Best,
Ed


On Jul 24, 2014, at 2:06 PM, Kevin Squire kevin.squ...@gmail.com wrote:

 Dear Ed,
 
 Thank you for announcing this!  I don't have any projects right now that need 
 permutations, but I have in the past, and while there is some support for 
 permutations in mainline Julia, permutations as a data type are definitely 
 useful!
 
 I'm wondering if you're interested in creating an official package out of 
 this?  It would require a few small changes to follow Julia conventions, but 
 would make it easier for people to test. What do you think?
 
 Cheers!
Kevin 
 
 On Thursday, July 24, 2014, Ed Scheinerman edward.scheiner...@gmail.com 
 wrote:
 Dear all,
 
 I've created a Permutation data type for Julia. A Permutation object 
 represents a permutation of a finite set of the form {1,2,...,n}. Operations 
 include composition and inverses. Output is in disjoint cycle format. I hope 
 someone finds this useful.
 
 It's available for download from github:
 
 https://github.com/scheinerman/Permutation.git
 
 but all you need is the file permutation.jl (attached) and the brief 
 instructions permutation.pdf (also attached).
 
 -Ed Scheinerman
 
 

[julia-users] Julia build with ifort?

[Ed Z]

Hi All,

I recently had to rebuild julia on a machine without gfortran installed, 
and noticed some of the libraries it downloads are compiled with gfortran 
by default.

Has anyone looked at building julia with ifort? It would be nice to use 
intel's implementation of the blas and lapack in the mkl.

-Ed

[julia-users] Re: Help getting started with Julia's Graphs package

[Ed Scheinerman]

Thanks. This helps some. Let me illustrate. I just want simple graphs with 
integer-named vertices. This starts off well:

julia using Graphs

julia g = simple_graph(4)
Directed Graph (4 vertices, 0 edges)

julia using Graphs

julia g = simple_graph(4,is_directed=false)
Undirected Graph (4 vertices, 0 edges)

julia add_edge!(g,1,2)
edge [1]: 1 -- 2

But if I want to add an additional vertex, I get trouble:

julia add_vertex!(g,5)
ERROR: no method push!(Range1{Int64},Int64)
 in add_vertex! at /home/ers/.julia/Graphs/src/graph.jl:50

And I can't figure out how to delete vertices!



On Sunday, February 23, 2014 12:50:01 PM UTC-5, Uwe Korn wrote:


 On Saturday, 22 February 2014 22:24:24 UTC, Ed Scheinerman wrote:

 I have looked through the documentation for the Graphs package here:
  http://julialang.org/Graphs.jl/index.html 
 http://julialang.org/Graphs.jl/index.html
 But I'm finding it difficult to get started, even creating simple graphs 
 (undirected, no loops, no multiple edges). Adding vertices doesn't seem to 
 work. 


 For an adjacency list representation, this short snippet may be helpful:

 using Graphs

 # Create new graph
 g = adjlist(KeyVertex{ASCIIString}, is_directed=false)

 # Add 2 vertices
 v = add_vertex!(g, v)
 u = add_vertex!(g, u)

 # Add an edge between them
 add_edge!(g, v, u)

 # This will print:

 #   KeyVertex{ASCIIString}(1,v)

 # which is the neighbour of u
 println(out_neighbors(u, g))

  

 Is there a tutorial somewhere to help me get started? Thanks. 


 I'm not aware of a tutorial (which would be indeed very helpful) but I 
 learnt how to use the Graphs package by looking at its tests like 
 https://github.com/JuliaLang/Graphs.jl/blob/master/test/adjlist.jl which 
 outline quite short how that package works.