Re: [julia-users] Generators vs Comprehensions, Type-stability?

In an email a few days back, Steven Johnson wrote: "We could use type inference on the function t -> t^2 (which is buried in the generator) to determine a more specific eltype." A feature request, maybe? On Sun, Sep 25, 2016 at 11:29 PM, Christoph Ortner < christophortn...@gmail.com> wrote: > > I

Re: [julia-users] Generators vs Comprehensions, Type-stability?

I didn't quite follow what the conclusion is: is it a bug that should be fixed (i.e. open an issue?), or is it expected behaviour and I should stop using generators when I need type inference? Thanks.

Re: [julia-users] Generators vs Comprehensions, Type-stability?

On Sat, Sep 24, 2016 at 8:54 PM, Steven G. Johnson wrote: > > julia> (begin;println(t);t^2;end for t=1:10) >> Base.Generator{UnitRange{Int64},##37#38}(#37,1:10) >> > > Julia knows that the input to the generator is a UnitRange{Int64}, i.e. > 1:10, so the input elements are Int64. It knows that

Re: [julia-users] Generators vs Comprehensions, Type-stability?

On Saturday, September 24, 2016 at 9:09:38 AM UTC-4, Michele Zaffalon wrote: > > Sorry for being slow: the input array rand(10) or the output array, the > square of each element of rand(10)? > > julia> (begin;println(t);t^2;end for t=1:10) > Base.Generator{UnitRange{Int64},##37#38}(#37,1:10) >

Re: [julia-users] Generators vs Comprehensions, Type-stability?

On Fri, Sep 23, 2016 at 1:14 PM, Steven G. Johnson wrote: > > > On Friday, September 23, 2016 at 2:42:00 AM UTC-4, Michele Zaffalon wrote: >> >> On Fri, Sep 23, 2016 at 2:23 AM, Steven G. Johnson >> wrote: >>> >>> >>> We could use type inference on the function t -> t^2 (which is buried in >>> t

Re: [julia-users] Generators vs Comprehensions, Type-stability?

I still don't quite get why a) inference between the generator and the comprehension is different, and b) why inference went down the drain when I added the type annotation for the return value in my example above... Sorry if the answer is in this discussion somewhere! On Friday, September 23,

Re: [julia-users] Generators vs Comprehensions, Type-stability?

On Friday, September 23, 2016 at 4:13:53 AM UTC-4, Christoph Ortner wrote: > > The sum of an empty set or vector is undefined it is not zero. > >> you can rewrite it in a more explicit way >> >>> >>> > Actually a sum over an empty set is normally defined to be zero while a > product over an empt

Re: [julia-users] Generators vs Comprehensions, Type-stability?

On Friday, September 23, 2016 at 2:42:00 AM UTC-4, Michele Zaffalon wrote: > > On Fri, Sep 23, 2016 at 2:23 AM, Steven G. Johnson > wrote: >> >> >> We could use type inference on the function t -> t^2 (which is buried in >> the generator) to determine a more specific eltype. >> > > Does this n

Re: [julia-users] Generators vs Comprehensions, Type-stability?

{We could use type inference on the function t -> t^2 (which is buried in the generator) to determine a more specific eltype.} We can declare : eltype(G::Base.Generator) = Base.code_typed(G.f,(eltype(G.iter),))[1].rettype element type of Generator G will be the inferred return type of G.f wit

Re: [julia-users] Generators vs Comprehensions, Type-stability?

>From reading the manual , producing a value is delayed until that value is required. Is my understanding wrong? On Fri, Sep 23, 2016 at 10:14 AM, Christoph Ortner < christophortn...@gmail.com> wrote: > why would type

Re: [julia-users] Generators vs Comprehensions, Type-stability?

why would type inference for sum(t^2 for t in r) be different from [t^2 for t in r] ? On Friday, 23 September 2016 07:42:00 UTC+1, Michele Zaffalon wrote: > > On Fri, Sep 23, 2016 at 2:23 AM, Steven G. Johnson > wrote: >> >> >> We could use type inference on the function t -> t^2 (which is burie

Re: [julia-users] Generators vs Comprehensions, Type-stability?

The sum of an empty set or vector is undefined it is not zero. > you can rewrite it in a more explicit way > >> >> Actually a sum over an empty set is normally defined to be zero while a product over an empty set is normally defined to be one.

Re: [julia-users] Generators vs Comprehensions, Type-stability?

On Fri, Sep 23, 2016 at 2:23 AM, Steven G. Johnson wrote: > > > We could use type inference on the function t -> t^2 (which is buried in > the generator) to determine a more specific eltype. > Does this not require evaluating the function on all inputs thereby losing the advantage of having a gen

Re: [julia-users] Generators vs Comprehensions, Type-stability?

Le jeudi 22 septembre 2016 à 14:54 -0700, Tsur Herman a écrit : > By the way my test3 functions is super fast > >  @time test3(r) >   0.32 seconds (4 allocations: 160 bytes) Beware, if you don't return 'total' from the function, LLVM optimizes away the whole loops and turns the function into a

Re: [julia-users] Generators vs Comprehensions, Type-stability?

I can a see a point in what you say .. eltype of a function should be the return type of that function if it can be inferred. Because an array is just a special kind of function with a special notation. On Friday, 23 September 2016, Steven G. Johnson wrote: > > > On Thursday, September 22, 2016

Re: [julia-users] Generators vs Comprehensions, Type-stability?

On Thursday, September 22, 2016 at 6:10:29 PM UTC-4, Tsur Herman wrote: > > The real problem is that eltype(t^2 for t in rand(10)) returns Any. > > > that is not a problem (t^2 for t in rand(10)) is a generator its element > type is Any which means a pointer to something complex. > >> It is a pr

Re: [julia-users] Generators vs Comprehensions, Type-stability?

The real problem is that eltype(t^2 for t in rand(10)) returns Any. that is not a problem (t^2 for t in rand(10)) is a generator its element type is Any which means a pointer to something complex. On Friday, September 23, 2016 at 12:50:18 AM UTC+3, Steven G. Johnson wrote: > > I don't think th

Re: [julia-users] Generators vs Comprehensions, Type-stability?

By the way my test3 functions is super fast @time test3(r) 0.32 seconds (4 allocations: 160 bytes) On Friday, September 23, 2016 at 12:48:50 AM UTC+3, Tsur Herman wrote: > > > On my side both function perform equally. although test2 had to be timed > twice to get to the same performan

Re: [julia-users] Generators vs Comprehensions, Type-stability?

I don't think the empty case should be the problem. If it can't infer the type, sum just throws an error. So test1(r) actually always returns the same type for r::Array{Float64} in any case where it returns a value at al. The real problem is that eltype(t^2 for t in rand(10)) returns Any.

Re: [julia-users] Generators vs Comprehensions, Type-stability?

On my side both function perform equally. although test2 had to be timed twice to get to the same performance. julia> test2(x)= sum( [t^2 for t in x] ) julia> @time test2(r) 0.017423 seconds (13.22 k allocations: 1.339 MB) julia> @time test2(r) 0.000332 seconds (9 allocations: 781.531 KB)

Re: [julia-users] Generators vs Comprehensions, Type-stability?

There might be a perfectly valid explanation for this, but this also surprises me. r = rand(10) f(x) = x^2 test1(r) = sum( f(x) for t in r ) test2(r) = sum( [f(x) for t in r] ) @code_warntype test1(r) # return type Any is inferred @code_warntype test2(r) # return type Float64 is inferred g(

Re: [julia-users] Generators vs Comprehensions, Type-stability?

would it maybe be possible to introduce a macro like @inbounds that somehow turns off the check that the generator is empty?

Re: [julia-users] Generators vs Comprehensions, Type-stability?

Yeah, this definitely matters for performance. It is a real shame since the generators are so elegant to use. inner1(R, i) = sum( R[j,i] for j = 1:size(R,1) ) inner2(R, i) = sum( [R[j,i] for j = 1:size(R,1)] ) function test(R, inner) n = [ inner(R, i)^2 for i = 1:size(R,2) ] N = leng

Re: [julia-users] Generators vs Comprehensions, Type-stability?

sum( Float64[] ) = 0.0 ?

Re: [julia-users] Generators vs Comprehensions, Type-stability?

I've seen the same, and the answer I got at the JuliaLang gitter channel was that it could not be inferred because r could be of length 0, and in that case, the return type could not be inferred. My Julia-fu is too weak to then explain why the comprehension would be able to infer the return typ

Re: [julia-users] Generators vs Comprehensions, Type-stability?

I didn't actually test performance - the problem for me was re-use of the output of test1. But it is hard to reproduce this with a simple example. The same code works in some situations and not in others - I haven't yet found out why.

Re: [julia-users] Generators vs Comprehensions, Type-stability?

I see the same, yet: julia> r = rand(10^5); julia> @time test1(r) 0.000246 seconds (7 allocations: 208 bytes) 33375.54531253989 julia> @time test2(r) 0.001029 seconds (7 allocations: 781.500 KB) 33375.54531253966 So test1 is efficient, despite the codewarn output. Not sure what's up. On T