[julia-users] Re: Is Julia slow with large arrays?

The code becomes about 10 times faster on my computer if I replace "bar=0" with "bar=0.0", see http://docs.julialang.org/en/release-0.4/manual/performance-tips/#avoid-changing-the-type-of-a-variable (Also running "foo()" twice avoids measuring JIT compilation.) On Wednesday, June 1, 2016 at

Re: [julia-users] Anonymous Function Behavior

BTW, it does work if you put it into a function rather than running it in global scope: julia> test(y) = map(x->10^x, y) test (generic function with 1 method) julia> @time test(a); 0.003387 seconds (4.34 k allocations: 97.662 KB) julia> @time test(a); 0.000440 seconds (4.01 k allocations:

[julia-users] Re: Macro as decorators

It's possible to have a macro in Julia that emulates Python decorators. But it's a separate question whether you really want to do it, there might be more efficient/elegant ways to achieve the same in Julia for a specific use case. Here's a macro that emulates Python decorators and an example

Re: [julia-users] what's good practice for default value in optional arguments?

In terms of type stability ( http://docs.julialang.org/en/release-0.4/manual/performance-tips/#avoid-changing-the-type-of-a-variable ), the latter is better: f1(x::Int, y::Union{Void,Dict}) = y==nothing ? Dict() : y @code_warntype f1(42, nothing) # shows ...end::UNION{DICT{ANY,ANY},VOID};

Re: [julia-users] Re: how to undefine variable in composite types

class X(object): @property def y(self): try: return x.__y except AttributeError: return "default value for y" x = X() print x.y On Friday, February 5, 2016 at 11:22:17 AM UTC+1, Andras Niedermayer wrote: > > The IPython autoreload extension does

Re: [julia-users] Re: how to undefine variable in composite types

The IPython autoreload extension does something quite similar to what has been discussed here ( https://ipython.org/ipython-doc/3/config/extensions/autoreload.html ). There are cases where it's actually very convenient, e.g. if you have results from a long-running calculation in an IPython

Re: [julia-users] Re: A question of Style: Iterators into regular Arrays

thon 2 and Python 3. On Thursday, October 22, 2015 at 5:15:17 PM UTC+2, Christoph Ortner wrote: > > > > On Thursday, 22 October 2015 10:24:50 UTC+1, Andras Niedermayer wrote: >> >> You're making a good point about an Array being sometimes faster than a >> LinSpace. But a

Re: [julia-users] Re: A question of Style: Iterators into regular Arrays

You're making a good point about an Array being sometimes faster than a LinSpace. But a LinSpace gets you a factor N improvement in terms of memory efficiency for a size N range, an Array only gets you a constant factor improvement in speed (the factor 15 being admittedly relatively large in

[julia-users] Re: speed increase of factor 70 for mixed scalar-vector vcat

Thanks for the pointer to https://github.com/JuliaLang/julia/issues/3738 . I filed a documentation issue https://github.com/JuliaLang/julia/issues/13702 And

[julia-users] speed increase of factor 70 for mixed scalar-vector vcat

I've written an implementation of vcat for the special case of mixed scalar-vector parameters (e.g. vcat(1,[2,3],4)) using generated functions. I get a speed increase of a factor 70 and memory usage reduction by a factor 10. It also makes this special case of vcat type stable (e.g. the

[julia-users] Re: speed increase of factor 70 for mixed scalar-vector vcat

ray{T,1},T}...) while loading In[8], in expression starting on line 1 On Tuesday, October 20, 2015 at 1:19:24 PM UTC+2, Kristoffer Carlsson wrote: > > Try: Base.vcat{T}(x::Vararg{Union{T,Array{T,1}}}) = mixed_vcat(x...) > > On Tuesday, October 20, 2015 at 11:44:15 AM UTC+2, Andras Niedermaye

[julia-users] Re: speed increase of factor 70 for mixed scalar-vector vcat

ulia> dispatchtest(2,[1,2],2,[1,2]) >> "success" >> >> julia> dispatchtest([1,2],2,[1,2],2,[1,2]) >> ERROR: MethodError: `dispatchtest` has no method matching dispatchtest(:: >> Array{Int64,1}, ::Int64, ::Array{Int64,1}, ::Int64, ::Array{Int64,1}) >

[julia-users] non-modifying push (and unshift, etc.)

In light of the recent discussions (https://groups.google.com/forum/#!topic/julia-users/xJ7GpKAa16E and https://groups.google.com/forum/#!topic/julia-users/_lIVpV0e_WI) I got curious, whether there is a non-modifying version of push!, since push!(copy(a),b) doesn't feel right (I try to avoid

[julia-users] Re: non-modifying push (and unshift, etc.)

.) is type stable. It may produce different output >> depending on the types of a and b but it won't change behavior depending on >> their values. >> >> On Monday, October 19, 2015 at 10:20:06 AM UTC-4, Andras Niedermayer >> wrote: >>> >>> I

[julia-users] strange things with type unions

I tried to write a special case of vcat which improves type inference to get around this problem: f() = vcat(1,[2,3]) @code_warntype f() gives Variables: ... end::ANY This works: function my_vcat{T}(x::T, y::AbstractArray{T}) result = Array(T, length(y)+1 ) result[1] = x

[julia-users] Re: Performance compared to Matlab

The type instability looks like a bug in Julia to me, filed issue: https://github.com/JuliaLang/julia/issues/13665 On Sunday, October 18, 2015 at 2:54:04 PM UTC+2, Andras Niedermayer wrote: > > There is a type instability (see here > <http://docs.julialang.org/en/release-0.4/manual

[julia-users] Re: Performance compared to Matlab

There is a type instability (see here ) that slows down your code. @code_warntype Jakes_Flat( 926, 1e-6, 5, 0, 1, 0 ) shows that variable h has type Any. I managed to track down the type

Re: [julia-users] Re: Type array bug?

You can also use `map`, which is better at type inference: julia> M=10 10 julia> [[i] for i=1:M] 10-element Array{Any,1}: [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] julia> map(x->[x],1:M) 10-element Array{Array{Int64,1},1}: [1] [2] [3] [4] [5] [6] [7] [8] [9]

[julia-users] Re: Passing data through Optim

If you're using Julia 0.4 you can also use call overloading, which is almost as convenient as closures and as fast as const globals. An extension of Tomas's benchmark gives me this: Non-const global 0.027968 seconds (999.84 k

[julia-users] Re: compute hermite polynomials

I was looking for Hermite polynomials and haven't found any code. I have some (very unpolished) code. I haven't made a public package yet, since it needs to be improved (especially in terms of efficiency, also documentation). Unfortunately, I'm unlikely to have time for this in the near

[julia-users] Re: compute hermite polynomials

Sorry, I meant Cubic Hermite Interpolation. Now I see you're looking for Hermite polynomials. On Monday, February 2, 2015 at 4:50:00 PM UTC+1, Andras Niedermayer wrote: I was looking for Hermite polynomials and haven't found any code. I have some (very unpolished) code. I haven't made

Re: [julia-users] Re: Sort performance depends on Array type in a strange way

it is.. Types in Julia are supposed to be abstraction-free, but included tuples seem to have a 231803748/40892612 = 5.6 times overhead compared to my Pair judging by the memory allocations. On Friday, January 9, 2015 at 10:06:30 AM UTC, Andras Niedermayer wrote: The performance

Re: [julia-users] Re: Sort performance depends on Array type in a strange way

. Johnson wrote: On Monday, January 12, 2015 at 8:36:28 AM UTC-5, Andras Niedermayer wrote: It's still not entirely satisfactory that sorting arrays of tuples is so much slower in Julia than in Python, (Note that for sorting an untyped array of tuples, Julia may never have much if any

[julia-users] Sort performance depends on Array type in a strange way

The performance of the sort algorithm varies largely with the element type of an Array, in an unexpected (at least for me) way. Sorting time is ordered like this: Vector{(Any,Any)} Vector{Any} Vector{(Float64,Int64}). Is this a bug or is this behavior intended? Here's the code: --- julia