[julia-users] Type inference

Hi all, I expected this to be true: *Dict{ASCIIString,Int64}<:Dict{String,Int64}# false* Should not there be covariance on the Dict's type parameter that allows this?

Re: [julia-users] Type inference

Please have a look at the manual. It is explained here 2014-02-06 Fil Mackay : > Hi all, I expected this to be true: > > > > *Dict{ASCIIString,Int64}<:Dict{String,Int64}# false* > > Should not there be covariance on th

[julia-users] Type inference on the length of varargs

Hi! I'm looking for the recommended way of getting type inference to determine the number of elements passed via varargs. I guess a code snippet is better than a thousand words: in the following function, the type of a isn't inferred correctly. function f(x...)     N = length(x)     a = Array{In

[julia-users] type inference on comprehension on recursive type woes

Here is some code https://gist.github.com/goretkin/967ca1bef0b07ee99ff8 (pasted at end of email too) It declares a recursive data type TreeNode that has a field children which is a Set of TreeNodes. The function nodes counts the number of nodes in the tree recursively. The code as shown (optio

[julia-users] Type inference cannot deduce that convert(Float32,x) returns a Float32?

I was a bit surprised when I tried this example: function foo() global G #b = Float32(G) b = convert(Float32,G) b end G = 0.5 println(foo()) code_warntype(foo,()) and code_warntype deduced that the type of b is ANY instead of Float32. Is this a bug or a feature? If I use the con

Re: [julia-users] Type inference cannot deduce that convert(Float32,x) returns a Float32?

There's nothing in the language that forces convert(T,x) to return something of type T, so type inference has no idea what type b is. The method that implements Float32(x) is this: call{T}(::Type{T}, arg) = convert(T, arg)::T Note the type assertion – so type inference does know the type of the

Re: [julia-users] Type inference cannot deduce that convert(Float32,x) returns a Float32?

Does this mean that in all the code that I've written for UTF conversions, I should decorate the results of the convert with ::T to help the compiler's inference? On Monday, June 1, 2015 at 11:31:53 PM UTC+2, Stefan Karpinski wrote: > > There's nothing in the language that forces convert(T,x) to

Re: [julia-users] Type inference cannot deduce that convert(Float32,x) returns a Float32?

Probably not necessary – that code already has more type annotations than it needs. The compiler is usually quite good at figuring out types, in this case the global sabotages it. On Mon, Jun 1, 2015 at 5:50 PM, Scott Jones wrote: > Does this mean that in all the code that I've written for UTF c

Re: [julia-users] Type inference cannot deduce that convert(Float32,x) returns a Float32?

On Mon, Jun 1, 2015 at 6:03 PM, Stefan Karpinski wrote: > Probably not necessary – that code already has more type annotations than it > needs. The compiler is usually quite good at figuring out types, in this > case the global sabotages it. And I guess typeinf gives up because of the number of m

Re: [julia-users] Type inference cannot deduce that convert(Float32,x) returns a Float32?

Either that or there's some convert method that violates that expectation, in which case inference would correctly decide that it can't predict the result type. On Mon, Jun 1, 2015 at 6:05 PM, Yichao Yu wrote: > On Mon, Jun 1, 2015 at 6:03 PM, Stefan Karpinski > wrote: > > Probably not necessar

Re: [julia-users] Type inference cannot deduce that convert(Float32,x) returns a Float32?

The convert methods for Date.Period, Complex and Rational are inferred to give Any. The problem in Period is because of the use of the value method in line 4 of periods.jl. It extracts a field from an abstract type so even though all subtypes in base have the specified field and have it defined

Re: [julia-users] Type inference cannot deduce that convert(Float32,x) returns a Float32?

Oh, good stuff, Andreas – how'd you go about looking for this? Can you open an issue about this? We should really make sure that all convert methods are well-behaved. On Tue, Jun 2, 2015 at 11:25 AM, Andreas Noack wrote: > The convert methods for Date.Period, Complex and Rational are inferred to

Re: [julia-users] Type inference cannot deduce that convert(Float32,x) returns a Float32?

On Jun 2, 2015 11:40 AM, "Stefan Karpinski" wrote: > > Oh, good stuff, Andreas – how'd you go about looking for this? Can you open an issue about this? We should really make sure that all convert methods are well-behaved. It would be easier if the output of code_typed(convert, Tuple{Type{Float32}