I've tripped myself up multiple times forgetting that flint_printf prints arb balls in a way that doesn't reflect their accuracy. For instance, I've repeatedly overlooked precision losses, misinterpreted things like [0.5 +/- 1.42e-6] as 0.5±1e-30 while the actual value was something like 0.49999999937898754567876543456±1e-30, etc.
It would be great if there was a simple way of having the actual order of magnitude of the radius show in the output—ideally without having to think of adding a flag to every printf call, though, on the other hand, I am not sure changing the default output format would be a good idea. For what it's worth I'm currently using a quick and dirty patch similar to the one below to get something like [0.4999... +/- 1.23e-30] in the above example.
diff --git src/arb/get_str.c src/arb/get_str.c
index e71446223..efc8786d1 100644
--- src/arb/get_str.c
+++ src/arb/get_str.c
@@ -33,7 +33,7 @@ _arb_condense_digits(char * s, slong n)
for (j = 0; isdigit(s[i + j]); j++)
run++;
- if (run > 3 * n)
+ if (run > 2 * n)
{
for (j = 0; j < n; j++)
{
@@ -41,13 +41,13 @@ _arb_condense_digits(char * s, slong n)
out++;
}
- out += flint_sprintf(res + out, "{...%wd digits...}", run - 2 * n);
+ out += flint_sprintf(res + out, "...", run - 2 * n);
- for (j = run - n; j < run; j++)
- {
- res[out] = s[i + j];
- out++;
- }
+ // for (j = run - n; j < run; j++)
+ // {
+ // res[out] = s[i + j];
+ // out++;
+ // }
}
else
{
diff --git src/generic_files/io_vprintf_impl.h src/generic_files/io_vprintf_impl.h
index 1ab812d73..a7dabed09 100644
--- src/generic_files/io_vprintf_impl.h
+++ src/generic_files/io_vprintf_impl.h
@@ -927,7 +927,7 @@ static size_t __arb_print(FLINT_VPRINTF_OUT_T * out, arb_srcptr ip, int flag)
else
ip2 = *ip;
- str = arb_get_str(&ip2, DIGITS, 0);
+ str = arb_get_str(&ip2, 1000, 6*ARB_STR_CONDENSE);
res = FLINT_VPRINTF_WRITE(str, strlen(str), out);
flint_free(str);
I've tripped myself up multiple times forgetting that
flint_printfprints arb balls in a way that doesn't reflect their accuracy. For instance, I've repeatedly overlooked precision losses, misinterpreted things like[0.5 +/- 1.42e-6]as 0.5±1e-30 while the actual value was something like 0.49999999937898754567876543456±1e-30, etc.It would be great if there was a simple way of having the actual order of magnitude of the radius show in the output—ideally without having to think of adding a flag to every printf call, though, on the other hand, I am not sure changing the default output format would be a good idea. For what it's worth I'm currently using a quick and dirty patch similar to the one below to get something like
[0.4999... +/- 1.23e-30]in the above example.