ArbVector (first try) about arblib.jl

[Joel-Dahne]

The struct for ArbVector, AcbVector and the such should not really depend on how we choose to handle mutability and non-allocation right? What I might do is to start implementing the simpler parts, defining the types and such.

[Joel-Dahne]

Nice! So this would be an example where indexing does not required allocations right? And then it would be the users responsibility to not use any variables gotten from indexing after the vector is freed.

I have some ideas for how we could do the unsafe indexing in Arblib, I'll write about it in the other issue.

[Joel-Dahne]

Never mind, I'll just write it here. If we define an ArbVector as a Ptr{arb_struct} (plus some metadata) then one way to allow inplace operations would be to rewrite our arbcall to not only work on Arb but also on arb_struct. Then you could work directly on the Ptr{arb_struct} using the same low-level methods as for Arb, one issue is that we would not know which precision to use but we could maybe just default to the global precision and if you want something else you have to be explicit about it. I think this would be fine to do for the low-level methods, if you use them you should expect some friction. So you could do something like

v = ArbVector([1, 2, 3])
Arblib.add!(Arblib.unsafe_getindex(v, 1), Arblib.unsafe_getindex(v, 1), 5, prec = precision(v))

It should also work for referencing radius and midpoint

x = Arb(pi)
r = Mag(1e-10)
Arblib.cmp(x.radius, r)

The higher level interface, v[1] and radius(x), could then be written in a safe way with allocations.

[kalmarek]

unsafe_load does copy the data, so it's not allocation free.

I just tried

v = [1,2,3]
CC = AcbField(256)
jlv = CC.(v)
arbv = AcbVector(jlv)
unsafe_wrap(Array, arbv.ptr, (3,)) # ← truly non-allocating

but it crashes instantly :D

[Joel-Dahne]

Okay, so it does allocation for the struct but does not call arb_init and thus doesn't need to allocate space for the pointers in the struct at least? I hope to have time to experiment a bit more with this in the weekend.

[kalmarek]

@Joel-Dahne that is correct: unsafe_load allocates a julia object and copies the corresponding fields to it. However the arblibs data (the fields are pointing to) are not copied, therefore the result is an unsafe object.
To be precise, this is the correct syntax to add 5 to the first coordinate:

v = ArbVector([1, 2, 3])
GC.@preserve v
    Arblib.add!(Arblib.unsafe_getindex(v, 1), Arblib.unsafe_getindex(v, 1), 5, prec = precision(v))
    b = Arblib.unsafe_getindex(v, 1)
    # do something with b, but never leak it out of @preserve block:
    (b > 1 ? true : false)
end

I'm not sure if unsafe_getindex is the right name here: in julia unsafe_* means that the arguments need to be checked for validity, but the result is a safe julia object. Here, it's the opposite...

[Joel-Dahne]

One problem I see if we copy the struct is that some of the data is stored directly in the struct and some of it where the fields are pointing to, which data is stored in the struct also depends on the data. So if we copy the struct and update the fields the original copy might or might not be updated correctly.