Skip to content

Generalise Clenshaw #112

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 8 commits into from
Jul 16, 2020
Merged

Generalise Clenshaw #112

merged 8 commits into from
Jul 16, 2020

Conversation

dlfivefifty
Copy link
Member

No description provided.

@assert length(c) == length(A) == length(B) == length(C)-1
@assert length(x) == length(phi0) == length(f)
N = length(c)
if length(A) < N || length(B) < N || length(C) < N
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@MikaelSlevinsky Do you agree that length(C) < N is fine? Before it seemed like it required an extra coefficient for no reason.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's because of the DLMF notation for C. You don't need C[0] to get p1 because p_{-1} == 0, but Clenshaw needs C[n] but only A[n-1] and B[n-1] (using C array indexing)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You could get away with pointing to the right place, but I thought an extra entry to match notation would be reasonable.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think that makes sense to require allocating an extra entry that is never used. I guess we can do pointer(c)-sizeof(T) to work around this?

@dlfivefifty
Copy link
Member Author

I don't see the coverage

@dlfivefifty dlfivefifty marked this pull request as draft July 16, 2020 08:19
@dlfivefifty dlfivefifty marked this pull request as ready for review July 16, 2020 12:56
@dlfivefifty
Copy link
Member Author

This is ready for review. OrthogonalPolynomialsQuasi.jl now successfully uses this version of forwardrecurrence!, with clenshaw! coming shortly.

@dlfivefifty
Copy link
Member Author

Note it's possible to special case Chebyshev T as well:

https://github.com/JuliaApproximation/OrthogonalPolynomialsQuasi.jl/blob/357550d358e3e738eab23caef76aab3304ba03da/src/OrthogonalPolynomialsQuasi.jl#L146

I decided not to move that here as it would mean adding a dependency on LazyArrays.jl, which is still a very in-progress package.

@MikaelSlevinsky
Copy link
Member

No idea why coverage isn't working.

@MikaelSlevinsky MikaelSlevinsky merged commit f89dbb3 into master Jul 16, 2020
@dlfivefifty
Copy link
Member Author

Wait!! I just said it was ready for review, not merge!

@dlfivefifty
Copy link
Member Author

I wanted to look at the coverage first

@MikaelSlevinsky
Copy link
Member

But it passed the review!

@MikaelSlevinsky
Copy link
Member

Looking at the templates, I think the codecov upload action has changed https://github.com/invenia/PkgTemplates.jl/pull/181/files

@dlfivefifty
Copy link
Member Author

OK good to get it fixed: I've become almost religious about making sure the diff is covered, it just avoids headaches down the line.

@MikaelSlevinsky
Copy link
Member

I guess I'll simultaneously up the package version to 0.10 since this adds more "features"?

@dlfivefifty
Copy link
Member Author

Wait, adding some more stuff right now in a new PR.

@dlfivefifty dlfivefifty deleted the dl/generalclenshaw branch July 16, 2020 14:42
@dlfivefifty
Copy link
Member Author

No, new features is not a new minor version, only new, breaking features.

So only v0.10 if we, say, export clenshaw!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants