Towards v1.0

[Joel-Dahne]

I have been thinking that it might be time for a 1.0 release. The interface has been fairly stable for some time and I see no reason to stay on 0.x. There are a couple of things I would like to tackle before 1.0

• Finish the transition to Flint v3
• Finish the first version of the documentation
• Reconsider the overloading of some Base methods, in particular union and intersect but also contains
• Reduce usage of XLike types in favor for XOrRef types in the high level interface

The first two points are more or less self explanatory. For the documentation I have made some progress the last month or so.

For union and intersect I have realized that the way we define them contradict the version in Base, and is also easily misused. The issue is that Real types are so both union and intersect already have a well defined meaning for those types, which is different from how we currently use it. For example

julia> using Arblib
julia> union(1.0, 2.0)
2-element Vector{Float64}:
 1.0
 2.0
julia> union(Arb(1), 2.0)
2-element Vector{Arb}:
 1.0000000000000000000000000000000000000000000000000000000000000000000000000000
 2.0000000000000000000000000000000000000000000000000000000000000000000000000000
julia> union(Arb(1), Arb(2))
[+/- 2.01]
julia> intersect(1.0, 1.0)
1-element Vector{Float64}:
 1.0
julia> intersect(Arb(1.0), 1.0)
1-element Vector{Arb}:
 1.0000000000000000000000000000000000000000000000000000000000000000000000000000
julia> intersect(Arb(1.0), Arb(1.0))
1.0000000000000000000000000000000000000000000000000000000000000000000000000000

For that reason I think it would be better to use some other name for taking the union or intersection of two Arb or Acb. My proposal would be setunion and setintersection, in line with for example getinterval, getball and setball. But I'm open to other ideas! The method Base.contains also has similar issues, but I haven't thought so much about how to deal with that one.

Regarding XLike types I have noticed that I very rarely need to use anything other than the XOrRef types with the high-level interface. When I do use the, it is mainly together with the lower-level interface. In most cases the high-level interface already uses XOrRef, but there are some exceptions:

• Most predicates use XLike
• hash
• a couple more spread out though the code
  The main reason to avoid the use of XLike is that it includes Ptr types and this can lead to unexpected behavior. For example we currently overload hash(x::Ptr{Arblib.arb_struct}) to compute the hash of the arb_struct it points to, but if the pointer is null this gives a segmentation fault. For other pointer types the hash of the null pointer is well defined. For predicates it is for example slightly confusing what iszero(Ptr{Arblib.arb_struct}) means, do we check if the pointer is zero or the thing it points to? For these reasons it seems reasonable to me to keep the use of XLike to the low-level interface as much as possible.

I might come up with more things to handle before 1.0, in that case I'll add them here.

[Joel-Dahne]

Closed by #174