Hmm - looking at that thread I struggle to agree with the outcome. Using this function was how I stumbled on the 20% speed issue with cov in stats base (due to type instability of the named arg). cov as it currently stands will return 'Any' whereas for an input set of two vectors of Float64. The code emitted for cov is not optimal due to the type instability.
To have any chance of performance in streaming time series operators I need to be able to figure out what the return type of an arbitrary function is ( say +( Float64, Float64 ) -> Float64, I use this is used to define the record type for each subsequent observation. On Friday, September 18, 2015 at 10:04:46 AM UTC-4, Tim Holy wrote: > > It's considered a no-no to call Base.return_types from code: > https://github.com/JuliaLang/julia/pull/12292#issuecomment-124322950 > > However, my PR expunging it (https://github.com/JuliaLang/julia/pull/12409) > > has not gotten any interest from those who objected, so I'm certain how > serious they are ;-). > > --Tim > > > On Friday, September 18, 2015 05:58:03 AM Michael Francis wrote: > > I should probably submit a PR to add - the extra info > > > > On Friday, September 18, 2015 at 8:50:35 AM UTC-4, Tomas Lycken wrote: > > > In this specific use case I don't need to handle anonymous functions, > so > > > `Base.return_types` will probably do just fine. > > > > > > It's not documented, though, so searching in the docs didn't turn > anything > > > up (and even though I guess it must have been used on this list, my > search > > > terms apparently weren't good enough to find it. > > > > > > Thanks! > > > > > > // T > > > > > > On Friday, September 18, 2015 at 2:42:47 PM UTC+2, Michael Francis > wrote: > > >> Yes in the sense it hands anon functions > > >> > > >> On Friday, September 18, 2015 at 8:41:16 AM UTC-4, Mauro wrote: > > >>> Is that better than Base.return_types ? > > >>> > > >>> On Fri, 2015-09-18 at 14:36, Michael Francis <[email protected]> > > >>> > > >>> wrote: > > >>> > function returns(f, types) > > >>> > > > >>> > rt = [] > > >>> > if( !isdefined(f, :code) ) > > >>> > > > >>> > for x in Base._methods(f,types,-1) > > >>> > > > >>> > linfo = x[3].func.code > > >>> > (tree, ty) = typeinf(linfo, x[1], x[2]) > > >>> > push!(rt, ty) > > >>> > > > >>> > end > > >>> > > > >>> > else > > >>> > > > >>> > # It is a lambda, not a function, we also need the types of > the > > >>> > > >>> bound > > >>> > > >>> > # variables to evaluate the lambda corectly > > >>> > println( types ) > > >>> > linfo = f.code > > >>> > env = f.env > > >>> > (tree, ty) = typeinf(linfo, types, () ) > > >>> > push!(rt, ty) > > >>> > > > >>> > end > > >>> > # If there is a set of return types we default to any for now > > >>> > # this could be converted to a union type > > >>> > if( length( rt ) == 0 ) > > >>> > > > >>> > println( "Failed to resolve return type for $f, $types") > > >>> > > > >>> > elseif( length(rt) > 1 ) > > >>> > > > >>> > return Any > > >>> > > > >>> > else > > >>> > > > >>> > return rt[1] > > >>> > > > >>> > end > > >>> > > > >>> > end > > >>> > > > >>> > > > >>> > > > >>> > The above is what I do - which also copes with anon-functions > > >>> > > > >>> > On Friday, September 18, 2015 at 8:32:45 AM UTC-4, Tomas Lycken > wrote: > > >>> >> Given a function `foo(x,y)` and two *types* `TX` and `TY`, is > there a > > >>> > > >>> way > > >>> > > >>> >> I can get the inferred return type from calling `foo(x::TX, > y::TY)`? > > >>> > > >>> I want > > >>> > > >>> >> to do this in the compile part of a generated function, so I > don't > > >>> > > >>> have > > >>> > > >>> >> access to any values to actually call the function with. > > >>> >> > > >>> >> I have already verified that the function `foo` is type stable, > so > > >>> > > >>> the > > >>> > > >>> >> inferred type should be good enough for my purposes. > > >>> >> > > >>> >> Thanks, > > >>> >> > > >>> >> // T > >
