Currently SEDs are much faster if their underlying function (spec) uses a LookupTable with interpolation='linear'. When this is the case, various manipulations preserve the function tabulation (e.g. multiplying by a bandpass), but when the function is anything else, the result is a lambda function.
This can be a gotcha for users who think they are providing a LookupTable, but use the default interpolation='spline'. Then it's very easy to do pretty normal things to an SED and end up with very slow integration when sampling wavelengths for chromatic photon shooting (for instance).
I think the reason for some of the choices here was that linear interpolated tables were the only functions that were quick to integrate. But now LookupTable.integrate can handle spline interpolation equally quickly. So I suspect we should revisit our choices here and try expand the use cases where we keep a tabulated function. And hopefully avoid the kind of gratuitous inefficiency trap that is easy to fall into currently.
Currently SEDs are much faster if their underlying function (
spec) uses a LookupTable withinterpolation='linear'. When this is the case, various manipulations preserve the function tabulation (e.g. multiplying by a bandpass), but when the function is anything else, the result is a lambda function.This can be a gotcha for users who think they are providing a LookupTable, but use the default
interpolation='spline'. Then it's very easy to do pretty normal things to an SED and end up with very slow integration when sampling wavelengths for chromatic photon shooting (for instance).I think the reason for some of the choices here was that linear interpolated tables were the only functions that were quick to integrate. But now
LookupTable.integratecan handle spline interpolation equally quickly. So I suspect we should revisit our choices here and try expand the use cases where we keep a tabulated function. And hopefully avoid the kind of gratuitous inefficiency trap that is easy to fall into currently.