Are we going to replace all bary with clenshaw in chebtech and smoothfun for function evaluation? about chebfun

[ajt60gaibb]

I agree, prolong.m should change as Clenshaw is better than bary in the regime of small degree.

In get: This is actually a rare case when bary is faster than Clenshaw (1 evaluation point, potentially large degree). Nick H and I did some experiments a while ago.

Smoothfun.m is using Floater-Horner interpolation (it looks like). So that should stay.

Perhaps, we should completely change to Clenshaw since its far cleaner message: "Clenshaw for evaluation". I would support prolong.m and get.m changing to Clenshaw. Unless someone feels the small efficiency lose in get.m is important.

[kuanxu]

I suggest that we replace the bary in get as well, so long as clenshaw is not much slower than bary for get. On the one hand, this can make the things in chebtech simpler and more uniform. On the other hand, if we use bary we have to update values before doing the evaluations. But there is an occasion (maybe more in the future) where we want to get the function values at the boundaries without updating the field 'values', for examples: extractBoundaryRoots.m. In this occasion, updating the field 'values' only for calling bary is a waste.

[ajt60gaibb]

OK, I don't know about extractBoundaryRoots.m. Though, I would expect the values field to be updated after every operation. It is really that expensive to update the values (one FFT), when roots are being computed. Perhaps, I've missed the point. Anyway, since your argument supports the "Clenshaw for evaluation" campaign, I'm happy! 👍

[aaustin141]

Good catch!

I second the idea of changing prolong() and chebtech1.get() (chebtech2.get() doesn't call bary()) to use clenshaw(). I'd be willing to bet that the performance hit from changing in chebtech1.get() is pretty unimportant, and, as @ajt60gaibb has already pointed out, using clenshaw() everywhere sends a simpler, more uniform message.

@kuanxu: I'm not sure what you mean with regard to extractBoundaryRoots(). All chebtech methods need to maintain the class invariant that the values and coeffs fields are up-to-date with one another. If extractBoundaryRoots() returns a chebtech for which this isn't true, it's a bug!

[kuanxu]

Yes. If we are not losing much, go uniform always.

@aaustin141: It seems that I didn't explain clearly. In fact, there is a while loop in extractBoundaryRoots where we only need to update coeffs to proceed to the next iteration. But boundary values are checked at the beginning of each loop. Now we have to update values too in each iteration to make sure that get and the underlying bary work.

[kuanxu]

BTW, bary shows up in legpts.m as well, which is beyond my universe.

[aaustin141]

@kuanxu: OK, I see what you mean. I just looked at the code now.

Assuming we weren't going to switch chebtech1.get() to use clenshaw() (and I think we are), you could always work around it in that kind of a situation by calling clenshaw() directly.

[kuanxu]

@aaustin141: True. This is what I'm going to do for time being.

[ajt60gaibb]

@kuanxu: You're right legpts.m and jacpts.m does use bary to numerically compute coefficients in the boundary asymptotic formula. I think for legpts we also use it for local Taylor expansions of Bessel. Before changing this I would like to make sure that we still nail every digit at the boundary with Clenshaw.

[nickhale]

@kuanxu, @ajt60gaibb: I think legpts() and jacpts() should be left out of this discussion. They are not tied to the @chebtech class, and should be free to use bary() if they so wish.

[ajt60gaibb]

Sorry, GITHUB decided to put the "Comment" button right next to the "Close" button. I'll drink less coffee to stop the twitching!

[aaustin141]

This has now been sorted out in the pull request issue #32.