Document common trap in `arb_set_d`

[rudolph-git-acc]

Ref. this AskSagemath-question: https://ask.sagemath.org/question/76066/ghost-numbers-when-using-arb/

When I run this simple code in my IDE:

    #include "flint/arb.h"
    
    int main(int argc, char **argv)
    {
    	arb_t a;
    	arb_init(a);
    	
    	slong prec;
    	prec = 256;
    	
    	arb_set_d(a, 1.1);
    	arb_printd(a, 70);
    	printf("  WRONG \n");
    	
    	arb_set_str(a, "1.1", prec);
    	arb_printd(a, 70);
    	printf("  FINE \n");
    	
    	arb_set_d(a, 1);
    	arb_printd(a, 70);
    	printf("  FINE \n");
    	
    	arb_clear(a);
    	return 0;
    }

I obtain:

1.100000000000000088817841970012523233890533447265625000000000000000000 +/- 0  WRONG 
1.100000000000000000000000000000000000000000000000000000000000000000000 +/- 1.7272e-77  FINE 
1.000000000000000000000000000000000000000000000000000000000000000000000 +/- 0  FINE 

Only the arb_set_d command seems to induce this issue and only for non-integer values. Is this a bug or an unavoidable effect?

[albinahlback]

I don't know what you specifically mean by "wrong" here, or a "bug".

1. arb_set_d will only convert a double to an arb_t. If the double is "inexact" (meaning that the original decimal number is not representable as a dyadic rational), that's on the user -- FLINT/Arb is not a compiler.
2. arb_set_d will not impose some error bound since it doesn't know if the double is inexact or not. Once again, that's on the user.

As 1.1 is not representable as a dyadic rational, you should not expect Arb to give a "correct" number. It will only convert what is given to it, which is an approximation, which in turn an arb_t can represent.

[vneiger]

Reading the provided code and the sagemath link, I think the following addition to the answer of @albinahlback might be useful for @rudolph-git-acc : observe what you get from the following piece of C,

printf("%.20f\n", 1.1);

It should yield 1.10000000000000008882. This is what is meant by "inexact" (not representable etc.) above, and this has nothing to do with arb or flint or sagemath. (Sorry for the noise if that was already clear to you.)

[rudolph-git-acc]

@vneiger Thanks for the clarification. Your example is very helpful and I had never appreciated the "inexact" issue.

It is good to be aware of this though and maybe it is worthwhile mentioning it in the documentation of arb_set_d. I have for instance seen it being used in setting integral limits and there it could make a big difference e.g. in a lower limit close to zero. Or for instance in this issue on the old ARB GitHub : flintlib/arb#451 Replacing arb_set_d by are_set_str has an immediate impact on the result.

I most certainly don't want to blame FLINT/ARB for having "bugs" or being "wrong" and will include a link to this thread in my AskSageMath question.

[albinahlback]

Yes, this should be documented. Thanks for bringing this up!

[albinahlback]

Fixed in 0c07030

[rudolph-git-acc]

Sorry to be a pain, but the same issue could be induced by the following commands:

\

\

\

The latter is often used in setting integral limits. Probably good to update the documentation for these as well.

P.S.
I believe we should be good for fmpz-types:

[edgarcosta]

arf_set_d does not have this issue, one is converting between two equivalent representations.