Re: [julia-users] Pre-ANN: PlotlyJS.jl

[Tom Breloff]

Much of Plotly.jl is for interacting with the cloud API (login,
credentials, etc). The remainder cannot be called directly so, for my
purpose, it made more sense to just build the json directly. Others will
likely still find this package to be useful.

On Monday, November 23, 2015, Sisyphuss  wrote:

> So the following package is no longer useful?
>
> https://github.com/plotly/Plotly.jl
>

[julia-users] Re: Pre-ANN: PlotlyJS.jl

[Tony Kelman]

Try using dirname(@__FILE__) instead of Pkg.dir

Re: [julia-users] Julia Install in Heterogenous Linux Environment: Target architecture mismatch

[Ian Watson]

Thank you Yichao

Updating binutils solved the problem. Note that the link says that binutils 
needed to be at 2.18 or better, but the initial version on the system was 
2.20 which failed. Once I updated to the latest, 2.25.1, everything worked. 
Maybe some other earlier versions might have worked too...

So, now I have julia built with 

MARCH=x86-64 OPENBLAS_DYNAMIC_ARCH=0 make

(or MARCH=core2) and it seems to be working on all the hardware in our 
cluster.

Now, presumably I am losing some performance on various pieces of hardware, 
but that can wait for another day...

As ever, the Julia community works just great...

Thanks!

Ian

On Monday, November 23, 2015 at 12:08:16 PM UTC-5, Yichao Yu wrote:
>
> On Mon, Nov 23, 2015 at 11:43 AM, Ian Watson  > wrote: 
> > We have a Linux cluster that consists of different models of hardware. 
> > 
> > If I build Julia on one kind of hardware, say 
> > 
> > model name  : Intel(R) Xeon(R) CPU E5-2680 v3 @ 2.50GHz 
> > 
> > but then run that installation on another kind of hardware, say 
> > 
> > model name  : Intel(R) Xeon(R) CPU E5-2670 0 @ 2.60GHz 
> > 
> > I will usually get an error message 
> > 
> > ERROR: Target architecture mismatch. Please delete or regenerate 
> > sys.{so,dll,dylib}. 
> > 
> > As far as I know, the underlying O/S and software on both machines is 
> the 
> > same, Red Hat Enterprise Linux Server release 6.6 (Santiago), but I 
> cannot 
> > be 100% certain about that. I am compiling with gcc-5.2.0 
> > 
> > I tried the suggestion in DISTRIBUTING.md, but setting MARCH to either 
> core2 
> > or x86-64 failed on the E5-2680 machine - openblas usually fails 
>
> Yes, you should build with an architecture that is compatible with all 
> the ones you want to run on. 
>
>
> > 
> > ../kernel/x86_64/dtrmm_kernel_4x8_haswell.c:79: Error: no such 
> instruction: 
> > `vpermpd $0xb1,%ymm3,%ymm3' 
>
> binutils too old 
>
> https://github.com/julialang/julia#linux-build-troubleshooting 
>
> > 
> > A discussion thread a year ago seemed to indicate some problems as 
> well... 
> > 
> > https://groups.google.com/forum/#!topic/julia-users/3H9Krno8aVU 
> > 
> > I can of course build an architecture specific Julia for each different 
> kind 
> > of hardware we have, or some subset of them, and then invoke the right 
> > version depending on where the job is run, but is there an easier way? 
> > 
> > 
>

[julia-users] Re: `(,a) = (1,2)` returns an error

[Seth]

Why not simply

_, x, _, y = f()

? This seems easier to read and understand. _ is a valid variable but is 
typically used for superfluous assignment.

On Monday, November 23, 2015 at 9:56:27 AM UTC-8, Sisyphuss wrote:
>
> OK, so if I have a function which returns a tuple (a,b,c,d), 
> but I only want the 2nd and 4th value, the most concise way is
>
> (x,y) = f()[[2;4]]
>
>

Re: [julia-users] Pre-ANN: PlotlyJS.jl

[Tom Breloff]

Thanks Eric. @joshday has been working on this as well in PlotlyLocal.jl,
and I'm working on a plotly backend built into Plots.jl. If you have any
interest in collaborating please let me know.

On Monday, November 23, 2015, Tony Kelman  wrote:

> Try using dirname(@__FILE__) instead of Pkg.dir

[julia-users] Re: ERROR: LoadError: UndefVarError: mesh not defined. using MeshIO

[Simon Danisch]

Well, it's load, not mesh...
I admit, the Readme is not very helpfull.
By the way, the REPL with typeof(), xdump(), println(), methodswith() and auto 
completion are your friend when it comes to figuring out how a type works.

Am Montag, 23. November 2015 15:38:44 UTC+1 schrieb kleinsplash:
> My aim is to load an object file and access its faces, vertices and normals. 
> 
> My current code:
> 
> 
> 
> using FileIO
> using GLVisualize
> using MeshIO
> 
> obj_file = "path_to_obj/file.obj"
> mesh(obj_file)
> I am getting the error: 
> 
> ERROR: LoadError: UndefVarError: mesh not defined
>  in include at ./boot.jl:261
>  in include_from_node1 at ./loading.jl:304
>  in process_options at ./client.jl:280
>  in _start at ./client.jl:378
> 
> Am I calling the mesh fxn incorrectly?

[julia-users] Re: Pre-ANN: PlotlyJS.jl

[Sisyphuss]

So the following package is no longer useful?

https://github.com/plotly/Plotly.jl

Re: [julia-users] Re: PyPlot behavior change in 0.4? (plt[:show] required?)

[Daniel Carrera]

It definitely looks as if you are just passing the script to the Julia
executable. So as soon as the program terminates all windows close.  Like
Steven said, it would be exactly the same in Python. If you want windows to
be permanent, you probably should be in the Julia (or Python) shell.

Cheers,
Daniel


On 23 November 2015 at 15:34, kleinsplash 
wrote:

> With Sublime I am using cnt+b and vim :!julia %. Both work just fine. I
> don't have a question, happy to use show as stated.
>
> On Monday, 23 November 2015 16:29:41 UTC+2, Steven G. Johnson wrote:
>>
>> On Monday, November 23, 2015 at 8:43:36 AM UTC-5, kleinsplash wrote:
>>>
>>> Yup. Not sure why but using Sublime/VIM I can only see PyPlot and Gadfly
>>> using plt[:show](); display(gcf()) does not work for me.
>>>
>>
>> What do you mean by "using Sublime/VIM"?  Are you editing a Julia script
>> foo.jl and then running it with "julia foo.jl"?   Just like in Python, if
>> you run Julia in non-interactive mode then Matplotlib is also run in
>> non-interactive mode, and you need plt[:show]() when you want the plot to
>> appear.
>>
>> If you are using some plugin for Sublime or VIM that allows you to
>> execute code in a running Julia session, but which is not using IJulia,
>> then maybe it is forgetting to turn on interactive mode (see
>> https://github.com/JuliaLang/IJulia.jl/blob/ca35a6397d5e430f94c087f727a499b8e6ecf906/src/kernel.jl#L28-L29
>> )
>>
>

[julia-users] Re: Versioning for unregistered Packages

[Leonardo]

Moreover, digging into Pkg code, I've found that version is returned by 
Pkg.Read.installed_version(), which requires firstly a call to 
Pkg.Read.available(pkgname::AbstractString), but calling this last method 
from REPL I get an empty Dict also for "normal" packages.
Maybe because Base (and all sub-packages) is precompiled?

Leonardo



Il giorno venerdì 20 novembre 2015 20:06:45 UTC+1, Leonardo ha scritto:
>
> Yes, but with no results (I've forgotten to indicate it in previous 
> message)
>
> I've tagged with Pkg.tag() after package was commited and tagged with 
> git: state of source is in correct state to do this?
>
> Thanks
>
> Leonardo
>
>
> Il giorno venerdì 20 novembre 2015 10:41:27 UTC+1, Kristoffer Carlsson ha 
> scritto:
>>
>> Did you tag with Pkg.tag("...")?
>
>

Re: [julia-users] Simple Quesiton about svd() function

[Milan Bouchet-Valat]

Le dimanche 22 novembre 2015 à 18:58 -0800, Michael Bullman a écrit :
> Hi All, 
> 
> I have a pretty easy question about how/why the svd() behaves how it
> does. 
> 
> Why are my U and V matrices always a factor of -1 from the textbook
> examples? I'm just getting my feet wet with all this, so I wanted to
> check what the function returns vs what the textbook says the answers
> would be, and it looks like it's always off by negative one. 
> 
> julia> A = [1 2 ; 2 2; 2 1]
> 3x2 Array{Int64,2}:
>  1  2
>  2  2
>  2  1
> 
> julia> U, s, V = svd(A, thin=false)
> (
> 3x3 Array{Float64,2}:
>  -0.514496   0.707107   0.485071
>  -0.685994   0.0   -0.727607
>  -0.514496  -0.707107   0.485071,
> 
> [4.123105625617661,0.],
> 2x2 Array{Float64,2}:
>  -0.707107  -0.707107
>  -0.707107   0.707107)
> 
> 
> text book shows the 1,1 entry of U to be 
> julia> 3/sqrt(34)
> 0.5144957554275265
> 
> without a negtive sign. really just all the negative signs are
> reversed. 
> source: http://www.math.iit.edu/~fass/477577_Chapter_2.pdf
> 
> 2nd example:
> julia> A = [3 2 -2 ; 2 3 -2]
> 2x3 Array{Int64,2}:
>  3  2  -2
>  2  3  -2
> 
> julia> U, s, V = svd(A, thin=false)
> (
> 2x2 Array{Float64,2}:
>  -0.707107  -0.707107
>  -0.707107   0.707107,
> 
> [5.744562646538029,1.0],
> 3x3 Array{Float64,2}:
>  -0.615457  -0.707107 0.348155
>  -0.615457   0.707107 0.348155
>   0.492366   5.55112e-17  0.870388)
> 
> which is U and V are negative
> http://www.d.umn.edu/~mhampton/m4326svd_example.pdf
> 
> So did I just get back luck with example problems? I feel like it's
> probably just a difference in convention or something, but figured I
> would ask for a definitive answer. Thank you for any help
Yes, this is just a matter of convention. Obviously you can flip the
sign of the first columns of U and V and still reconstruct the same
original matrix. You would need to apply additional rules if you want
to get reliably the same solution (e.g. that coefficients in the first
line of U should be positive).

FWIW, R using the reference BLAS returns the same results as Julia.


Regards

[julia-users] Re: Ray tracing for complex geometry

[Simon Danisch]

I'm still confused about what you want.
Google says:
"In computer graphics, ray tracing is a technique for generating an Image by 
tracing the path of light through pixels in an image plane and simulating the 
effects of its encounters with virtual objects." which is pretty much what I 
understand under ray tracing.
So what is your goal? Usually ray tracing is used when you want a realistically 
lit render(plot) of a 3d scene, or if you have some implicitely defined 
geometry ( like steve kelly pointed out).
Usually you have a mesh in an obj file, which you would only ray trace when you 
need photo realism (since it's way slower then any other displaying method).
I'm really unsure, why you want to get out a 3d matrix in the end. Do you want 
to compute a lightfield?! Or do you want to have an interpolated voxel 
representation of that mesh in a dense volume? This is probably not what you 
really want and also not what a ray tracer produces.
The last thing I can imagine is, that you actually have only vertices(points) 
in your obj file without any faces, which then wouldn't really show up in a 
plot, so that you started assuming it's not dense enough. I wouldn't call 
pointclouds a complex geometry though, since its one of the most simplest.
If that's the case, you should just visualize them as particles.
Here is how you would do that in GLVisualize:
Using FileIO, GLVisualize
obj = load("pathtoobj.obj")
points = vertices(obj)
w,r = glscreen()
view(visualize(points))
r()

If you have problems with that example, please file an issue on github under 
GLVisualize.jl.


Best,
Simon

Re: [julia-users] Simple Quesiton about svd() function

[Tamas Papp]

U and V are not unique. Even when A is square and nonsingular, you eg
can multiply them by a diagonal unitary matrix (the same one for both,
of course).

Best,

Tamas

On Mon, Nov 23 2015, Michael Bullman  wrote:

> Hi All, 
>
> I have a pretty easy question about how/why the svd() behaves how it does. 
>
> Why are my U and V matrices always a factor of -1 from the textbook 
> examples? I'm just getting my feet wet with all this, so I wanted to check 
> what the function returns vs what the textbook says the answers would be, 
> and it looks like it's always off by negative one. 
>
> julia> A = [1 2 ; 2 2; 2 1]
> 3x2 Array{Int64,2}:
>  1  2
>  2  2
>  2  1
>
> julia> U, s, V = svd(A, thin=false)
> (
> 3x3 Array{Float64,2}:
>  -0.514496   0.707107   0.485071
>  -0.685994   0.0   -0.727607
>  -0.514496  -0.707107   0.485071,
>
> [4.123105625617661,0.],
> 2x2 Array{Float64,2}:
>  -0.707107  -0.707107
>  -0.707107   0.707107)
>
>
> text book shows the 1,1 entry of U to be 
> julia> 3/sqrt(34)
> 0.5144957554275265
>
> without a negtive sign. really just all the negative signs are reversed. 
> source: http://www.math.iit.edu/~fass/477577_Chapter_2.pdf
>
> 2nd example:
> julia> A = [3 2 -2 ; 2 3 -2]
> 2x3 Array{Int64,2}:
>  3  2  -2
>  2  3  -2
>
> julia> U, s, V = svd(A, thin=false)
> (
> 2x2 Array{Float64,2}:
>  -0.707107  -0.707107
>  -0.707107   0.707107,
>
> [5.744562646538029,1.0],
> 3x3 Array{Float64,2}:
>  -0.615457  -0.707107 0.348155
>  -0.615457   0.707107 0.348155
>   0.492366   5.55112e-17  0.870388)
>
> which is U and V are negative
> http://www.d.umn.edu/~mhampton/m4326svd_example.pdf
>
> So did I just get back luck with example problems? I feel like it's 
> probably just a difference in convention or something, but figured I would 
> ask for a definitive answer. Thank you for any help

[julia-users] Re: Ray tracing for complex geometry

[kleinsplash]

Thank you. 

Apologies, I struggle trying to explain myself at the best of times. 

I have a number of virtual objects (*.obj) I want to get ~1000 depth images 
from x angles. I used the pinpoint camera approximation only to find that 
the obj files had so view vertices that getting reasonable depth 
information was not feasible. So I can do two things - figure out how to 
make my mesh more dense (surface fitting or re-sampling) or do ray tracing 
so that I can obtain points wherever my rays intersect with the faces of my 
virtual object. 

I will then be using these depth images as input for a convolutional neural 
net. 

 

On Monday, 23 November 2015 11:20:28 UTC+2, Simon Danisch wrote:
>
> I'm still confused about what you want.
> Google says:
> "In computer graphics, ray tracing is a technique for generating an Image 
> by tracing the path of light through pixels in an image plane and 
> simulating the effects of its encounters with virtual objects." which is 
> pretty much what I understand under ray tracing.
> So what is your goal? Usually ray tracing is used when you want a 
> realistically lit render(plot) of a 3d scene, or if you have some 
> implicitely defined geometry ( like steve kelly pointed out).
> Usually you have a mesh in an obj file, which you would only ray trace 
> when you need photo realism (since it's way slower then any other 
> displaying method).
> I'm really unsure, why you want to get out a 3d matrix in the end. Do you 
> want to compute a lightfield?! Or do you want to have an interpolated voxel 
> representation of that mesh in a dense volume? This is probably not what 
> you really want and also not what a ray tracer produces.
> The last thing I can imagine is, that you actually have only 
> vertices(points) in your obj file without any faces, which then wouldn't 
> really show up in a plot, so that you started assuming it's not dense 
> enough. I wouldn't call pointclouds a complex geometry though, since its 
> one of the most simplest.
> If that's the case, you should just visualize them as particles.
> Here is how you would do that in GLVisualize:
> Using FileIO, GLVisualize
> obj = load("pathtoobj.obj")
> points = vertices(obj)
> w,r = glscreen()
> view(visualize(points))
> r()
>
> If you have problems with that example, please file an issue on github 
> under GLVisualize.jl.
>
>
> Best,
> Simon
>
>

Re: [julia-users] Concatenation without splatting

[Dan]

Using `append!` instead of `push!` and letting efficient dynamic 
reallocation of vector do the resizing:

function vcat_nosplat2a(y)
result = Array(eltype(y[1]), 0)
for a in y
append!(result, a)
end
result
end

(@benchmark shows way less allocations and 2-3x time)
BTW the splat version is just as quick, but perhaps allocation on stack is 
problematic (anybody check the limit?)

On Monday, November 23, 2015 at 12:07:18 PM UTC+2, Tomas Lycken wrote:
>
> That doesn’t quite seem to do what you want, Mauro:
>
> julia> arr_of_arr = Vector{Int}[[1],[2,3],[4,5]]
> 3-element Array{Array{Int64,1},1}:
>  [1]
>  [2,3]
>  [4,5]
>
> julia> vcat_nosplat(y) = eltype(y[1])[el[1] for el in y]
> vcat_nosplat (generic function with 1 method)
>
> julia> vcat_nosplat(arr_of_arr)
> 3-element Array{Int64,1}:
>  1
>  2
>  4
>
> It’s quite trivial to achieve the desired result with only a few lines of 
> code, though:
>
> julia> function vcat_nosplat2(y)
>result = Array(eltype(y[1]), 0)
>sizehint!(result, sum(map(length, y))) #skip if iterating is more 
> expensive than reallcoation
>
>for a in y
>for x in a
>push!(result, x)
>end
>end
>
>result
>end
> vcat_nosplat2 (generic function with 1 method)
>
> julia> vcat_nosplat2(arr_of_arr)
> 5-element Array{Int64,1}:
>  1
>  2
>  3
>  4
>  5
>
> // T
>
> On Sunday, November 22, 2015 at 9:12:55 PM UTC+1, Mauro wrote:
>
> In ODE.jl, I've used 
>>
>> vcat_nosplat(y) = eltype(y[1])[el[1] for el in y] # Does vcat(y...) 
>> without the splatting 
>>
>> I think the eltype might not be needed.  There may be better ways though. 
>>
>> On Sun, 2015-11-22 at 14:04, Cedric St-Jean  wrote: 
>> > I have a big vector of vectors. Is there any way to vcat/hcat them 
>> without 
>> > splatting? 
>> > 
>> > arr_of_arr = Vector[[1],[2,3],[4,5]] 
>> > vcat(arr_of_arr...) 
>> > 
>> > I'm asking because splatting big arrays is a performance issue (and 
>> IIRC it 
>> > blows the stack at some point). 
>>
> ​
>

Re: [julia-users] OffsetArrays (Fortran-style indexing)

[Tim Holy]

If no answers are forthcoming here, you should file an issue with the 
OffsetArrays package.

Best,
--Tim

On Thursday, November 19, 2015 02:08:29 PM Ted Wetherbee wrote:
> OffsetArrays, as per its package example, is missing arrayset in 3.12, also
> not working in 4.1 and 5.0 versions as per the package example.  I'm
> evaluating Julia so may be missing something assumed.
> 
> Fortran style indexing is a huge plus, say (Float32,-1:n+2,-1:n+2,-1:n+2).
> 
> Has something changed so that OffsetArrays does not function as per the
> package example?
> 
> Many thanks

Re: [julia-users] Ray tracing for complex geometry

[kleinsplash]

Thanks a stack. The geometry is defined in a mesh file .obj. Consisting of 
vertices and faces. The objects are complex, so any primitive ray-tracing 
is most likely not going to work. My challenge is that my obj files are 
just not dense enough. If they were I could use the vertices no problem. So 
I either increase the density of the mesh, or ray-trace. 

My outline:

load obj file
set camera angle(random range something like 0-2/pi) 
set focal length(random range)
ray-trace(~1000 points - much greater than the number of vertices I have)
plot the view of the object(just for visual confirmation)
hold 3D matrix of view (x,y,z) or (x,y,ind) 


On Friday, 20 November 2015 18:45:55 UTC+2, Steve Kelly wrote:
>
> How is your geometry defined? If it is an implicit function, ShaderToy.jl 
> (built on GLVisualize) has a raymarching example. 
> https://github.com/SimonDanisch/ShaderToy.jl/blob/master/examples/rayprimitive.frag
>  
>
> The method can be generalized to generating distance fields, but I haven't 
> gotten to it yet. I'd also recommend taking a look at the link in the 
> comments. Inigo has some great stuff on ray tracing techniques for the GPU.
>
> I've been working on a solid modeler that makes describing primitives as 
> functions much easier. 
> https://github.com/FactoryOS/Descartes.jl/tree/master/examples The 
> eventual goal is to get all the geometric realization code on the GPU (SDFs 
> and Dual Contours). 
> On Nov 20, 2015 11:15 AM, "Tom Breloff"  
> wrote:
>
>> Could you describe a little more about your use-case?  I'm not sure that 
>> ray-tracing is necessarily what you want if you're displaying point 
>> clouds.  I would check out GLVisualize.jl as a first step.
>>
>> On Fri, Nov 20, 2015 at 10:18 AM, kleinsplash > > wrote:
>>
>>> I was wondering if someone could help me out with a decision/offer an 
>>> opinion:
>>>
>>> I need a ray tracer that deals with complex geometry (a fast ray tracer 
>>> that can create 1000's of point clouds in minimal time) 
>>> Python has methods: http://pyopengl.sourceforge.net/ that I could get 
>>> to grips with. But I want to stick with Julia. 
>>>
>>> I have found these resources: 
>>> https://github.com/JuliaGL/ModernGL.jl - not sure if this has a ray 
>>> tracing option
>>> http://www.cs.columbia.edu/~keenan/Projects/QuaternionJulia/ - looks 
>>> crazy complicated
>>>
>>> https://github.com/JuliaLang/julia/blob/master/test/perf/kernel/raytracer.jl
>>>  
>>> - looks like only handles simple geometry
>>>
>>> Could someone point me in the right direction?
>>>
>>>  
>>>
>>
>>

Re: [julia-users] Concatenation without splatting

[Tomas Lycken]

That doesn’t quite seem to do what you want, Mauro:

julia> arr_of_arr = Vector{Int}[[1],[2,3],[4,5]]
3-element Array{Array{Int64,1},1}:
 [1]
 [2,3]
 [4,5]

julia> vcat_nosplat(y) = eltype(y[1])[el[1] for el in y]
vcat_nosplat (generic function with 1 method)

julia> vcat_nosplat(arr_of_arr)
3-element Array{Int64,1}:
 1
 2
 4

It’s quite trivial to achieve the desired result with only a few lines of 
code, though:

julia> function vcat_nosplat2(y)
   result = Array(eltype(y[1]), 0)
   sizehint!(result, sum(map(length, y))) #skip if iterating is more 
expensive than reallcoation

   for a in y
   for x in a
   push!(result, x)
   end
   end

   result
   end
vcat_nosplat2 (generic function with 1 method)

julia> vcat_nosplat2(arr_of_arr)
5-element Array{Int64,1}:
 1
 2
 3
 4
 5

// T

On Sunday, November 22, 2015 at 9:12:55 PM UTC+1, Mauro wrote:

In ODE.jl, I've used 
>
> vcat_nosplat(y) = eltype(y[1])[el[1] for el in y] # Does vcat(y...) 
> without the splatting 
>
> I think the eltype might not be needed.  There may be better ways though. 
>
> On Sun, 2015-11-22 at 14:04, Cedric St-Jean  > wrote: 
> > I have a big vector of vectors. Is there any way to vcat/hcat them 
> without 
> > splatting? 
> > 
> > arr_of_arr = Vector[[1],[2,3],[4,5]] 
> > vcat(arr_of_arr...) 
> > 
> > I'm asking because splatting big arrays is a performance issue (and IIRC 
> it 
> > blows the stack at some point). 
>
​

Re: [julia-users] Using Meshes.ji

[kleinsplash]

Looks like accessing has changed a bit - so to get to the faces I did 

obj = load("path.obj")
faces = obj.faces

So far I haven't had much luck in either plotting this or accessing the 
faces and the verticies. As soon as I figure it out I will get back. This 
is linked to my other question, for some reason I wasn't automatically 
subscribed to this one. 


On Monday, 9 November 2015 18:45:01 UTC+2, Steve Kelly wrote:
>
> The faces can be accessed with faces(load("foo.obj")) or mesh.faces.
>
> Probably the easiest way to display the mesh at this point is with 
> ThreeJS.jl: 
> https://github.com/rohitvarkey/ThreeJS.jl/blob/master/examples/mesh.jl. 
> This approach should work in IJulia and Blink.
>
> GLVisualize has some good demos and a much more responsive backend, but it 
> needs some work to run in OpenGL < 3.3 and the working commits aren't on 
> Metadata yet. Meshes is kind of a weird state right now, and most of the 
> functionality can be had with GeometryTypes, Meshing, and MeshIO. We have 
> been working the past few months to finish the coupling between data 
> structures for geometry and visualization. It would be great to hear your 
> application, and see if we could achieve something in the short term that 
> would work for you. Personally I use Meshlab when I do solid modelling in 
> Julia which slows down my iteration time, and it would be nice to have a 
> mesh viewer in the workflow.
>
> Best,
> Steve
> On Nov 9, 2015 9:55 AM, "Ashley Kleinhans"  > wrote:
>
>> Hi,
>>
>> I am new at this - but have decided that Julia is my language of choice. 
>> So I begin silly question stage: 
>>
>> Could someone talk me through how to access and display an .obj file? 
>>
>> I have gotten so far:
>>
>> using Meshes
>> using PyPlot
>> using FileIO
>> using MeshIO
>>
>> obj = load(filename)
>> vts = obj.vertices 
>>
>>
>> Which gives me: 
>>
>> 502-element Array{FixedSizeArrays.Point{3,Float32},1}:
>>
>>
>>
>> One example point being: 
>>
>> Point(0.00117,-0.02631,0.03907)
>>
>>  
>>   
>>
>>   
>>
>> How do I access the verticies to use them with plot? 
>>
>> -A
>>
>>
>>

Re: [julia-users] Re: Better alternative to find all permutations?

[Glen O]

Logically, the same definition being used by "unique" would be applied, 
unless specified otherwise (which should also be available for unique - 
it's silly that you can't specify the level of inequality necessary for 
uniqueness).

Incidentally, in the example you gave, unique gives 
[0.0,-0.0,NaN,Foo(),Bar(NaN),Bar(NaN)]

On Monday, 23 November 2015 05:08:12 UTC+10, Tamas Papp wrote:
>
> Also, "unique" permutations require a notion of equality, and which is 
> hard to define in general (classic essay is [1], about Common Lisp, 
> but applies to Julia mutatis mutandis). At least Julia has bits types 
> for numbers, which makes life a bit easier. 
>
> Whether one picks is, isequal, or == for comparison, it easy to come up 
> with cases which go against user expectations (at least for some 
> users). For example, given 
>
> type Foo end 
> type Bar x end 
>
> what should be the unique permutations of 
>
> [0.0,-0.0,NaN,NaN,Foo(),Foo(),Bar(NaN),Bar(NaN)] 
>
> ? 
>
> Best, 
>
> Tamas 
>
> [1] http://www.nhplace.com/kent/PS/EQUAL.html 
>
> On Sun, Nov 22 2015, Ratan Sur  wrote: 
>
> > I think julia more than other languages has a tendency to stick with 
> > mathematical consistency over some user preferences, which is good. For 
> > that reason, I would be in favor of permutations remaining as is but 
> having 
> > multiset_permutations renamed to something more intuitive, like 
> > uniqueperms, or unique_permutations. 
> > 
> > On Sun, Nov 22, 2015 at 2:16 AM Glen O  
> wrote: 
> > 
> >> While it is true that an interpretation of arrays is multisets, that's 
> not 
> >> the only reasonable interpretation. And while the strict interpretation 
> of 
> >> "permutations" suggests it should include duplicates, you have to 
> consider 
> >> what the user would most likely expect it to do. Most would think that 
> a 
> >> list of the permutations would include unique permutations only. 
> >> 
> >> So perhaps both functionalities should be available in the same 
> function 
> >> with a keyword argument. At the very least, the description of the 
> function 
> >> should directly inform the user that it's going to give duplicate 
> >> permutations if the array contains repeat elements. 
> >> 
> >> On Saturday, 21 November 2015 04:24:51 UTC+10, Jiahao Chen wrote: 
> >>> 
> >>> The current behavior of permutations is correct and should not be 
> >>> changed. Combinatorially, arrays are multisets, not sets, since they 
> allow 
> >>> for duplicate entries, so it is correct to produce what look like 
> identical 
> >>> permutations. The redundancy is important for operations that can be 
> >>> expressed as sums over all permutations. 
> >>> 
> >>> Combinatorics.jl currently provides multiset_permutations for 
> generating 
> >>> only distinct permutations: 
> >>> 
> >>> 
> >>> 
> https://github.com/JuliaLang/Combinatorics.jl/blob/3c08c9af9ebeaa54589e939c0cf2e652ef4ca6a0/test/permutations.jl#L24-L25
>  
> >>> 
> >> 
>
>

[julia-users] Re: Coveralls/Codecov report certain lines are not covered, but test for the lines do appear to exist in code

[Zygmunt Szpak]

Thank you Dan.

On Sunday, November 22, 2015 at 6:25:54 PM UTC+10:30, Dan wrote:
>
> Regarding the last printing point only
> print(string(eltype(8)) * ", " * string(eltype(8)))
>
> is probably what you meant. AbstractString(Int64), tries to create an 
> AbstractString from an Int64, while string(Int64) asks for a string 
> representation. The latter semantics is more accurate, and works.
>
> On Sunday, November 22, 2015 at 7:46:17 AM UTC+2, Zygmunt Szpak wrote:
>>
>> Hi All,
>>
>> I've been perusing the Coveralls/Codecov reports looking for 
>> opportunities to write some additional tests.
>> I was looking at the promote_rule in int.jl and noticed that some 
>> promote_rules were apparently missing tests. 
>>
>> See for example:
>>  promote_rule(::Type{Int64}, ::Type{Int8} ) = Int64 
>>
>>  
>>
>> https://codecov.io/github/JuliaLang/julia/base/int.jl?ref=e6cd2bc8c6ab2444d7750cf42d43b4c45e8f3545
>>
>> Apparently, this line is not covered by any test as indicated by the red 
>> highlight.
>>
>> However, the test file for int.jl
>>
>> https://github.com/JuliaLang/julia/blob/master/test/int.jl
>>
>> contains the following tests:
>>
>> UItypes = (UInt8, UInt16, UInt32, UInt64, UInt128)
>> SItypes = (Int8, Int16, Int32, Int64, Int128)
>>
>>
>> for T in UItypes, S in UItypes
>> @test promote(S(3), T(3)) === (sizeof(T) < sizeof(S) ? (S(3), S(3)) : 
>> (T(3), T(3)))
>> end
>>
>>
>> for T in SItypes, S in SItypes
>> @test promote(S(3), T(3)) === (sizeof(T) < sizeof(S) ? (S(3), S(3)) : 
>> (T(3), T(3)))
>> end
>>
>>
>> for T in SItypes, S in UItypes
>> R = sizeof(S) < sizeof(Int) ? Int : S
>> @test promote(R(3), T(3)) === (sizeof(R) < sizeof(T) ? (T(3), T(3)) : 
>> (R(3), R(3)))
>> end
>>
>> Looking deeper at one of these tests using the following code:
>>
>> for  T in SItypes, S in SItypes
>> print(eltype(S(3)) )
>> print(", ")
>> print(eltype(T(3)) )
>> print(" -> ")
>> print(eltype(promote(S(3), T(3
>> print(" | ")
>> print(@which promote(S(3), T(3)))
>> println(" ")
>> end
>>
>> which yields:
>>
>> Int8, Int8 -> Int8 | promote{T,S}(x::T, y::S) at promotion.jl:132 
>>> Int16, Int8 -> Int16 | promote{T,S}(x::T, y::S) at promotion.jl:132 
>>> Int32, Int8 -> Int32 | promote{T,S}(x::T, y::S) at promotion.jl:132 
>>> *Int64, Int8 -> Int64 | promote{T,S}(x::T, y::S) at promotion.jl:132 *
>>> Int128, Int8 -> Int128 | promote{T,S}(x::T, y::S) at promotion.jl:132 
>>> Int8, Int16 -> Int16 | promote{T,S}(x::T, y::S) at promotion.jl:132 
>>> Int16, Int16 -> Int16 | promote{T,S}(x::T, y::S) at promotion.jl:132 
>>> Int32, Int16 -> Int32 | promote{T,S}(x::T, y::S) at promotion.jl:132 
>>> Int64, Int16 -> Int64 | promote{T,S}(x::T, y::S) at promotion.jl:132 
>>> Int128, Int16 -> Int128 | promote{T,S}(x::T, y::S) at promotion.jl:132 
>>> Int8, Int32 -> Int32 | promote{T,S}(x::T, y::S) at promotion.jl:132 
>>> Int16, Int32 -> Int32 | promote{T,S}(x::T, y::S) at promotion.jl:132 
>>> Int32, Int32 -> Int32 | promote{T,S}(x::T, y::S) at promotion.jl:132 
>>> Int64, Int32 -> Int64 | promote{T,S}(x::T, y::S) at promotion.jl:132 
>>> Int128, Int32 -> Int128 | promote{T,S}(x::T, y::S) at promotion.jl:132 
>>> Int8, Int64 -> Int64 | promote{T,S}(x::T, y::S) at promotion.jl:132 
>>> Int16, Int64 -> Int64 | promote{T,S}(x::T, y::S) at promotion.jl:132 
>>> Int32, Int64 -> Int64 | promote{T,S}(x::T, y::S) at promotion.jl:132 
>>> Int64, Int64 -> Int64 | promote{T,S}(x::T, y::S) at promotion.jl:132 
>>> Int128, Int64 -> Int128 | promote{T,S}(x::T, y::S) at promotion.jl:132 
>>> Int8, Int128 -> Int128 | promote{T,S}(x::T, y::S) at promotion.jl:132 
>>> Int16, Int128 -> Int128 | promote{T,S}(x::T, y::S) at promotion.jl:132 
>>> Int32, Int128 -> Int128 | promote{T,S}(x::T, y::S) at promotion.jl:132 
>>> Int64, Int128 -> Int128 | promote{T,S}(x::T, y::S) at promotion.jl:132 
>>> Int128, Int128 -> Int128 | promote{T,S}(x::T, y::S) at promotion.jl:132 
>>
>>
>> it would appear that the line *highlighted in blue* above is indeed 
>> testing:
>>  promote_rule(::Type{Int64}, ::Type{Int8} ) = Int64 
>>
>> contrary to what the Coveralls/Codecov is reporting. I'm not sure how 
>> to reconcile these results, and would appreciate any insight.
>>
>> On a sightly different note, could anyone suggest a neat way of printing 
>> element types on a single
>> line such as:
>>
>>> Int64, Int64 -> Int64 
>>
>>
>> For example, is there a way to convert Tuples to Strings? 
>>
>> I've tried things such as:
>> print(AbstractString(eltype(8)) * ", " * AbstractString(eltype(8)))
>>
>> LoadError: MethodError: `convert` has no method matching 
>>> convert(::Type{AbstractString}, ::Type{Int64})
>>> This may have arisen from a call to the constructor AbstractString(...),
>>> since type constructors fall back to convert methods.
>>> Closest candidates are:
>>> call{T}(::Type{T}, ::Any)
>>> convert{T<:AbstractString,S<:Union{Char,Int32,UInt32}}(::Type{T<:AbstractString},
>>>  
>>> 

Re: [julia-users] Re: Better alternative to find all permutations?

[Tamas Papp]

IMO permutations should maintain the following invariant: for any vector
v,

isequal(map(i -> getindex(v,i), collect(permutations(1:length(v,
collect(permutations(v)))

Bringing equality and uniqueness into the issue disposes of this
property, which is desirable in many applications.

Best,

Tamas

On Mon, Nov 23 2015, Glen O  wrote:

> Logically, the same definition being used by "unique" would be applied,
> unless specified otherwise (which should also be available for unique -
> it's silly that you can't specify the level of inequality necessary for
> uniqueness).
>
> Incidentally, in the example you gave, unique gives
> [0.0,-0.0,NaN,Foo(),Bar(NaN),Bar(NaN)]
>
> On Monday, 23 November 2015 05:08:12 UTC+10, Tamas Papp wrote:
>>
>> Also, "unique" permutations require a notion of equality, and which is
>> hard to define in general (classic essay is [1], about Common Lisp,
>> but applies to Julia mutatis mutandis). At least Julia has bits types
>> for numbers, which makes life a bit easier.
>>
>> Whether one picks is, isequal, or == for comparison, it easy to come up
>> with cases which go against user expectations (at least for some
>> users). For example, given
>>
>> type Foo end
>> type Bar x end
>>
>> what should be the unique permutations of
>>
>> [0.0,-0.0,NaN,NaN,Foo(),Foo(),Bar(NaN),Bar(NaN)]
>>
>> ?
>>
>> Best,
>>
>> Tamas
>>
>> [1] http://www.nhplace.com/kent/PS/EQUAL.html
>>
>> On Sun, Nov 22 2015, Ratan Sur  wrote:
>>
>> > I think julia more than other languages has a tendency to stick with
>> > mathematical consistency over some user preferences, which is good. For
>> > that reason, I would be in favor of permutations remaining as is but
>> having
>> > multiset_permutations renamed to something more intuitive, like
>> > uniqueperms, or unique_permutations.
>> >
>> > On Sun, Nov 22, 2015 at 2:16 AM Glen O 
>> wrote:
>> >
>> >> While it is true that an interpretation of arrays is multisets, that's
>> not
>> >> the only reasonable interpretation. And while the strict interpretation
>> of
>> >> "permutations" suggests it should include duplicates, you have to
>> consider
>> >> what the user would most likely expect it to do. Most would think that
>> a
>> >> list of the permutations would include unique permutations only.
>> >>
>> >> So perhaps both functionalities should be available in the same
>> function
>> >> with a keyword argument. At the very least, the description of the
>> function
>> >> should directly inform the user that it's going to give duplicate
>> >> permutations if the array contains repeat elements.
>> >>
>> >> On Saturday, 21 November 2015 04:24:51 UTC+10, Jiahao Chen wrote:
>> >>>
>> >>> The current behavior of permutations is correct and should not be
>> >>> changed. Combinatorially, arrays are multisets, not sets, since they
>> allow
>> >>> for duplicate entries, so it is correct to produce what look like
>> identical
>> >>> permutations. The redundancy is important for operations that can be
>> >>> expressed as sums over all permutations.
>> >>>
>> >>> Combinatorics.jl currently provides multiset_permutations for
>> generating
>> >>> only distinct permutations:
>> >>>
>> >>>
>> >>>
>> https://github.com/JuliaLang/Combinatorics.jl/blob/3c08c9af9ebeaa54589e939c0cf2e652ef4ca6a0/test/permutations.jl#L24-L25
>> >>>
>> >>
>>
>>

[julia-users] Problem with "using PyPlot"

[Ilya Orson]

Hello everyone!

I am having some trouble with PyPlot, can somebody help me?

I have Anaconda's Python 2.7 installed and normally Julia recognized it 
while using PyPlot and PyCall but it suddenly failed today while importing 
PyPlot:

ERROR: InitError: Failed to pyimport("matplotlib"): PyPlot will not work 
until you have a functioning matplotlib module.

For automated Matplotlib installation, try configuring PyCall to use the 
Conda Python distribution within Julia.  Relaunch Julia and run:
  ENV["PYTHON"]=""
  Pkg.build("PyCall")
  using PyPlot

pyimport exception was: PyError (:PyImport_ImportModule) 
ImportError('/home/ilya/anaconda2/lib/python2.7/site-packages/numpy/linalg/lapack_lite.so:
 
undefined symbol: zgelsd_',)
  File 
"/home/ilya/anaconda2/lib/python2.7/site-packages/matplotlib/__init__.py", 
line 122, in 
from matplotlib.cbook import is_string_like, mplDeprecation, dedent, 
get_label
  File 
"/home/ilya/anaconda2/lib/python2.7/site-packages/matplotlib/cbook.py", 
line 32, in 
import numpy as np
  File 
"/home/ilya/anaconda2/lib/python2.7/site-packages/numpy/__init__.py", line 
180, in 
from . import add_newdocs
  File 
"/home/ilya/anaconda2/lib/python2.7/site-packages/numpy/add_newdocs.py", 
line 13, in 
from numpy.lib import add_newdoc
  File 
"/home/ilya/anaconda2/lib/python2.7/site-packages/numpy/lib/__init__.py", 
line 18, in 
from .polynomial import *
  File 
"/home/ilya/anaconda2/lib/python2.7/site-packages/numpy/lib/polynomial.py", 
line 20, in 
from numpy.linalg import eigvals, lstsq, inv
  File 
"/home/ilya/anaconda2/lib/python2.7/site-packages/numpy/linalg/__init__.py", 
line 51, in 
from .linalg import *
  File 
"/home/ilya/anaconda2/lib/python2.7/site-packages/numpy/linalg/linalg.py", 
line 29, in 
from numpy.linalg import lapack_lite, _umath_linalg

 in __init__ at /home/ilya/.julia/v0.4/PyPlot/src/PyPlot.jl:229
 in _require_from_serialized at loading.jl:84
 in _require_from_serialized at ./loading.jl:109
 in require at ./loading.jl:219
during initialization of module PyPlot

So I tried to reinstall julia and set ENV["PYTHON"] = "" before adding 
PyCall to force the usage of Conda.jl ,
then I added PyPlot and everything seemed fine until then, but when I use 
import PyPlot I get the following error:

ERROR: InitError: PyError (:PyImport_ImportModule) 
ImportError('cannot import name scimath',)
  File 
"/home/ilya/.julia/v0.4/Conda/deps/usr/lib/python2.7/site-packages/matplotlib/__init__.py",
 
line 122, in 
from matplotlib.cbook import is_string_like, mplDeprecation, dedent, 
get_label
  File 
"/home/ilya/.julia/v0.4/Conda/deps/usr/lib/python2.7/site-packages/matplotlib/cbook.py",
 
line 32, in 
import numpy as np
  File 
"/home/ilya/.julia/v0.4/Conda/deps/usr/lib/python2.7/site-packages/numpy/__init__.py",
 
line 180, in 
from . import add_newdocs
  File 
"/home/ilya/.julia/v0.4/Conda/deps/usr/lib/python2.7/site-packages/numpy/add_newdocs.py",
 
line 13, in 
from numpy.lib import add_newdoc
  File 
"/home/ilya/.julia/v0.4/Conda/deps/usr/lib/python2.7/site-packages/numpy/lib/__init__.py",
 
line 17, in 
from . import scimath as emath

 [inlined code] from /home/ilya/.julia/v0.4/PyCall/src/exception.jl:81
 in pyimport at /home/ilya/.julia/v0.4/PyCall/src/PyCall.jl:302
 in __init__ at /home/ilya/.julia/v0.4/PyPlot/src/PyPlot.jl:227
 in _require_from_serialized at loading.jl:84
 in _require_from_serialized at ./loading.jl:109
 in require at ./loading.jl:219
during initialization of module PyPlot

I get the same error if I try to use the development branch of PyCall 
instead:
Pkg.checkout("PyCall") 
ENV["PYTHON"] = "" 

Pkg.build("PyCall")


And I get the same error when I try to use Anaconda as before by setting 
ENV["PYTHON"] = "python" and building PyCall again. (with both versions of 
PyCall)

The problem always appears when I try *using PyPlot*.

I don't know if this helps but if I try to continue and plot something I 
get the following:

ERROR: ArgumentError: haskey of NULL PyObject
 in haskey at /home/ilya/.julia/v0.4/PyCall/src/PyCall.jl:260
 in plot at /home/ilya/.julia/v0.4/PyPlot/src/PyPlot.jl:457

Any help would be highly apreciated!

Thanks,
Ilya

[julia-users] What is the best way to delete unwanted subgraph?

[Aleksandr Mikheev]

Hi all,

I'm currently using LightGraphs package in my student research work. And I 
have some problems with it. Imagine we have a undirrected graph G, which 
contains, for example, 10 vertices and some edges. I would like to know 
which components of graph G are connected, so I call 
"connected_components(G)". Suppose I have this situation:

julia> connected_components(G)
6-element Array{Array{Int64,1},1}:
[1,2,3]
[4,7]
[5]
[6]
[8,9]
[10]

And now I would like to delete all subgraphs, except [1,2,3]. In other 
words, I would like to have subgraph [1,2,3] as a graph G further. Is there 
any effective methods to do this in LightGraphs or in any other packages? I 
mean, I can delete vertices one by one (I guess I saw this function 
somewhere in GitHub), but that would be pretty slow, I imagine.

Thank you in advance.

[julia-users] Re: Ray tracing for complex geometry

[Simon Danisch]

I'm not sure what you mean by virtual objects. Obj is in the context of 3D 
objects is usually the wavefront 
 format.
If you have an object database with *.obj's in it, the probability is very 
high, that you don't have pointclouds whatsoever.
You can try this, to confirm my hypothesis:

using GLVisualize, FileIO
obj = load("file.obj")
w,r = glscreen()
view(visualize(obj))
r()

Or just download any obj viewer from the interwebzz and look at that thing. 
If you have nice smooth surfaces, you're getting it all wrong with the 
pointclouds and ray tracing.
I could give you some hacky way of extracting depth images with 
GLVisualize, if that's what you're after.
In that case, just try the example above and if that works, open an issue 
at GLVisualize that you want depth images. Then we can take it from there.


If by any chance you DO have pointclouds stored in an obj file, things are 
more complicated since you then need to approximate the surface of that 
cloud.
Still, raytracing wouldn't be your friend ;) If you have infinitely small 
points, there is no magic that lets a ray hit these points any better then 
some other visualization algorithm.
Even if it's really dense, you still have infinitely small points. You can 
treat the points as particles, to give them some "body" that you can 
see, but then it's not really a surface anymore.

Just google for pointcloud surface approximation and see where that gets 
you.

I'm guessing here, that you have some sensor that outputs depth images and 
you want to recognize objects in these depth images.
To train your depth image classifier, you need depth images from a lot of 
perspectives from a lot of random 3D objects, which is why you searched for 
a 3D object database, which got you to the obj files of random 3D objects.

It'd have been a lot easier, if you just stated this in your problem 
description, probably even with links to the obj database.

Best,
Simon

Am Freitag, 20. November 2015 16:18:46 UTC+1 schrieb kleinsplash:
>
> I was wondering if someone could help me out with a decision/offer an 
> opinion:
>
> I need a ray tracer that deals with complex geometry (a fast ray tracer 
> that can create 1000's of point clouds in minimal time) 
> Python has methods: http://pyopengl.sourceforge.net/ that I could get to 
> grips with. But I want to stick with Julia. 
>
> I have found these resources: 
> https://github.com/JuliaGL/ModernGL.jl - not sure if this has a ray 
> tracing option
> http://www.cs.columbia.edu/~keenan/Projects/QuaternionJulia/ - looks 
> crazy complicated
>
> https://github.com/JuliaLang/julia/blob/master/test/perf/kernel/raytracer.jl 
> - looks like only handles simple geometry
>
> Could someone point me in the right direction?
>
>  
>

Re: [julia-users] Using Meshes.ji

[kleinsplash]

Thanks guys :)

On Tuesday, 10 November 2015 13:20:44 UTC+2, Rohit Thankachan wrote:
>
> I've made a few changes to the file Steve pointed you to. It can be found 
> at https://gist.github.com/rohitvarkey/5be4542faff17014afc7.
>
> If you use Escher to run that file, you can load .obj files by just typing 
> in the filename (provided you ran the Escher server from the directory the 
> file exists) or the absolute path to the file in the input field. A very 
> primitive mesh viewer in Julia I guess. :)
>
> Regards,
> Rohit  
>
> On Monday, 9 November 2015 22:15:01 UTC+5:30, Steve Kelly wrote:
>>
>> The faces can be accessed with faces(load("foo.obj")) or mesh.faces.
>>
>> Probably the easiest way to display the mesh at this point is with 
>> ThreeJS.jl: 
>> https://github.com/rohitvarkey/ThreeJS.jl/blob/master/examples/mesh.jl. 
>> This approach should work in IJulia and Blink.
>>
>> GLVisualize has some good demos and a much more responsive backend, but 
>> it needs some work to run in OpenGL < 3.3 and the working commits aren't on 
>> Metadata yet. Meshes is kind of a weird state right now, and most of the 
>> functionality can be had with GeometryTypes, Meshing, and MeshIO. We have 
>> been working the past few months to finish the coupling between data 
>> structures for geometry and visualization. It would be great to hear your 
>> application, and see if we could achieve something in the short term that 
>> would work for you. Personally I use Meshlab when I do solid modelling in 
>> Julia which slows down my iteration time, and it would be nice to have a 
>> mesh viewer in the workflow.
>>
>> Best,
>> Steve
>> On Nov 9, 2015 9:55 AM, "Ashley Kleinhans"  wrote:
>>
>>> Hi,
>>>
>>> I am new at this - but have decided that Julia is my language of choice. 
>>> So I begin silly question stage: 
>>>
>>> Could someone talk me through how to access and display an .obj file? 
>>>
>>> I have gotten so far:
>>>
>>> using Meshes
>>> using PyPlot
>>> using FileIO
>>> using MeshIO
>>>
>>> obj = load(filename)
>>> vts = obj.vertices 
>>>
>>>
>>> Which gives me: 
>>>
>>> 502-element Array{FixedSizeArrays.Point{3,Float32},1}:
>>>
>>>
>>>
>>> One example point being: 
>>>
>>> Point(0.00117,-0.02631,0.03907)
>>>
>>> 
>>>
>>>
>>>   
>>>
>>> How do I access the verticies to use them with plot? 
>>>
>>> -A
>>>
>>>
>>>

[julia-users] Re: Ray tracing for complex geometry

[kleinsplash]

Nope. I have obj files. Your hypothesis is correct. I have attached one of 
them. Your script works just fine (is there an easy way to save this 
image?). 

As a side note: I do collect point clouds using V-REP, and I can generate 
pointclouds (pcd) using pcl - but I want to work with the obj mesh files 
because the clouds are too sparse. 

I probably could have explained myself better, point taken. I will aim to 
try harder next time, I feel horrid when I am asking basic questions and on 
top of that writing an essay. 

The only other person I know who uses the term interwebz is Richard on Fast 
and Loud - I am an avid supporter. 

On Monday, 23 November 2015 13:41:40 UTC+2, Simon Danisch wrote:
>
> I'm not sure what you mean by virtual objects. Obj is in the context of 3D 
> objects is usually the wavefront 
>  format.
> If you have an object database with *.obj's in it, the probability is very 
> high, that you don't have pointclouds whatsoever.
> You can try this, to confirm my hypothesis:
>
> using GLVisualize, FileIO
> obj = load("file.obj")
> w,r = glscreen()
> view(visualize(obj))
> r()
>
> Or just download any obj viewer from the interwebzz and look at that 
> thing. 
> If you have nice smooth surfaces, you're getting it all wrong with the 
> pointclouds and ray tracing.
> I could give you some hacky way of extracting depth images with 
> GLVisualize, if that's what you're after.
> In that case, just try the example above and if that works, open an issue 
> at GLVisualize that you want depth images. Then we can take it from there.
>
>
> If by any chance you DO have pointclouds stored in an obj file, things are 
> more complicated since you then need to approximate the surface of that 
> cloud.
> Still, raytracing wouldn't be your friend ;) If you have infinitely small 
> points, there is no magic that lets a ray hit these points any better then 
> some other visualization algorithm.
> Even if it's really dense, you still have infinitely small points. You can 
> treat the points as particles, to give them some "body" that you can 
> see, but then it's not really a surface anymore.
>
> Just google for pointcloud surface approximation and see where that gets 
> you.
>
> I'm guessing here, that you have some sensor that outputs depth images and 
> you want to recognize objects in these depth images.
> To train your depth image classifier, you need depth images from a lot of 
> perspectives from a lot of random 3D objects, which is why you searched for 
> a 3D object database, which got you to the obj files of random 3D objects.
>
> It'd have been a lot easier, if you just stated this in your problem 
> description, probably even with links to the obj database.
>
> Best,
> Simon
>
> Am Freitag, 20. November 2015 16:18:46 UTC+1 schrieb kleinsplash:
>>
>> I was wondering if someone could help me out with a decision/offer an 
>> opinion:
>>
>> I need a ray tracer that deals with complex geometry (a fast ray tracer 
>> that can create 1000's of point clouds in minimal time) 
>> Python has methods: http://pyopengl.sourceforge.net/ that I could get to 
>> grips with. But I want to stick with Julia. 
>>
>> I have found these resources: 
>> https://github.com/JuliaGL/ModernGL.jl - not sure if this has a ray 
>> tracing option
>> http://www.cs.columbia.edu/~keenan/Projects/QuaternionJulia/ - looks 
>> crazy complicated
>>
>> https://github.com/JuliaLang/julia/blob/master/test/perf/kernel/raytracer.jl 
>> - looks like only handles simple geometry
>>
>> Could someone point me in the right direction?
>>
>>  
>>
>

42_wineglass_final-29-Oct-2015-10-38-19.obj
Description: Binary data

Re: [julia-users] Re: Better alternative to find all permutations?

[Glen O]

Mathematical consistency is nice, to be sure, but it's important that the 
user gets the behaviour that they would expect. There is nothing in the 
name "Permutations", nor in the description given by help, that makes it 
clear to the user that the permutations include identical permutations. The 
only people who would expect the current behaviour are combinatorialists 
and maybe computer scientists. If I asked you to write out the permutations 
of the string "test", you wouldn't include the word "test" twice on the 
list (unless you're in one of the aforementioned categories, that is).

multiset_permutations is certainly too obscure as a name, and overly long 
to boot (the latter issue applies to unique_permutations, too). uniqueperms 
is a bit better (but might cause a little confusion with the "perm" 
commands for permissions).

I personally think that incorporating an option into the existing function 
is a better approach - permutations(A,unique=true) to only include unique 
permutations. The default would be unique=false, which would cause the code 
to produce all permutations, including the duplicates. Then the help 
message can explain the option, and that also makes clear what the default 
behaviour will do.

On Monday, 23 November 2015 04:50:45 UTC+10, Ratan Sur wrote:
>
> I think julia more than other languages has a tendency to stick with 
> mathematical consistency over some user preferences, which is good. For 
> that reason, I would be in favor of permutations remaining as is but having 
> multiset_permutations renamed to something more intuitive, like 
> uniqueperms, or unique_permutations.
>
> On Sun, Nov 22, 2015 at 2:16 AM Glen O  
> wrote:
>
>> While it is true that an interpretation of arrays is multisets, that's 
>> not the only reasonable interpretation. And while the strict interpretation 
>> of "permutations" suggests it should include duplicates, you have to 
>> consider what the user would most likely expect it to do. Most would think 
>> that a list of the permutations would include unique permutations only.
>>
>> So perhaps both functionalities should be available in the same function 
>> with a keyword argument. At the very least, the description of the function 
>> should directly inform the user that it's going to give duplicate 
>> permutations if the array contains repeat elements.
>>
>> On Saturday, 21 November 2015 04:24:51 UTC+10, Jiahao Chen wrote:
>>>
>>> The current behavior of permutations is correct and should not be 
>>> changed. Combinatorially, arrays are multisets, not sets, since they allow 
>>> for duplicate entries, so it is correct to produce what look like identical 
>>> permutations. The redundancy is important for operations that can be 
>>> expressed as sums over all permutations.
>>>
>>> Combinatorics.jl currently provides multiset_permutations for generating 
>>> only distinct permutations:
>>>
>>>
>>> https://github.com/JuliaLang/Combinatorics.jl/blob/3c08c9af9ebeaa54589e939c0cf2e652ef4ca6a0/test/permutations.jl#L24-L25
>>>
>>

Re: [julia-users] Re: Better alternative to find all permutations?

[Tamas Papp]

On Mon, Nov 23 2015, Glen O  wrote:

> Mathematical consistency is nice, to be sure, but it's important that the
> user gets the behaviour that they would expect. There is nothing in the
> name "Permutations", nor in the description given by help, that makes it
> clear to the user that the permutations include identical permutations. The
> only people who would expect the current behaviour are combinatorialists
> and maybe computer scientists. If I asked you to write out the permutations

I am neither a combinatorialist nor a computer scientist, and I expect
the current behavior, so perhaps your statement is not true. Different
users expect different things, and expectations can be (and are)
adjusted with experience. So it is hard to design for these things.

I think that these kind of discussions move very quickly from "I didn't
expect it" to "violates user expectations" without a lot of additional
data. I understand that Julia is a new language so people would like to
mold it to their own expectations, and surely there are a lot of things
that can be improved. Personally, I prefer mathematical consistency,
simplicity and composability to DWIM special cases.

Best,

Tamas

Re: [julia-users] Concatenation without splatting

[Tomas Lycken]

Using append! is definitely an improvement, thanks!

The reason I included the sizehint! call was that this resizes the vector 
*once*, and without requiring to copy any elements, and I assumed those 
saved copies would quickly win over having to iterate the collection an 
extra time to get the total number of elements. I’m glad to be proven wrong 
:)

function vcat_prealloc(y)
result = Array(eltype(y[1]), sum(map(length, y)))

for a in y
append!(result, a)
end
end

function vcat_dynamic(y)
result = Array(eltype(y[1]), 0)
for a in y
append!(result, a)
end
end

arr_of_arrs = Vector{Int}[rand(1:10, rand(1:10)) for _ in 1:10_000]

julia> @benchmark vcat_dynamic(arr_of_arrs)
 Benchmark Results 
 Time per evaluation: 441.11 μs [405.40 μs, 476.82 μs]
Proportion of time in GC: 0.00% [0.00%, 0.00%]
Memory allocated: 1.00 mb
   Number of allocations: 16 allocations
   Number of samples: 100
   Number of evaluations: 100
 Time spent benchmarking: 0.07 s

julia> @benchmark vcat_prealloc(arr_of_arrs)
 Benchmark Results 
 Time per evaluation: 716.85 μs [652.07 μs, 781.62 μs]
Proportion of time in GC: 0.00% [0.00%, 0.00%]
Memory allocated: 933.78 kb
   Number of allocations: 7 allocations
   Number of samples: 100
   Number of evaluations: 100
 Time spent benchmarking: 0.10 s

// T

On Monday, November 23, 2015 at 11:51:25 AM UTC+1, Dan wrote:

Using `append!` instead of `push!` and letting efficient dynamic 
> reallocation of vector do the resizing:
>
> function vcat_nosplat2a(y)
> result = Array(eltype(y[1]), 0)
> for a in y
> append!(result, a)
> end
> result
> end
>
> (@benchmark shows way less allocations and 2-3x time)
> BTW the splat version is just as quick, but perhaps allocation on stack is 
> problematic (anybody check the limit?)
>
> On Monday, November 23, 2015 at 12:07:18 PM UTC+2, Tomas Lycken wrote:
>>
>> That doesn’t quite seem to do what you want, Mauro:
>>
>> julia> arr_of_arr = Vector{Int}[[1],[2,3],[4,5]]
>> 3-element Array{Array{Int64,1},1}:
>>  [1]
>>  [2,3]
>>  [4,5]
>>
>> julia> vcat_nosplat(y) = eltype(y[1])[el[1] for el in y]
>> vcat_nosplat (generic function with 1 method)
>>
>> julia> vcat_nosplat(arr_of_arr)
>> 3-element Array{Int64,1}:
>>  1
>>  2
>>  4
>>
>> It’s quite trivial to achieve the desired result with only a few lines of 
>> code, though:
>>
>> julia> function vcat_nosplat2(y)
>>result = Array(eltype(y[1]), 0)
>>sizehint!(result, sum(map(length, y))) #skip if iterating is more 
>> expensive than reallcoation
>>
>>for a in y
>>for x in a
>>push!(result, x)
>>end
>>end
>>
>>result
>>end
>> vcat_nosplat2 (generic function with 1 method)
>>
>> julia> vcat_nosplat2(arr_of_arr)
>> 5-element Array{Int64,1}:
>>  1
>>  2
>>  3
>>  4
>>  5
>>
>> // T
>>
>> On Sunday, November 22, 2015 at 9:12:55 PM UTC+1, Mauro wrote:
>>
>> In ODE.jl, I've used 
>>>
>>> vcat_nosplat(y) = eltype(y[1])[el[1] for el in y] # Does vcat(y...) 
>>> without the splatting 
>>>
>>> I think the eltype might not be needed.  There may be better ways 
>>> though. 
>>>
>>> On Sun, 2015-11-22 at 14:04, Cedric St-Jean  
>>> wrote: 
>>> > I have a big vector of vectors. Is there any way to vcat/hcat them 
>>> without 
>>> > splatting? 
>>> > 
>>> > arr_of_arr = Vector[[1],[2,3],[4,5]] 
>>> > vcat(arr_of_arr...) 
>>> > 
>>> > I'm asking because splatting big arrays is a performance issue (and 
>>> IIRC it 
>>> > blows the stack at some point). 
>>>
>> ​
>>
> ​

[julia-users] drandn sometimes crashes

[Antonio Suriano]

addprocs(3)

@everywhere using DistributedArrays

function tony(N)
return sum(drandn(N,N))
end


function pesante(N)
a=zeros(N,N)
for i = 1:N
for j=1:N
a[i,j]=tony(1000)
end
end
return a
end

matrice= pesante(100)



julia 0.4.1

when calling pesante with N>30 sometimes it crashes

LoadError: BoundsError: attempt to access 0-element Array{Any,1}
  at index [2]
while loading In[3], in expression starting on line 20

fatal error on 2: ERROR: MethodError: `convert` has no method matching 
convert(::Type{RemoteRef{T<:AbstractChannel}}, ::Base.RemoteDoMsg)
This may have arisen from a call to the constructor 
RemoteRef{T<:AbstractChannel}(...),
since type constructors fall back to convert methods.
Closest candidates are:
  call{T}(::Type{T}, ::Any)
  convert{T}(::Type{T}, !Matched::T)
  RemoteRef()
  ...
 in setindex! at array.jl:313
 in deserialize_array at serialize.jl:616
 in deserialize_datatype at serialize.jl:651
 in handle_deserialize at serialize.jl:477 (repeats 2 times)
 in deserialize_datatype at serialize.jl:651
 in message_handler_loop at multi.jl:861
 in anonymous at task.jl:63
Worker 2 terminated.
ERROR (unhandled task failure): EOFError: read end of file
 in read at stream.jl:911
 in message_handler_loop at multi.jl:861
 in anonymous at task.jl:63

Re: [julia-users] Ray tracing for complex geometry

[kleinsplash]

Not sure if you get other comments, please forgive me if this generates two 
mails in your inbox. Please see my answer to Steve Kelly below. 

On Friday, 20 November 2015 18:15:35 UTC+2, Tom Breloff wrote:
>
> Could you describe a little more about your use-case?  I'm not sure that 
> ray-tracing is necessarily what you want if you're displaying point 
> clouds.  I would check out GLVisualize.jl as a first step.
>
> On Fri, Nov 20, 2015 at 10:18 AM, kleinsplash  > wrote:
>
>> I was wondering if someone could help me out with a decision/offer an 
>> opinion:
>>
>> I need a ray tracer that deals with complex geometry (a fast ray tracer 
>> that can create 1000's of point clouds in minimal time) 
>> Python has methods: http://pyopengl.sourceforge.net/ that I could get to 
>> grips with. But I want to stick with Julia. 
>>
>> I have found these resources: 
>> https://github.com/JuliaGL/ModernGL.jl - not sure if this has a ray 
>> tracing option
>> http://www.cs.columbia.edu/~keenan/Projects/QuaternionJulia/ - looks 
>> crazy complicated
>>
>> https://github.com/JuliaLang/julia/blob/master/test/perf/kernel/raytracer.jl 
>> - looks like only handles simple geometry
>>
>> Could someone point me in the right direction?
>>
>>  
>>
>
>

[julia-users] pmap - intermingled output from workers on v0.4

['Greg Plowman' via julia-users]

Has output from parallel workers changed in Julia v0.4 from v0.3?

I guess that running parallel processes might lead to intermingled output.
However, I have (more or less) the same parallel simulation code using pmap 
running on v0.3 and v0.4.

On v0.3 the output from workers is always orderly.

On v0.4 it's often intermingled between workers.
But moreover, the output sometimes seems delayed, as if it's being buffered 
and not being flushed straight away.

Is there a way I can get the output fro workers written immediately?

Re: [julia-users] Best way to pass many arguments to functions

[Milan Bouchet-Valat]

Le lundi 23 novembre 2015 à 05:32 -0800, Maxim Berman a écrit :
> Hello,
> 
> In Matlab, people often use structures to pass around arguments
> between functions, for example problem instances. This allows some
> flexibility in the development, since I don't have to think of all
> variables that I need and their types, and new objects can be easily
> added to existing structs
> 
> In Julia, I tend to use Dicts to replicate this behavior, to pass
> around options and helper structures to my functions. I don't think
> this is recommended since it doesn't allow functions to specialize on
> the type of objects contained in the Dict.
> 
> Should I use custom types instead? If some fields can be of different
> types, should I use an abstract type for my options and then use
> different subtypes ? This seems a bit too complicated... On the other
> hand, writing down all arguments in functions without using Dicts or
> custom types can be tedious when they are a lot of variables...
> 
> Thanks for your advice.
I'd say yes, use custom types and parameterize them on the types of the
fields that have no fixed type.

Also, using abstract types in function signatures cannot hurt, and it's
only a pair of lines to add, so I'm not sure you're referring to that
when you say "complicated". Maybe you could give us a short example?


Regards

[julia-users] Re: What is the best way to delete unwanted subgraph?

[Seth]

Aleksandr,

The easiest way to do this is something like the following:

cc = connected_components(G)
G = G[cc[1]]


This replaces G with the induced subgraph made up of the vertices in the 
first connected component. (You can create a new graph H if you want to 
keep G.)

We are also implementing rem_vertex!() soon thanks to Carlo Lucibello, but 
it's not in master yet and it's probably not as performant as the above.

Thanks,

Seth.


On Monday, November 23, 2015 at 5:17:33 AM UTC-8, Aleksandr Mikheev wrote:
>
> Hi all,
>
> I'm currently using LightGraphs package in my student research work. And I 
> have some problems with it. Imagine we have a undirrected graph G, which 
> contains, for example, 10 vertices and some edges. I would like to know 
> which components of graph G are connected, so I call 
> "connected_components(G)". Suppose I have this situation:
>
> julia> connected_components(G)
> 6-element Array{Array{Int64,1},1}:
> [1,2,3]
> [4,7]
> [5]
> [6]
> [8,9]
> [10]
>
> And now I would like to delete all subgraphs, except [1,2,3]. In other 
> words, I would like to have subgraph [1,2,3] as a graph G further. Is there 
> any effective methods to do this in LightGraphs or in any other packages? I 
> mean, I can delete vertices one by one (I guess I saw this function 
> somewhere in GitHub), but that would be pretty slow, I imagine.
>
> Thank you in advance.
>

[julia-users] Re: What is the best way to delete unwanted subgraph?

[Seth]

Keep in mind that induced subgraphs will not preserve vertex numbering, so 
if you do something like

G = G[4,5,6]

your old vertices 4, 5, and 6 will be renumbered so that the new G has 
vertices in the range 1 : 3.



On Monday, November 23, 2015 at 5:23:55 AM UTC-8, Seth wrote:
>
> Aleksandr,
>
> The easiest way to do this is something like the following:
>
> cc = connected_components(G)
> G = G[cc[1]]
>
>
> This replaces G with the induced subgraph made up of the vertices in the 
> first connected component. (You can create a new graph H if you want to 
> keep G.)
>
> We are also implementing rem_vertex!() soon thanks to Carlo Lucibello, but 
> it's not in master yet and it's probably not as performant as the above.
>
> Thanks,
>
> Seth.
>
>
> On Monday, November 23, 2015 at 5:17:33 AM UTC-8, Aleksandr Mikheev wrote:
>>
>> Hi all,
>>
>> I'm currently using LightGraphs package in my student research work. And 
>> I have some problems with it. Imagine we have a undirrected graph G, which 
>> contains, for example, 10 vertices and some edges. I would like to know 
>> which components of graph G are connected, so I call 
>> "connected_components(G)". Suppose I have this situation:
>>
>> julia> connected_components(G)
>> 6-element Array{Array{Int64,1},1}:
>> [1,2,3]
>> [4,7]
>> [5]
>> [6]
>> [8,9]
>> [10]
>>
>> And now I would like to delete all subgraphs, except [1,2,3]. In other 
>> words, I would like to have subgraph [1,2,3] as a graph G further. Is there 
>> any effective methods to do this in LightGraphs or in any other packages? I 
>> mean, I can delete vertices one by one (I guess I saw this function 
>> somewhere in GitHub), but that would be pretty slow, I imagine.
>>
>> Thank you in advance.
>>
>

[julia-users] Best way to pass many arguments to functions

[Maxim Berman]

Hello,

In Matlab, people often use structures to pass around arguments between 
functions, for example problem instances. This allows some flexibility in 
the development, since I don't have to think of all variables that I need 
and their types, and new objects can be easily added to existing structs

In Julia, I tend to use Dicts to replicate this behavior, to pass around 
options and helper structures to my functions. I don't think this is 
recommended since it doesn't allow functions to specialize on the type of 
objects contained in the Dict.

Should I use custom types instead? If some fields can be of different 
types, should I use an abstract type for my options and then use different 
subtypes ? This seems a bit too complicated... On the other hand, writing 
down all arguments in functions without using Dicts or custom types can be 
tedious when they are a lot of variables...

Thanks for your advice.

[julia-users] Re: PyPlot behavior change in 0.4? (plt[:show] required?)

[kleinsplash]

Yup. Not sure why but using Sublime/VIM I can only see PyPlot and Gadfly 
using plt[:show](); display(gcf()) does not work for me. 

On Thursday, 19 November 2015 17:52:24 UTC+2, NotSoRecentConvert wrote:
>
> Has PyPlot's default behavior changed in 0.4? When I plot nothing shows up 
> with 0.3 code but there are also no errors. I'm able to save it and 
> everything looks fine but I can't see or interact with the plots when my 
> code is finished. Somebody mentioned plt[:show]() to make all the plots 
> visible but I haven't seen this until today.
>
> Is this a new default behavior or do I have to change a default setting 
> somewhere?
>

Re: [julia-users] Re: passing data by remotecall_fetch slower than writing & loading from disk

[Andre Bieler]

New issue opened #14106

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

[julia-users] jupiter server issue on OSX

[Jon Norberg]

Maybe not strictly a julia question but maybe someone can help...

I just got brand new iMac. I set up everything for jupiter, julia and 
ijulia. can launch notebook just fine. then I change the jupiter config to 
serve the notebook via http. On the computer itself i can open using the ip 
address x.x.x.x:portnr and it opens fine asking for password and julia 
notebook works. But I cannot open it from any other computer. I tried using 
my iPhone as a internet gate in case my university blocked a port, but same 
issue. The port doesn't seem to be open for outside. On a note, I did the 
same on my old iMac and had the same problem. I thought I wait for a new 
computer in case I had screwed anything up on the old one, but alas, same 
problem. Anyone had similar issue and solved it?

set up: 

Xcode (App Store)

Anaconda (graphical installer)

Julia (downloaded 0.4.1 and symlink)

IJulia (Pkg.add)

Jupyter (conda install)


generated jupiter config file


added:


c=get_config()

c.NotebookApp.port=

c.NotebookApp.open_browser=False

c.NotebookApp.password = u'sha1:xyz'

c.NotebookApp.ip = '*'


I have also tried with the ssh certfile and keyhole setup, but no change.

[julia-users] Re: PyPlot behavior change in 0.4? (plt[:show] required?)

[Steven G. Johnson]

On Monday, November 23, 2015 at 8:43:36 AM UTC-5, kleinsplash wrote:
>
> Yup. Not sure why but using Sublime/VIM I can only see PyPlot and Gadfly 
> using plt[:show](); display(gcf()) does not work for me.
>

What do you mean by "using Sublime/VIM"?  Are you editing a Julia script 
foo.jl and then running it with "julia foo.jl"?   Just like in Python, if 
you run Julia in non-interactive mode then Matplotlib is also run in 
non-interactive mode, and you need plt[:show]() when you want the plot to 
appear.

If you are using some plugin for Sublime or VIM that allows you to execute 
code in a running Julia session, but which is not using IJulia, then maybe 
it is forgetting to turn on interactive mode 
(see 
https://github.com/JuliaLang/IJulia.jl/blob/ca35a6397d5e430f94c087f727a499b8e6ecf906/src/kernel.jl#L28-L29)

[julia-users] Re: Problem with "using PyPlot"

[Steven G. Johnson]

Are you on Ubuntu and using the Julia binary there?  If so, it looks like 
you are running into

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

(see the discussion at the very end) due to a conflict between the openblas 
in Ubuntu and the openblas that numpy wants to link to.  See the issue for 
workarounds.

[julia-users] Re: Best way to pass many arguments to functions

[James Gilbert]

(Advice from total julia novice follows, so may be off the mark!)

Yes, you should be using composite types; they are structures.

What abstract types offer you is the ability to write general code which 
works efficiently (thanks to the julia compiler) on different concrete 
types, so they should simplify code overall. (Generic programming.)

Fields in your composite types don't have to specify a particular type, ie: 
they can be type Any. You can start writing your code untyped, then make it 
type stable later where needed.

[julia-users] Re: PyPlot behavior change in 0.4? (plt[:show] required?)

[kleinsplash]

With Sublime I am using cnt+b and vim :!julia %. Both work just fine. I 
don't have a question, happy to use show as stated. 

On Monday, 23 November 2015 16:29:41 UTC+2, Steven G. Johnson wrote:
>
> On Monday, November 23, 2015 at 8:43:36 AM UTC-5, kleinsplash wrote:
>>
>> Yup. Not sure why but using Sublime/VIM I can only see PyPlot and Gadfly 
>> using plt[:show](); display(gcf()) does not work for me.
>>
>
> What do you mean by "using Sublime/VIM"?  Are you editing a Julia script 
> foo.jl and then running it with "julia foo.jl"?   Just like in Python, if 
> you run Julia in non-interactive mode then Matplotlib is also run in 
> non-interactive mode, and you need plt[:show]() when you want the plot to 
> appear.
>
> If you are using some plugin for Sublime or VIM that allows you to execute 
> code in a running Julia session, but which is not using IJulia, then maybe 
> it is forgetting to turn on interactive mode (see 
> https://github.com/JuliaLang/IJulia.jl/blob/ca35a6397d5e430f94c087f727a499b8e6ecf906/src/kernel.jl#L28-L29
> )
>

[julia-users] ERROR: LoadError: UndefVarError: mesh not defined. using MeshIO

[kleinsplash]

My aim is to load an object file and access its faces, vertices and 
normals. 

My current code:

using FileIO
using GLVisualize
using MeshIO

obj_file = "path_to_obj/file.obj"
mesh(obj_file)

I am getting the error: 

ERROR: LoadError: UndefVarError: mesh not defined
 in include at ./boot.jl:261
 in include_from_node1 at ./loading.jl:304
 in process_options at ./client.jl:280
 in _start at ./client.jl:378

Am I calling the mesh fxn incorrectly? 

Re: [julia-users] Best way to pass many arguments to functions

[Sisyphuss]

On Monday, November 23, 2015 at 2:46:12 PM UTC+1, Milan Bouchet-Valat wrote:
>
> Le lundi 23 novembre 2015 à 05:32 -0800, Maxim Berman a écrit : 
> > Hello, 
> > 
> > In Matlab, people often use structures to pass around arguments 
> > between functions, for example problem instances. This allows some 
> > flexibility in the development, since I don't have to think of all 
> > variables that I need and their types, and new objects can be easily 
> > added to existing structs 
> > 
> > In Julia, I tend to use Dicts to replicate this behavior, to pass 
> > around options and helper structures to my functions. I don't think 
> > this is recommended since it doesn't allow functions to specialize on 
> > the type of objects contained in the Dict. 
> > 
> > Should I use custom types instead? If some fields can be of different 
> > types, should I use an abstract type for my options and then use 
> > different subtypes ? This seems a bit too complicated... On the other 
> > hand, writing down all arguments in functions without using Dicts or 
> > custom types can be tedious when they are a lot of variables... 
> > 
> > Thanks for your advice. 
> I'd say yes, use custom types and parameterize them on the types of the 
> fields that have no fixed type. 
>
> Also, using abstract types in function signatures cannot hurt, and it's 
> only a pair of lines to add, so I'm not sure you're referring to that 
> when you say "complicated". Maybe you could give us a short example? 
>
> By "complicated", I think he referred to constructor functions. 

Btw, isn't the keyword argument a good alternative solution? I'm no sure 
whether Julia multipatches the keyword argument type.
 

Re: [julia-users] Re: passing data by remotecall_fetch slower than writing & loading from disk

[Tim Holy]

Thanks
--Tim

On Monday, November 23, 2015 06:24:39 AM Andre Bieler wrote:
> New issue opened #14106
> 
> https://github.com/JuliaLang/julia/issues/14106

Re: [julia-users] Julia Install in Heterogenous Linux Environment: Target architecture mismatch

[elextr]

To obtain best performance Julia uses all resources it knows how to use and 
that are available on the machine it compiles to.  To run on different 
machines the architecture of both has to have the same resources.  So you 
either have to compile to the lowest common denominator of the 
architectures and so possibly missing performance on the machine with more 
resources, or you have to re-compile on both machines. 

The OP doesn't make it clear what version the 2670 chips are, but for 
example a 2680 V3 has different AVX capabilities to a 2670 V2, so code 
compiled for the newer chip may not run on the older one without 
re-compilation.

So its not as simple as just ARM vs Intel.  Advances in the architecture 
happen between two Intel releases as well, and that might prevent binary 
code compatibility.

All languages that compile to machine code have the problem.  Languages 
like Java compile to machine code at runtime, thats fine, but it has a 
performance cost.  You can do that with Julia too for the Julia code, but 
libraries written in other languages still need to be binary compatible.

On Tuesday, November 24, 2015 at 7:49:04 AM UTC+10, Páll Haraldsson wrote:
>
> On Monday, November 23, 2015 at 5:08:16 PM UTC, Yichao Yu wrote:
>>
>> On Mon, Nov 23, 2015 at 11:43 AM, Ian Watson  wrote: 
>> > As far as I know, the underlying O/S and software on both machines is 
>> the 
>> > same, Red Hat Enterprise Linux Server release 6.6 (Santiago), but I 
>> cannot 
>> > be 100% certain about that. I am compiling with gcc-5.2.0 
>> > 
>> > I tried the suggestion in DISTRIBUTING.md, but setting MARCH to either 
>> core2 
>> > or x86-64 failed on the E5-2680 machine - openblas usually fails 
>>
>> Yes, you should build with an architecture that is compatible with all 
>> the ones you want to run on.
>>
>
> I do not see a reason that the architecture "should" be the same (except 
> as he says "but that can wait for another day", of course start with the 
> low hanging fruit). It's not clear to me from the link, if the way to 
> install on heterogeneous is not just supported (because it is not worth it 
> much?), any more, but easily could (seems it could, as it was supported, or 
> was it broken and that is why not longer supported?).
>
> Is it just not worth the effort? Not a large payoff? No need to read 
> further for my speculations..
>
>
> I would think there are a lot of such clusters (maybe a large fraction or 
> majority?). If some parts of clusters are older/slower is that a big 
> drawback (except for the hassle to get different ISAs to work)? [You might 
> need some load balancing? Wouldn't code at least work, with possibly slower 
> nodes dragging down performance, at least never giving wrong results/more 
> race conditions or something?]
>
> I expect the bitness needs to be the same.. (not really much of a 
> problem), and the endianness (or not..?), in theory x86 and ARM etc. could 
> be combined (not a good idea..?), and even to OSes different (maybe again 
> not a good idea and no good reason..(?)).
>
> I just ask out of curiosity, it seems Julia would be ideal to do stuff 
> like this, and say for x86 and ARM, not really possible (or at least a 
> hassle) for the "competition" (e.g. C++). An exception, might be Java/JVM 
> and CLR etc. but at least JVM (both?) do not have multi-dimensional arrays 
> (I'm not sure if JVMs are much of a competition, but IBM did some heroic 
> optimizations to get multidimensional arrays to work fast/er with [their 
> (only I think)] JVM and compiler - I'm not sure if this is used much..).
>
>
> The alternative for established languages is differently compiled 
> executable on each node - might not be out of the question in a source code 
> environment (already done that way?) - and/or executable/libraries 
> dynamically choose different machine code as in e.g.: "openblas defaults to 
> detecting the runtime system and picking the best code to run for that 
> computer." [See above, why did openblas then fail? I guess because of 
> "binutils too old", and shouldn't have otherwise] I wander how commonly 
> code is compiled that way, just for x86-variants (it has a runtime cost.. 
> and I assume not done as fat binaries for x86/ARM and wouldn't scale to 
> more..). 
>
> -- 
> Palli.
>
>

[julia-users] Images, ImageView.view change the original variable

[Fliprl Data]

I'm a newbie in Julia, I really appreciate if you could help me on this. 

I had issues when using piece of code below. Apparently, the original 
variable (excm) is changed, so when I type ImageView.view(excm) before and 
after the routine, it is changed, but I'm only manipulating a copy of it 
(dmode). I have a similar issue when copying properties of one image to 
another. 

ImageView.view(excm)
dmode = excm;
for i in 2:206
for j in 2:206
surr = length(dmode[i-1:i+1,j-1:j+1] .< 0.2)
if surr > 4 dmode[i,j] = 0 end
end
end
ImageView.view(excm)

note: once I ran the code ImageView.view(excm) shows me a modified version 
of excm, even if I'm modifying dmode only. 

How can I create copies of the image without changing the original, I guess 
I don't know how to assign it.

thanks a lot,

[julia-users] Re: What is the best way to delete unwanted subgraph?

[Aleksandr Mikheev]

Really sorry for silly questions, but I am really new to Julia language and 
also I am not very good in coding generally.

[julia-users] Re: What is the best way to delete unwanted subgraph?

[Aleksandr Mikheev]

Excuse me once again. How can I use rem_vertex!() now? I tried to update my 
package - didn't help. I tried to do a new file (called GraphFeatures), in 
witch I copied all the functions from here 

 - 
but it does not understand standart Graph type from LightGraphs:

ERROR: MethodError: `rem_vertex!` has no method matching 
> rem_vertex!(::LighGraphs.Graph, ::Int64)
> Closest candidates are:
>   rem_vertex!(::Union{GraphFeatures.DiGraph,GraphFeatures.Graph}, ::Int64)


 What should I do? 

[julia-users] Re: What is the best way to delete unwanted subgraph?

[Seth]

On Monday, November 23, 2015 at 2:09:13 PM UTC-8, Aleksandr Mikheev wrote:
>
> Excuse me once again. How can I use rem_vertex!() now? I tried to update 
> my package - didn't help. I tried to do a new file (called GraphFeatures), 
> in witch I copied all the functions from here 
> 
>  - 
> but it does not understand standart Graph type from LightGraphs:
>
> ERROR: MethodError: `rem_vertex!` has no method matching 
>> rem_vertex!(::LighGraphs.Graph, ::Int64)
>> Closest candidates are:
>>   rem_vertex!(::Union{GraphFeatures.DiGraph,GraphFeatures.Graph}, ::Int64)
>
>
>  What should I do? 
>

Try this:

Pkg.clone("LightGraphs") # this makes sure you're on the most current code 
in master
Then exit / restart Julia REPL, and type "using LightGraphs" - this will 
force a recompile
rem_vertex!() should now be available for Graph and DiGraph:

julia> g = PathGraph(10)
{10, 9} undirected graph

julia> rem_vertex!(g,4)
{9, 7} undirected graph

If you have any other questions, please feel free to ask here or open up an 
issue on the LightGraphs repo.

Really sorry for silly questions, but I am really new to Julia language and 
> also I am not very good in coding generally.
>
 
Absolutely no need to apologize. Feel free to ask away.

Re: [julia-users] Images, ImageView.view change the original variable

[Fliprl Data]

that's awesome, it works like a charm, thank you very much

also, do you see any need on using the 'data' function (from image.jl: 
returns a reference to the array data in the image. It allows you to use an 
algorithm written for Arrays or AbstractArrays on Image types.) to extract 
data of an image to an array, or is it the same as making a copy of it to 
further manipulation?

thanks a lot,



On Monday, November 23, 2015 at 7:06:20 PM UTC-3, Tom Breloff wrote:
>
> When you do "dmode = excm", you're only binding the variable name "dmode" 
> to the reference "excm".  They point to the same underlying object.  You 
> could try "dmode = copy(excm)"
>
> On Mon, Nov 23, 2015 at 4:38 PM, Fliprl Data  > wrote:
>
>>
>>
>> I'm a newbie in Julia, I really appreciate if you could help me on this. 
>>
>> I had issues when using piece of code below. Apparently, the original 
>> variable (excm) is changed, so when I type ImageView.view(excm) before and 
>> after the routine, it is changed, but I'm only manipulating a copy of it 
>> (dmode). I have a similar issue when copying properties of one image to 
>> another. 
>>
>> ImageView.view(excm)
>> dmode = excm;
>> for i in 2:206
>> for j in 2:206
>> surr = length(dmode[i-1:i+1,j-1:j+1] .< 0.2)
>> if surr > 4 dmode[i,j] = 0 end
>> end
>> end
>> ImageView.view(excm)
>>
>> note: once I ran the code ImageView.view(excm) shows me a modified 
>> version of excm, even if I'm modifying dmode only. 
>>
>> How can I create copies of the image without changing the original, I 
>> guess I don't know how to assign it.
>>
>> thanks a lot,
>>
>
>

Re: [julia-users] Images, ImageView.view change the original variable

[Tom Breloff]

When you do "dmode = excm", you're only binding the variable name "dmode"
to the reference "excm".  They point to the same underlying object.  You
could try "dmode = copy(excm)"

On Mon, Nov 23, 2015 at 4:38 PM, Fliprl Data  wrote:

>
>
> I'm a newbie in Julia, I really appreciate if you could help me on this.
>
> I had issues when using piece of code below. Apparently, the original
> variable (excm) is changed, so when I type ImageView.view(excm) before and
> after the routine, it is changed, but I'm only manipulating a copy of it
> (dmode). I have a similar issue when copying properties of one image to
> another.
>
> ImageView.view(excm)
> dmode = excm;
> for i in 2:206
> for j in 2:206
> surr = length(dmode[i-1:i+1,j-1:j+1] .< 0.2)
> if surr > 4 dmode[i,j] = 0 end
> end
> end
> ImageView.view(excm)
>
> note: once I ran the code ImageView.view(excm) shows me a modified version
> of excm, even if I'm modifying dmode only.
>
> How can I create copies of the image without changing the original, I
> guess I don't know how to assign it.
>
> thanks a lot,
>

[julia-users] Re: What is the best way to delete unwanted subgraph?

[Seth]

Er. Sorry for the bad instructions. Don't use Pkg.clone("LightGraphs"), use 
Pkg.checkout("LightGraphs").

On Monday, November 23, 2015 at 2:31:42 PM UTC-8, Seth wrote:
>
>
>
> On Monday, November 23, 2015 at 2:09:13 PM UTC-8, Aleksandr Mikheev wrote:
>>
>> Excuse me once again. How can I use rem_vertex!() now? I tried to update 
>> my package - didn't help. I tried to do a new file (called GraphFeatures), 
>> in witch I copied all the functions from here 
>> 
>>  - 
>> but it does not understand standart Graph type from LightGraphs:
>>
>> ERROR: MethodError: `rem_vertex!` has no method matching 
>>> rem_vertex!(::LighGraphs.Graph, ::Int64)
>>> Closest candidates are:
>>>   rem_vertex!(::Union{GraphFeatures.DiGraph,GraphFeatures.Graph}, 
>>> ::Int64)
>>
>>
>>  What should I do? 
>>
>
> Try this:
>
> Pkg.clone("LightGraphs") # this makes sure you're on the most current code 
> in master
> Then exit / restart Julia REPL, and type "using LightGraphs" - this will 
> force a recompile
> rem_vertex!() should now be available for Graph and DiGraph:
>
> julia> g = PathGraph(10)
> {10, 9} undirected graph
>
> julia> rem_vertex!(g,4)
> {9, 7} undirected graph
>
> If you have any other questions, please feel free to ask here or open up 
> an issue on the LightGraphs repo.
>
> Really sorry for silly questions, but I am really new to Julia language 
>> and also I am not very good in coding generally.
>>
>  
> Absolutely no need to apologize. Feel free to ask away.
>
>

Re: [julia-users] ObjectIdDict

[Leonardo]

Many thanks!

I've not found these info on Julia official documentation: if not present, 
I think should be useful to add them

Leonardo


Il giorno domenica 22 novembre 2015 20:20:35 UTC+1, Stefan Karpinski ha 
scritto:
>
> Yes, Set is implemented using a hash table. ObjectIdDict is for situations 
> where you want to hash based on object identity (===) rather than equality 
> (isequal).
>
> On Sunday, November 22, 2015, Leonardo  
> wrote:
>
>> Of course I can use Dict (ObjectIdDict is a sort of Dict), adding entries 
>> as previously written.
>> Set is even better, but elements of Set are accessed with hash?
>> E.g. "hello" in s of your example is executed in constant or linear time?
>>
>> Thanks 
>>
>> Leonardo
>>
>> P.S. for my clarification: what is reccomended context of use for 
>> ObjectIdDict?
>>
>>
>> Il giorno domenica 22 novembre 2015 19:05:58 UTC+1, Tim Holy ha scritto:
>>>
>>> Why can't you use Set or Dict? 
>>>
>>> julia> s = Set{ASCIIString}() 
>>> Set{ASCIIString}() 
>>>
>>> julia> push!(s, "hello") 
>>> Set(ASCIIString["hello"]) 
>>>
>>> julia> push!(s, "world") 
>>> Set(ASCIIString["hello","world"]) 
>>>
>>> julia> "hello" in s 
>>> true 
>>>
>>> julia> "nope" in s 
>>> false 
>>>
>>> --Tim 
>>>
>>> On Sunday, November 22, 2015 09:58:31 AM Leonardo wrote: 
>>> > Hello, 
>>> > I'm looking for an Hash table in Julia (or Hash Set, how is called in 
>>> other 
>>> > programming languages), to efficiently check existence of an element 
>>> in 
>>> > set, but I haven't found it. 
>>> > I've found ObjectIdDict as alternative, defined as: 
>>> > ObjectIdDict <: Dict{Any,Any} 
>>> > where key and value are equals, capable to store reference any object 
>>> (if 
>>> > I'm not wrong). 
>>> > It has a simple constructor: 
>>> > d = ObjectIdDict() 
>>> > (no type stored is specified, cause previous definition) 
>>> > 
>>> > But - also inspecting code of dict.jl in Base package - I haven't 
>>> found a 
>>> > simple method to add element in set like: 
>>> > push!(d,obj) 
>>> > but only the form 
>>> > d[obj] = obj 
>>> > works. This is correct way to do this? (potentially key and value can 
>>> be 
>>> > different ...) 
>>> > 
>>> > Many thanks in advance 
>>> > 
>>> > Leonardo 
>>>
>>>

[julia-users] Error while Building PyCall

[Vishnu Raj]

Hi,

I'm using Julia 0.4.0 in OSX 10.10. Today when I tried to upgrade my 
packages I got this error
julia> Pkg.build( "PyCall" )
INFO: Building PyCall
INFO: Recompiling stale cache file /Users/vish/.julia/lib/v0.4/Conda.ji for 
module Conda.
WARNING: Module SHA uuid did not match cache file
WARNING: deserialization checks failed while attempting to load cache from 
/Users/vish/.julia/lib/v0.4/Conda.ji
INFO: Precompiling module Conda...
INFO: Recompiling stale cache file /Users/vish/.julia/lib/v0.4/Conda.ji for 
module Conda.
WARNING: Module JSON uuid did not match cache file
==[
 
ERROR: PyCall 
]==

LoadError: __precompile__(true) but require failed to create a precompiled 
cache file
while loading /Users/vish/.julia/v0.4/PyCall/deps/build.jl, in expression 
starting on line 12

=

==[
 
BUILD ERRORS 
]===

WARNING: PyCall had build errors.

 - packages with build errors remain installed in /Users/vish/.julia/v0.4
 - build the package(s) and all dependencies with `Pkg.build("PyCall")`
 - build a single package by running its `deps/build.jl` script

=
 Version Info gives
julia> versioninfo()
Julia Version 0.4.0
Commit 0ff703b* (2015-10-08 06:20 UTC)
Platform Info:
  System: Darwin (x86_64-apple-darwin13.4.0)
  CPU: Intel(R) Core(TM) i5-4570R CPU @ 2.70GHz
  WORD_SIZE: 64
  BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Haswell)
  LAPACK: libopenblas64_
  LIBM: libopenlibm
  LLVM: libLLVM-3.3


Any thoughts on what's happening and how to build this?

[julia-users] Re: Ray tracing for complex geometry

[Simon Danisch]

Yeah, now worries! This is pretty much the XY problem 
, which easily happens to the best 
of us.
Just be sure to include enough context information. 

You can make a screenshot with glvisisualize with: screenshot(window, path="
screenshot.png")
Screenshot of the depth map is slowly on its way... Don't want to promise 
anything here!
Best would be, if you file an issue 
, so we don't have to 
missuse julia-users for that discussion!

Am Freitag, 20. November 2015 16:18:46 UTC+1 schrieb kleinsplash:
>
> I was wondering if someone could help me out with a decision/offer an 
> opinion:
>
> I need a ray tracer that deals with complex geometry (a fast ray tracer 
> that can create 1000's of point clouds in minimal time) 
> Python has methods: http://pyopengl.sourceforge.net/ that I could get to 
> grips with. But I want to stick with Julia. 
>
> I have found these resources: 
> https://github.com/JuliaGL/ModernGL.jl - not sure if this has a ray 
> tracing option
> http://www.cs.columbia.edu/~keenan/Projects/QuaternionJulia/ - looks 
> crazy complicated
>
> https://github.com/JuliaLang/julia/blob/master/test/perf/kernel/raytracer.jl 
> - looks like only handles simple geometry
>
> Could someone point me in the right direction?
>
>  
>

[julia-users] Re: JuliaBox disconnects after several hours of use (or non-use)

[cdm]

related:

  
https://groups.google.com/forum/#!searchin/julia-box/timeout/julia-box/FkTpk5r91Oc/53U8gU_JB4cJ



of note, similar hosted services are provided at:

   https://try.jupyter.org/  (note that the Julia version here is 
dated ...)



and an option for those comfortable in Linux environment, there is the Sage 
Math Cloud:

   https://cloud.sagemath.com/help  (the latest Julia Ubuntu PPAs 
are usually installed ...)

where there are free and paid subsriptions ...

Re: [julia-users] Pre-ANN: PlotlyJS.jl

[Eric Forgy]

Hi Tom,

Thanks for your note. Yeah, sure. I am definitely interested in helping where I 
can. I started out working on Tony's fork of Plotly.jl since he had already 
converted to using Requests.jl, but by the time I got the WebSockets working, I 
realized I didn't need any of that code and could just interact with plotly.js 
directly, so gave it a new name :) With PlotlyJS, I'm pretty sure I can 
reproduce every example from their web page already. You simply need to 
construct Dicts that correspond to the JSON.

I submitted a PR to plotly.js too that would allow us to create multiple axes 
dynamically. Currently, the div name you provide needs to already exist in the 
DOM. In my PR, if you supply a name that isn't in the DOM, it will create a div 
with that name. Not sure if they will accept it though :)

I haven't spent much time with Bokeh and Vega, but expect it should be 
straightforward to use the same trick with those guys. In fact, I have my own 
JS graphing library I spent about 6 months developing a while ago I'd like to 
resurrect (boring demo alert http://youtu.be/IriE1ZP-uOM ) :)

I am also interested in updating existing charts. If we just change "newPlot" 
to "plot", it will append subplots to the current div, but that's not what I 
wanted. I should follow the same naming as plotly.js though I suppose. As I 
said, this is a "Pre-ANN" :D

For applications beyond visualizations, I may have need in my day job for 
something like this to get Matlab/Julia talking (without using MEX) so ideas 
are welcome :)

Sent from my iPhone

> On 24 Nov 2015, at 5:21 AM, Tom Breloff  wrote:
> 
> Eric: I just looked through your code.  It doesn't seem like there's very 
> much plotly-specific code in there.  I wonder if you could generalize a 
> little so that Bokeh or Vega could use your websocket approach as well.  That 
> seems like it has uses beyond desktop visualizations.  I also think it would 
> be great to separate plot-creation from plot-updating so that you could use 
> websockets to update existing plots.  Let me know if you'd like to integrate 
> your idea with Plots.jl.
> 
> ps - I love your music choice for your video... very dramatic
> 
>> On Mon, Nov 23, 2015 at 2:34 PM, Tom Breloff  wrote:
>> Much of Plotly.jl is for interacting with the cloud API (login, credentials, 
>> etc). The remainder cannot be called directly so, for my purpose, it made 
>> more sense to just build the json directly. Others will likely still find 
>> this package to be useful. 
>> 
>> 
>>> On Monday, November 23, 2015, Sisyphuss  wrote:
>>> So the following package is no longer useful?
>>> 
>>> https://github.com/plotly/Plotly.jl
> 

[julia-users] funky ccall macro

[Dömötör Gulyás]

So apparently, this: https://github.com/JuliaLang/julia/issues/14110 is not 
a bug. Which leaves me with the question, how to accomplish concatenating 
the argument types tuple for ccall()? There doesn't seem to be a way to 
accomplish the concatenation (without also evaluating the type parameters) 
in ways that result in a valid argument type list for ccall(). The idea is 
to not have to eval() at runtime for every ccall(), as ObjectiveC.jl 
currently does.

A simplified core part of the above:

julia> U = (Ptr{UInt8},)

(Ptr{UInt8},)


julia> :((Ptr{Void},Ptr{Void})..., $U...)

:(((Ptr{Void},Ptr{Void})...,(Ptr{UInt8},)...))


julia> Meta.show_sexpr(:((Ptr{Void},Ptr{Void})..., $U...))

(:tuple, (:..., (:tuple, (:curly, :Ptr, :Void), (:curly, :Ptr, :Void))), 
(:..., (Ptr{UInt8},)))


The suggestion is not evaluate the macro, which still leaves the unexpanded 
(Ptr{UInt8},) in there, and ccall() complains about the types. With some 
mucking about of objc_msgSendTupleConcat sometimes that shows up as (:curly, 
:Ptr, :UInt8) but only in ways that fail at the ccall or julia trying to 
evaluate the tuple concatenation.

Is there another way of doing this? I wasn't able to get the intended 
behavior with a templated function, either, but it feels like it should be 
possible.

Re: [julia-users] Re: Ray tracing for complex geometry

[Steve Kelly]

I think most of the people working on mesh related geometry are doing it
part-time and building these libraries is part of the learning experience.
Asking questions is important, since it is the only way to gain insight. If
you have more questions about Meshes, I'd be happy to help on the github
bug tracker.

My senior thesis is on Polyhedra, and I thought it would be easy since I
have been working with mesh types for over a year. It turned out I was
wrong, and the needs of the application revealed a whole set of types (and
more importantly relations between them) that are very important for
combinatorial geometry. Stretching the application of libraries is really
important, and I am sure in time you will be contributing back if you stick
with it!

On Mon, Nov 23, 2015 at 7:31 AM, kleinsplash 
wrote:

> Nope. I have obj files. Your hypothesis is correct. I have attached one of
> them. Your script works just fine (is there an easy way to save this
> image?).
>
> As a side note: I do collect point clouds using V-REP, and I can generate
> pointclouds (pcd) using pcl - but I want to work with the obj mesh files
> because the clouds are too sparse.
>
> I probably could have explained myself better, point taken. I will aim to
> try harder next time, I feel horrid when I am asking basic questions and on
> top of that writing an essay.
>
> The only other person I know who uses the term interwebz is Richard on
> Fast and Loud - I am an avid supporter.
>
> On Monday, 23 November 2015 13:41:40 UTC+2, Simon Danisch wrote:
>>
>> I'm not sure what you mean by virtual objects. Obj is in the context of
>> 3D objects is usually the wavefront
>>  format.
>> If you have an object database with *.obj's in it, the probability is
>> very high, that you don't have pointclouds whatsoever.
>> You can try this, to confirm my hypothesis:
>>
>> using GLVisualize, FileIO
>> obj = load("file.obj")
>> w,r = glscreen()
>> view(visualize(obj))
>> r()
>>
>> Or just download any obj viewer from the interwebzz and look at that
>> thing.
>> If you have nice smooth surfaces, you're getting it all wrong with the
>> pointclouds and ray tracing.
>> I could give you some hacky way of extracting depth images with
>> GLVisualize, if that's what you're after.
>> In that case, just try the example above and if that works, open an issue
>> at GLVisualize that you want depth images. Then we can take it from there.
>>
>>
>> If by any chance you DO have pointclouds stored in an obj file, things
>> are more complicated since you then need to approximate the surface of that
>> cloud.
>> Still, raytracing wouldn't be your friend ;) If you have infinitely small
>> points, there is no magic that lets a ray hit these points any better then
>> some other visualization algorithm.
>> Even if it's really dense, you still have infinitely small points. You
>> can treat the points as particles, to give them some "body" that you can
>> see, but then it's not really a surface anymore.
>>
>> Just google for pointcloud surface approximation and see where that gets
>> you.
>>
>> I'm guessing here, that you have some sensor that outputs depth images
>> and you want to recognize objects in these depth images.
>> To train your depth image classifier, you need depth images from a lot of
>> perspectives from a lot of random 3D objects, which is why you searched for
>> a 3D object database, which got you to the obj files of random 3D objects.
>>
>> It'd have been a lot easier, if you just stated this in your problem
>> description, probably even with links to the obj database.
>>
>> Best,
>> Simon
>>
>> Am Freitag, 20. November 2015 16:18:46 UTC+1 schrieb kleinsplash:
>>>
>>> I was wondering if someone could help me out with a decision/offer an
>>> opinion:
>>>
>>> I need a ray tracer that deals with complex geometry (a fast ray tracer
>>> that can create 1000's of point clouds in minimal time)
>>> Python has methods: http://pyopengl.sourceforge.net/ that I could get
>>> to grips with. But I want to stick with Julia.
>>>
>>> I have found these resources:
>>> https://github.com/JuliaGL/ModernGL.jl - not sure if this has a ray
>>> tracing option
>>> http://www.cs.columbia.edu/~keenan/Projects/QuaternionJulia/ - looks
>>> crazy complicated
>>>
>>> https://github.com/JuliaLang/julia/blob/master/test/perf/kernel/raytracer.jl
>>> - looks like only handles simple geometry
>>>
>>> Could someone point me in the right direction?
>>>
>>>
>>>
>>

[julia-users] Re: JuliaBox disconnects after several hours of use (or non-use)

[Sisyphuss]

If he has many cells, it won't be convenient to copy-paste. 
But Juliabox autosaves every several minutes, which already largely prevent 
the lost of code (at least for my speed of coding).


On Monday, November 23, 2015 at 8:23:50 AM UTC+1, Patrick Kofod Mogensen 
wrote:
>
> I know this is not a solution to the problem, but what do you mean by 
> "lost code" ? Couldn't you just copy the text in the browser to a local 
> editor?
>
> On Monday, November 23, 2015 at 6:09:45 AM UTC+1, Thomas Moore wrote:
>>
>> I've been really enjoying using JuliaBox for some simulations related to 
>> my PhD work. The fact that I can work on my code *anywhere* - in the 
>> office, the library, at home - with no worries about which version of Julia 
>> I'm using is fantastic! 
>>
>> However, I've noticed that JuliaBox often disconnects after it's been 
>> running for several hours - this seems to happen even if it's being used 
>> the entire time. Unfortunately, this can result in lost code (as saving is 
>> impossible) and some frustration.
>>
>> I realise that JuliaBox is not being hosted by Julia itself, but would 
>> there be any way we could work to getting remove this issue?
>>
>> Thanks
>>
>

Re: [julia-users] Assigning variables

[Sisyphuss]

Maybe metaprogramming?


On Sunday, November 22, 2015 at 8:52:24 PM UTC+1, Stefan Karpinski wrote:
>
> Not really. An array is much better for this.
>
> On Sun, Nov 22, 2015 at 2:28 PM, digxx  > wrote:
>
>> Manually I can do:
>> arr1=...
>> arr2=...
>> arr3=...
>> and so on
>> If I have a loop over i can i construct in each loop a new variable 
>> symbolically like this:
>> arr*string(i)=... ?
>>
>>
>

Re: [julia-users] Assigning variables

[Stefan Karpinski]

You have a bunch of values indexed by an integer. That's what arrays are
for.

On Mon, Nov 23, 2015 at 10:11 AM, Sisyphuss  wrote:

> Maybe metaprogramming?
>
>
> On Sunday, November 22, 2015 at 8:52:24 PM UTC+1, Stefan Karpinski wrote:
>>
>> Not really. An array is much better for this.
>>
>> On Sun, Nov 22, 2015 at 2:28 PM, digxx  wrote:
>>
>>> Manually I can do:
>>> arr1=...
>>> arr2=...
>>> arr3=...
>>> and so on
>>> If I have a loop over i can i construct in each loop a new variable
>>> symbolically like this:
>>> arr*string(i)=... ?
>>>
>>>
>>

Re: [julia-users] Concatenation without splatting

[Mauro]

> That doesn’t quite seem to do what you want, Mauro:

Yes, you're right, sorry for the noise!

> julia> arr_of_arr = Vector{Int}[[1],[2,3],[4,5]]
> 3-element Array{Array{Int64,1},1}:
>  [1]
>  [2,3]
>  [4,5]
>
> julia> vcat_nosplat(y) = eltype(y[1])[el[1] for el in y]
> vcat_nosplat (generic function with 1 method)
>
> julia> vcat_nosplat(arr_of_arr)
> 3-element Array{Int64,1}:
>  1
>  2
>  4
>
> It’s quite trivial to achieve the desired result with only a few lines of
> code, though:
>
> julia> function vcat_nosplat2(y)
>result = Array(eltype(y[1]), 0)
>sizehint!(result, sum(map(length, y))) #skip if iterating is more 
> expensive than reallcoation
>
>for a in y
>for x in a
>push!(result, x)
>end
>end
>
>result
>end
> vcat_nosplat2 (generic function with 1 method)
>
> julia> vcat_nosplat2(arr_of_arr)
> 5-element Array{Int64,1}:
>  1
>  2
>  3
>  4
>  5
>
> // T
>
> On Sunday, November 22, 2015 at 9:12:55 PM UTC+1, Mauro wrote:
>
> In ODE.jl, I've used
>>
>> vcat_nosplat(y) = eltype(y[1])[el[1] for el in y] # Does vcat(y...)
>> without the splatting
>>
>> I think the eltype might not be needed.  There may be better ways though.
>>
>> On Sun, 2015-11-22 at 14:04, Cedric St-Jean > > wrote:
>> > I have a big vector of vectors. Is there any way to vcat/hcat them
>> without
>> > splatting?
>> >
>> > arr_of_arr = Vector[[1],[2,3],[4,5]]
>> > vcat(arr_of_arr...)
>> >
>> > I'm asking because splatting big arrays is a performance issue (and IIRC
>> it
>> > blows the stack at some point).
>>
>

Re: [julia-users] type conversion

[Sisyphuss]

On Sunday, November 22, 2015 at 11:22:07 PM UTC+1, Milan Bouchet-Valat 
wrote:
>
> Le dimanche 22 novembre 2015 à 14:08 -0800, Martin Kuzma a écrit : 
> > 
> > 
> > Hi, i am new to Julia and i am little bit confused about type 
> > conversion. 
> > In the docs is written following: 
> > 
> > When appended to a variable in a statement context, the :: operator 
> > means something a bit different: it declares the variable to always 
> > have the specified type, like a type declaration in a statically 
> > -typed language such as C. Every value assigned to the variable will 
> > be converted to the declared type using convert() 
> > 
> > So I tried a little experiment. 
> > 
> > a::Array{Cdouble, 2} = [1 2 3;4 5 6] #this throws ERROR: TypeError: 
> > typeassert: expected Array{Float64,2}, got Array{Int64,2} 
> >  in eval at ./boot.jl:263 
> > 
> > experiment no. 2: 
> > convert(Array{Cdouble,2}, [1 2 3;4 5 6]) # this outputs 2x3 
> > Array{Float64,2}: 
> >  1.0  2.0  3.0 
> >  4.0  5.0  6.0 
> > So the conversion works.. I thought, that the conversion will be 
> > automatic, but it isn't. What am I getting wrong? 
> This works only inside of a function, not directly at the REPL. Maybe 
> the docs could be clarified. 
>
> To be precise, only on local (not global) scope.  

Re: [julia-users] Re: Better alternative to find all permutations?

[Stefan Karpinski]

Any algorithm for producing unique permutations obviously needs to rely on
some notion of element equality. That could be user-defined but default to
something sane. I suspect that isequal or === would be good choices; == is
not a good choice since NaN is not even == to itself.

On Mon, Nov 23, 2015 at 8:03 AM, Tamas Papp  wrote:

> IMO permutations should maintain the following invariant: for any vector
> v,
>
> isequal(map(i -> getindex(v,i), collect(permutations(1:length(v,
> collect(permutations(v)))
>
> Bringing equality and uniqueness into the issue disposes of this
> property, which is desirable in many applications.
>
> Best,
>
> Tamas
>
> On Mon, Nov 23 2015, Glen O  wrote:
>
> > Logically, the same definition being used by "unique" would be applied,
> > unless specified otherwise (which should also be available for unique -
> > it's silly that you can't specify the level of inequality necessary for
> > uniqueness).
> >
> > Incidentally, in the example you gave, unique gives
> > [0.0,-0.0,NaN,Foo(),Bar(NaN),Bar(NaN)]
> >
> > On Monday, 23 November 2015 05:08:12 UTC+10, Tamas Papp wrote:
> >>
> >> Also, "unique" permutations require a notion of equality, and which is
> >> hard to define in general (classic essay is [1], about Common Lisp,
> >> but applies to Julia mutatis mutandis). At least Julia has bits types
> >> for numbers, which makes life a bit easier.
> >>
> >> Whether one picks is, isequal, or == for comparison, it easy to come up
> >> with cases which go against user expectations (at least for some
> >> users). For example, given
> >>
> >> type Foo end
> >> type Bar x end
> >>
> >> what should be the unique permutations of
> >>
> >> [0.0,-0.0,NaN,NaN,Foo(),Foo(),Bar(NaN),Bar(NaN)]
> >>
> >> ?
> >>
> >> Best,
> >>
> >> Tamas
> >>
> >> [1] http://www.nhplace.com/kent/PS/EQUAL.html
> >>
> >> On Sun, Nov 22 2015, Ratan Sur 
> wrote:
> >>
> >> > I think julia more than other languages has a tendency to stick with
> >> > mathematical consistency over some user preferences, which is good.
> For
> >> > that reason, I would be in favor of permutations remaining as is but
> >> having
> >> > multiset_permutations renamed to something more intuitive, like
> >> > uniqueperms, or unique_permutations.
> >> >
> >> > On Sun, Nov 22, 2015 at 2:16 AM Glen O  >
> >> wrote:
> >> >
> >> >> While it is true that an interpretation of arrays is multisets,
> that's
> >> not
> >> >> the only reasonable interpretation. And while the strict
> interpretation
> >> of
> >> >> "permutations" suggests it should include duplicates, you have to
> >> consider
> >> >> what the user would most likely expect it to do. Most would think
> that
> >> a
> >> >> list of the permutations would include unique permutations only.
> >> >>
> >> >> So perhaps both functionalities should be available in the same
> >> function
> >> >> with a keyword argument. At the very least, the description of the
> >> function
> >> >> should directly inform the user that it's going to give duplicate
> >> >> permutations if the array contains repeat elements.
> >> >>
> >> >> On Saturday, 21 November 2015 04:24:51 UTC+10, Jiahao Chen wrote:
> >> >>>
> >> >>> The current behavior of permutations is correct and should not be
> >> >>> changed. Combinatorially, arrays are multisets, not sets, since they
> >> allow
> >> >>> for duplicate entries, so it is correct to produce what look like
> >> identical
> >> >>> permutations. The redundancy is important for operations that can be
> >> >>> expressed as sums over all permutations.
> >> >>>
> >> >>> Combinatorics.jl currently provides multiset_permutations for
> >> generating
> >> >>> only distinct permutations:
> >> >>>
> >> >>>
> >> >>>
> >>
> https://github.com/JuliaLang/Combinatorics.jl/blob/3c08c9af9ebeaa54589e939c0cf2e652ef4ca6a0/test/permutations.jl#L24-L25
> >> >>>
> >> >>
> >>
> >>
>

Re: [julia-users] Assigning variables

[Sisyphuss]

I knew it.

On Monday, November 23, 2015 at 4:25:37 PM UTC+1, Stefan Karpinski wrote:
>
> You have a bunch of values indexed by an integer. That's what arrays are 
> for.
>
> On Mon, Nov 23, 2015 at 10:11 AM, Sisyphuss  > wrote:
>
>> Maybe metaprogramming?
>>
>>
>> On Sunday, November 22, 2015 at 8:52:24 PM UTC+1, Stefan Karpinski wrote:
>>>
>>> Not really. An array is much better for this.
>>>
>>> On Sun, Nov 22, 2015 at 2:28 PM, digxx  wrote:
>>>
 Manually I can do:
 arr1=...
 arr2=...
 arr3=...
 and so on
 If I have a loop over i can i construct in each loop a new variable 
 symbolically like this:
 arr*string(i)=... ?


>>>
>

[julia-users] Are traits or another form of multiple inheritance in base

[Lampkld]

Hello,

I have a  use case that specifically requires multiple inheritance (and 
concrete inheritance to a lesser degree).

Will traits or another mechanism for subtyping from multiple kinds 
definitely make it into base? 

Thanks

Re: [julia-users] Using Meshes.ji

[kleinsplash]

Thanks to group managed to plot using GLVisualize:

using GLVisualize
using FileIO
w,r = glscreen()
view(visualize(obj))
r()

from Simon's answer here: 
https://groups.google.com/d/msg/julia-users/W8D6kAJhREI/N89EOObzCAAJ  
 

On Monday, 23 November 2015 13:53:50 UTC+2, kleinsplash wrote:
>
> Looks like accessing has changed a bit - so to get to the faces I did 
>
> obj = load("path.obj")
> faces = obj.faces
>
> So far I haven't had much luck in either plotting this or accessing the 
> faces and the verticies. As soon as I figure it out I will get back. This 
> is linked to my other question, for some reason I wasn't automatically 
> subscribed to this one. 
>
>
> On Monday, 9 November 2015 18:45:01 UTC+2, Steve Kelly wrote:
>>
>> The faces can be accessed with faces(load("foo.obj")) or mesh.faces.
>>
>> Probably the easiest way to display the mesh at this point is with 
>> ThreeJS.jl: 
>> https://github.com/rohitvarkey/ThreeJS.jl/blob/master/examples/mesh.jl. 
>> This approach should work in IJulia and Blink.
>>
>> GLVisualize has some good demos and a much more responsive backend, but 
>> it needs some work to run in OpenGL < 3.3 and the working commits aren't on 
>> Metadata yet. Meshes is kind of a weird state right now, and most of the 
>> functionality can be had with GeometryTypes, Meshing, and MeshIO. We have 
>> been working the past few months to finish the coupling between data 
>> structures for geometry and visualization. It would be great to hear your 
>> application, and see if we could achieve something in the short term that 
>> would work for you. Personally I use Meshlab when I do solid modelling in 
>> Julia which slows down my iteration time, and it would be nice to have a 
>> mesh viewer in the workflow.
>>
>> Best,
>> Steve
>> On Nov 9, 2015 9:55 AM, "Ashley Kleinhans"  wrote:
>>
>>> Hi,
>>>
>>> I am new at this - but have decided that Julia is my language of choice. 
>>> So I begin silly question stage: 
>>>
>>> Could someone talk me through how to access and display an .obj file? 
>>>
>>> I have gotten so far:
>>>
>>> using Meshes
>>> using PyPlot
>>> using FileIO
>>> using MeshIO
>>>
>>> obj = load(filename)
>>> vts = obj.vertices 
>>>
>>>
>>> Which gives me: 
>>>
>>> 502-element Array{FixedSizeArrays.Point{3,Float32},1}:
>>>
>>>
>>>
>>> One example point being: 
>>>
>>> Point(0.00117,-0.02631,0.03907)
>>>
>>> 
>>>
>>>
>>>   
>>>
>>> How do I access the verticies to use them with plot? 
>>>
>>> -A
>>>
>>>
>>>

[julia-users] Re: ERROR: LoadError: UndefVarError: mesh not defined. using MeshIO

[kleinsplash]

Nope.

On Monday, 23 November 2015 17:16:29 UTC+2, Simon Danisch wrote:
>
> This is solved in your other thread, is it?
>
> Am Montag, 23. November 2015 15:38:44 UTC+1 schrieb kleinsplash:
>>
>> My aim is to load an object file and access its faces, vertices and 
>> normals. 
>>
>> My current code:
>>
>> using FileIO
>> using GLVisualize
>> using MeshIO
>>
>> obj_file = "path_to_obj/file.obj"
>> mesh(obj_file)
>>
>> I am getting the error: 
>>
>> ERROR: LoadError: UndefVarError: mesh not defined
>>  in include at ./boot.jl:261
>>  in include_from_node1 at ./loading.jl:304
>>  in process_options at ./client.jl:280
>>  in _start at ./client.jl:378
>>
>> Am I calling the mesh fxn incorrectly? 
>>
>

[julia-users] Re: ERROR: LoadError: UndefVarError: mesh not defined. using MeshIO

[Simon Danisch]

This is solved in your other thread, is it?

Am Montag, 23. November 2015 15:38:44 UTC+1 schrieb kleinsplash:
>
> My aim is to load an object file and access its faces, vertices and 
> normals. 
>
> My current code:
>
> using FileIO
> using GLVisualize
> using MeshIO
>
> obj_file = "path_to_obj/file.obj"
> mesh(obj_file)
>
> I am getting the error: 
>
> ERROR: LoadError: UndefVarError: mesh not defined
>  in include at ./boot.jl:261
>  in include_from_node1 at ./loading.jl:304
>  in process_options at ./client.jl:280
>  in _start at ./client.jl:378
>
> Am I calling the mesh fxn incorrectly? 
>

[julia-users] Re: What is the best way to delete unwanted subgraph?

[Seth]

...and just to follow up, rem_vertex!() is now in LightGraphs master. This 
will be more efficient if the connected components you're trying to remove 
are small relative to the ones you want to preserve.


On Monday, November 23, 2015 at 5:28:04 AM UTC-8, Seth wrote:
>
> Keep in mind that induced subgraphs will not preserve vertex numbering, so 
> if you do something like
>
> G = G[4,5,6]
>
> your old vertices 4, 5, and 6 will be renumbered so that the new G has 
> vertices in the range 1 : 3.
>
>
>
> On Monday, November 23, 2015 at 5:23:55 AM UTC-8, Seth wrote:
>>
>> Aleksandr,
>>
>> The easiest way to do this is something like the following:
>>
>> cc = connected_components(G)
>> G = G[cc[1]]
>>
>>
>> This replaces G with the induced subgraph made up of the vertices in the 
>> first connected component. (You can create a new graph H if you want to 
>> keep G.)
>>
>> We are also implementing rem_vertex!() soon thanks to Carlo Lucibello, 
>> but it's not in master yet and it's probably not as performant as the above.
>>
>> Thanks,
>>
>> Seth.
>>
>>
>> On Monday, November 23, 2015 at 5:17:33 AM UTC-8, Aleksandr Mikheev wrote:
>>>
>>> Hi all,
>>>
>>> I'm currently using LightGraphs package in my student research work. And 
>>> I have some problems with it. Imagine we have a undirrected graph G, which 
>>> contains, for example, 10 vertices and some edges. I would like to know 
>>> which components of graph G are connected, so I call 
>>> "connected_components(G)". Suppose I have this situation:
>>>
>>> julia> connected_components(G)
>>> 6-element Array{Array{Int64,1},1}:
>>> [1,2,3]
>>> [4,7]
>>> [5]
>>> [6]
>>> [8,9]
>>> [10]
>>>
>>> And now I would like to delete all subgraphs, except [1,2,3]. In other 
>>> words, I would like to have subgraph [1,2,3] as a graph G further. Is there 
>>> any effective methods to do this in LightGraphs or in any other packages? I 
>>> mean, I can delete vertices one by one (I guess I saw this function 
>>> somewhere in GitHub), but that would be pretty slow, I imagine.
>>>
>>> Thank you in advance.
>>>
>>

Re: [julia-users] Best way to pass many arguments to functions

[Mauro]

This is for what I put https://github.com/mauro3/Parameters.jl
together.  Give it a spin!

- allows fields with default values
- constructors for constructing new instances from old ones with some
  changes
- packing and unpacking macros to save on typing

Example:

using Parameters

@with_kw immutable PhysicalPara{R}
rw::R = 1000.
ri::R = 900.
end

# create an instance with the defaults
pp = PhysicalPara{Float64}()
# make one afresh with some non-defaults
pp2 = PhysicalPara{Float32}(ri=87)
# make another one based on the previous one with some modifications
pp3 = PhysicalPara(pp2; rw=100.)

# unpacking and packing
function fn(var, pa::PhysicalPara)
@unpack pa: ri, rw # creates local variable ri=pa.ri and rw=pa.rw
out = var + rw
ri = 77.77
@pack pa: ri # pa.ri = ri
return out, pa
end


On Mon, 2015-11-23 at 14:32, Maxim Berman  wrote:
> Hello,
>
> In Matlab, people often use structures to pass around arguments between
> functions, for example problem instances. This allows some flexibility in
> the development, since I don't have to think of all variables that I need
> and their types, and new objects can be easily added to existing structs
>
> In Julia, I tend to use Dicts to replicate this behavior, to pass around
> options and helper structures to my functions. I don't think this is
> recommended since it doesn't allow functions to specialize on the type of
> objects contained in the Dict.
>
> Should I use custom types instead? If some fields can be of different
> types, should I use an abstract type for my options and then use different
> subtypes ? This seems a bit too complicated... On the other hand, writing
> down all arguments in functions without using Dicts or custom types can be
> tedious when they are a lot of variables...
>
> Thanks for your advice.

Re: [julia-users] Are traits or another form of multiple inheritance in base

[Milan Bouchet-Valat]

Le lundi 23 novembre 2015 à 08:06 -0800, Lampkld a écrit :
> Hello,
> 
> I have a  use case that specifically requires multiple inheritance
> (and concrete inheritance to a lesser degree).
> 
> Will traits or another mechanism for subtyping from multiple kinds
> definitely make it into base? 
I think the plan is indeed to integrate them, though the precise form
this will take is not completely defined yet. For details, see
https://github.com/JuliaLang/julia/pull/13222


Regards

Re: [julia-users] Julia Install in Heterogenous Linux Environment: Target architecture mismatch

[Yichao Yu]

On Mon, Nov 23, 2015 at 11:43 AM, Ian Watson  wrote:
> We have a Linux cluster that consists of different models of hardware.
>
> If I build Julia on one kind of hardware, say
>
> model name  : Intel(R) Xeon(R) CPU E5-2680 v3 @ 2.50GHz
>
> but then run that installation on another kind of hardware, say
>
> model name  : Intel(R) Xeon(R) CPU E5-2670 0 @ 2.60GHz
>
> I will usually get an error message
>
> ERROR: Target architecture mismatch. Please delete or regenerate
> sys.{so,dll,dylib}.
>
> As far as I know, the underlying O/S and software on both machines is the
> same, Red Hat Enterprise Linux Server release 6.6 (Santiago), but I cannot
> be 100% certain about that. I am compiling with gcc-5.2.0
>
> I tried the suggestion in DISTRIBUTING.md, but setting MARCH to either core2
> or x86-64 failed on the E5-2680 machine - openblas usually fails

Yes, you should build with an architecture that is compatible with all
the ones you want to run on.


>
> ../kernel/x86_64/dtrmm_kernel_4x8_haswell.c:79: Error: no such instruction:
> `vpermpd $0xb1,%ymm3,%ymm3'

binutils too old

https://github.com/julialang/julia#linux-build-troubleshooting

>
> A discussion thread a year ago seemed to indicate some problems as well...
>
> https://groups.google.com/forum/#!topic/julia-users/3H9Krno8aVU
>
> I can of course build an architecture specific Julia for each different kind
> of hardware we have, or some subset of them, and then invoke the right
> version depending on where the job is run, but is there an easier way?
>
>

Re: [julia-users] OffsetArrays (Fortran-style indexing)

[Ted Wetherbee]

OK, I filed an issue with the package OffsetArrays.jl 

I just started checking Julia out, so I'm not up to fixing this as yet or 
certain that I'm not missing a common assumption..working on it though.

Many thanks, Ted

On Monday, November 23, 2015 at 5:27:18 AM UTC-6, Tim Holy wrote:
>
> If no answers are forthcoming here, you should file an issue with the 
> OffsetArrays package. 
>
> Best, 
> --Tim 
>
>

[julia-users] Julia Install in Heterogenous Linux Environment: Target architecture mismatch

[Ian Watson]

We have a Linux cluster that consists of different models of hardware.

If I build Julia on one kind of hardware, say

model name  : Intel(R) Xeon(R) CPU E5-2680 v3 @ 2.50GHz

but then run that installation on another kind of hardware, say

model name  : Intel(R) Xeon(R) CPU E5-2670 0 @ 2.60GHz

I will usually get an error message

ERROR: Target architecture mismatch. Please delete or regenerate 
sys.{so,dll,dylib}.

As far as I know, the underlying O/S and software on both machines is the 
same, Red Hat Enterprise Linux Server release 6.6 (Santiago), but I cannot 
be 100% certain about that. I am compiling with gcc-5.2.0

I tried the suggestion in DISTRIBUTING.md, but setting MARCH to either 
core2 or x86-64 failed on the E5-2680 machine - openblas usually fails 

../kernel/x86_64/dtrmm_kernel_4x8_haswell.c:79: Error: no such instruction: 
`vpermpd $0xb1,%ymm3,%ymm3'

A discussion thread a year ago seemed to indicate some problems as well...

https://groups.google.com/forum/#!topic/julia-users/3H9Krno8aVU

I can of course build an architecture specific Julia for each different 
kind of hardware we have, or some subset of them, and then invoke the right 
version depending on where the job is run, but is there an easier way? 

[julia-users] Re: Pre-ANN: PlotlyJS.jl

[Eric Forgy]

A shot of all 4 browsers (including Juno - which is using the browser-plus 
package btw) :)

Re: [julia-users] Are traits or another form of multiple inheritance in base

[Lampkld]

Great thanks for the info and pointer!

On Monday, November 23, 2015 at 11:20:08 AM UTC-5, Tim Holy wrote:
>
> And to make it clear, you can do this now, though it's sometimes a little 
> awkward. As recommended reading, the source code for ColorTypes.jl is a 
> pretty 
> good example. See also base/multidimensional.jl. 
>
> --Tim 
>
> On Monday, November 23, 2015 05:15:47 PM Milan Bouchet-Valat wrote: 
> > Le lundi 23 novembre 2015 à 08:06 -0800, Lampkld a écrit : 
> > > Hello, 
> > > 
> > > I have a  use case that specifically requires multiple inheritance 
> > > (and concrete inheritance to a lesser degree). 
> > > 
> > > Will traits or another mechanism for subtyping from multiple kinds 
> > > definitely make it into base? 
> > 
> > I think the plan is indeed to integrate them, though the precise form 
> > this will take is not completely defined yet. For details, see 
> > https://github.com/JuliaLang/julia/pull/13222 
> > 
> > 
> > Regards 
>
>

[julia-users] Re: Pre-ANN: PlotlyJS.jl

[Eric Forgy]

Oopsies. And here is the link :D 

https://github.com/EricForgy/PlotlyJS.jl

On Tuesday, November 24, 2015 at 12:47:38 AM UTC+8, Eric Forgy wrote:
>
> Hi everyone,
>
>
> In this post 
>  
> from last Wednesday, Hans-Peter pointed out that plotly.js was made open 
> source (  https://plot.ly/javascript/open-source-announcement/ ).
>
>
> Anyway, I tried my hands at writing a wrapper for the JS API. There 
> already exists Plotly.jl, but that is an API to interact with the company's 
> server requiring login info, etc. With the opening of the JS API, the 
> interaction between Julia and Plotly can be much simpler, I think.
>
>
> In the other post, I mused that it should be straightforward to hook up 
> Plotly.js with Juno, so here is a snapshot:
>
>
>
> 
>
>
> To make it interactive, I used WebSockets.jl. One neat artifact of that is 
> you can stream the charts to multiple connections. 
>
>
> Here is a silly video demo of me controlling 4 browsers (only 3 are 
> visible) including an iPhone from Juno: 
> https://www.youtube.com/watch?v=mWDyyfVNqP0
>
>
> The same concept should work with Vega.jl in Juno.
>
>
> I call this a "Pre-announcement", because it is not really ready for the 
> wild yet, but it is far enough that if some friendlies would like to have a 
> look and help me get it in shape, that would be more than welcome.
>
>
> Currently, I am struggling a bit to get the paths correct. If I "git 
> clone" it and run it from the REPL, then I can make it work, but if I 
> "Pkg.clone" it, the path to the html containing the scripts is wrong. 
>
>
> Here are the lines in question:
>
>
> # res = Response(open(readall,Pkg.dir("Plotly","src","web","plotly.html")))
> res = Response(open(readall,"web/plotly.html"))
>
> When run from the REPL (after CD'ing to the directory), the code will find 
> plotly.html. But if I Pkg.clone, it can't find it. It seems to find it when 
> I use the commented Pkg.dir, but then that doesn't work when I'm trying to 
> test before committing to Github and Pkg.checkout etc. Any ideas?
>
> Anyway, this has been kind of fun and if others can help improve it, that 
> would be a great learning experience for me.
>
> Best regards,
> Eric
>

[julia-users] Re: `(,a) = (1,2)` returns an error

[Sisyphuss]

OK, so if I have a function which returns a tuple (a,b,c,d), 
but I only want the 2nd and 4th value, the most concise way is

(x,y) = f()[[2;4]]

Re: [julia-users] `(,a) = (1,2)` returns an error

[Sisyphuss]

On Monday, November 23, 2015 at 6:44:58 PM UTC+1, Yichao Yu wrote:
>
> > I have a function that returns a tuple. 
> > But I only want the second value of this tuple. 
> > So I tried `(,a) =f()`. But it does not work. 
> > 
> > I'd like to is there any syntax which works? 
> > Note `(a,) = (1,2)` does work. 
>
> I don't think it's too useful you can just do `a = f()[2]` or `_, a = 
> f()` 
>
In the second example, it will overwrite `_`. 

[julia-users] `(,a) = (1,2)` returns an error

[Sisyphuss]

I have a function that returns a tuple. 
But I only want the second value of this tuple.
So I tried `(,a) =f()`. But it does not work.

I'd like to is there any syntax which works?
Note `(a,) = (1,2)` does work.

Re: [julia-users] `(,a) = (1,2)` returns an error

[Yichao Yu]

> I have a function that returns a tuple.
> But I only want the second value of this tuple.
> So I tried `(,a) =f()`. But it does not work.
>
> I'd like to is there any syntax which works?
> Note `(a,) = (1,2)` does work.

I don't think it's too useful you can just do `a = f()[2]` or `_, a = f()`

[julia-users] Re: `(,a) = (1,2)` returns an error

[Ilya Orson]

You can get the arguments of a tuple the same way you get the arguments of 
an array.

For example:

f(x) = (x,x+2) 

results = f(1)

results[1]   returns  1   and   results[2]  returns  3

http://docs.julialang.org/en/latest/stdlib/collections/#indexable-collections

Good luck

El lunes, 23 de noviembre de 2015, 11:26:05 (UTC-6), Sisyphuss escribió:
>
>
>
> I have a function that returns a tuple. 
> But I only want the second value of this tuple.
> So I tried `(,a) =f()`. But it does not work.
>
> I'd like to is there any syntax which works?
> Note `(a,) = (1,2)` does work.
>

Re: [julia-users] Using Gadfly with sublime-ijulia or vim

[kleinsplash]

I wasn't using interactive mode with IJulia. Putting 
plt[:show]()
at the end did the trick. 

On Friday, 20 November 2015 15:35:13 UTC+2, kleinsplash wrote:
>
> Thanks.. I still dont get a pop up though - it just says Plot(...) 
> [Finished in 7.4s]. Do you think I installed my ijulia-sublime incorrectly? 
>
> On Thursday, 19 November 2015 16:58:20 UTC+2, Tom Breloff wrote:
>>
>> Wrap your spy call: "display(spy(...))"
>>
>> On Thursday, November 19, 2015, Ashley Kleinhans  
>> wrote:
>>
>>> I was wondering if someone could help me with a very basic question (as 
>>> a newbie on so many levels). I finally managed to get spy() working under 
>>> Gadfly, thanks to the good people at stack exchange. But I have to type 
>>> each line into terminal for it to pop up with a plot and even then I had to 
>>> be using Escher. 
>>>
>>> I think I am misunderstanding how to plot using an editor, I like vim 
>>> and sublime, everything builds - but nothing shows. Am I looking at the 
>>> wrong editors? this is an example output:
>>>
>>> using Gadfly
>>> M = sprand(300, 300, 0.1)  # generate a sparse matrix with density 0.1 
>>> of non-zeros
>>> M = full(M)
>>> spy(M)
>>>
>>> How do I make fancy plots using an editor? 
>>>
>>

[julia-users] Ann: StatefulIterators (streams over iterables)

[andrew cooke]

I mentioned this here earlier, but since then okvs improved things hugely 
and it's now only a factor of 2 slower than "normal" iterators, which 
likely makes it useful for anything except critical inner loops.

The basic idea is that you can turn any iterable into something that is 
"consumed" operation by operation (ie a stream).

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

Examples:

julia> using StatefulIterators

julia> s = StatefulIterator([1,2,3,4,5])
StatefulIterators.StatefulIterator{Array{Int64,1},Int64}([1,2,3,4,5],1)

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

julia> eltype(s)
Int64

julia> read(s)
3

julia> readbytes(s)
16-element Array{UInt8,1}:
 0x04
 0x00
 0x00
 0x00
 0x00
 0x00
 0x00
 0x00
 0x05
 0x00
 0x00
 0x00
 0x00
 0x00
 0x00
 0x00

Re: [julia-users] Are traits or another form of multiple inheritance in base

[Tim Holy]

And to make it clear, you can do this now, though it's sometimes a little 
awkward. As recommended reading, the source code for ColorTypes.jl is a pretty 
good example. See also base/multidimensional.jl.

--Tim

On Monday, November 23, 2015 05:15:47 PM Milan Bouchet-Valat wrote:
> Le lundi 23 novembre 2015 à 08:06 -0800, Lampkld a écrit :
> > Hello,
> > 
> > I have a  use case that specifically requires multiple inheritance
> > (and concrete inheritance to a lesser degree).
> > 
> > Will traits or another mechanism for subtyping from multiple kinds
> > definitely make it into base?
> 
> I think the plan is indeed to integrate them, though the precise form
> this will take is not completely defined yet. For details, see
> https://github.com/JuliaLang/julia/pull/13222
> 
> 
> Regards

[julia-users] Pre-ANN: PlotlyJS.jl

[Eric Forgy]

Hi everyone,


In this post 
 from 
last Wednesday, Hans-Peter pointed out that plotly.js was made open source 
(  https://plot.ly/javascript/open-source-announcement/ ).


Anyway, I tried my hands at writing a wrapper for the JS API. There already 
exists Plotly.jl, but that is an API to interact with the company's server 
requiring login info, etc. With the opening of the JS API, the interaction 
between Julia and Plotly can be much simpler, I think.


In the other post, I mused that it should be straightforward to hook up 
Plotly.js with Juno, so here is a snapshot:





To make it interactive, I used WebSockets.jl. One neat artifact of that is 
you can stream the charts to multiple connections. 


Here is a silly video demo of me controlling 4 browsers (only 3 are 
visible) including an iPhone from 
Juno: https://www.youtube.com/watch?v=mWDyyfVNqP0


The same concept should work with Vega.jl in Juno.


I call this a "Pre-announcement", because it is not really ready for the 
wild yet, but it is far enough that if some friendlies would like to have a 
look and help me get it in shape, that would be more than welcome.


Currently, I am struggling a bit to get the paths correct. If I "git clone" 
it and run it from the REPL, then I can make it work, but if I "Pkg.clone" 
it, the path to the html containing the scripts is wrong. 


Here are the lines in question:


# res = Response(open(readall,Pkg.dir("Plotly","src","web","plotly.html")))
res = Response(open(readall,"web/plotly.html"))

When run from the REPL (after CD'ing to the directory), the code will find 
plotly.html. But if I Pkg.clone, it can't find it. It seems to find it when 
I use the commented Pkg.dir, but then that doesn't work when I'm trying to 
test before committing to Github and Pkg.checkout etc. Any ideas?

Anyway, this has been kind of fun and if others can help improve it, that 
would be a great learning experience for me.

Best regards,
Eric

[julia-users] Re: Simple Quesiton about svd() function

[Sisyphuss]

If `x` is an eigenvector, then `-x` is also an eigenvector (and with the 
same norm).


On Monday, November 23, 2015 at 3:58:31 AM UTC+1, Michael Bullman wrote:
>
> Hi All, 
>
> I have a pretty easy question about how/why the svd() behaves how it does. 
>
> Why are my U and V matrices always a factor of -1 from the textbook 
> examples? I'm just getting my feet wet with all this, so I wanted to check 
> what the function returns vs what the textbook says the answers would be, 
> and it looks like it's always off by negative one. 
>
> julia> A = [1 2 ; 2 2; 2 1]
> 3x2 Array{Int64,2}:
>  1  2
>  2  2
>  2  1
>
> julia> U, s, V = svd(A, thin=false)
> (
> 3x3 Array{Float64,2}:
>  -0.514496   0.707107   0.485071
>  -0.685994   0.0   -0.727607
>  -0.514496  -0.707107   0.485071,
>
> [4.123105625617661,0.],
> 2x2 Array{Float64,2}:
>  -0.707107  -0.707107
>  -0.707107   0.707107)
>
>
> text book shows the 1,1 entry of U to be 
> julia> 3/sqrt(34)
> 0.5144957554275265
>
> without a negtive sign. really just all the negative signs are reversed. 
> source: http://www.math.iit.edu/~fass/477577_Chapter_2.pdf
>
> 2nd example:
> julia> A = [3 2 -2 ; 2 3 -2]
> 2x3 Array{Int64,2}:
>  3  2  -2
>  2  3  -2
>
> julia> U, s, V = svd(A, thin=false)
> (
> 2x2 Array{Float64,2}:
>  -0.707107  -0.707107
>  -0.707107   0.707107,
>
> [5.744562646538029,1.0],
> 3x3 Array{Float64,2}:
>  -0.615457  -0.707107 0.348155
>  -0.615457   0.707107 0.348155
>   0.492366   5.55112e-17  0.870388)
>
> which is U and V are negative
> http://www.d.umn.edu/~mhampton/m4326svd_example.pdf
>
> So did I just get back luck with example problems? I feel like it's 
> probably just a difference in convention or something, but figured I would 
> ask for a definitive answer. Thank you for any help
>
>

Re: [julia-users] Re: Define an objective function type

[Sisyphuss]

Another inconvenience of your solution is that: if you have N objective 
functions, you will have to define N types and cannot use loop. However, in 
my solution, I only need to construct an array of objective functions (as 
objects).


On Sunday, November 22, 2015 at 2:20:30 PM UTC+1, Sisyphuss wrote:
>
> I was waiting for someone others to comment on it. But since no one did 
> it, I'll try it.
>
> Your solution is just fine for personal use. But imagine that you are 
> making an application working on ObjectiveFunction. For your clients to 
> profit from your application, they should inherit a concrete type from your 
> abstract ObjectiveFunction. However, ObjectiveFunction gives no information 
> about how to construct a concrete subtype. All your clients know is that 
> they can use a "fancy call". All in all, for your clients, they have to 
> have knowledge of inheritance (a beginner won't be able to do it) and 
> perfect information of interface (should provide a detailed manual).
>
> Instead, my solution is more direct and flexible, Everyone looking into 
> the definition knows that all it needs is two functions. I can further use 
> constructor to regulate the initialization. Moreover, my object can work 
> with your type: `myObjectiveFunction.f = yourObjectiveFunction` and 
> `myObjectiveFunction.g = @D yourObjectiveFunction`.
>
>
>

Re: [julia-users] Pre-ANN: PlotlyJS.jl

[Tom Breloff]

Eric: I just looked through your code.  It doesn't seem like there's very
much plotly-specific code in there.  I wonder if you could generalize a
little so that Bokeh or Vega could use your websocket approach as well.
That seems like it has uses beyond desktop visualizations.  I also think it
would be great to separate plot-creation from plot-updating so that you
could use websockets to update existing plots.  Let me know if you'd like
to integrate your idea with Plots.jl.

ps - I love your music choice for your video... very dramatic

On Mon, Nov 23, 2015 at 2:34 PM, Tom Breloff  wrote:

> Much of Plotly.jl is for interacting with the cloud API (login,
> credentials, etc). The remainder cannot be called directly so, for my
> purpose, it made more sense to just build the json directly. Others will
> likely still find this package to be useful.
>
>
> On Monday, November 23, 2015, Sisyphuss  wrote:
>
>> So the following package is no longer useful?
>>
>> https://github.com/plotly/Plotly.jl
>>
>

[julia-users] Re: pmap - intermingled output from workers on v0.4

['Greg Plowman' via julia-users]

I should add this problem is only when using *remote* workers. (In my case 
ssh on Windows).

The following code produces intermingled output with multiple workers on 
multiple machines (Julia v0.4)
Output is orderly when using Julia v0.3, or with v0.4 when workers are on 
local machine only.


function Launch()
@everywhere function sim(trial, numIterations)
println("Starting trial $trial")
s = 0.0
for i = 1:numIterations
s += sum(sqrt(rand(10^6)))
end
println("Finished trial $trial")
s
end

numTrials = 100
numIterations = 100
println("Running random simulation: $numTrials trials of $numIterations 
iterations ... ")
results = pmap(sim, 1:numTrials, fill(numIterations, numTrials))
end 

Re: [julia-users] Julia Install in Heterogenous Linux Environment: Target architecture mismatch

[Páll Haraldsson]

On Monday, November 23, 2015 at 5:08:16 PM UTC, Yichao Yu wrote:
>
> On Mon, Nov 23, 2015 at 11:43 AM, Ian Watson  > wrote: 
> > As far as I know, the underlying O/S and software on both machines is 
> the 
> > same, Red Hat Enterprise Linux Server release 6.6 (Santiago), but I 
> cannot 
> > be 100% certain about that. I am compiling with gcc-5.2.0 
> > 
> > I tried the suggestion in DISTRIBUTING.md, but setting MARCH to either 
> core2 
> > or x86-64 failed on the E5-2680 machine - openblas usually fails 
>
> Yes, you should build with an architecture that is compatible with all 
> the ones you want to run on.
>

I do not see a reason that the architecture "should" be the same (except as 
he says "but that can wait for another day", of course start with the low 
hanging fruit). It's not clear to me from the link, if the way to install 
on heterogeneous is not just supported (because it is not worth it much?), 
any more, but easily could (seems it could, as it was supported, or was it 
broken and that is why not longer supported?).

Is it just not worth the effort? Not a large payoff? No need to read 
further for my speculations..


I would think there are a lot of such clusters (maybe a large fraction or 
majority?). If some parts of clusters are older/slower is that a big 
drawback (except for the hassle to get different ISAs to work)? [You might 
need some load balancing? Wouldn't code at least work, with possibly slower 
nodes dragging down performance, at least never giving wrong results/more 
race conditions or something?]

I expect the bitness needs to be the same.. (not really much of a problem), 
and the endianness (or not..?), in theory x86 and ARM etc. could be 
combined (not a good idea..?), and even to OSes different (maybe again not 
a good idea and no good reason..(?)).

I just ask out of curiosity, it seems Julia would be ideal to do stuff like 
this, and say for x86 and ARM, not really possible (or at least a hassle) 
for the "competition" (e.g. C++). An exception, might be Java/JVM and CLR 
etc. but at least JVM (both?) do not have multi-dimensional arrays (I'm not 
sure if JVMs are much of a competition, but IBM did some heroic 
optimizations to get multidimensional arrays to work fast/er with [their 
(only I think)] JVM and compiler - I'm not sure if this is used much..).


The alternative for established languages is differently compiled 
executable on each node - might not be out of the question in a source code 
environment (already done that way?) - and/or executable/libraries 
dynamically choose different machine code as in e.g.: "openblas defaults to 
detecting the runtime system and picking the best code to run for that 
computer." [See above, why did openblas then fail? I guess because of 
"binutils too old", and shouldn't have otherwise] I wander how commonly 
code is compiled that way, just for x86-variants (it has a runtime cost.. 
and I assume not done as fat binaries for x86/ARM and wouldn't scale to 
more..). 

-- 
Palli.