Support for callable object on 0.4-dev

[yuyichao]

When trying to see how would the new DFT API affect packages, I find ApproxFun as the single user of the FFTW plan api among registered packages JuliaLang/julia#12087 (comment).

Since the API change makes the plan_* functions return an plan object rather than an anonymous function, this seems to break certain assumptions in ApproxFun and causing dispatching errors etc.

As a more general issue, from what I can tell, ApproxFun make heavy use of the Function type and assume it is the only callable object. This would probably cause some trouble after 0.4 is released since people may try to pass in callable object and expect better efficiency but end up getting wierd errors.

I'm bringing this issue up because I'd like to get ApproxFun ready before the breakage is merged (which I'd like to do in a few days) and would like to know if devs of ApproxFun have any plan for the more general issue (supporting callable object). (simply removing the ::Function causes tones of ambiguity warnings.)

If there's not a plan on the table yet, I would try to fix the breakage by wrapping the result in an anonymous function. (Since the old interface of calling the returned object is deprecated, a wrapper would always be necessary. However, this can be a callable object if ApproxFun supports it.) This would not be as effectient but shouldn't be worse that what it is right now.

[dlfivefifty]

I think it should be possible to remove the ::Function typing so, I'll have a go making this change

Sent from my iPad

On 16 Jul 2015, at 12:26 am, Yichao Yu [email protected] wrote:

When trying to see how would the new DFT API affect packages, I find ApproxFun as the single user of the FFTW plan api among registered packages JuliaLang/julia#12087 (comment).

Since the API change makes the plan_* functions return an plan object rather than an anonymous function, this seems to break certain assumptions in ApproxFun and causing dispatching errors etc.

As a more general issue, from what I can tell, ApproxFun make heavy use of the Function type and assume it is the only callable object. This would probably cause some trouble after 0.4 is released since people may try to pass in callable object and expect better efficiency but end up getting wierd errors.

I'm bringing this issue up because I'd like to get ApproxFun ready before the breakage is merged (which I'd like to do in a few days) and would like to know if devs of ApproxFun have any plan for the more general issue (supporting callable object). (simply removing the ::Function causes tones of ambiguity warnings.)

If there's not a plan on the table yet, I would try to fix the breakage by wrapping the result in an anonymous function. (Since the old interface of calling the returned object is deprecated, a wrapper would always be necessary. However, this can be a callable object if ApproxFun supports it.) This would not be as effectient but shouldn't be worse that what it is right now.

—
Reply to this email directly or view it on GitHub.

[yuyichao]

I think it should be possible to remove the ::Function typing so, I'll have a go making this change.

That will be nice. I had a look at it myself and found some cases that would probably need careful handling. Examples including this and when extending Base functions. The more specific issue (accepting non-function FFTW plan) might be easier though.

[dlfivefifty]

The first example isn’t too important since the timeevolution routines aren’t really meant for general use, they are just a hack to do movies of time evolution PDEs.

The second case should be left as it is because it is just to allow

dot(∇,f)

to work, where ∇ is defined as a function a few lines above.

On 16 Jul 2015, at 7:50 am, Yichao Yu [email protected] wrote:

I think it should be possible to remove the ::Function typing so, I'll have a go making this change.

That will be nice. I had a look at it myself and found some cases that would probably need careful handling. Examples including this https://github.com/ApproxFun/ApproxFun.jl/blob/9aa3f924d57e253ed67ba7c085bccb5712128fa0/src/Extras/timeevolution.jl#L209 and when extending Base functions https://github.com/ApproxFun/ApproxFun.jl/blob/9aa3f924d57e253ed67ba7c085bccb5712128fa0/src/Extras/poetry.jl#L58. The more specific issue (accepting non-function FFTW plan) might be easier though.

—
Reply to this email directly or view it on GitHub #216 (comment).

[dlfivefifty]

I've made this change in development branch, but bizarrely it makes the compile time huge. I'm not sure how that could be.

[dlfivefifty]

I reverted LowRankFun/ProductFun to fix the compile time issue. I think we can close this as those aren't really meant for general use

[yuyichao]

The specific issue of supporting new DFT API should be fixed by #218, which should still remain compatibility with the old API. I'm not sure what's the plan for ApproxFun and callable objects so please feel free to close this if you think it's good for now.

P.S. for allowing sth like dot(∇,f), I think a better way to do it is to make ∇ a singleton object with proper dot method. Note that this only works on 0.4 if ∇ still needs to be callable.

[dlfivefifty]

Merged!