-
Notifications
You must be signed in to change notification settings - Fork 6
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
Add support for ArbPoly #32
Conversation
I'm pretty amazed by how fast we can bootstrap a new Arb type with almost all Arb functionality wrapped! |
deps/build.jl
Outdated
@@ -0,0 +1 @@ | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
don't re-add build.jl
;)
src/arbcalls/arb_poly.jl
Outdated
arbcall"slong arb_poly_allocated_bytes(const arb_poly_t x)" | ||
|
||
### Basic manipulation | ||
arbcall"slong arb_poly_length(const arb_poly_t poly)" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This needs an import Base: length
at the top
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There will be a similar function in acb_poly.jl
as well. I'm still thinking about how to handle this in a good way.
arbcall"void arb_poly_evaluate2(arb_t y, arb_t z, const arb_poly_t f, const arb_t x, slong prec)" | ||
arbcall"void _arb_poly_evaluate2_acb_horner(acb_t y, acb_t z, arb_srcptr f, slong len, const acb_t x, slong prec)" | ||
arbcall"void arb_poly_evaluate2_acb_horner(acb_t y, acb_t z, const arb_poly_t f, const acb_t x, slong prec)" | ||
arbcall"void _arb_poly_evaluate2_acb_rectangular(acb_t y, acb_t z, arb_srcptr f, slong len, const acb_t x, slong prec)" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here we should probably change the code gen to produce a function which also accepts an ArbVector
for the two arguments arb_srcptr f, slong len
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My plan here was to later implement methods which are not in-place for which we add more conveniences, like automatically picking up the length from AcbVector
and such. It would be great if we could change the code-gen to automatically make length a keyword argument which takes the length of AcbVector
as default value, but I'm worried this would be hard to do. The length parameter is sometimes called len
, sometimes flen
or glen
, so it's hard to automatically identify it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense, but note that I added some code exactly doing this
It would be great if we could change the code-gen to automatically make length a keyword argument which takes the length of AcbVector as default value
in #27 for the vector types 🙃
Adds - ArbPoly and arb_poly_struct types - Support for parsing arb_poly_t - Parsed methods from arb_poly.h
This includes - Constructors - show method - predicates - basic indexing
Now I have finally taken the time to finish this pull request. I have added support for Later on I might do some rearranging of code, moving things from |
Now I have merged this with the updated One thing I noted is that now that the length of the vectors become key-word arguments we have some clashes. Specifically |
src/poly.jl
Outdated
|
||
Base.@propagate_inbounds function Base.setindex!( | ||
poly::Union{ArbPoly,ArbSeries}, | ||
x::Arb, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
x::Arb, | |
x::ArbLike, |
src/poly.jl
Outdated
|
||
Base.@propagate_inbounds function Base.setindex!( | ||
poly::Union{AcbPoly,AcbSeries}, | ||
x::Acb, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
x::Acb, | |
x::AcbLike, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good! Some comments are nitpicky, but I think we should definitely widen the setindex!
methods and add a ref
version for getindex
.
src/poly.jl
Outdated
end | ||
|
||
# Constructors | ||
for (TPoly, T) in [(:ArbPoly, :Arb), (:AcbPoly, :Acb)] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
for (TPoly, T) in [(:ArbPoly, :Arb), (:AcbPoly, :Acb)] | |
for (TPoly, T) in [(:ArbPoly, :ArbLike), (:AcbPoly, :AcbLike)] |
src/poly.jl
Outdated
end | ||
|
||
@eval function $TPoly( | ||
coeffs::AbstractVector{$T}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
coeffs::AbstractVector{$T}; | |
coeffs::AbstractVector{<:$T}; |
end | ||
end | ||
|
||
for (TSeries, T) in [(:ArbSeries, :Arb), (:AcbSeries, :Acb)] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Prob. the same changes as for the poly case above
res = eltype(T)(prec = precision(poly)) | ||
get_coeff!(res, poly, i) | ||
return res | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think should also add a ref(poly:T, i)
method which returns an ArbRef
/AcbRef
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was my initial plan, but it's slightly complicated. Arb allows getting the value of any index i >= 0
, for i
higher than any set index it will just give the value 0. This means that while poly[i]
will be defined for any i >= 0
it might not correspond to an actual arb_struct
in memory.
In practice my experience is that you don't change polynomials element-wise very often, or at least it's definitely not where most of the computational cost lies, so it's not such a big problem.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok that's a fair point :)
src/poly.jl
Outdated
function Base.one(::Type{T}) where {T<:Union{ArbPoly,AcbPoly}} | ||
res = T() | ||
one!(res) | ||
return res | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
function Base.one(::Type{T}) where {T<:Union{ArbPoly,AcbPoly}} | |
res = T() | |
one!(res) | |
return res | |
end | |
Base.one(::Type{T}) where {T<:Union{ArbPoly,AcbPoly}} = one!(T()) |
We can do these way shorter by now :)
I'll wait for #62 to be merged with master and then start updating things! |
I merged it with the updates to master and took care of your comments! The only thing I have not taken care of is adding a |
So far I have just added one commit with
One of the main things to discuss is what interface to use for
ArbPoly
. There is Polynomials.jl but I think that might only work for polynomials with a parametrized type. We could maybe still take inspiration from it and possibly overload some of their methods forArbPoly
. Do you have any other ideas?Another thing is that I want to add a dedicated
ArbSeries
type, basically anArbPoly
with a specified order. Something likeIt would work identically to
ArbPoly
when it comes to interfacing directly with functions from Arb. The difference would be that we overload different methods for it. For example*
would forArbPoly
usearb_poly_mul
whereas forArbSeries
it would usearb_poly_mullow
, forArbPoly
the length would depend on the highest non-zero term whereas forArbSeries
it would be fixed to the given degree. There are a number of differences like that. Here I'm also not sure what interface to use, we could maybe take inspiration from TaylorSeries.jl.