[julia-users] [ANN] GLVisualize

[Simon Danisch]

I finally tagged a new version of GLVisualize with a lot of new goodies and 
overall improved stability.
For more information please see my blog post:

GLVisualize - a modern graphics platform for julia 


[Lets deprecate Julia-Users, so please answer on the discourse thread 
]

Best,
Simon

[julia-users] Re: How to tell if Val{T} is using a fast route

[Simon Danisch]

... And really should be, if you want to use code typed:

# module scope

ff(x::Type{Val{1}}) = 1

const y = 1

function test()
# local scope
x = 1
a = ff(Val{x})
c = ff(Val{y})
d = ff(Val{1})
end

@code_warntype test()


Best,
Simon


Am Mittwoch, 16. November 2016 16:06:31 UTC+1 schrieb FANG Colin:
>
> In performance tips, it says
>
> Essentially, Val{T}works only when T is either hard-coded (Val{3}) or 
> already specified in the type-domain.
>
> Suppose I have
>
> ff(::Type{Val{1}}) = 1
>
> I guess the following is on a slower route.
>
> x = 1
> a = ff(::Type{Val{x}})
>
> And maybe this one can be determined in compile time
>
> const y = 1
> a = ff(::Type{Val{y}})
>
> How can I tell if it is fast or slow? @code_warntype doesn't tell the 
> difference here?
>

[julia-users] Re: ANN: Highlights.jl

[Simon Danisch]

That's a great library, very pleasant to use! Thanks!

Am Mittwoch, 2. November 2016 21:14:06 UTC+1 schrieb Michael Hatherly:
>
> I’m pleased to announce the initial 0.1 release of Highlights.jl 
>  — a Julia package for 
> highlighting source code similar to the well-known Python package called 
> Pygments .
>
> The documentation for the package can be found here 
> . Currently there are 
> only a handful of supported languages and colour schemes, so if your 
> favourite language (aside from Julia) is missing then please feel free to add 
> it to the requests list 
>  or open a PR.
>
> Any bugs or feature requests can be made over on the issue tracker 
> .
>
> — Mike
>

[julia-users] Re: Julia types newbie question

[Simon Danisch]

There is a speed difference, which you can see beautifully like this:


function _sum{T}(::Type{T}, A)
r = zero(T)
@inbounds for i in eachindex(A)
r += T(A[i])
end
r
end

@code_llvm _sum(Int, rand(Int64, 10^6)) -> uses <4,Int64> vectors
@code_llvm _sum(Int, rand(Int32, 10^6)) -> uses <8,Int32> vectors
# this suggests that we can get a speed up, but if we get it still depends 
on the CPU we use.
using BenchmarkTools # so lets benchmark this
x = rand(Int32(1):Int32(10), 10^6)
@benchmark _sum($Int64, $x) # ~ 80μs
@benchmark _sum($Int32, $x) # ~ 50μs <- its faster!


Am Montag, 17. Oktober 2016 15:19:51 UTC+2 schrieb Ángel de Vicente:
>
> Hi, 
>
> probably a very basic question, but I'm just starting to play around 
> with Julia types. 
>
> I was hoping to improve the performance of a little program I wrote, so 
> I decided to try Int32 integers instead of the default Int64, but if I 
> try to use sum, it seems that it is expecting Int64 and the result is 
> Int64, defeating the purpose of working with Int32 and actually making 
> the code much slower than the naive version. 
>
> , 
> | julia> typeof(sum([i for i in Int32(1):Int32(100)])) 
> 
>| 
> | Int64 
> ` 
>
> Do I have to write down my own Int32::sum function? I assume I'm missing 
> something quite obvious? 
>
> Thanks, 
> -- 
> Ángel de Vicente 
> http://www.iac.es/galeria/angelv/   
>

[julia-users] Re: Julia types newbie question

[Simon Danisch]

I'm guessing that is done to prevent overflow.
So you need to use your own implementation.
Here are the promote rules defining this behavior: 
https://github.com/JuliaLang/julia/blob/master/base/reduce.jl#L32
So in theory you could also implement your own Int type, that has a 
different promote behavior. Probably not worth it, though ;)


Am Montag, 17. Oktober 2016 15:19:51 UTC+2 schrieb Ángel de Vicente:
>
> Hi, 
>
> probably a very basic question, but I'm just starting to play around 
> with Julia types. 
>
> I was hoping to improve the performance of a little program I wrote, so 
> I decided to try Int32 integers instead of the default Int64, but if I 
> try to use sum, it seems that it is expecting Int64 and the result is 
> Int64, defeating the purpose of working with Int32 and actually making 
> the code much slower than the naive version. 
>
> , 
> | julia> typeof(sum([i for i in Int32(1):Int32(100)])) 
> 
>| 
> | Int64 
> ` 
>
> Do I have to write down my own Int32::sum function? I assume I'm missing 
> something quite obvious? 
>
> Thanks, 
> -- 
> Ángel de Vicente 
> http://www.iac.es/galeria/angelv/   
>

[julia-users] Re: StaticArrays vs FixedSizeArrays

[Simon Danisch]

You might enjoy: GeometryTypes.jl 

Especially the Face type should be convenient: 
https://github.com/JuliaGeometry/GeometryTypes.jl/blob/master/src/faces.jl

Its currently based on FixedSizeArrays, but I want to port it to 
StaticArrays whenever it's sensible (and I have time :P ).
So in the ideal case, you won't notice any change in the low-level 
implementation.
I've made sure that most operations needed in Graphics are fast and 
supported in FixedSizeArrays. This doesn't seem to be fully the case for 
StaticArrays yet.
On the other hand, StaticArrays is more fit for general fixed array code.

I'm tracking porting GeometryTypes to StaticArrays in this issue:
https://github.com/JuliaArrays/StaticArrays.jl/issues/45

Best,
Simon


Am Freitag, 7. Oktober 2016 08:10:56 UTC+2 schrieb Petr Hlavenka:
>
> Hi,
> With Julia 0.5 I'm little bit confused what is the best approach for high 
> speed array access. I'm writing a simulation where particles move in the 
> field interpolated from an irregular mesh of tetrahedrons in 3D.
> So i basically have a *points* array of MyPoint (= 3xFloat64, stands for 
> x,y,z) and *elements *array of MyElement(= 4xUInt32,  stands for indexes 
> to points forming a tetrahedron) and some lookup arrays.
> I often access the points by direct indexing  - defining own 
> getindex(::MyPoint, ::Integer) for the custom types, such as this example: 
>
> points[elements[tetrahedron_id][vertex_id]][axis_ix] 
>
> or in loops where i prefer treating the arrays as types such as 
>
> for el in elements
>   point1 = el[1]
>   point2 = el[2]
>   r = (point1[1]+point2[1])/2 + (point1[2]+point2[2])/2
> end
>
>
> or even calling specialized functions on MyElement type
>
> for el in elements
>   myfunc(el)
> end
>
> I'm considering StaticArrays.jl and FixedSizeArrays to use for the 
> definition of MyPoint and MyElement, but I'm little bit confused what is 
> the actual difference between the two implementation. Could please someone 
> explain to me, what is the difference between this two packages? Is one of 
> them superseding the other one on 0.5+? What is the difference in memory 
> layout and performance consequences?
>
> Thank you very much.
> Cheers 
> Petr
>
>  
>
>

[julia-users] Re: ANN: CUDAdrv.jl, and CUDA.jl deprecation

[Simon Danisch]

Great work! :)

Well, I think GPUArrays should be the right place! If it is the right place 
depends on how much time and cooperation I get ;)
The plan is to integrate all these 3rd party libraries. If you could help 
me with that, it would already be a great first step to establish that 
library :)

Am Freitag, 30. September 2016 03:31:29 UTC+2 schrieb Tim Besard:
>
> Hi all,
>
> CUDAdrv.jl  is Julia wrapper for 
> the CUDA driver API -- not to be confused with its counterpart CUDArt.jl 
>  which wraps the slightly 
> higher-level CUDA runtime API.
>
> The package doesn't feature many high-level or easy-to-use wrappers, but 
> focuses on providing the necessary functionality for other packages to 
> build upon. For example, CUDArt uses CUDAdrv for launching kernels, while 
> CUDAnative (the in-development native programming interface) completely 
> relies on CUDAdrv for all GPU interactions.
>
> It features a ccall-like cudacall interface for launching kernels and 
> passing values:
> using CUDAdrv
> using Base.Test
>
> dev = CuDevice(0)
> ctx = CuContext(dev)
>
> md = CuModuleFile(joinpath(dirname(@__FILE__), "vadd.ptx"))
> vadd = CuFunction(md, "kernel_vadd")
>
> dims = (3,4)
> a = round(rand(Float32, dims) * 100)
> b = round(rand(Float32, dims) * 100)
>
> d_a = CuArray(a)
> d_b = CuArray(b)
> d_c = CuArray(Float32, dims)
>
> len = prod(dims)
> cudacall(vadd, len, 1, (DevicePtr{Cfloat},DevicePtr{Cfloat},DevicePtr{
> Cfloat}), d_a, d_b, d_c)
> c = Array(d_c)
> @test a+b ≈ c
>
> destroy(ctx)
>
> For documentation, refer to the NVIDIA docs 
> . Even though they don't 
> fully match what CUDAdrv.jl implements, the package is well tested, and 
> redocumenting the entire thing is too much work.
>
> Current master of this package only supports 0.5, but there's a tagged 
> version supporting 0.4 (as CUDArt.jl does so as well). It has been tested 
> on CUDA 5.0 up to 8.0, but there might always be issues with certain 
> versions (as the wrappers aren't auto-generated, and probably will never be 
> due to how NVIDIA has implemented cuda.h)
>
> Anybody thinking there's a lot of overlap between CUDArt and CUDAdrv is 
> completely right, but it mimics the overlap between CUDA's runtime and 
> driver APIs as in some cases we do specifically need one or the other (eg., 
> CUDAnative wouldn't work with only the runtime API). There's also some 
> legacy at the Julia side: CUDAdrv.jl is based on CUDA.jl, while CUDArt.jl 
> has been an independent effort.
>
>
> In other news, we have recently *deprecated the old CUDA.jl package*. All 
> users should now use either CUDArt.jl or CUDAdrv.jl, depending on what 
> suits them best. Neither is a drop-in replacement, but the changes should 
> be minor. At the very least, users will have to change the kernel launch 
> syntax, which should use cudacall as shown above. In the future, we might 
> re-use the CUDA.jl package name for the native programming interface 
> currently at CUDAnative.jl
>
>
> Best,
> Tim
>

Re: [julia-users] Re: [ANN] UnicodeFun

[Simon Danisch]

Sounds fun! Since I won't use this, this would need to wait until the next
procrastination attack.
But feel free to submit a PR. Should be relatively straight forward :)

2016-09-28 17:30 GMT+02:00 Chris Rackauckas <rackd...@gmail.com>:

> what about the other direction? It would be a sick to write symbolic code
> for SymEngine or SymPy in that unicode form, and have it convert to the
> appropriate code.
>
> On Wednesday, September 28, 2016 at 6:43:48 AM UTC-7, Simon Danisch wrote:
>>
>> That's the short form which works with sub/superscript and will create
>> something like:
>> to_fraction("a-123", 392) == "ᵃ⁻¹²³⁄₃₉₂"
>>
>> For the newline version try:
>> to_fraction_nl("α² ⋅ α²⁺³ ≡ α⁷", " ℝ: 퐴퐯 = λᵢ퐯")
>>
>> I really need to rework the names and documentation ;)
>>
>> 2016-09-28 15:22 GMT+02:00 henri@gmail.com <henri@gmail.com>:
>>
>>> I probably misused it but that what I get (before I add it and checkout)
>>>
>>> Sorry
>>>
>>> Henri
>>>
>>>
>>> julia> to_fraction("α² ⋅ α²⁺³ ≡ α⁷", " ℝ: 퐴퐯 = λᵢ퐯")
>>> ERROR: Char ² doesn't have a unicode superscript
>>>  in to_superscript(::Char) at /home/pi/.julia/v0.5/UnicodeFu
>>> n/src/sub_super_scripts.jl:156
>>>  in to_superscript(::Base.AbstractIOBuffer{Array{UInt8,1}}, ::String)
>>> at /home/pi/.julia/v0.5/UnicodeFun/src/sub_super_scripts.jl:13
>>>  in to_fraction at 
>>> /home/pi/.julia/v0.5/UnicodeFun/src/sub_super_scripts.jl:178
>>> [inlined]
>>>  in 
>>> (::UnicodeFun.##5#6{String,String})(::Base.AbstractIOBuffer{Array{UInt8,1}})
>>> at /home/pi/.julia/v0.5/UnicodeFun/src/sub_super_scripts.jl:173
>>>  in #sprint#304(::Void, ::Function, ::Int64, ::Function) at
>>> ./strings/io.jl:37
>>>  in to_fraction(::String, ::String) at /home/pi/.julia/v0.5/UnicodeFu
>>> n/src/sub_super_scripts.jl:172
>>>
>>> julia>
>>>
>>>
>>> Le 28/09/2016 à 13:40, Simon Danisch a écrit :
>>>
>>> I added the to_fraction function:
>>>
>>> to_fraction("α² ⋅ α²⁺³ ≡ α⁷", " ℝ: 퐴퐯 = λᵢ퐯") -->
>>>
>>> α̲²̲ ̲⋅̲ ̲α̲²̲⁺̲³̲ ̲≡̲ ̲α̲⁷̲
>>>  ℝ: 퐴퐯 = λᵢ퐯
>>>
>>> https://github.com/SimonDanisch/UnicodeFun.jl/pull/3
>>>
>>> But I won't have time to add this to the *to*_*latex* function, since
>>> it's a bit more involved with the line break.
>>>
>>> Am Mittwoch, 28. September 2016 12:05:36 UTC+2 schrieb Simon Danisch:
>>>>
>>>> Good news everyone!
>>>> I've written a small library that offers various transformations of
>>>> text to special Unicode characters.
>>>> The most prominent one is the latex-string to latex-unicode:
>>>>
>>>> "\\itA \\in \\bbR^{nxn}, \\bfv \\in \\bbR^n, \\lambda_i \\in \\bbR: 
>>>> \\itA\\bfv = \\lambda_i\\bfv"==> "퐴 ∈ ℝⁿˣⁿ, 퐯 ∈ ℝⁿ, λᵢ ∈ ℝ: 퐴퐯 = λᵢ퐯"
>>>>
>>>>
>>>> It doesn't support the whole range of latex, but I hope it will be
>>>> enough for simple formulas.
>>>> I will obviously use this library for latex label support in
>>>> GLVisualize <https://github.com/JuliaGL/GLVisualize.jl>, but I hope
>>>> that this library can also be usable in other contexts! (REPL latex
>>>> renderer?)
>>>> Enjoy with a simple *Pkg.add("UnicodeFun") *(since its freshly
>>>> registered, a Pkg.update() might be needed)
>>>>
>>>> Please feel free to report latex strings that are not working, or help
>>>> adding new transformations! :)
>>>>
>>>> Best,
>>>> Simon
>>>>
>>>
>>>
>>

Re: [julia-users] Re: [ANN] UnicodeFun

[Simon Danisch]

That's the short form which works with sub/superscript and will create
something like:
to_fraction("a-123", 392) == "ᵃ⁻¹²³⁄₃₉₂"

For the newline version try:
to_fraction_nl("α² ⋅ α²⁺³ ≡ α⁷", " ℝ: 퐴퐯 = λᵢ퐯")

I really need to rework the names and documentation ;)

2016-09-28 15:22 GMT+02:00 henri.gir...@gmail.com <henri.gir...@gmail.com>:

> I probably misused it but that what I get (before I add it and checkout)
>
> Sorry
>
> Henri
>
>
> julia> to_fraction("α² ⋅ α²⁺³ ≡ α⁷", " ℝ: 퐴퐯 = λᵢ퐯")
> ERROR: Char ² doesn't have a unicode superscript
>  in to_superscript(::Char) at /home/pi/.julia/v0.5/
> UnicodeFun/src/sub_super_scripts.jl:156
>  in to_superscript(::Base.AbstractIOBuffer{Array{UInt8,1}}, ::String) at
> /home/pi/.julia/v0.5/UnicodeFun/src/sub_super_scripts.jl:13
>  in to_fraction at 
> /home/pi/.julia/v0.5/UnicodeFun/src/sub_super_scripts.jl:178
> [inlined]
>  in (::UnicodeFun.##5#6{String,String})(::Base.
> AbstractIOBuffer{Array{UInt8,1}}) at /home/pi/.julia/v0.5/
> UnicodeFun/src/sub_super_scripts.jl:173
>  in #sprint#304(::Void, ::Function, ::Int64, ::Function) at
> ./strings/io.jl:37
>  in to_fraction(::String, ::String) at /home/pi/.julia/v0.5/
> UnicodeFun/src/sub_super_scripts.jl:172
>
> julia>
>
>
> Le 28/09/2016 à 13:40, Simon Danisch a écrit :
>
> I added the to_fraction function:
>
> to_fraction("α² ⋅ α²⁺³ ≡ α⁷", " ℝ: 퐴퐯 = λᵢ퐯") -->
>
> α̲²̲ ̲⋅̲ ̲α̲²̲⁺̲³̲ ̲≡̲ ̲α̲⁷̲
>  ℝ: 퐴퐯 = λᵢ퐯
>
> https://github.com/SimonDanisch/UnicodeFun.jl/pull/3
>
> But I won't have time to add this to the *to*_*latex* function, since
> it's a bit more involved with the line break.
>
> Am Mittwoch, 28. September 2016 12:05:36 UTC+2 schrieb Simon Danisch:
>>
>> Good news everyone!
>> I've written a small library that offers various transformations of text
>> to special Unicode characters.
>> The most prominent one is the latex-string to latex-unicode:
>>
>> "\\itA \\in \\bbR^{nxn}, \\bfv \\in \\bbR^n, \\lambda_i \\in \\bbR: 
>> \\itA\\bfv = \\lambda_i\\bfv"==> "퐴 ∈ ℝⁿˣⁿ, 퐯 ∈ ℝⁿ, λᵢ ∈ ℝ: 퐴퐯 = λᵢ퐯"
>>
>>
>> It doesn't support the whole range of latex, but I hope it will be enough
>> for simple formulas.
>> I will obviously use this library for latex label support in GLVisualize
>> <https://github.com/JuliaGL/GLVisualize.jl>, but I hope that this
>> library can also be usable in other contexts! (REPL latex renderer?)
>> Enjoy with a simple *Pkg.add("UnicodeFun") *(since its freshly
>> registered, a Pkg.update() might be needed)
>>
>> Please feel free to report latex strings that are not working, or help
>> adding new transformations! :)
>>
>> Best,
>> Simon
>>
>
>

[julia-users] Re: [ANN] UnicodeFun

[Simon Danisch]

I added the to_fraction function:

to_fraction("α² ⋅ α²⁺³ ≡ α⁷", " ℝ: 퐴퐯 = λᵢ퐯") -->

α̲²̲ ̲⋅̲ ̲α̲²̲⁺̲³̲ ̲≡̲ ̲α̲⁷̲
 ℝ: 퐴퐯 = λᵢ퐯

https://github.com/SimonDanisch/UnicodeFun.jl/pull/3

But I won't have time to add this to the *to*_*latex* function, since it's 
a bit more involved with the line break.

Am Mittwoch, 28. September 2016 12:05:36 UTC+2 schrieb Simon Danisch:
>
> Good news everyone!
> I've written a small library that offers various transformations of text 
> to special Unicode characters.
> The most prominent one is the latex-string to latex-unicode:
>
> "\\itA \\in \\bbR^{nxn}, \\bfv \\in \\bbR^n, \\lambda_i \\in \\bbR: 
> \\itA\\bfv = \\lambda_i\\bfv"==> "퐴 ∈ ℝⁿˣⁿ, 퐯 ∈ ℝⁿ, λᵢ ∈ ℝ: 퐴퐯 = λᵢ퐯"
>
>
> It doesn't support the whole range of latex, but I hope it will be enough 
> for simple formulas.
> I will obviously use this library for latex label support in GLVisualize 
> <https://github.com/JuliaGL/GLVisualize.jl>, but I hope that this library 
> can also be usable in other contexts! (REPL latex renderer?) 
> Enjoy with a simple *Pkg.add("UnicodeFun") *(since its freshly 
> registered, a Pkg.update() might be needed)
>
> Please feel free to report latex strings that are not working, or help 
> adding new transformations! :)
>
> Best,
> Simon
>

[julia-users] Re: [ANN] UnicodeFun

[Simon Danisch]

The best adhoc solution I could find looks like this:
1̲2̲ ̲/̲ ̲2̲0̲
200

So not impossible... I'll see how we can integrate this


Am Mittwoch, 28. September 2016 12:05:36 UTC+2 schrieb Simon Danisch:
>
> Good news everyone!
> I've written a small library that offers various transformations of text 
> to special Unicode characters.
> The most prominent one is the latex-string to latex-unicode:
>
> "\\itA \\in \\bbR^{nxn}, \\bfv \\in \\bbR^n, \\lambda_i \\in \\bbR: 
> \\itA\\bfv = \\lambda_i\\bfv"==> "퐴 ∈ ℝⁿˣⁿ, 퐯 ∈ ℝⁿ, λᵢ ∈ ℝ: 퐴퐯 = λᵢ퐯"
>
>
> It doesn't support the whole range of latex, but I hope it will be enough 
> for simple formulas.
> I will obviously use this library for latex label support in GLVisualize 
> <https://github.com/JuliaGL/GLVisualize.jl>, but I hope that this library 
> can also be usable in other contexts! (REPL latex renderer?) 
> Enjoy with a simple *Pkg.add("UnicodeFun") *(since its freshly 
> registered, a Pkg.update() might be needed)
>
> Please feel free to report latex strings that are not working, or help 
> adding new transformations! :)
>
> Best,
> Simon
>

[julia-users] [ANN] UnicodeFun

[Simon Danisch]

Good news everyone!
I've written a small library that offers various transformations of text to 
special Unicode characters.
The most prominent one is the latex-string to latex-unicode:

"\\itA \\in \\bbR^{nxn}, \\bfv \\in \\bbR^n, \\lambda_i \\in \\bbR: \\itA\\bfv 
= \\lambda_i\\bfv"==> "퐴 ∈ ℝⁿˣⁿ, 퐯 ∈ ℝⁿ, λᵢ ∈ ℝ: 퐴퐯 = λᵢ퐯"


It doesn't support the whole range of latex, but I hope it will be enough 
for simple formulas.
I will obviously use this library for latex label support in GLVisualize 
, but I hope that this library 
can also be usable in other contexts! (REPL latex renderer?) 
Enjoy with a simple *Pkg.add("UnicodeFun") *(since its freshly registered, 
a Pkg.update() might be needed)

Please feel free to report latex strings that are not working, or help 
adding new transformations! :)

Best,
Simon

[julia-users] Re: Get the red out!

[Simon Danisch]

How about something like this:

function showtypetree(T, level=0)
println("\t" ^ level, T)
for t in subtypes(T)
(t != Any) && showtypetree(t, level+1)
end   
end

This is still not type stable, since *_subtype *seems to use untyped sets:
https://github.com/JuliaLang/julia/blob/master/base/reflection.jl#L283

Not sure if this is an oversight, or if there are actually corner cases 
making it impossible to type as Set{DataType}().
Fact is, with that change subtype is 10x faster and doesn't return 
Vector{Any} anymore.
I opened a PR:
https://github.com/JuliaLang/julia/pull/18663

Best,
Simon


Am Sonntag, 25. September 2016 00:12:16 UTC+2 schrieb Brian Rogoff:
>
> ... of @code_warntype output.
>
> I was reading 
> https://en.wikibooks.org/wiki/Introducing_Julia/Types#Investigating_types 
> and I came across the following code, described as "not very elegant":
>
> level = 0
> function showtypetree(subtype)
> global level
> subtypelist = filter(asubtype -> asubtype != Any, subtypes(subtype))
> if length(subtypelist) > 0 
>  println("\t" ^ level, subtype)
>  level += 1
>  map(showtypetree, subtypelist)
>  level -= 1
> else
>  println("\t" ^ level, subtype)
> end
> end
>
> showtypetree(Number)
>
>
> Being unable to leave well enough alone, I decided to try to make it more 
> elegant. After replacing the inelegant global variable with a nested 
> function, I first noticed that the function returns '0', which is ugly. So, 
> the increment operators return a value, which is unfortunate (any reason 
> there's no increment with doesn't do that?) and the two branches of the if 
> return different types. A special 'ignore' function patches that. map also 
> builds and returns a value that's discarded. In OCaml we'd use an 'iter' 
> instead of 'map', but Julia's 'for' can be a one-liner too. I left the 
> print alone even though there's no need to repeatedly build those strings 
> (print_nchars_before is easy)  .In the end I got here
>
> ignore{T<:Any}(value::T)::Void = return
>
> function showtypetree(subtype::DataType)::Void
> level::Int64 = 0
> function nested(st::DataType)::Void
> subtypelist = filter(asubtype -> asubtype != Any, subtypes(st))
> if length(subtypelist) > 0 
> println("\t" ^ level, st)
> level += 1
> for s in subtypelist nested(s)  end
> ignore(level -= 1)
> else
> println("\t" ^ level, st)
> end
> end
> nested(subtype)
> end
>
>
> I still notice that when I do @code_warntype showtypetree(Number), I get 
> some 'red', notably, level is shown as Core.Box, even though I explicitly 
> type it. Is there some way to reduce the red in the @code_warntype for this 
> function? Here's what I get in 0.6.0-dev.749
>
> julia> @code_warntype showtypetree(Number)
> Variables:
>   #self#::#showtypetree
>   subtype::Type{Number}
>   level::Core.Box
>   nested::Core.Box
>
> Body:
>   begin
>   level::Core.Box = $(Expr(:new, :(Core.Box)))
>   nested::Core.Box = $(Expr(:new, :(Core.Box)))
>   SSAValue(0) = Main.Void
>   (Core.setfield!)(level::Core.Box,:contents,0)::Int64 # line 3:
>   SSAValue(1) = $(Expr(:new, :(Main.#nested#2), :(level), :(nested)))
>   (Core.setfield!)(nested::Core.Box,:contents,SSAValue(1))::#nested#2 
> # line 16:
>   return 
> (Base.convert)(SSAValue(0),((Core.getfield)(nested::Core.Box,:contents)::Any)(subtype::Type{Number})::Any)::Void
>   end::Void
>
>
> and I'm not sure how to remove the red and make the code more elegant. 
> Ideas?
>
>

[julia-users] Re: GPU CUDA programming in Julia

[Simon Danisch]

>What I'm after is something simple as for exemple what ArrayFire.jl

If ArrayFire is the kind of simplicity you want and if you don't need more 
than that, ArrayFire is your best bet right now!
It should be relatively stable. Make sure that you installed the 
dependencies correctly and if it still doesn't pass please open a Github 
issue.

Another option is CUDAnative.jl  
which 
lets you run a subset of Julia code on an NVIDIA gpu.
Sadly, it's not that simple to use yet. You need to build a special Julia 
version, set things up correctly and you will still frequently hit bugs 
with opaque errors.

I'm currently working on a GPUArray prototype, which makes using 
CUDAnative.jl  easier and has a 
fallback if you're not on NVIDIA hardware/ not building your own Julia 
version.
But that's still in the early prototype phase.


Am Samstag, 17. September 2016 11:21:12 UTC+2 schrieb Ferran Mazzanti:
>
> Hi folks,
> I know this is a very naive question as such but I can't make me a 
> complete picture of this world. I would like to be able to program Julia 
> code for the nVidia GPU's supporting CUDA: What is the best/easiest way to 
> do that? Is it possible to write all the code (including the GPU part) in 
> Julia, or does one need to resort to C to write kernels? What I'm after is 
> something simple as for exemple what ArrayFire.jl seems to provide, but 
> unfortunately this one does not seem to pass the tests in Julia. Does 
> anybody know of a good (and simple) CUDA tutorial for that?
> Thanks in advance and sorry for being so naive,
> Ferran.
>

[julia-users] Re: New to Julia - Need some basic help

[Simon Danisch]

Also, are you looking for *include("Filename.jl")* ?

Am Freitag, 19. August 2016 12:09:05 UTC+2 schrieb Pigskin Ablanket:
>
> Ok, I am trying to familiarize myself with a study published using Julia. 
>  I have Julia up and running, but cant seep to get the actual code open.
>
> Here is what I done so far:
>
> julia> Pkg.add("JuMP")
> julia> Pkg.add("DataFrames")
> julia> Pkg.add("GLPKMathProgInterface")
>
> I believe I successfully added the requisite programs.  all good.  Now I 
> downloaded the code via CSV.  
>
> It contains the Code in a .jl file, license file, readme file and a couple 
> excel CSV files needed.
>
> I tried top open the file using Julia> Open("Filename.jl") and got the 
> following error:
>
> *No such file or directory in open at iostream.jl:90  **in open at 
> **iostream.jl:99*
>
> My sense is that I dont have the file in the right directory, but this is 
> where I get over my skis.
>
> Is that the issue?  How do I make Julia find the file?  Sorry or such basic 
> questions 
>
>

[julia-users] Re: JuliaIO

[Simon Danisch]

I replied on github ;)

Best,
Simon

Am Montag, 8. August 2016 19:54:14 UTC+2 schrieb David Anthoff:
>
> Who is maintaining JuliaIO packages? It would be great if someone with 
> push rights could follow up on 
> https://github.com/JuliaIO/GZip.jl/issues/57. 
>
>  
>
> Thanks,
>
> David
>
>  
>
> --
>
> David Anthoff
>
> University of California, Berkeley
>
>  
>
> http://www.david-anthoff.com
>
>  
>

[julia-users] Re: How to make a variable length tuple with inferred type

[Simon Danisch]

How about:
julia> @code_warntype ntuple( x -> 0, Val{3})
Variables:
  #self#::Base.#ntuple
  f::##1#2
  #unused#::Type{Val{3}}

Body:
  begin
  $(Expr(:static_parameter, 2)) # line 73:
  # meta: location tuple.jl _ntuple 80
  # meta: location tuple.jl _ntuple 80
  SSAValue(1) = $(QuoteNode(0))
  # meta: pop location
  # meta: pop location
  return 
(Core.tuple)(SSAValue(1),$(QuoteNode(0)),$(QuoteNode(0)))::Tuple{Int64,Int64,Int64}
  end::Tuple{Int64,Int64,Int64}

Am Montag, 1. August 2016 02:16:04 UTC+2 schrieb Sheehan Olver:
>
> I'm doing the following:
>
>
> immutable FooIterator{d} end
>
> Base.start(::FooIterator{d}) = tuple(zeros(Int,d)...)::NTuple{d,Int}
>
>
> But is there a more elegant way of getting the type inferred?  I suppose I 
> can override low order d directly:
>
> Base.start(::FooIterator{2}) = (0,0)
> Base.start(::FooIterator{3}) = (0,0,0)
>

[julia-users] Re: GraphViz.jl alternative on windows

[Simon Danisch]

There's also https://github.com/JuliaGraphs/GraphVisualize.jl


Am Mittwoch, 22. Juni 2016 16:01:10 UTC-4 schrieb David Anthoff:
>
> Hi,
>
>  
>
> GraphViz.jl doesn’t seem to work on Windows. Is there an alternative 
> package for this sort of thing? I know about NetworkViz.jl and 
> TikzGraphs.jl, but would appreciate pointers to any other package that I 
> might have missed.
>
>  
>
> Thanks,
>
> David
>
>  
>
> --
>
> David Anthoff
>
> University of California, Berkeley
>
>  
>
> http://www.david-anthoff.com
>
>  
>

[julia-users] Re: Packages Distances problem with Distances.Jaccard : very slow

[Simon Danisch]

It also seems unnecessary to restrict it to Float64 and Array:

function myjaccard2{T}(A::AbstractArray{T,1}, B::AbstractArray{T, 1})
num = zero(T)
den = zero(T) 
for (a,b) in zip(A,B) 
num += min(a,b) 
den += max(a,b) 
end 
return 1.0 - num/den 
end

Maybe also use T1, T2 and then promote to a common type ;)

Best,
Simon

Am Montag, 13. Juni 2016 03:53:14 UTC+2 schrieb jean-pierre both:
>
>
>
> I encountered in my application with Distances.Jaccard compared with 
> Distances.Euclidean
> It was very slow.
>
> For example with 2 vecteurs Float64 of size 11520
>
> I get the following 
> julia> D=Euclidean()
> Distances.Euclidean()
> julia> @time for i in 1:500
>evaluate(D,v1,v2)
>end
>   0.002553 seconds (500 allocations: 7.813 KB)
>
> and with Jaccard
>
> julia> D=Jaccard()
> Distances.Jaccard()
> @time for i in 1:500
>   evaluate(D,v1,v2)
>   end
>   1.995046 seconds (40.32 M allocations: 703.156 MB, 9.68% gc time)
>
> With a simple loop for computing jaccard :
>
>
> function myjaccard2(a::Array{Float64,1}, b::Array{Float64,1})
>num = 0
>den = 0
>for i in 1:length(a)
>num = num + min(a[i],b[i])
>den = den + max(a[i],b[i])  
>end
>1. - num/den
>end
> myjaccard2 (generic function with 1 method)
>
> julia> @time for i in 1:500
>   myjaccard2(v1,v2)
>   end
>   0.451582 seconds (23.04 M allocations: 351.592 MB, 20.04% gc time)
>
> I do not see the problem in jaccard distance implementation in the 
> Distances packages
>

[julia-users] Re: ArrayFire.jl - GPU Programming in Julia

[Simon Danisch]

That would need the capability of compiling arbitrary Julia functions for 
the GPU.
If you remove the arbitrary (no allocations, no exceptions, no IO) and are 
confident with trying out prototypes, this already exists for NVidia GPU's: 
https://github.com/JuliaGPU/CUDAnative.jl
If you only have a couple of thousand elements, it might be that you won't 
profit much from the GPU, though ;)



Am Freitag, 10. Juni 2016 07:08:42 UTC+2 schrieb ran...@juliacomputing.com:
>
> Hello, 
>
> We are pleased to announce ArrayFire.jl, a library for GPU and 
> heterogeneous computing in Julia: (
> https://github.com/JuliaComputing/ArrayFire.jl). We look forward to your 
> feedback and your contributions as well! 
>
> For more information, check out Julia Computing's latest blog post: 
> http://juliacomputing.com/blog/2016/06/09/julia-gpu.html
>
> Thanks,
> Ranjan
> Julia Computing, Inc. 
>

[julia-users] Re: Reconstruct a string from a Clang.jl generated looong type

[Simon Danisch]

What exactly are you after? 
There's not much more to it than using tuples, which should be well 
documented.

We wrapped Vulkan with this Clang 
version: 
https://github.com/JuliaGPU/VulkanCore.jl/blob/master/gen/api/vk_common_1.0.0.jl#L1367

Best,
Simon

Am Montag, 6. Juni 2016 01:41:34 UTC+2 schrieb J Luis:
>
> Hi,
>
> I have one of those types generated from a C struct with Clang.jl that 
> turns a stack variable into a lng list of members (for example (but I 
> have longer ones))
>
> https://github.com/joa-quim/GMT.jl/blob/master/src/libgmt_h.jl#L1246
>
> (an in interlude: isn't yet any better way of representing a C "char 
> str[256];"?)
>
> when executed I get (example)
>
> julia> hdr.x_units
> GMT.Array_80_Uint8(0x6c,0x6f,0x6e,0x67,0x69,0x74,0x75,0x64,0x65,0x20,0x5b,
> 0x64,0x65,0x67,0x72,0x65,0x65,0x73,0x5f,0x65,0x61,0x73,0x74,0x5d,0x00,0x00
> ,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
> 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
> ,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
> 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00)
>
> but I need to transform it into a string. After some suffering I came out 
> with this solution
>
> julia> join([Char(hdr.x_units.(n)) for n=1:sizeof(hdr.x_units)])
> "longitude 
> [degrees_east]\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
>
> well, it works but it's kind or ugly. Is there a better way of achieving 
> this? Namely, how could I avoid creating a string with all of those \0's? I 
> know I can remove them after, but what about not copying them on first 
> place?
>
> Thanks
>
>

[julia-users] Re: Reconstruct a string from a Clang.jl generated looong type

[Simon Danisch]

On master, Clang will emit NTuples, which is a bit nicer at least!

bytestring(UInt8[a...])
a = map(UInt8, ("abcd"...,))

Am Montag, 6. Juni 2016 01:41:34 UTC+2 schrieb J Luis:
>
> Hi,
>
> I have one of those types generated from a C struct with Clang.jl that 
> turns a stack variable into a lng list of members (for example (but I 
> have longer ones))
>
> https://github.com/joa-quim/GMT.jl/blob/master/src/libgmt_h.jl#L1246
>
> (an in interlude: isn't yet any better way of representing a C "char 
> str[256];"?)
>
> when executed I get (example)
>
> julia> hdr.x_units
> GMT.Array_80_Uint8(0x6c,0x6f,0x6e,0x67,0x69,0x74,0x75,0x64,0x65,0x20,0x5b,
> 0x64,0x65,0x67,0x72,0x65,0x65,0x73,0x5f,0x65,0x61,0x73,0x74,0x5d,0x00,0x00
> ,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
> 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
> ,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
> 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00)
>
> but I need to transform it into a string. After some suffering I came out 
> with this solution
>
> julia> join([Char(hdr.x_units.(n)) for n=1:sizeof(hdr.x_units)])
> "longitude 
> [degrees_east]\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
>
> well, it works but it's kind or ugly. Is there a better way of achieving 
> this? Namely, how could I avoid creating a string with all of those \0's? I 
> know I can remove them after, but what about not copying them on first 
> place?
>
> Thanks
>
>

[julia-users] Re: Julia Users Berlin

[Simon Danisch]

That's awesome!
I'm based in Berlin and just recently discussed with different people that 
we really need a meetup... So, thanks for doing this!
I should be able to attend, looking forward seeing everyone there.

Best,
Simon

Am Montag, 30. Mai 2016 15:16:08 UTC+2 schrieb David Higgins:
>
> Hi all,
>
> I gave a talk at the recent PyData Berlin conference (
> http://pydata.org/berlin2016/) and there seems to be enough interest in 
> forming a regular users group in the city. Some of you may recall that we 
> had a preliminary meeting a year ago, which happened to coincide with Viral 
> Shah being within striking distance and he came along, but at the time none 
> of us were really ready to make it a regular event.
>
> A year is a long time in the life of a Julia user. Now there are more of 
> us and we'd like to meet up again.
>
> On *Thursday June 9th *at* 7pm*, we're going to meet at St Oberholz 
> (Rosenthaler 
> Str. 72A, 10119 Berlin). Miles Lubin from JuMP happens to be in town, so 
> the topics of the night might include (i) numerical optimisation and (ii) 
> how to organise more regular meetings (topics, location). So please come 
> along. The reservation is in the name Robert Schwarz and based on previous 
> experience we'll probably be upstairs at the back of the room.
>
> By the way, I've created a landing page for a Julia Users Group - Berlin 
> on GitHub. Feel free to contribute. http://julia-users-berlin.github.io/
>
> David Higgins
>
>

[julia-users] Re: why does Julia have both map and broadcast?

[Simon Danisch]

The main thing we should try is to at least have them share as much of the 
implementation as possible, so that user defined arrays just have to 
implement one of them correctly and fast(which is non trivial, so it 
shouldn't really be done 2 times).

I propose something like this:
```

lazy_reshape(x::Scalar, shape) = ScalarRepeat(x, shape)
lazy_reshape{N}(x::AbstractVector, shape::NTuple{N, Int}) = Grid{N}(x, 
shape)
#...
function broadcast(F, x...)
# broadcast should be about shape only
shape = broadcast_shape(x)
map_args = map(arg -> lazy_reshape(arg, shape), x)
map(F, map_args...) # map should infer return types
end
```
This should be very fast and still memory efficient, as long as the 
compiler inlines nicely and infers constants correctly.


Am Samstag, 21. Mai 2016 15:26:21 UTC+2 schrieb Steven G. Johnson:
>
> It seems at first glance like broadcast(f, args...) could be interpreted 
> as a strict generalization of map(f, args...), in which case you might as 
> well just have one function (map).
>
> In particular, are there any cases where both broadcast(f, args...) and 
> map(f, args...) are applicable (sans exceptions), but the two functions 
> (intentionally) give different results?
>

[julia-users] Re: GLVisualize in existing OpenGL context

[Simon Danisch]

I prefer issues for these kind of questions ;)
I opened one for you: https://github.com/JuliaGL/GLVisualize.jl/issues/94

Best,
Simon
Am Donnerstag, 28. April 2016 22:45:30 UTC+2 schrieb Bart Janssens:
>
> Hi,
>
> For QML.jl, I have created an experimental OpenGL QML type that can be 
> used as rendering target for GLAbstraction.jl by simply skipping the GLFW 
> commands and drawing directly to the Qt-provided context (code: 
> https://github.com/barche/QML.jl/blob/master/example/gltriangle.jl). I 
> attempted to do the same using GLVisualize, but the result crashes. The 
> code is here: 
> https://github.com/barche/QML.jl/blob/master/example/glvisualize.jl
>
> What is the proper way to make GLVisualize use an existing (non-GLFW) 
> OpenGL context?
>
> Cheers,
>
> Bart
>

[julia-users] Re: Options for constructing a 3D surface from a point cloud

[Simon Danisch]

Well just for visualization you should checkout glvisualize 
... 

Am Mittwoch, 17. Februar 2016 18:46:57 UTC+1 schrieb Chris:
>
> If I have a set of 3D points, randomly sampled from some arbitrary 
> surface, what are my options (in terms of Julia packages) for 
> reconstructing the surface for plotting? I've done a little research and 
> found the Meshes.jl package, but I can't find any good examples or 
> documentation for it. In case it's not already obvious, I'm completely new 
> to this topic, so any direction would be appreciated.
>
> Thanks,
> Chris
>

[julia-users] Re: Simple function allocating too much memory (Gini coefficient)

[Simon Danisch]

In Julia this:
function xxx22xx1B(e99y::Array,ww=ones(22))
return 22.2
end

turns into this:
xxx22xx1B(e99y::Array) = xxx22xx1B(e99y, ones(22))
function xxx22xx1B(e99y::Array,ww)
return 22.2
end

So you get 2 functions ;)

Am Montag, 18. April 2016 09:38:19 UTC+2 schrieb bernhard:
>
> Hi all
>
> I have written the function below. For some reason it is quite slow and 
> allocates a lot of memory.
> I realize that the sorting (which creates srt) needs memory to store the 
> sort order.
> However the second loop also seems to allocate a lot of memory and I do 
> not know why.
> Arrlen and i are integers, but I do not think that is the issue here.
>
> Does anybody see a way to improve the function?
> Thanks
>
>
>
> function 
> gini{T<:Number}(actual,estimate::Array{T,1},weight=ones(T,length(estimate)))
> arrlen=length(actual)
> srt=sortperm(estimate,rev=true) 
> sumactual=0.0
> @inbounds for i=1:arrlen
> sumactual+=actual[i]*weight[i]
> end 
> cums=0.0
> res=0.0
> #the summation is not quite accurate here (accuracy is at e-7 or so) (the 
> reason is the fact that we do not sort and sum the data)
> @inbounds for i in srt
> cums+=(actual[i]*weight[i])
> res+=cums/sumactual-i/arrlen
> end
> return res 
> end
>
> n=3
> ab=rand(n);
> cd=rand(n);
> ef=rand(n);
>
> @time x=gini(ab,cd,ef)
>   
>

[julia-users] Re: [ANN] VulkanCore

[Simon Danisch]

Thanks :)

@Eric Forgy: I hope that we can bring some of the comfort you have in the 
Web to native Julia and GPU computing ;) If and when that'll be achieved is 
an open question...


>I haven't tried GLVisualize - isn't there a problem with high-performance 
3D in a stop-the-world GC'ed language like Julia?

There definitely is. Luckily, in the scientific world throughput is more 
important than minor stutters, so this should give us some time to let the 
GC and visualization infrastructure grow up.

Right now, GLVisualize is mostly pretty smooth and if it's not smooth, it 
should mainly be because of the event system.

If 3D visualization in Julia works out to a point that people get serious 
about it, I'm sure we will figure out ways to make the GC less of an issue.
Vulkan needs a lot of manual memory management anyways, so one might just 
expand on that and don't really put any pressure on the GC.
It might also be possible to create low latency threads, which don't get 
interrupted by the GC.

 

Am Samstag, 9. April 2016 19:32:53 UTC+2 schrieb Simon Danisch:
>
> Valentin <https://github.com/vchuravy> and I are proud to announce a 
> Julia wrapper for the Vulkan API <https://www.khronos.org/vulkan/>:
> VulkanCore.jl <https://github.com/JuliaGPU/VulkanCore.jl>
>
> Vulkan can be called the successor of OpenGL, but it's a lot closer to the 
> hardware, which is why it's not a direct replacement of OpenGL.
>
> In short, the main differences to OpenGL are:
>
>- lower driver overhead
>- better utilization of multi-core setups
>- shader/kernel are consumed in form of a new intermediate format, 
>SPIR-V <https://www.khronos.org/registry/spir-v/specs/1.0/SPIRV.pdf>, 
>which can be targeted by any language (yes, especially Julia+LLVM)
>- better low-level abstraction for GPU-CPU/GPU-GPU synchronization and 
>memory management
>- GPGPU becomes more of a first class citizen
>- supports a large variety of hardware and platforms (NVIDIA, AMD, 
>Intel, ARM, Android, Linux, Windows 
><https://en.wikipedia.org/wiki/Vulkan_(API)>...)
>
> One of the more exciting use cases of Vulkan is running Julia kernels over 
> GPU-Arrays and then seamlessly visualizing the results.
> Enabling this will be a lot of work. Please stay tuned for further posts 
> and watch the progress at Vulkan.jl 
> <https://github.com/JuliaGPU/Vulkan.jl>, the (not yet finished) higher 
> level abstraction over VulkanCore.jl.
>
> You can find some more information in a blog post 
> <http://randomfantasies.com/2016/02/why-im-betting-on-vulkan-and-julia/> 
> I recently wrote.
>
> Best,
> Simon
>

[julia-users] Re: is accessing tuple elements more efficient than accessing elements of a 1d array?

[Simon Danisch]

Your benchmark is flawed.
Try something like the Benchmarks 
 package, or use this:

using FixedSizeArrays
Base.(:+){T}(p1::NTuple{2,T}, p2::NTuple{2,T}) = (p1[1]+p2[1], p1[2]+p2[2])
function test(a, b, N)
   ct = a+b
   for _ in 1:N ct = ct+a+b end # use intermediate result so that llvm 
doesn't just remove the loop
   ct # return value so it doesn't get optimized away
end
a, b = randn(2), randn(2)
at, bt = (randn(2)...), (randn(2)...)
p1, p2 = Point2D(randn(2)...), Point2D(randn(2)...)

#warm up
test(a,b,10^7)
test(at,bt,10^7)
test(p1,p1,10^7)


@time test(a,b,10^7) # 1.175718 seconds (40.00 M allocations: 1.788 GB, 
9.77% gc time)
@time test(at,bt,10^7) #0.017781 seconds (6 allocations: 208 bytes)
@time test(p1,p1,10^7) #0.017783 seconds (6 allocations: 208 bytes)


As you can see, tuples and types are pretty much the same, while Vector is 
far behind.
In this benchmark, it's mainly because the Vector is heap allocated.
Tuples are preferable to types, since they have the same performance, but 
you can implement n-dimensional point types.
If you already found FixedSizeArrays, what's holding you back of using it?
It already has the Point{N, T} type and GeometryTypes.jl 
 has even more ;)

Best,
Simon
Am Montag, 11. April 2016 22:00:59 UTC+2 schrieb Anonymous:
>
> If I have a vector of data which I don't intend to ever change, should I 
> represent it as a tuple rather than a 1d array?  Is there any benefit above 
> and beyond protecting against mutability?  Is it more efficient?
>

[julia-users] Re: [ANN] FixedSizeDictionaries

[Simon Danisch]

@Christoph: arbitrarily, of course :D Joke aside, it should also use *zip* 
for the *(keys, values)* constructor (like Base does).
@tshort:
It can have arbitrary *isbits* & *immutables* as keys.
E.g, this works (should probably get some macro sugar):
*function test{Keys<: Tuple{Val{1}, Val{:c}, 
Val{MyKeyType()}}(x::FixedKeyValueDict{Keys})*

Also, it doesn't need to look up if a Dict is already defined, which 
simplifies the implementation.

In general, I think it's a bit more future proof.
I expect generating types via eval to be never really idiomatic, while* 
@generated *seems to be fine for these kind of optimizations.
With *getfield* overloading and better constant propagation, the 
implementation might be freed of any *@generated* and macro magic at some 
point, which I think is desirable.

For NamedTuples speaks, that it'll be equally fast or faster in most cases 
and* getfield/setfield* works currently better with types.
Also, it already has the nicer macro sugar ;)



Am Montag, 11. April 2016 14:08:59 UTC+2 schrieb Simon Danisch:
>
> Here is yet another package: FixedSizeDictionaries.jl 
> <https://github.com/SimonDanisch/FixedSizeDictionaries.jl>
>
> From the README:
> *Library which implements a FixedSize variant of Dictionaries. These can 
> be stack allocated and have O(1) indexing performance without boundcheck. 
> It implements most parts of the Base.Dict interface. *
> *This package is useful, when you want anonymous composite types. You 
> should be a bit careful with generating a lot of FixedSizeDict's, since it 
> will compile a unique set of functions for every field of a Dict.*
>
> I'll be using it to speed up various places where I'm currently using a 
> dictionary but where the number of keys is set at compile time.
> Also, Shashi <https://github.com/shashi> and I contemplated to implement  
> <http://goog_285611601>Extensible Records 
> <http://elm-lang.org/docs/records>, which seems like a good fit to 
> represent all kind of graphics/geometry types.
> FixedSizeDictionaries could be an integral part of this!
>
> Best,
> Simon
>
> PS:
> I do feel like it's time for a package announcement list...
>

[julia-users] [ANN] FixedSizeDictionaries

[Simon Danisch]

Here is yet another package: FixedSizeDictionaries.jl 


>From the README:
*Library which implements a FixedSize variant of Dictionaries. These can be 
stack allocated and have O(1) indexing performance without boundcheck. It 
implements most parts of the Base.Dict interface. *
*This package is useful, when you want anonymous composite types. You 
should be a bit careful with generating a lot of FixedSizeDict's, since it 
will compile a unique set of functions for every field of a Dict.*

I'll be using it to speed up various places where I'm currently using a 
dictionary but where the number of keys is set at compile time.
Also, Shashi  and I contemplated to implement  
Extensible Records , 
which seems like a good fit to represent all kind of graphics/geometry 
types.
FixedSizeDictionaries could be an integral part of this!

Best,
Simon

PS:
I do feel like it's time for a package announcement list...

[julia-users] [ANN] VulkanCore

[Simon Danisch]

Valentin  and I are proud to announce a Julia 
wrapper for the Vulkan API :
VulkanCore.jl 

Vulkan can be called the successor of OpenGL, but it's a lot closer to the 
hardware, which is why it's not a direct replacement of OpenGL.

In short, the main differences to OpenGL are:

   - lower driver overhead
   - better utilization of multi-core setups
   - shader/kernel are consumed in form of a new intermediate format, SPIR-V 
   , which can 
   be targeted by any language (yes, especially Julia+LLVM)
   - better low-level abstraction for GPU-CPU/GPU-GPU synchronization and 
   memory management
   - GPGPU becomes more of a first class citizen
   - supports a large variety of hardware and platforms (NVIDIA, AMD, 
   Intel, ARM, Android, Linux, Windows 
   ...)

One of the more exciting use cases of Vulkan is running Julia kernels over 
GPU-Arrays and then seamlessly visualizing the results.
Enabling this will be a lot of work. Please stay tuned for further posts 
and watch the progress at Vulkan.jl , 
the (not yet finished) higher level abstraction over VulkanCore.jl.

You can find some more information in a blog post 
 I 
recently wrote.

Best,
Simon

Re: [julia-users] Re: raytracing in julia

[Simon Danisch]

Sorry, totally forgot to reply. Well, Cxx only works with a differently
compiled julia, which is why I'm not using it yet to wrap user facing
libraries. There a few half backed plans to support ray tracing for hit
detection at some point... But preferably on the GPU, maybe simply with
FireRay;)
It seems that the official FireRays
<https://github.com/GPUOpen-LibrariesAndSDKs/FireRays_SDK> repo currently
can't be build on my system (Ubuntu 14.04), though there is already an
issue about this.

If there is only a C++ API, what kind of trouble does that mean for trying
to wrap it with julia? Is it impossible? Very hacky? Need to look into
llvm? Bad performance?

Also what about your GeometryTypes
<https://github.com/JuliaGeometry/GeometryTypes.jl> package? I saw there a
type 'Particle', are there any plans to support ray tracing in that package
or on top of it?

On Tuesday, March 29, 2016 at 12:30:14 PM UTC+2, Simon Danisch wrote:
>
> Oh, contrary to FireRender, FireRay seems to only have a C++ API...
> There's also https://github.com/JuliaGeometry/GeometricalPredicates.jl
> and https://github.com/JuliaGeometry/TriangleIntersect.jl, though!
>
>
> Am Freitag, 25. März 2016 14:54:01 UTC+1 schrieb jw3126:
>>
>> I need to do things like building a simple geometry which consists of a
>> few polygons, cylinders, spheres and calculate if/where rays hit these
>> objects.
>>
>> Is there some julia library which does this already? Or some easy to wrap
>> C/Fortran library? Any suggestions?
>> I would prefer a solution, which does not depend on vectorization, but
>> can be called efficiently as part of a loop, one ray at a time.
>>
>

[julia-users] Re: raytracing in julia

[Simon Danisch]

Oh, contrary to FireRender, FireRay seems to only have a C++ API...
There's also https://github.com/JuliaGeometry/GeometricalPredicates.jl
and https://github.com/JuliaGeometry/TriangleIntersect.jl, though!


Am Freitag, 25. März 2016 14:54:01 UTC+1 schrieb jw3126:
>
> I need to do things like building a simple geometry which consists of a 
> few polygons, cylinders, spheres and calculate if/where rays hit these 
> objects.
>
> Is there some julia library which does this already? Or some easy to wrap 
> C/Fortran library? Any suggestions?
> I would prefer a solution, which does not depend on vectorization, but can 
> be called efficiently as part of a loop, one ray at a time.
>

[julia-users] Re: raytracing in julia

[Simon Danisch]

I wrapped FireRender.jl , 
which uses FireRays 

 to 
do the hit detection.
The C-Interface of FireRender was very nice to wrap and got me started very 
quickly, so i expect it to be the same for FireRays (which sounds more like 
the library you'd like to target). If you use Clang.jl 
, you should be up to speed quickly!
It's very fast and cross platform, as they use OpenCL.
Since I'm already familiar with everything involved, I could help to get 
you started.

Best,
Simon


Am Freitag, 25. März 2016 14:54:01 UTC+1 schrieb jw3126:
>
> I need to do things like building a simple geometry which consists of a 
> few polygons, cylinders, spheres and calculate if/where rays hit these 
> objects.
>
> Is there some julia library which does this already? Or some easy to wrap 
> C/Fortran library? Any suggestions?
> I would prefer a solution, which does not depend on vectorization, but can 
> be called efficiently as part of a loop, one ray at a time.
>

[julia-users] [ANN] new tagged version of GLVisualize

[Simon Danisch]

Hi,
there is a new version of *GLVisualize* and I also improved the website 
.
improvements include various bug fixes, a new vertex color mesh type 
 and better 
performance.
The website contains 3 more examples now, and you can just click on the 
images on the front page to get to the examples.
One of the examples is targeted to get you started with the general 
workflow of GLVisualize: 
http://www.glvisualize.com/examples/introduction/#simulation

I also put up an issue for feedback to get a better idea what to 
concentrate on:
https://github.com/JuliaGL/GLVisualize.jl/issues/80
Please comment freely!


Best,
Simon

[julia-users] Re: ANN: NetworkViz.jl - Julia module for graph visualization

[Simon Danisch]

Ah great! lets continue there!

Am Donnerstag, 17. März 2016 14:17:15 UTC+1 schrieb Abhijith Anilkumar:
>
> Hi,
>
> I'm happy to announce the first registered version of NetworkViz.jl 
> , a julia interface 
> to visualize graphs using ThreeJS.jl 
>  and Escher.jl 
> . The package is tightly coupled 
> with LightGraphs.jl . It 
> uses Escher.jl to interactively modify the visualization. The following 
> examples demonstrate what NetworkViz is capable of :
>
>
>- WheelGraph Visualization 
>
>- Code-Mirror example 
>
>
> I've planned to implement the following features in the future releases :
>
>- Implement different Graph Plotting algorithms
>- Better Text Support 
>- Blink Integration
>- Generalize the package (to work with packages other than LightGraphs)
>
>
> I would like to take this up as a GSoC project and continue working on the 
> package. I would therefore like to ask if there is someone who would like 
> to be a mentor for this project? 
>
> Please give your suggestions so that I can use it to improve the package 
> and make it useful for the community. 
>
> Regards,
> Abhijith
>

[julia-users] Re: ANN: NetworkViz.jl - Julia module for graph visualization

[Simon Danisch]

Why not writing rendering backend agnostic code and switch out backends as 
the library evolves? You can simply work with lines, points and text types, 
and decouple things from the visualization code completely. This way you 
could also use GLVisualize , which should help 
quite a bit with latency ;)

Am Donnerstag, 17. März 2016 14:17:15 UTC+1 schrieb Abhijith Anilkumar:
>
> Hi,
>
> I'm happy to announce the first registered version of NetworkViz.jl 
> , a julia interface 
> to visualize graphs using ThreeJS.jl 
>  and Escher.jl 
> . The package is tightly coupled 
> with LightGraphs.jl . It 
> uses Escher.jl to interactively modify the visualization. The following 
> examples demonstrate what NetworkViz is capable of :
>
>
>- WheelGraph Visualization 
>
>- Code-Mirror example 
>
>
> I've planned to implement the following features in the future releases :
>
>- Implement different Graph Plotting algorithms
>- Better Text Support 
>- Blink Integration
>- Generalize the package (to work with packages other than LightGraphs)
>
>
> I would like to take this up as a GSoC project and continue working on the 
> package. I would therefore like to ask if there is someone who would like 
> to be a mentor for this project? 
>
> Please give your suggestions so that I can use it to improve the package 
> and make it useful for the community. 
>
> Regards,
> Abhijith
>

[julia-users] Re: ANN: NetworkViz.jl - Julia module for graph visualization

[Simon Danisch]

See that there is already GraphVisualize.jl 
and I took a quick stab 
at the issue with SignalView.jl 
.
Both are 2D right now, but should easily work for 3D as well. Note, that I 
actually plan to create a ThreeJS backend for GLVisualize at some point ;)
I can be a mentor for this project, if you don't mind making your project a 
bit more independant from the backend!


Am Donnerstag, 17. März 2016 14:17:15 UTC+1 schrieb Abhijith Anilkumar:
>
> Hi,
>
> I'm happy to announce the first registered version of NetworkViz.jl 
> , a julia interface 
> to visualize graphs using ThreeJS.jl 
>  and Escher.jl 
> . The package is tightly coupled 
> with LightGraphs.jl . It 
> uses Escher.jl to interactively modify the visualization. The following 
> examples demonstrate what NetworkViz is capable of :
>
>
>- WheelGraph Visualization 
>
>- Code-Mirror example 
>
>
> I've planned to implement the following features in the future releases :
>
>- Implement different Graph Plotting algorithms
>- Better Text Support 
>- Blink Integration
>- Generalize the package (to work with packages other than LightGraphs)
>
>
> I would like to take this up as a GSoC project and continue working on the 
> package. I would therefore like to ask if there is someone who would like 
> to be a mentor for this project? 
>
> Please give your suggestions so that I can use it to improve the package 
> and make it useful for the community. 
>
> Regards,
> Abhijith
>

[julia-users] Re: [ANN] GLVisualize

[Simon Danisch]

@Job van der Zwan 
Thanks, I will include a few more introductions with my next Documentation 
run!
VideoIO <https://github.com/kmsquire/VideoIO.jl>can give you video streams. 
It's not in the best state whatsoever :(
I had it included into GLVisualize at some point, but removed it because of 
reoccuring build errors and conflicting dependencies.
Someone, maybe me, should put some work into the package, it'd be worth it!

@feza
I'm not a big fan of the processing API. It seems to be very hard to 
optimize, so the API already prohibits speed.
But I actually have never looked into it that deeply. If anyone wants, it 
should be possible to create a processing API layer over GLVisualize.
I'm not sure how it would compare to the GLVisualize + GLAbstraction API ;) 
I, obviously, would much rather improve the GLVisualize API!

One could also target the representation that I propose 
here: https://github.com/JuliaGeometry/GeometryTypes.jl/issues/46

The anti aliasing for 3D is indeed problematic right now, for 2D it should 
be very high quality though!
I have different ideas about how to fix the 3D anti-aliasing, but I need to 
find the time for it and decide on a strategy!

Am Freitag, 26. Februar 2016 23:11:02 UTC+1 schrieb Simon Danisch:
>
> Hi
>
> this is the first release of GLVisualize.jl 
> <https://github.com/JuliaGL/GLVisualize.jl>, a 2D/3D visualization 
> library completely written in Julia and OpenGL.
>
> You can find some crude documentation on glvisualize.com 
> <http://www.glvisualize.com/>.
> I hope to improve the examples and the documentation in the coming weeks.
> The biggest problem for most people right now will be a slightly flaky 
> camera and missing guides and labels.
> This is being worked on! If someone beats me to the guide/axis creation, 
> I'd be very happy. This could be a fun project to get started with 
> GLVisualize.
> Please feel free to open any issue concerning missing documentation, 
> discrepancies <http://www.dict.cc/englisch-deutsch/discrepancies.html> and 
> bugs!
>
> Relation to GLPlot <https://github.com/SimonDanisch/GLPlot.jl>:
> GLPlot is now a thin wrapper for GLVisualize with a focus on plotting. 
> Since I concentrated mostly on finishing GLVisualize, it's a reeally thin 
> wrapper. 
> It basically just forwards all calls to GLVisualize, and adds a 
> boundingbox around the objects. 
> In the future, it should offer some basic UI, automatic creation of 
> axis/labels, screenshots and an alternative API that is more familiar to 
> people that are coming from other plotting libraries (e.g. functions like 
> surf, contourf, patches).
> If anyone has specific plans on how this could look like don't hesitate to 
> open issues and PR's!
>
> Outlook:
> I'd like to make GLVisualize more independent of the rendering backend by 
> using some backend agnostic geometry 
> <https://github.com/JuliaGeometry/GeometryTypes.jl/issues/46> 
> representation.
> This will make it easier to integrate backends like FireRender 
> <https://github.com/JuliaGraphics/FireRender.jl>, WebGL, Vulkan 
> <https://github.com/JuliaGPU/Vulkan.jl/tree/api> (why Vulkan 
> <http://randomfantasies.com/2016/02/why-im-betting-on-vulkan-and-julia/>), 
> or some text based backends like PDF/SVG.
>
> Furthermore, I'd like to improve the performance and interaction 
> possibilities.
>
> I have to thank the Julia Group for supporting me :) It's a pleasure to be 
> a part of the Julia community!
>
> I'm looking forward to the great visualizations you'll create!
>
> Best,
> Simon Danisch
>

[julia-users] Re: 3D scatter / meshed surface color map

[Simon Danisch]

There is: 
http://www.glvisualize.com/examples/surfaces/
Which also supports any 2D/3D billboard (2D particles that keep facing the 
camera): http://www.glvisualize.com/examples/sprites/
If you need axes and labels right away, there 
is: https://github.com/stevengj/PyPlot.jl which supports 3D plots.
They're not really interactive though, from all I know.

Am Donnerstag, 3. März 2016 05:10:52 UTC+1 schrieb mauri...@gmail.com:
>
> Hello Julia users, 
>
> I would like to know if anyone knows how we can have 3D scatter plots or 
> meshed surfaces color plots using Julia.  
>
> My problem is based on four variables, so I'm trying to visualize the data 
> according to these options. 
>
> Any idea or example code will be really helpful. 
>
> Thanks!
>

[julia-users] Re: [ANN] GLVisualize

[Simon Danisch]

> If not MatplotLib, could this become the Processing (and by extension 
OpenFrameworks, LibCinder) of Julia?

That's definitely more the direction I'd like to take (although with a very 
different approach).
I hope that it will enable us to create a nice platform for accelerated 
data processing in general. With FireRender 
<https://github.com/JuliaGraphics/FireRender.jl> as a backend it might also 
appeal to artists more!


@Josef, that's exactly the other concern!
You might have noted that I've written a backend for Gadfly 
<http://www.glvisualize.com/examples/compose/>. While Gadfly is not that 
slow, it's written in a way that it's really hard to apply the 
optimizations needed to display large data-set and it's even worse for 
animations.


Am Freitag, 26. Februar 2016 23:11:02 UTC+1 schrieb Simon Danisch:
>
> Hi
>
> this is the first release of GLVisualize.jl 
> <https://github.com/JuliaGL/GLVisualize.jl>, a 2D/3D visualization 
> library completely written in Julia and OpenGL.
>
> You can find some crude documentation on glvisualize.com 
> <http://www.glvisualize.com/>.
> I hope to improve the examples and the documentation in the coming weeks.
> The biggest problem for most people right now will be a slightly flaky 
> camera and missing guides and labels.
> This is being worked on! If someone beats me to the guide/axis creation, 
> I'd be very happy. This could be a fun project to get started with 
> GLVisualize.
> Please feel free to open any issue concerning missing documentation, 
> discrepancies <http://www.dict.cc/englisch-deutsch/discrepancies.html> and 
> bugs!
>
> Relation to GLPlot <https://github.com/SimonDanisch/GLPlot.jl>:
> GLPlot is now a thin wrapper for GLVisualize with a focus on plotting. 
> Since I concentrated mostly on finishing GLVisualize, it's a reeally thin 
> wrapper. 
> It basically just forwards all calls to GLVisualize, and adds a 
> boundingbox around the objects. 
> In the future, it should offer some basic UI, automatic creation of 
> axis/labels, screenshots and an alternative API that is more familiar to 
> people that are coming from other plotting libraries (e.g. functions like 
> surf, contourf, patches).
> If anyone has specific plans on how this could look like don't hesitate to 
> open issues and PR's!
>
> Outlook:
> I'd like to make GLVisualize more independent of the rendering backend by 
> using some backend agnostic geometry 
> <https://github.com/JuliaGeometry/GeometryTypes.jl/issues/46> 
> representation.
> This will make it easier to integrate backends like FireRender 
> <https://github.com/JuliaGraphics/FireRender.jl>, WebGL, Vulkan 
> <https://github.com/JuliaGPU/Vulkan.jl/tree/api> (why Vulkan 
> <http://randomfantasies.com/2016/02/why-im-betting-on-vulkan-and-julia/>), 
> or some text based backends like PDF/SVG.
>
> Furthermore, I'd like to improve the performance and interaction 
> possibilities.
>
> I have to thank the Julia Group for supporting me :) It's a pleasure to be 
> a part of the Julia community!
>
> I'm looking forward to the great visualizations you'll create!
>
> Best,
> Simon Danisch
>

[julia-users] Real-time user input

[Simon Danisch]

You could try GLVisualize... There is the mario example to get you started: 
http://www.glvisualize.com/examples/interactive/

[julia-users] Re: [ANN] GLVisualize

[Simon Danisch]

Thanks :)

>I wonder if it will be the Matplotlib of Julia

While possible, it will need quite a bit of work :) Offering the 
flexibility and usability of Matplotlib is no easy task! 
Right now the strength rather lies in interactivity and easy means to 
visualize animated and large data sets.

But there could be shortcuts like implementing a backend for Matplotlib 
first.

@Alan, I can create one ;)
Also, as you can see in http://www.glvisualize.com/examples/interactive/, 
something similar to @manipulate can be implemented in GLVisualize.

Am Freitag, 26. Februar 2016 23:11:02 UTC+1 schrieb Simon Danisch:
>
> Hi
>
> this is the first release of GLVisualize.jl 
> <https://github.com/JuliaGL/GLVisualize.jl>, a 2D/3D visualization 
> library completely written in Julia and OpenGL.
>
> You can find some crude documentation on glvisualize.com 
> <http://www.glvisualize.com/>.
> I hope to improve the examples and the documentation in the coming weeks.
> The biggest problem for most people right now will be a slightly flaky 
> camera and missing guides and labels.
> This is being worked on! If someone beats me to the guide/axis creation, 
> I'd be very happy. This could be a fun project to get started with 
> GLVisualize.
> Please feel free to open any issue concerning missing documentation, 
> discrepancies <http://www.dict.cc/englisch-deutsch/discrepancies.html> and 
> bugs!
>
> Relation to GLPlot <https://github.com/SimonDanisch/GLPlot.jl>:
> GLPlot is now a thin wrapper for GLVisualize with a focus on plotting. 
> Since I concentrated mostly on finishing GLVisualize, it's a reeally thin 
> wrapper. 
> It basically just forwards all calls to GLVisualize, and adds a 
> boundingbox around the objects. 
> In the future, it should offer some basic UI, automatic creation of 
> axis/labels, screenshots and an alternative API that is more familiar to 
> people that are coming from other plotting libraries (e.g. functions like 
> surf, contourf, patches).
> If anyone has specific plans on how this could look like don't hesitate to 
> open issues and PR's!
>
> Outlook:
> I'd like to make GLVisualize more independent of the rendering backend by 
> using some backend agnostic geometry 
> <https://github.com/JuliaGeometry/GeometryTypes.jl/issues/46> 
> representation.
> This will make it easier to integrate backends like FireRender 
> <https://github.com/JuliaGraphics/FireRender.jl>, WebGL, Vulkan 
> <https://github.com/JuliaGPU/Vulkan.jl/tree/api> (why Vulkan 
> <http://randomfantasies.com/2016/02/why-im-betting-on-vulkan-and-julia/>), 
> or some text based backends like PDF/SVG.
>
> Furthermore, I'd like to improve the performance and interaction 
> possibilities.
>
> I have to thank the Julia Group for supporting me :) It's a pleasure to be 
> a part of the Julia community!
>
> I'm looking forward to the great visualizations you'll create!
>
> Best,
> Simon Danisch
>

[julia-users] [ANN] GLVisualize

[Simon Danisch]

Hi

this is the first release of GLVisualize.jl 
<https://github.com/JuliaGL/GLVisualize.jl>, a 2D/3D visualization library 
completely written in Julia and OpenGL.

You can find some crude documentation on glvisualize.com 
<http://www.glvisualize.com/>.
I hope to improve the examples and the documentation in the coming weeks.
The biggest problem for most people right now will be a slightly flaky 
camera and missing guides and labels.
This is being worked on! If someone beats me to the guide/axis creation, 
I'd be very happy. This could be a fun project to get started with 
GLVisualize.
Please feel free to open any issue concerning missing documentation, 
discrepancies <http://www.dict.cc/englisch-deutsch/discrepancies.html> and 
bugs!

Relation to GLPlot <https://github.com/SimonDanisch/GLPlot.jl>:
GLPlot is now a thin wrapper for GLVisualize with a focus on plotting. 
Since I concentrated mostly on finishing GLVisualize, it's a reeally thin 
wrapper. 
It basically just forwards all calls to GLVisualize, and adds a boundingbox 
around the objects. 
In the future, it should offer some basic UI, automatic creation of 
axis/labels, screenshots and an alternative API that is more familiar to 
people that are coming from other plotting libraries (e.g. functions like 
surf, contourf, patches).
If anyone has specific plans on how this could look like don't hesitate to 
open issues and PR's!

Outlook:
I'd like to make GLVisualize more independent of the rendering backend by 
using some backend agnostic geometry 
<https://github.com/JuliaGeometry/GeometryTypes.jl/issues/46> 
representation.
This will make it easier to integrate backends like FireRender 
<https://github.com/JuliaGraphics/FireRender.jl>, WebGL, Vulkan 
<https://github.com/JuliaGPU/Vulkan.jl/tree/api> (why Vulkan 
<http://randomfantasies.com/2016/02/why-im-betting-on-vulkan-and-julia/>), 
or some text based backends like PDF/SVG.

Furthermore, I'd like to improve the performance and interaction 
possibilities.

I have to thank the Julia Group for supporting me :) It's a pleasure to be 
a part of the Julia community!

I'm looking forward to the great visualizations you'll create!

Best,
Simon Danisch

[julia-users] Re: Weird Hygiene Issue

[Simon Danisch]

Why not:

module X
  export f
  g(x) = 2x
  f(x, g=g) = g(x)
end

module Y
  using X
  g(x) = 3x
  println(f(4, g))
end

?

Am Sonntag, 14. Februar 2016 20:49:24 UTC+1 schrieb Julia Tylors:
>
> Hi fellows,
>
>
> I was coding a macro, and I am having a prefix issue with functions.
>
> basically the problem is: Every single one of  available functions 
> (_ex_func) which i want to be globally accessible are prefixed with the 
> name of the module(X)  in which the macro f is defined
>
>
> Here is the code example:
>
> julia> module X
> export @f
> macro f(x)
> st = string("_",x)
> sy = symbol(st)
> esc(quote
> function ($sy)()
> println("st")
> end
>
> function ($(symbol(string("_1",x()
> ($sy)()
> println("sty")
> end
> export $sy
> export $(symbol(string("_1",x)))
> end
> )
> end
> @eval @f ex_func
>end
> X
>
> julia> using X
>
> julia> _
>
> _1ex_func  __precompile__  _ex_func
> julia> _1ex_func.env.defs.func.code
> AST(:($(Expr(:lambda, Any[], Any[Any[],Any[],0,Any[]], :(begin  # none, 
> line 12:
> *(X._ex_func)() # none, line 13: # i want this to be not prefixed 
> by X*
> return (X.println)("sty")
> end)
>
> julia> macroexpand(:(@f ex_func))
> quote  # none, line 7:
> function _ex_func() # none, line 8:
> println("st")
> end # none, line 11:
> function _1ex_func() # none, line 12:
> *_ex_func() # none, line 13: # it seems OK, here!!!*
> println("sty")
> end # none, line 15:
> export _ex_func # none, line 16:
> export _1ex_func
> end
>
> as you may see , I may well define _ex_func in other modules and use it 
> from the function X._1ex_func().
> But this prevents me doing it.
>
> How can i solve this problem?
>
> Thanks
>

[julia-users] convention for unspecified argument (R's NULL and FALSE, Common Lisp nil)

[Simon Danisch]

Why not typemax(Int)? That's also equivalent to all rows, has the same type and 
you don't need to treat it in a special way...

[julia-users] Re: how to run julia without the llvm jit

[Simon Danisch]

@Jameson, thanks for the interesting read!

@Tim, I'd like to hear about anything you come up with :)

Am Mittwoch, 10. Februar 2016 04:12:19 UTC+1 schrieb Jameson:
>
> I've been working on a static (no-JIT) Julia mode and related 
> ahead-of-time-compilation tools. I put together a blog post describing this 
> work, and also covering some of the build stages of Julia as well, that I 
> felt may be of interest to some users. It is available at:
>
> http://juliacomputing.com/blog/2016/02/09/static-julia.html
>
> -jameson
>

[julia-users] Re: Are there solutions for tuple/fixed-length vector arithmetic?

[Simon Danisch]

There is this: https://github.com/SimonDanisch/FixedSizeArrays.jl

Best,
Simon


Am Dienstag, 2. Februar 2016 01:07:11 UTC+1 schrieb Nathan Baum:
>
> In some code I'm writing I have inner loops which, amongst other things, 
> translate spherical coordinates into Cartesian.
>
> I notice that the inner loop is a *lot* faster if I change the code to 
> use tuples. This makes sense, but when I use tuples I can't use the maths 
> operators and functions that I can with vectors.
>
> Is there some package which provides these functions for tuples or, 
> alternatively, which offers alternative implementations of efficient 
> fixed-length vectors?
>
> The code is
>
> rll2xyz(r, θ, ϕ) = let cosθ = cos(θ)
>   [r * cosθ * cos(ϕ), r * cosθ * sin(ϕ), r * sin(θ)] # slower version
> end
>
>
> vs
>
> rll2xyz(r, θ, ϕ) = let cosθ = cos(θ)
>   (r * cosθ * cos(ϕ), r * cosθ * sin(ϕ), r * sin(θ)) # faster version
> end
>
>
>

[julia-users] Re: Immutable type with a function datatype

[Simon Danisch]

Am I missing something, or why isn't there this solution:

@enum Metric RIEMANNIAN LORENTZIAN # ...
immutable Sphere{Matric}
dim::Int
end
function metric(s::Sphere{RIEMANNIAN})

end
function metric(s::Sphere{LORENTZIAN})

end

Am Montag, 18. Januar 2016 16:08:38 UTC+1 schrieb Anonymous:
>
> Is the following code considered bad form in Julia?
>
> immutable Foo
> func::Function
> end
>
> foo = Foo(x->x^2)
> foo.func(3)
>
> This mimics the behavior of OOP since just like in OOP the internal method 
> cannot be changed (since the type is immutable).  Sometimes it really does 
> make the most sense to attach a function to an instance of a type, do I 
> take a performance hit doing things this way?
>

[julia-users] Re: Resources for GLAbstraction and the PerspectiveCamera method

[Simon Danisch]

In the case of GLAbstraction, with it's missing Documentation, it's best to 
just open an issue there!

I did that for you:  https://github.com/JuliaGL/GLAbstraction.jl/issues/33


Am Dienstag, 12. Januar 2016 14:06:45 UTC+1 schrieb kleinsplash:
>
> Hi,
>
> Is there an API or somewhere I can find info on the args of 
> PerspectiveCamera? Specifically for theta, translation, zoom, FOV and clip 
> distances. I know my understanding is not up to scratch because translation 
> and eyeposition seem similar, along with eyeposition and translation, zoom 
> and FOV etc.. Basically I am just confusing myself with what needs to go 
> where and ending up with a blank image render. 
>
> https://github.com/JuliaGL/GLAbstraction.jl/blob/master/src/GLCamera.jl
>
> Thx
>
 

[julia-users] Re: Moore foundation grant.

[Simon Danisch]

What is the functionality you fancy the most from ggplot and ggvis?

Am Mittwoch, 11. November 2015 02:24:27 UTC+1 schrieb Lampkld:
>
> Congratulations on the exciting news!
>
> I have played around with Julia A bit and love the language , But Found 
> Its Lacking Some robust stats/ml/data manipulation infrastructure. 
>
> Can anyone tell me if these areas are slated  to be worked on from the 
> grant money? I'm trying to get some foresight on the ecosystem so I can 
> make some decisions to use Julia for some projects.
>
> thanks !
>
>

[julia-users] Re: Convert result of get request from Requests.jl to an Image from Images.jl

[Simon Danisch]

I just tried the same and concluded, that we should add a Vector{Uint8} 
option to FileIO.

Am Mittwoch, 16. Dezember 2015 23:56:22 UTC+1 schrieb Christof Stocker:
>
> I am trying to find a way to convert a JPEG that I receive from a GET 
> request into an Image, but without creating a temporary file. Does 
> anyone know a good solution to this? I tried a couple of things such as 
> creating an IOStream out of the Array{UInt8,1} that I receive from the 
> GET request, but FileIO.load doesn't like that. 
>

[julia-users] Re: Interactive graph visualization in Julia

[Simon Danisch]

If you have the physics code ready, this should be really easy to do in 
GLVisualize.
I'm about to merge some important rebuild and writing up docs right now, 
which is why it's not released, but here is a teaser:
http://julialang.org/blog/2015/10/glvisualize/

Best,
Simon


Am Montag, 30. November 2015 13:25:40 UTC+1 schrieb Weijian Zhang:
>
> Dear all,
>
> I really like the force-directed graph example in d3 . 
> See http://bl.ocks.org/mbostock/4062045
> A user can drag the nodes and move the graph around.
>
> I am wondering if we can do something similar just with Julia? Is there a 
> Julia package for this?
>
> Thanks,
>
> Weijian
>
>
>

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

[Simon Danisch]

Sorry, that was the method definition, not the actual call!
So it's just an optional second argument!
Ah yeah, if implementing it from scratch is an option, ray tracing in its 
simple form is probably the most approachable (although still slow compared 
to visualizing it with OpenGL).


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: Using Meshes.ji

[Simon Danisch]

This is the best GLVisualize can do for you right meow:




You get this with:


using GLVisualize, FileIO, Colors, GeometryTypes, GLAbstractionwindow, 
renderloop = glscreen()obj = load("cat.obj")obj_vizz = visualize(obj, color=
RGBA{Float32}(0,0,0,0.1))point3d_vizz = visualize(vertices(obj), scale=
Vec3f0(0.01))axis = visualize(boundingbox(point3d_vizz).value, :grid)view
(obj_vizz)view(point3d_vizz)view(axis)renderloop()
A lot of improvements are on its way (like better camera, more consistent 
API and better axis), but this is still not out yet.

I'm not sure what would be possible with a combination of MeshIO and e.g. 
PyPlot, but I guess it could be better axis/labels + print quality, while 
being slower ;)
You quite likely need to do something like:

points = vertices(obj) #GeometryTypes exports vertices(...)
x,y,z = [p[1] for p in points], map(p->p[2], points), map(last, points) # 
three different ways of getting the x,y,z coordinates

and then go from there with the PyPlot/matplotlib docs.


Am Montag, 9. November 2015 15:55:57 UTC+1 schrieb kleinsplash:


Am Montag, 9. November 2015 15:55:57 UTC+1 schrieb kleinsplash:
>
> 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

[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: 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

[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?
>
>  
>

[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: 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: Triangular Dispatch, Integerm Range and UniformScaling error

[Simon Danisch]

As far as I know, triangular dispatch hasn't hit the shores yet (especially 
not in 0.4).
This sort of works, because I is actually a global variable in Base (I::
UniformScaling{Int64})
Try some other name, and it will tell you that the variable is undefined, 
as expected.

Best,
Simon

Am Sonntag, 22. November 2015 13:38:29 UTC+1 schrieb andrew cooke:
>
>
> Out of my depth here - no idea if this is a bug or me...
>
> julia> foo{I<:Integer,U<:UnitRange{I}}(u::U) = 1
> ERROR: TypeError: UnitRange: in T, expected T<:Real, got UniformScaling{
> Int64}
>
> Version 0.4.1-pre+22 (2015-11-01 00:06 UTC)
>
> Thanks, Andrew
>

[julia-users] Re: Please help me understand comprehensions for creating an array

[Simon Danisch]

This is not wanted but expected behavior, since type inference of non 
constant globals doesn't work very well (since the type can change 
unpredictable).
Two fixes: put your code in a function, or declare a and Nb as const.
This is directly 
related: http://docs.julialang.org/en/release-0.4/manual/performance-tips/

Best,
Simon

Am Montag, 26. Oktober 2015 11:35:06 UTC+1 schrieb Ferran Mazzanti:
>
> Hi folks, 
>
> I try to create an array of constant float64 values. Something I did was:
>
> a = 0.8;
> Nb = 100;
> p = zeros(Nb)
> for i in 1:Nb
> p[i] = a/Nb
>
end
>

> and typeof(p) returns
> Array{Float64,1}
> so far, so good :)
>
> But now I do the following instead to shorten things:
>
> a = 0.8;
> Nb = 100;
> p = [ a/Nb for i in 1:Nb]
>
> and typeof(p) returns
> Array{Any,1}
>
> which is *big* pain since I obviously wanted to create an array of floats. 
> So the questions are:
> a) Is this behaviour normal/ expected?
> b) If so, why is it? What is the logic of that? Isn't it true that the 
> normal behaviour, in the statistical sense of what *most* people would 
> expect, is to 
> get floats right away? Or am I missing something?
>
> I know I can always write 
> p = float64( [ a/Nb for i in 1:Nb ] )
> but anyway...
>
> Cheers,
>
> Ferran.
>
>
> Array{Float64,1}
>
>
>

[julia-users] Re: map() vs. comprehensions

[Simon Danisch]

It's a well known issue: https://github.com/JuliaLang/julia/issues/1864
Sadly, it's not that easy to fix.
There's a temporary fix in form of a 
package: https://github.com/timholy/FastAnonymous.jl
We might get fast anonymous functions in 0.5, though!

Am Mittwoch, 21. Oktober 2015 14:55:50 UTC+2 schrieb Ján Dolinský:
>
> Hi,
>
> I'd like to check which approach is a better one for the example below. 
> The task is rather simple, each string in vector "s" should be "surrounded" 
> by square brackets.
>
> e.g.
>
> s = AbstractString["as", "sdf", "qwer"] # s is typically a lot longer
>
> @time st1 = AbstractString[ "[" * i * "]" for i in s ]
>   0.57 seconds (16 allocations: 672 bytes)
> 3-element Array{AbstractString,1}:
>  "[as]"  
>  "[sdf]" 
>  "[qwer]"
>
> @time st2 = map(x->"["*x*"]", s)
>   0.002932 seconds (33 allocations: 2.035 KB)
> 3-element Array{ASCIIString,1}:
>  "[as]"  
>  "[sdf]" 
>  "[qwer]"
>
>
>
> The both expressions yield same results. I wonder whether from the 
> language design point of view one approach should be preferred over the 
> other. Comprehension here is considerably faster, I wonder why.
>
> Thanks,
> Jan
>
>

[julia-users] Re: Julia and Object-Oriented Programming

[Simon Danisch]

This design has at least 3 issues, since you can't have instances of a 
module.
In general:
I personally would value the discussion of why Julia needs more OOP 
constructs much more, If one can show that there are terrible flaws in 
Julia's model which are swiftly solvable with OOP.
My guess is, that the argument "I learned X and can't transfer it to Julia, 
so Julia needs to change", can't really convince anyone to start 
implementing something rather involved.

There are a lot of comments on people trying to bring OOP to Julia, which 
are best summarized by: give Julia's model a chance and don't stick to OOP 
- it will pay off.
And this kind of comment is pretty understandable in my opinion, since 
Julia is quite a sophistaced language with plenty of constructs to avoid 
OOP.
I don't see much value in OOP and Julia's multiple dispatch is actually one 
of the things that brought me here ( I exclusively worked with OOP 
languages before).
Besides the current flaws, I think it's a better model for numerical 
computing, it yields concise code, easier maintenance and it's easier to 
add feature to an existing code base than it is in OOP.

I think Julia should move forward by not mimicking OOP further, but instead 
improve the current model - there's lots to do already.
Wasting time by chasing after features from other languages will make it 
much harder to turn Julia into a well rounded, sound language. (this only 
applies to feature that get chased without a concrete problem)

Best,
Simon


Am Sonntag, 18. Oktober 2015 14:41:58 UTC+2 schrieb Sisyphuss:
>
> When I'm learning Julia, I am always thinking what is the correct way to 
> do OOP in this language. It seems to me that what I learned in C++ does not 
> apply in Julia.
>
> It took me long to realize that the equivalent of Class of C++ in Julia is 
> not Type, but Module. Module is the basic function unit in Julia.
>
> Thus, a Class in Julia is like
> module ClassName # class Name {
> using# include<> // should be outside
> import   # include<>
> export  function # public  function;
> var = 1  # private static var;
> end  # }
> This provides the same structure as C++.
>
> However, this design has two issues:
> 1) The visit control is not as fine-grained as in C++, the encapsulation 
> is not strict;
> 2) Variables at the top level of a module are global variables.
>
> These two points are closely correlated. If we let module have private 
> variables, then they are not too different from local variables, ans thus 
> can be type inferred.
> I think this is a natural way to do OOP with Julia.
>
>
>
>

[julia-users] Re: [ANN] JuliaIO and FileIO

[Simon Danisch]

So your biggest concern doesn't seem to be a problem:
You can just do query("file.ext") and get back the format without loading the 
file. I see that in the way you want to use it, a hierarchy would be a nice 
addition.
You could just do this:
myload(path) = myload(query(path))
myload{T <: VectorGraphic}(::File{T}) = ...
Right now, VectorGraphic would need to be a union of the formats, though.

We do dynamically load libraries to completly decouple the loading from the IO 
library, so that a new user doesn't need to know what the best IO library is 
for his format. Since he doesn't know, FileIO must know.

When you have an IO library already loaded, FileIO might use it. So far it 
depends on the priority of that library, if FileIO loads another one. Maybe I 
should change that, so that FileIO determines first if any of the IO candidates 
is already loaded and if so, it just uses that library.

[julia-users] Re: [ANN] JuliaIO and FileIO

[Simon Danisch]

@MA Laforge

This looks a little bit like our first prototypes, with the addition of an 
hierarchical format system.
I'm not sure if we really need a hierarchy. It seems hard to program 
against some abstract type in this area, since you get so many edge cases.
It might be useful in some cases, but at least for now, FileIO works pretty 
well without it.
In the end, I would rather like to have the hierarchy in the Julia objects 
that get returned by load (e.g. AbstractString <: UTF8String etc)

Please consider the following points, that have lead to the current design:
- There are many IO libraries which should get dynamically loaded when the 
format is detected (first argument for registry)
- we utilize magic bytes to recognize file formats (second argument for 
registry)
- there are multiple IO libraries for the same formats and we need to 
choose one dynamically
- we use dispatch in the same way, but just inside one module, to better 
resolve ambiguities

>but something seems a little off about how I use/generate objects

I'm not really sure what you mean by that.

Best,
Simon

Am Samstag, 4. April 2015 17:41:14 UTC+2 schrieb Simon Danisch:
>
> Hi there,
>
> FileIO has the aim to make it very easy to read any arbitrary file.
> I hastily copied together a proof of concept by taking code from Images.jl.
>
> JuliaIO is the umbrella group, which takes IO packages with no home. If 
> someone wrote an IO package, but doesn't have time to implement the FileIO 
> interface, giving it to JuliaIO might be a good idea in order to keep the 
> package usable.
>
> Concept of FileIO is described in the readme:
>
> Meta package for FileIO. Purpose is to open a file and return the 
> respective Julia object, without doing any research on how to open the file.
>
> f = file"test.jpg" # -> File{:jpg}read(f) # -> Imageread(file"test.obj") # -> 
> Meshread(file"test.csv") # -> DataFrame
>
> So far only Images are supported and MeshIO is on the horizon.
>
> It is structured the following way: There are three levels of abstraction, 
> first FileIO, defining the file_str macro etc, then a meta package for a 
> certain class of file, e.g. Images or Meshes. This meta package defines the 
> Julia datatype (e.g. Mesh, Image) and organizes the importer libraries. 
> This is also a good place to define IO library independant tests for 
> different file formats. Then on the last level, there are the low-level 
> importer libraries, which do the actual IO. They're included via Mike Innes 
> Requires <https://github.com/one-more-minute/Requires.jl> package, so 
> that it doesn't introduce extra load time if not needed. This way, using 
> FileIO without reading/writing anything should have short load times.
>
> As an implementation example please look at FileIO -> ImageIO -> 
> ImageMagick. This should already work as a proof of concept. Try:
>
> using FileIO # should be very fast, thanks to Mike Innes Requires 
> packageread(file"test.jpg") # takes a little longer as it needs to load the 
> IO libraryread(file"test.jpg") # should be fastread(File("documents", 
> "images", "myimage.jpg") # automatic joinpath via File constructor
>
> Please open issues if things are not clear or if you find flaws in the 
> concept/implementation.
>
> If you're interested in working on this infrastructure I'll be pleased to 
> add you to the group JuliaIO.
>
>
> Best,
>
> Simon
>

[julia-users] Re: Combining arrays in an R enlist like manner

[Simon Danisch]

you can also try vcat(vec...)!

Am Montag, 12. Oktober 2015 23:33:19 UTC+2 schrieb Ben Ward:
>
> Hi,
>
> In R, if you have a list, containing two vectors that are - say - numeric, 
> you can unlist them into one vector:
>
> > a <- list(c(1,2,3,4,5), c(7,8,9,10,11))
>
> > a
>
> [[1]]
>
> [1] 1 2 3 4 5
>
>
>
> [[2]]
>
> [1]  7  8  9 10 11
>
>
>
> > unlist(a)
>
>  [1]  1  2  3  4  5  7  8  9 10 11
>
> > 
>
>
> Is there a convenient way to do this with vectors in Julia? Say I have a 
> Vector{Vector{Int}}:
>
> *vec = Vector{Int}[[1,2,3,4,5], [6,7,8,9,10]]*
>
> I can only think of creating a new vector and through some 
> loopiness, filling it in. 
>
> Thanks,
> Ben.
>

[julia-users] Re: Error occurred when I Push! this to Array{Any}

[Simon Danisch]

This should work and nowadays overwritting push! should throw an error, so 
it's unlikely that you did this.
What usually helps is to give a minimal reproducable example, e.g. via a 
github gist.

Best,
Simon

Am Donnerstag, 8. Oktober 2015 12:48:38 UTC+2 schrieb cheng wang:
>
> Hello everyone,
>
> I got this error by the compiler (Julia 0.4rc):
> ERROR: LoadError: MethodError: `push!` has no method matching 
> push!(::Array{Any,1}, 
> ::Tuple{Array{ASCIIString,1},Array{ASCIIString,1},TestFilter})
>
> As far as I see, this pushing should be ok. Could someone help ?
>
> Best,
> Cheng
>

[julia-users] Re: Use preallocation, A[:] vs A, and wrapping and passing collections of variables as types

[Simon Danisch]

Well that's how assignment usually works.
The *[:]* is something else and is redirecting you to setindex!.
*x[:] = 42* is the same as *setindex(a, 42, :)*, which is the same as 
*setindex(a, 
42, 1:length(a))*

So it's assigning to the indexes of that vector, which means it's reusing 
it.
Maybe have a look at array_indexing 
 ?

Am Mittwoch, 7. Oktober 2015 22:25:00 UTC+2 schrieb Patrick Kofod Mogensen:
>
> So I asked a question over at 
> https://github.com/lindahua/Devectorize.jl/issues/48#issuecomment-146307811 
> and it seems that I have got something completely wrong.
>
> It seems that the following
>
> index = rand(8000)
> phat = zeros(8000)
>
> phat = 1./(1+exp(-index))
>
> binds the output of the calculation on the rhs to a _new_ vector phat, not 
> the original vector. This really means I have misunderstood 
> preallocation/re-using memory in Julia completely! @blakejohnson suggests 
> that I use
>
> phat[:] = 1./1+(exp(-index))
>
> instead. As this puts the calculations in the already preallocated vector 
> phat. 
>
> Question 1) Can I learn more about this in the documentation ? I'm having 
> a hard time finding anything, probably because [:] is hard to use as a 
> search phrase, and I'm not sure what concepts to search for.
>
>
>
> I often wrap my variables in a type, but this seems like an extremely bad 
> idea in combination with devec. I have taken Blake Johnsons examples from 
> github, and added a few 
> https://gist.github.com/pkofod/fb6c4b8ffcca1a056363
>
> Question 2) What is it that makes test4() and test6() run so slowly?  
> test1() and test3() seems to perform equivalently fast. I use this kind of 
> setup all the time, and I am surprised that this method allocates so much 
> memory.
>
> Bad news: I've been doing Julia ALL wrong!
> Good news: Time to learn some more!
>

[julia-users] Re: Is there a way to replace f(object, args...) with object.f(args...)?

[Simon Danisch]

There are a lot of things "one could do" ;) Can you give some appealing 
reasons, why someone should invest his/her time into this?

Best,
Simon


Am Mittwoch, 7. Oktober 2015 17:13:33 UTC+2 schrieb cheng wang:
>
> Hello everyone,
>
> In some cases, I would like to make a function belongs to an object.
> In classical OO, we do something like object.f(args...).
> In Julia, we could do it like this: f(object, args...).
>
> So I was wandering if there is some way to do following:
> I write object.f(args...), while julia could know it actual means 
> f(object, args...).
>
> One naive way to implement this is in two steps:
> first, the compiler search for a field of object equal to f, if it's not 
> found,
> then, compiler search for a function like f, and the invoke it.
>
> Looking forward for your opinions!
>

[julia-users] Re: When are @generated functions useful?

[Simon Danisch]

>Short answer: if you don't need them, don't use them. 

@tim holy is right! This should be the first thing to know about @generated 
functions. 
They make quite a few things difficult for the compiler and probably won't 
exist very long in their current form. 

But they're great for prototyping optimizations, which should rather be 
left to the compiler in the future.
They're also useful when you want to inline computations at first call into 
the frechly compiled function.


Am Montag, 5. Oktober 2015 21:34:43 UTC+2 schrieb Matt:
>
> Most of the time I read Julia code with generated functions, the goal is loop 
> unrolling  (included the 
> main example in the documentation 
> 
> ).
> What are other good cases to use @generated functions?
>

[julia-users] Re: StackOverflow error while attempting to "lift" Nullables

[Simon Danisch]

I can't reproduce it on 0.4.
But I have an improvements:
https://gist.github.com/SimonDanisch/92e4500a0198c81912f5#file-jl
Map works perfectly fine with tuples ;)

>When I type in anything else into the interpreter in this case f

what f?


Am Montag, 5. Oktober 2015 15:27:45 UTC+2 schrieb data.pu...@gmail.com:
>
> I am trying to "lift" base functions to allow Nullable types to be used 
> natively I am getting a stack-overflow error with the following code:
>
> # Test with just a few functions
> import Base: get, +, -, /, *, ^
>
> # Function symbols to be lifted
> funs = [:+, :-, :/, :*, :^]
>
> # Generic get function
> # Assume appropriate get functions are written for each type
> function get{T}(x::T)
>   x
> end
>
> S = Union{Symbol, Expr}
>
> # Lifter function
> function lift(fun_name::S, new_type::S)
>   quote
> function $fun_name{T}(x...;t::T=x)
> y = Array(Any, length(x))
> for i in 1:length(x)
>   y[i] = get(x[i])
> end
> ret = $fun_name(y...)
> return $new_type(ret)
> end
>   end
> end
>
> # Then lift the functions
> for i in funs
>   eval(lift(i, :Nullable))
> end
>
> When I type in anything else into the interpreter in this case f, I get 
> the error message:
>
> WARNING: Caught an exception in the keymap:
> ERROR: StackOverflowError:
> ERROR: UndefVarError: f not defined
>
> Another odd thing about this error is that it doesn't always happen right 
> away and sometimes doesn't happen at all which is odd. I have also tried 
> loading the code by include(scriptfile.jl) but the same thing happens
>
> My Environment: Version Info: 0.5.0-dev+433 (2015-09-29 15:39 UTC), Ubuntu 
> 14.04 x86_64-linux-gnu
>
> DP
>
>
>

[julia-users] Re: StackOverflow error while attempting to "lift" Nullables

[Simon Danisch]

It works.
But using any for x in your new function definition seems very prone to 
stack overflow errors.
What happens if you do:

function $fun_name{T}(x::$new_type{T}...)
or
function $fun_name{T}(x::$new_type...)

I'm not sure how well Julia handles your *t::T=x.* For what is this even 
needed?
You could also do:
function $fun_name{T <: $new_type}(x::T...)

Am Montag, 5. Oktober 2015 15:27:45 UTC+2 schrieb data.pu...@gmail.com:
>
> I am trying to "lift" base functions to allow Nullable types to be used 
> natively I am getting a stack-overflow error with the following code:
>
> # Test with just a few functions
> import Base: get, +, -, /, *, ^
>
> # Function symbols to be lifted
> funs = [:+, :-, :/, :*, :^]
>
> # Generic get function
> # Assume appropriate get functions are written for each type
> function get{T}(x::T)
>   x
> end
>
> S = Union{Symbol, Expr}
>
> # Lifter function
> function lift(fun_name::S, new_type::S)
>   quote
> function $fun_name{T}(x...;t::T=x)
> y = Array(Any, length(x))
> for i in 1:length(x)
>   y[i] = get(x[i])
> end
> ret = $fun_name(y...)
> return $new_type(ret)
> end
>   end
> end
>
> # Then lift the functions
> for i in funs
>   eval(lift(i, :Nullable))
> end
>
> When I type in anything else into the interpreter in this case f, I get 
> the error message:
>
> WARNING: Caught an exception in the keymap:
> ERROR: StackOverflowError:
> ERROR: UndefVarError: f not defined
>
> Another odd thing about this error is that it doesn't always happen right 
> away and sometimes doesn't happen at all which is odd. I have also tried 
> loading the code by include(scriptfile.jl) but the same thing happens
>
> My Environment: Version Info: 0.5.0-dev+433 (2015-09-29 15:39 UTC), Ubuntu 
> 14.04 x86_64-linux-gnu
>
> DP
>
>
>

[julia-users] Re: [ANN] ShaderToy.jl

[Simon Danisch]

Well, Julia is not directly at work here and its not really about ray 
tracing ;) You need to write the shader in GLSL 
<https://en.wikipedia.org/wiki/OpenGL_Shading_Language>, which is more 
C-like.
That said, I'm pretty sure that the ray tracing examples are faster than 
most of the ray tracing examples listed in the links.
It runs even on on-board GPU's in real time. The algorithms allow only for 
very limited ray tracing, but work nicely on the GPU.

Am Donnerstag, 24. September 2015 01:21:16 UTC+2 schrieb Simon Danisch:
>
> Hi,
> you want to try out GPU accelerated ray tracing? You want some quick and 
> easy start for GPU accelerated fractal rendering?
> You can do this quite easily now!
> ShaderToy <https://github.com/SimonDanisch/ShaderToy.jl> allows you to 
> only specify a fragmentshader, which is an OpenGL program which can execute 
> arbitrary code per pixel(fragment).
> Its based on GLVisualize and basically the Julia native version of: 
> https://www.shadertoy.com/
> I copied a few examples to get you started. Just click on the gifs in the 
> README to see the fragment shader that produced the image.
> The installation is still a little bit wonky, but should mostly work if 
> the script executes without error.
> If it doesn't work, please open an issue. This will help me to make the 
> release of GLPlot and GLVisualize a lot smoother!
>
> Best,
> Simon
>

[julia-users] Re: Julia code 5x to 30x slower than Matlab code

[Simon Danisch]

There is no question that Julia needs more work. This applies to offering 
speedy primitives and also doing more optimizations.
But I think you get one thing wrong.
The magic lays in the fact, that in Julia you have the chance to write the 
vectorized implementation that are offered by languages like R or Matlab in 
Julia itself.
In that case Julia still offers much more comfort than the usual suspects 
(C/C++ fortran). It's not only more comfortable but also makes the high 
performance code easier to maintain.
And in theory, that gives you more room for optimizations, since the 
compiler does not have to optimize outside the border of the language.

It also means, that some person like you and me can go out there, write 
some functions that incoorperates the speed improvement achieved in this 
thread and offer it to other people so they can write higher level and fast 
code in the end.
That's basically what the Matlab team does (in C++ and Java) and they have 
had much more time and resources to do this.
So no, just because Matlab already has some speedy, optimized primitives 
written in C++ and better loop fusion, which Julia still doesn't have, 
Julia does not become irrelevant.



Am Samstag, 19. September 2015 19:50:50 UTC+2 schrieb Adam:
>
> Hi, I'm a novice to Julia but have heard promising things and wanted to 
> see if the language can help with a problem I'm working on. I have some 
> Matlab code with some user-defined functions that runs a simulation in 
> about ~1.4 seconds in Matlab (for a certain set of parameters that 
> characterize a small problem instance). I translated the code into Julia, 
> and to my surprise the Julia code runs 5x to 30x slower than the Matlab 
> code. I'll be running this code on much larger problem instances many, many 
> times (within some other loops), so performance is important here. 
>
> I created a GitHub gist that contains a stripped-down version of the Julia 
> code that gets as close to (as I can find) the culprit of the problem. The 
> gist is here: https://gist.github.com/anonymous/010bcbda091381b0de9e. A 
> quick description: 
>
>- set_up.jl sets up parameters and other items.
>- set_up_sim.jl sets up items particular to the simulation.
>- simulation.jl runs the simulation.
>- calc_net.jl, dist_o_i.jl, and update_w.jl are user-defined functions 
>executed in the simulation. 
>
>
> On my laptop (running in Juno with Julia version 0.3.10), this code yields:
> elapsed time: 43.269609577 seconds (20297989440 bytes allocated, 38.77% gc 
> time)
> elapsed time: 38.500054653 seconds (20291872804 bytes allocated, 40.41% gc 
> time)
> elapsed time: 40.238907235 seconds (20291869252 bytes allocated, 39.44% gc 
> time)
>
> Why is so much memory used, and why is so much time spent in garbage 
> collection?
>
> I'm familiar with 
> http://docs.julialang.org/en/release-0.3/manual/performance-tips/ and 
> have tried to follow these tips to the best of my knowledge. One example of 
> what might be seen as low-hanging fruit: I tried removing the type 
> declarations from my functions, but this actually increased the run-time of 
> the code by a few seconds. Also, other permutations of the column orders 
> pertaining to D, T, and I led to slower performance. 
>
> I'm sure there are several issues at play here-- I'm just using Julia for 
> the first time. Any tips would be greatly appreciated. 
>

[julia-users] Re: Same native code, different performance

[Simon Danisch]

I cannot reproduce this on RC2.
Probably the inlining fails for f on some julia version?

Am Donnerstag, 24. September 2015 18:04:18 UTC+2 schrieb Kristoffer 
Carlsson:
>
> Can someone explain these results to me.
>
> Two functions: 
> f(x) = @fastmath cos(x)^3
> f_float(x) = @fastmath  cos(x)^3.0
>
>
> Identical native code:
>
> julia> code_native(f, (Float64,))
> .text
> Filename: none
> Source line: 1
> pushq   %rbp
> movq%rsp, %rbp
> movabsq $cos, %rax
> Source line: 1
> callq   *%rax
> movabsq $140084090479408, %rax  # imm = 0x7F67DE73A330
> vmovsd  (%rax), %xmm1
> movabsq $pow, %rax
> callq   *%rax
> popq%rbp
> ret
>
> julia> code_native(f_float, (Float64,))
> .text
> Filename: none
> Source line: 1
> pushq   %rbp
> movq%rsp, %rbp
> movabsq $cos, %rax
> Source line: 1
> callq   *%rax
> movabsq $140084090501536, %rax  # imm = 0x7F67DE73F9A0
> vmovsd  (%rax), %xmm1
> movabsq $pow, %rax
> callq   *%rax
> popq%rbp
> ret
>
> Still a large difference in performance:
>
> function bench(N)
> @time for i = 1:N
> f(π/4)
>end
>@time for i = 1:N
>f_float(π/4)
>end
> end
>
> julia> bench(10^6)
>   0.062536 seconds
>   0.010077 seconds
>
> Secondly, can someone explain why there should be a performance difference 
> at all? Is power by a float which is == an int defined differently? IEEE 
> shenanigans?
>

[julia-users] Re: [ANN] ShaderToy.jl

[Simon Danisch]

I'm not sure what you're talking about.
ShaderToy.jl just makes it easy to execute an OpenGL shader written in 
GLSL, which then runs directly on the GPU. 
Running an OpenGL shader, animating some variables and displaying the 
results requires some setup, which is the part done in Julia.

Ray tracing just happens to be a much applied technology on shadertoy.com, 
which is why the examples I copied use ray tracing. 
If you go to shadertoy.com, you will see a lot of other stuff.
There are worlds between these simple toy ray tracing implementation and 
IRay from nvidia. It's not comparable at all.



Am Donnerstag, 24. September 2015 01:21:16 UTC+2 schrieb Simon Danisch:
>
> Hi,
> you want to try out GPU accelerated ray tracing? You want some quick and 
> easy start for GPU accelerated fractal rendering?
> You can do this quite easily now!
> ShaderToy <https://github.com/SimonDanisch/ShaderToy.jl> allows you to 
> only specify a fragmentshader, which is an OpenGL program which can execute 
> arbitrary code per pixel(fragment).
> Its based on GLVisualize and basically the Julia native version of: 
> https://www.shadertoy.com/
> I copied a few examples to get you started. Just click on the gifs in the 
> README to see the fragment shader that produced the image.
> The installation is still a little bit wonky, but should mostly work if 
> the script executes without error.
> If it doesn't work, please open an issue. This will help me to make the 
> release of GLPlot and GLVisualize a lot smoother!
>
> Best,
> Simon
>

[julia-users] [ANN] ShaderToy.jl

[Simon Danisch]

Hi,
you want to try out GPU accelerated ray tracing? You want some quick and 
easy start for GPU accelerated fractal rendering?
You can do this quite easily now!
ShaderToy  allows you to only 
specify a fragmentshader, which is an OpenGL program which can execute 
arbitrary code per pixel(fragment).
Its based on GLVisualize and basically the Julia native version 
of: https://www.shadertoy.com/
I copied a few examples to get you started. Just click on the gifs in the 
README to see the fragment shader that produced the image.
The installation is still a little bit wonky, but should mostly work if the 
script executes without error.
If it doesn't work, please open an issue. This will help me to make the 
release of GLPlot and GLVisualize a lot smoother!

Best,
Simon

[julia-users] Re: method_exist inconsistent with dispatch ?

[Simon Danisch]

you're passing types to next, and it points out correctly: no method 
matching next(::*Type*{Number}, ::*Type*{Any})
method_exist on the other hands takes types as its arguments so your query 
should look like this:
*method_exists( next, Tuple{DataType, DataType } )* or *method_exists( 
next, Tuple{ Type{Number}, Type{Any} } )*
which correctly returns false.

Am Mittwoch, 16. September 2015 19:16:50 UTC+2 schrieb Michael Francis:
>
> I was executing the following on 0.4 
>
> julia> next( Number, Any )
> ERROR: MethodError: `next` has no method matching next(::Type{Number}, 
> ::Type{Any})
> Closest candidates are:
>   next(::SimpleVector, ::Any)
>   next{T}(::StepRange{T,S}, ::Any)
>   next{T}(::UnitRange{T}, ::Any)
>   ...
>
> julia> method_exists( next, Tuple{ Number, Any } )
> true
>
> This seems incorrect?
>

[julia-users] Re: Anti-Grain Geometry and other alternatives

[Simon Danisch]

@Tim Holy, the wait has been long enough ;)
By the way, what graphic card do you have? 
It's quite possible that it works on windows without a new machine.
- given that this is an acceptable temporary solution for you :)

Am Dienstag, 15. September 2015 18:01:37 UTC+2 schrieb Tom Breloff:
>
> Does anyone in the community have experience with Anti-Grain Geometry as 
> an alternative to Cairo?  
>
> http://www.antigrain.com/
>
> I know very little about it, but it could possibly be faster and more 
> stable than Cairo for 2D graphics, with a lighter dependency footprint.  It 
> is a C++ package, so this is something that will depend on a stable Cxx.jl.
>
> Are there any other similar frameworks that could be more performant than 
> Cairo for intense 2D simulations and realtime plots?  I suppose OpenGL, 
> although my experience with OpenGL is that it's hard to make the graphics 
> pretty.  Thoughts?
>

[julia-users] Re: Anti-Grain Geometry and other alternatives

[Simon Danisch]

I've looked at most techniques and settled for distancefield based 
techniques for OpenGL.
I'm in the middle of putting everything together but right now I've just 
finished support for different markers, styles (glow || outlined || filled) 
and full unicode rendering.
You can place and rotate them however you want ;)
Lines rendered with the same technique are mostly there. They'll support 
the same styles and stuff like dotted lines, etc.
To get an idea of how the technique compares to Agg and Skia you can look 
here: https://www.mapbox.com/blog/drawing-antialiased-lines/ (there is a 
graphic with exactly that comparison, WebGL is the technique I'm talking 
about).
What's missing with that approach is hinting and LCD aware anti aliasing. 
I've seen people add these techniques to distance field rendering 
pipelines, so I'm optimistique that we can add them later on when asked for.
So far I'm positively surprised by the quality. I've made some screenshot 
if you're 
interested: 
https://drive.google.com/folderview?id=0B9vNkD-OdlWNV3dCUWJyeTk3aDA=sharing

The speed is top notch, giving me smooth rendering of 1 million static 
particles and 50 thousand animated particles on my pretty weak ultrabook 
(i3 with hd 4400 - 1 million particles render in roughly 0.03s)
It supports hit testing calculated on the GPU( exposed via Reactive). Any 
pixel on the screen can be traced back to its origin.
I've added quite a lot of support for selection and editing the data 
directly on the GPU, which enabled me to implement complex stuff like text 
editing and 3D gizmos.
I hope that I can release all this in roughly one week.

By the way, it's all written in Julia and OpenGL with very little 
dependencies ;)

Best,
Simon


Am Dienstag, 15. September 2015 18:01:37 UTC+2 schrieb Tom Breloff:
>
> Does anyone in the community have experience with Anti-Grain Geometry as 
> an alternative to Cairo?  
>
> http://www.antigrain.com/
>
> I know very little about it, but it could possibly be faster and more 
> stable than Cairo for 2D graphics, with a lighter dependency footprint.  It 
> is a C++ package, so this is something that will depend on a stable Cxx.jl.
>
> Are there any other similar frameworks that could be more performant than 
> Cairo for intense 2D simulations and realtime plots?  I suppose OpenGL, 
> although my experience with OpenGL is that it's hard to make the graphics 
> pretty.  Thoughts?
>

[julia-users] Re: Anti-Grain Geometry and other alternatives

[Simon Danisch]

Good question! Best would be to wait a little more. I plan to release a 
tutorial video, explaining all the new features. 
Don't expect something too polished, though. It's good to have the 
primitives working, but turning it into a well-rounded package will still 
require quite a bit of time.
I hope I can turn GLVisualize into a backend for Gadfly, to profit from 
Gadfly's rich functionality. That would leverage the 2D part a bit.
Daniel has done quite a bit of work to align everything nicely and make 
plots look great. I really don't want to duplicate that work ;)

Am Dienstag, 15. September 2015 18:01:37 UTC+2 schrieb Tom Breloff:
>
> Does anyone in the community have experience with Anti-Grain Geometry as 
> an alternative to Cairo?  
>
> http://www.antigrain.com/
>
> I know very little about it, but it could possibly be faster and more 
> stable than Cairo for 2D graphics, with a lighter dependency footprint.  It 
> is a C++ package, so this is something that will depend on a stable Cxx.jl.
>
> Are there any other similar frameworks that could be more performant than 
> Cairo for intense 2D simulations and realtime plots?  I suppose OpenGL, 
> although my experience with OpenGL is that it's hard to make the graphics 
> pretty.  Thoughts?
>

[julia-users] Re: I don't understand the behaviour of macros and let.

[Simon Danisch]

Well, m is not a global because of the let blog. Because you evaluate that 
statement, m needs to be in the scope of the macro, which it is only for 
msg (msg is global).
You probably don't want to eval in a macro, and just return an expression 
instead. That's what macros do, take an expression and replace that 
expression at compile time.
e.g.
macro example(var)
:(dump($var))
end

So this:
let m = "hola"
   @example m
   end
will be expanded at compile time to:
let m = "hola"
   dump(m)
end
so they're in the same scope now.
You might find macroexpand useful: macroexpand(:( @mymacro my_expr)))

Am Samstag, 12. September 2015 23:45:23 UTC+2 schrieb Diego Javier Zea:
>
> I don't understand why am I getting this error? My macros can not find the 
> variables inside *let* blocks. How Can I fix it? Thanks in advance
>
> julia> macro example(var)
>dump(var)
>@eval dump($var)
>end
>
> julia> msg = "hola"
> "hola"
>
> julia> @example msg
> Symbol msg
> ASCIIString "hola"
>
> julia> let m = "hola"
>@example m
>end
> Symbol m
> ERROR: UndefVarError: m not defined
>  in eval_user_input at REPL.jl:64
>  [inlined code] from REPL.jl:93
>  in anonymous at task.jl:68
>
>
>
>
>

[julia-users] Re: [ANN] FixedSizeArrays

[Simon Danisch]

Thanks =)
It should be tagged, although the last tag does not have the newest 
commits. I'll tag a new version.

Best,
Simon
Am Samstag, 5. September 2015 23:09:20 UTC+2 schrieb Simon Danisch:
>
> Hi everyone,
>
> FixedSizeArrays <https://github.com/SimonDanisch/FixedSizeArrays.jl>offers 
> an abstract interface to turn arbitrary types into arrays of fixed size 
> with most array functionality defined.
> The types Point, Vec and Mat are already included per default.
>
> Advantages are that they're stack allocated, often have less overhead than 
> Julia arrays and you can dispatch on the dimension.
> Disadvantages are, that they're still immutable (advantage?!), 0.4 only 
> and I still have some problems with compilation times for first calls of 
> the function even with precompilation.
> Also the constructor code is pretty messy, as it is currently relatively 
> hard to write constructors for abstract types.
>
> In the future I want to move this into base, by simply inheriting from 
> AbstractArray, which is currently not possible for immutable arrays. 
> Major blocking issue for this is my restricted time and #11610 
> <https://github.com/JuliaLang/julia/issues/11610>.
> Also, we might use Ref{NTuples} for fixed size arrays in the future, which 
> would resolve quite a few issues.
> It's pretty fast but might get even faster as soon as NTuple gets 
> translated into LLVM's vector type (currently array).
>
> Here's a short code sample:
>
> immutable RGB{T} <: FixedVectorNoTuple{T, 3}
> r::T
> g::T
> b::Tendimmutable Vec{N, T} <: FixedVector{N, T} # defined in GeometryTypes.jl
> _::NTuple{N, T}end
> Vec{3, Float32}(0) # constructor with 1 argument already definedrand(Vec{3, 
> Int})+sin(Vec(0,2,2)) # a lot of array functions are already defined#There is 
> also a matrix typeeye(Mat{3,3,Float32}) * rand(Vec{3, Float32}) # will also 
> "just work"
> a = Vec(1,2,3)[1:2] # returns (1,2)
>
>
> Best,
> Simon
>

[julia-users] Re: JuliaCon 2015 videos

[Simon Danisch]

Thanks for all the hard work and making JuliaCon what it was!!
I had a great time there :)


Am Donnerstag, 13. August 2015 19:22:09 UTC+2 schrieb Viral Shah:
>
> Folks, 
>
> I am happy to announce that the videos are almost all ready, and I will 
> start posting them in batches. I am starting with Jeff’s talk on our 
> Youtube channel: 
>
> https://www.youtube.com/user/JuliaLanguage 
>
> Direct link to the video: 
>
> https://www.youtube.com/watch?v=xUP3cSKb8sI 
>
> -viral 
>
>
>
>

[julia-users] [ANN] FixedSizeArrays

[Simon Danisch]

Hi everyone,

FixedSizeArrays offers 
an abstract interface to turn arbitrary types into arrays of fixed size 
with most array functionality defined.
The types Point, Vec and Mat are already included per default.

Advantages are that they're stack allocated, often have less overhead than 
Julia arrays and you can dispatch on the dimension.
Disadvantages are, that they're still immutable (advantage?!), 0.4 only and 
I still have some problems with compilation times for first calls of the 
function even with precompilation.
Also the constructor code is pretty messy, as it is currently relatively 
hard to write constructors for abstract types.

In the future I want to move this into base, by simply inheriting from 
AbstractArray, which is currently not possible for immutable arrays. 
Major blocking issue for this is my restricted time and #11610 
.
Also, we might use Ref{NTuples} for fixed size arrays in the future, which 
would resolve quite a few issues.
It's pretty fast but might get even faster as soon as NTuple gets 
translated into LLVM's vector type (currently array).

Here's a short code sample:

immutable RGB{T} <: FixedVectorNoTuple{T, 3}
r::T
g::T
b::Tendimmutable Vec{N, T} <: FixedVector{N, T} # defined in GeometryTypes.jl
_::NTuple{N, T}end
Vec{3, Float32}(0) # constructor with 1 argument already definedrand(Vec{3, 
Int})+sin(Vec(0,2,2)) # a lot of array functions are already defined#There is 
also a matrix typeeye(Mat{3,3,Float32}) * rand(Vec{3, Float32}) # will also 
"just work"
a = Vec(1,2,3)[1:2] # returns (1,2)


Best,
Simon

[julia-users] Re: Declare user-defined type variable but *not* initialize it

[Simon Danisch]

I'm not a big fan of* p = Point(); p.x = 1.0*, since it might sneak in 
undefined reference errors, which seems totally avoidable to me.
You can always do this, after all:
*x = compute_x()*
**
*y = compute_y()*
**
*Point(x,y)*

If performance is your concern, I'm pretty sure that LLVM is smart enough 
about it to not make this perform any slower.

Am Freitag, 4. September 2015 18:49:47 UTC+2 schrieb Ferran Mazzanti:
>
> Dear all,
> I was wonder if it is possible to do in Julia what I can do in other 
> languages, such as define a user type, as for instance
>
> type Point
>   x::Float64
>   y::Float64
> end
>
> and then define a new varible of that type, but do not initialize it, as in
>
> z::Point
>
> which obviously doesn't work (unless in the local scope of a function, 
> with z being passed as an argument to the function).
>
> I ask because I am used to use pointers (in other languages), declare the 
> pointer, allocate room for the object, and  then
> use an instance of the object and initialize the different components in 
> the order I like. I mean to say something of the form, inventing my
> own instructions :)
>
> ype Point
>   x::Float64
>   y::Float64
> end
> z::Point
> allocate(z)
> z.y = 2.0
> z.x = 3.1
>
> In Julia the only way I know to initialize the object is to pass values to 
> it in exactly the same order the different fields appear in the
> type deffinition. Look as I have changed this order in my invented piexe 
> of code...
>
> Any hint appreciated.
>
> Thanks.
>

[julia-users] Re: Define functions in loop

[Simon Danisch]

this case is pretty simple:
for letter in [:A,:B]
 @eval begin
function $letter(T::test)
T.$letter
end
 end
end
@eval == eval(quote  end) == eval( :(  ) )
Am Mittwoch, 2. September 2015 11:16:53 UTC+2 schrieb Robert DJ:
>
> Hi,
>
> I have a situation where a number of functions differ so little that it 
> would make sense to define them by a loop. 
> I don't know if I am using the correct jargon, but here is a small example 
> to illustrate:
>
> type test
> A::Int
> B::Int
> end
>
> function A(T::test)
> T.A
> end
>
> function B(T::test)
> T.B
> end
>
>
> If possible, I would like to define the functions A and B along these 
> lines:
>
> for letter in [A,B]
> function letter(T::Test)
> T.letter
> end
> end
>
>
> Thanks,
>
> Robert
>

[julia-users] Re: Need help optimizing my implementation of Selection Sort

[Simon Danisch]

Here are some code snippets, which apply the knowledge from the performance 
tip section 
http://julia.readthedocs.org/en/latest/manual/performance-tips/
https://gist.github.com/SimonDanisch/a36dcc824034c43b5d78#file-selectionsort-jl
Spoiler: the fastest version is 15 times faster.
The one with boundchecks is 8-10 times faster, which is on eye level with 
java.
That's not a big surprise, since Julia and Java are often equally fast, but 
you would need to use the unsafe collection to get rid of boundchecks in 
Java, from what I know.

Am Samstag, 29. August 2015 18:20:05 UTC+2 schrieb Ravi Mohan:

 So I wrote an inplace selection sort in Julia,  to compare its performance 
 against a Java counterpart,
 Here is the code

 function selectionSort!{T}(v::AbstractVector{T}, f)
 
 n = length(v)

 for i=1:n-1
 min  = i
 for j=i+1:n
if f(v[j], v[min])
  min = j
end
 end

 tmp = v[i]
 v[i] = v[min]
 v[min] = tmp
 end
 
 end # selection Sort

 The equivalent java code is 

  public static void sort(Comparable[] a) {
 int N = a.length;
 for (int i = 0; i  N; i++) {
 int min = i;
 for (int j = i + 1; j  N; j++) {
 if (a[j].compareTo(a[min])  0) {
 min = j;
 }
 }
 Comparable temp = a[i];
 a[i] = a[min];
 a[j] = temp;
 }
 }

 I have the following questions
 (1) the function f passed in to selectionSort should have the type f: 
 (T,T) = Boolean, ie it takes two elements of the Vector and tells whether 
 they are in correct order or not. This could be   for example. How do I 
 state this in Julia iow, how do I specify the function signature?

 (2) Are there any horrendous inefficiencies in the Julia code which are 
 apparent to experienced Julians? When I benchmark  against the equivalent 
 Java I'm getting a factor of 10+ slowdown for larger arrays (though both 
 seem O(n^2) as it should be)

 size(of array, uniform distribution of doubles between 0 and 1),time taken 
 to sort in Java (in milliseconds), time taken to sort in Julia. both times 
 are an average of 5 runs for each array size

 1000,0.003,0.010
 2000,0.003,0.041
 4000,0.011,0.165
 8000,0.044,0.664
 16000,0.206,2.660


 I readily admit I have very little idea of what it takes to write 
 performant code in Julia. Any help greatly appreciated.

 Of course, I might be doing something really stupid in the first place, 
 which happens all to frequently sadly enough. Please point out any mistakes 
 in my code.

 Thanks in advance,
 Ravi

[julia-users] Re: How to best define an EulerAngles type

[Simon Danisch]

First of all I would recommend FixedSizeArrays or NTuples for this, as they 
can be faster in some cases and you can restrict them to 3 dimensions.
Then I'd follow Tim Holy's advice.
Concerning your problem, you can do this on 0.4:

call{T : Number, SEQ}(::Type{EulerAngles{SEQ}, a::Vector{T}} = 
EulerAngles{SEQ, T}(a)

Best,
Simon


Am Mittwoch, 26. August 2015 05:29:08 UTC+2 schrieb danie...@gmail.com:

 Hi, everyone.

 I've been tinkering with creating a package for dealing with Euler angles, 
 using a very recent build of v0.4.  Rather than just rehash Matlab's 
 functions, I wanted to take advantage of the type system, to learn more 
 about parametric types and constructors.

 I definitely want the Euler rotation sequence and the angles to be bound 
 together.  One straightforward way to do this would of course be:

 type EulerAngles{T : Number}
 seq::Int
 angles::Vector{T}
 end

 Which would work fine, but I'd end up with a huge if block for every valid 
 sequence.  So I thought I'd try moving the sequence into the type 
 definition.  I think I would declare the type like this:

 type EulerAngles{T : Number, s}
 angles::Vector{T}
 end

 But then I can't figure out the best way to provide constructors for this 
 type.  What I want is something like this:

 EulerAngles{321}([1.0, 2.0, 3.0])

 But I can't figure out how to get this to work.  Is this kind of 
 constructor even possible with the type I showed above?

 I was able to get something very similar to work, by making functions that 
 look like constructors with the sequence in their names, like this:

 EulerAngles321([1.0, 2.0, 3.0])

 Which works, but gives the impression that EulerAngles321 is actually a 
 type.  But it seems that typealiases can't have constructors, and I get an 
 error trying to define a typealias and a function with the same name.  Even 
 with this limitation, though, this seems like an OK solution.

 If I really wanted to have types with those names, I could have an 
 abstract EulerAngles type, and then have concrete types like 
 EulerAngles321.  But that seems like overkill (in terms of the number of 
 types I'd create).  Though it would work.

 Does anyone have any guidance on how to best approach this?

 Thanks for the help!

 Daniel

[julia-users] 0.4 used to load fast

[Simon Danisch]

You should try julia --precompile=yes .
I never took the time to search why this was done, though.

[julia-users] Re: 0.4 used to load fast

[Simon Danisch]

Ah okay, I suspected this. I wasn't convinced though.
I compared the stack traces for precompiled=yes/no for the cases that 
really annoyed me and it seemed precompiled=no never gave better results.
Guess I haven't hit the edge cases yet.
But given these findings, I would greatly prefer precompiled=yes as the 
default, and if I'm unhappy with the stack traces I would want to switch to 
precompiled=no temporarily.
I'll comment on the PR.


Am Montag, 10. August 2015 16:17:17 UTC+2 schrieb J Luis:

 On Windows here. 
 Some months ago the local build with MinGW used to start almost 
 instantaneously. Now it takes almost 4 seconds again.

[julia-users] Re: John L. Gustafson's UNUMs

[Simon Danisch]

How cool!
I don't know much about this matter, but this looks very exciting! 
Julia seems to be a good fit to prototype this! 

Am Samstag, 25. Juli 2015 15:11:54 UTC+2 schrieb Job van der Zwan:

 So I came across the concept of UNUMs on the Pony language mailing list 
 http://lists.ponylang.org/pipermail/ponydev/2015-July/71.html this 
 morning. I hadn't heard of them before, and a quick search doesn't show up 
 anything on this mailing list, so I guess most people here haven't either. 
 They're a proposed alternate encoding for numbers by John L. Gustafson. 
 This presentation by him sums it up nicely:

 http://sites.ieee.org/scv-cs/files/2013/03/Right-SizingPrecision1.pdf

 “Unums”(universal numbers) are to floating point what floating point is to 
 fixed point.
 Floating-point values self-describe their scale factor, but fix the 
 exponent and fraction size. Unums self-describe the exponent size, fraction 
 size, and inexact state, and include fixed point and IEEE floats as special 
 cases.


 The presentation can be seen here, provided you have the Silverlight 
 plugin:


 http://sites.ieee.org/scv-cs/archives/right-sizing-precision-to-save-energy-power-and-storage

 Now, I don't know enough about this topic to say if they're a good or bad 
 idea, but I figured the idea is interesting/relevant enough to share with 
 the Julia crowd.

 I'm also wondering if they could be implemented (relatively) easily within 
 Julia, given its flexible type system. If so, they might provide an 
 interesting advanced example, no?

[julia-users] Re: mouse event

[Simon Danisch]

2D/3D picking is implemented in GLVisualize.jl... Though, it might not have 
your type of visualization, especially if its 2D plotting...


Am Dienstag, 21. Juli 2015 18:34:31 UTC+2 schrieb Emerson Vitor Castelani:

 Guys, I need to know if we can create mouse events using pyplot in Julia? 
 And how?

 Thanks

[julia-users] Re: Indexing Array with empty vector in v.0.4.

[Simon Danisch]

This is actually one of the biggest missing features in most programming 
languages. 
Giving good interactive feedback and educating people instead of 
disallowing things just because these noobs can't deal with it 
anywaysaand because its actually pretty hard to give good feedback :D
But I think Julia started off as very intuitive and educational and I hope 
it will continue on this road =)

Am Samstag, 18. Juli 2015 12:00:16 UTC+2 schrieb Felipe Jiménez:

 Say A is an Array, like A = [1 2 3 4], and I index it with an empty vector.

 In Julia v.0.3, A[[]] is empty. I find this convenient when programming.

 In Julia v.0.4, A[[]] throws an error.

 Is this intended? It sometimes forces me to code if isempty()... else...

 My version is 0.4.0-dev+5841 (2015-07-07 14:58 UTC), Commit f428392* (10 
 days old master), x86_64-w64-mingw32.

 Thank you.

[julia-users] Re: SOLVED: ERROR: `start` has no method matching start(::Nothing)

[Simon Danisch]

This could actually be solved by having something like this in base:

start{T}(x::T) = error($T is not iterable. Try implementing start(::$T), 
done(::$T, state), next(::$T, state))

The basic problem here is, that Julia has weakly enforced interfaces, which 
often ends in no method errors instead of something meaningfull for people 
who don't know the implicit interfaces.

Am Montag, 20. Juli 2015 21:09:00 UTC+2 schrieb Kaj Wiik:

 I started to get a strange error while debugging my code, here's a 
 simplified example:

 julia function foo(a)
println(foo..)
end
 foo (generic function with 1 method)

 julia a = foo(2)
 foo..

 julia a,b = foo(2)
 foo..
 ERROR: `start` has no method matching start(::Nothing)


 So, the problem was a missing return value, it is strange that missing one 
 value did not give error but two values It took a quite long time to 
 track this down. Perhaps a bit more informative error message would be 
 possible...?

 Cheers,
 Kaj

[julia-users] Re: SOLVED: ERROR: `start` has no method matching start(::Nothing)

[Simon Danisch]

@Patrick O'Leary  solved was probably exaggerated...But would be a lot 
better =)
The connection between iteration and asigning multiple variables to one 
return value is easier made than a no method error about a function you 
might have never heard about.


Am Montag, 20. Juli 2015 21:09:00 UTC+2 schrieb Kaj Wiik:

 I started to get a strange error while debugging my code, here's a 
 simplified example:

 julia function foo(a)
println(foo..)
end
 foo (generic function with 1 method)

 julia a = foo(2)
 foo..

 julia a,b = foo(2)
 foo..
 ERROR: `start` has no method matching start(::Nothing)


 So, the problem was a missing return value, it is strange that missing one 
 value did not give error but two values It took a quite long time to 
 track this down. Perhaps a bit more informative error message would be 
 possible...?

 Cheers,
 Kaj

[julia-users] Re: Escher/Compose/Gadfly for heavy visualization

[Simon Danisch]

GLVisualize should be a perfect fit for this kind of task, though it might 
not install flawlessly on all platforms (I'm working on that). 
You can definitely give it a try, I fixed quite a few problems in the last 
days.
Combining it with GTK or QT should be relatively straight forward, but 
someone would need to invest some work into creating the correct calls to 
setup an OpenGL window to run GLVisualize in and transforming the QT/GTK 
events into reactive signals. If someone bootstraps this, I'm willing to 
help out to make this work. (Just create a project with GTK/QT, that opens 
an OpenGL window and some GUI elements and callbacks for it, and I'll 
figure out the GLVisualize side)
There is a nice article about 
this: https://www.bassi.io/articles/2015/02/17/using-opengl-with-gtk/ 
(thank valentin for the link)

Creating GUIs with Escher controling visualizations in a seperate OpenGL 
window should be pretty straight forward.
The ultimate goal is to combine Compose3D, Escher and GLVisualize really 
nicely. 
If things work out, it might be possible to render the GUI elements from 
Escher with GLVisualize, making it possible to have them all in the same 
window with the highest possible performance.
I'm working on this, as well as trying out ways to make Compose/3D fast for 
animated, large data sets.
So currently, things might be a little wonky, but I think we can look 
forward to a pleasant future for these kind of tasks.
If you have specific use cases please open an issue over at GLVisualize and 
we can figure out how to make it happen.
I'm very interested in developping GLVisualize around actual use cases, to 
make the API as pleasant as possible for the people that actually use it.

Best,
Simon


Am Mittwoch, 1. Juli 2015 13:56:06 UTC-4 schrieb Tom Breloff:

 Has anyone used Escher/Compose/Gadfly for interactive 
 visualization/plotting with lots of data (million's of updates)?  Is there 
 support for 3D visualization as part of this ecosystem? If not, is it 
 planned?  Any performance gotchas I need to worry about?  Bandwidth issues? 
  Missing functionality? etc

 Does anyone split their gui/backend into 2 different Julia processes for 
 cpu-heavy processing?  Are there built-in methods for updating the gui/viz 
 like that or do I have to roll my own with zmq or similar?

 Any opinions in the matter would be appreciated.  I'm on the fence whether 
 I should commit to a web gui for everything I do or whether I should still 
 do some things with Qt, or perhaps GLVisualize.

[julia-users] Re: Convert Array{Tuple} to Matrix

[Simon Danisch]

You could do also try this, which does not introduce any overhead:
reinterpret(Int, tuple_array, (3, 1000))
But it only works with Julia 0.4 and I'm not sure if you would consider it 
as clean.

Am Montag, 6. Juli 2015 16:10:01 UTC-4 schrieb Júlio Hoffimann:

 Hi,

 How to convert:

 1000-element Array{Tuple{Integer,Integer,Integer},1}:
  (10,2,1) 
  (5,7,10) 
  (5,7,4)  
  (1,1,6)  
  (2,3,6)  
  (8,6,4)  
  (10,2,4) 
  (1,3,9)  
  (9,3,7)  
  (5,2,4)  
  ⋮
  (1,6,8)  
  (4,6,6)  
  (3,9,5)  
  (10,4,10)
  (8,7,4)  
  (4,8,9)  
  (2,6,10) 
  (3,6,5)  
  (1,7,10) 

 into the corresponding 1000x3 matrix in a clean fashion?

 -Júlio