arb_get_str() & arb_set_str() does not preserve value

[saraedum]

Consider the following C program.

$ cat roundtrip.c
#include <arb.h>

int main() {
  arb_t a;
  arb_init(a);

  arb_load_str(a, "2bb573849d73 -2c 800031b 365d");

  arb_printn(a, 1024, ARB_STR_MORE);

  arb_set_str(a, arb_get_str(a, 1024, ARB_STR_MORE), 1024);

  arb_printn(a, 1024, ARB_STR_MORE);
}

When run (with Arb 2.22.1 from conda-forge) it prints:

[+/- 3.65e+4197][+/- 3.66e+4197]

I understand that arb_get_str() can introduce imprecision and I also understand that I should probably use arb_dump_str to serialize an arb_t; but shouldn't arb_set_str() preserve the radius?

[albinahlback]

Neither arb_get_str nor arb_set_str says in their documentation that they preserve the radius. It only states that the old interval is contained in the new interval.

[saraedum]

@albinahlback Thanks, I am aware of that. I am not saying that the implementation breaks the documentation.

[albinahlback]

Then what is your issue? You asked if arb_set_str preserves the radius, for which I gave an answer.

[saraedum]

My question was: Shouldn't arb_set_str() try to preserve the radius here?

[saraedum]

Note that this is somewhat related to flintlib/arb#391. In flintlib/arb#391 arb_get_str introduces an error, here arb_set_str introduces an error.

I wonder if both methods could be more careful when it's possible not to introduce any error.

[JeffreySarnoff]

I have been trying to get this right for a while, testing various approaches and they all end like this:

using Serialization, ArbNumerics
using Serialization: serialize_type
using ArbNumerics: @libarb, @libflint

function Serialization.serialize(s::AbstractSerializer, x::ArbFloat)
Serialization.serialize_type(s, typeof(x))
unsafestr = ccall(@libarb(arf_dump_str), Cstring, (Ref{ArbFloat},), x)
len = Int64(ccall(:strlen, Csize_t, (Cstring,), unsafestr)) + 1
write(s.io, len)
unsafe_write(s.io, pointer(unsafestr), len)
ccall(@libflint(flint_free), Cvoid, (Cstring,), unsafestr)
return nothing
end

function Serialization.deserialize(s::AbstractSerializer, ::Type{ArbFloat{P}}) where {P}
len = read(s.io, Int64)::Int64
str = Serialization.deserialize_string(s, Int(len))
# TODO: call arb_load_str to constuct arb_t from str
x = ArbFloat{P}(0)
ccall(@libarb(arf_load_str), Int, (Ref{ArbFloat{P}}, Ref{Cstring}), x, str)
return x
end

low_precision = 53
high_precision = 320

setworkingprecision(low_precision)

arf_val = log(ArbFloat(17))

2.83321334405621608

serialize_buffer = Serializer(IOBuffer())

Serializer{IOBuffer}(IOBuffer(data=UInt8[...], readable=true, writable=true, seekable=true, append=false,

size=0, maxsize=Inf, ptr=1, mark=-1), 0, IdDict{Any, Any}(),

Int64[], Dict{UInt64, Any}(), 26)

serialize(serialize_buffer, arf_val)

Serializer{IOBuffer}(IOBuffer(data=UInt8[...], readable=true, writable=true, seekable=true, append=false,

size=82, maxsize=Inf, ptr=83, mark=-1), 3, IdDict{Any, Any}(:ArbNumerics => 2, ArbFloat{64} => 0, :ArbFloat => 1),

Int64[], Dict{UInt64, Any}(), 26)

arf_val_recovered = deserialize(serialize_buffer, typeof(arf_val))
ERROR: EOFError: read end of file

[albinahlback]

@fredrik-johansson can you transfer this issue to FLINT?

[albinahlback]

@JeffreySarnoff can you provide a MWE in C for your issue? Also, please use code blocks to format the code.

[albinahlback]

@saraedum So the issue is that when you use string methods, you convert between a binary and a decimal representation on an inexact ring. This forces a loss of information.

[d0sboots]

@saraedum So the issue is that when you use string methods, you convert between a binary and a decimal representation on an inexact ring. This forces a loss of information.

It doesn't force a loss of information, though. It is true that you can't exactly represent one with the other, but with the additional context of the precision you can still keep all the same information. In particular, with ARB_STR_MORE the information in the midpoint is already adequately preserved; preserving the radius is what's at issue here.

[d0sboots]

Here is an example showing one of the obstacles here. arb_set_str doesn't set the correctly rounded result, so (by necessity) it has to inflate the error bounds when setting. It is usually impossible to set a number with an exact bound with this interface.

#include <stdio.h>
#include <stdlib.h>
#include "flint/arb.h"

int main() {
  arb_t x, x2;
  double y;
  arb_init(x);
  arb_init(x2);
  arb_set_str(x, "1.1", 53);
  arb_set_str(x2, "1.1", 100);
  y = strtod("1.1", NULL);
  printf("Value: ");
  arb_printn(x, 20, ARB_STR_MORE);
  printf("\nTrue precision: %g\nDouble value: %.20g\nArb conversion error: ", mag_get_d(arb_radref(x)), y);
  mag_set_ui(arb_radref(x), 0);
  arb_sub(x, x2, x, 100);
  arb_printn(x, 7, ARB_STR_NO_RADIUS);
  printf("\nDouble conversion error: ");
  arb_set_d(x, y);
  arb_sub(x, x2, x, 100);
  arb_printn(x, 7, ARB_STR_NO_RADIUS);
  printf("\n");
  arb_clear(x);
  arb_clear(x2);
  return 0;
}

Value: [1.0999999999999998668 +/- 2.23e-16]
True precision: 2.22045e-16
Double value: 1.1000000000000000888
Arb conversion error: 1.332268e-16
Double conversion error: -8.881784e-17