Hi Michael... have you had a chance to look at OnlineStats yet? https://github.com/joshday/OnlineStats.jl
On Fri, Sep 18, 2015 at 11:31 AM, Michael Francis <mdcfran...@gmail.com> wrote: > 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 <mdcfr...@gmail.com> >> > >>> >> > >>> 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 >> >>
