Opened 5 years ago

# inconsistent interval evaluation of pFq

Reported by: Owned by: Marc Mezzarobba minor sage-wishlist numerical David Einstein N/A

Add support for conversion of the hypergeometric symbolic function to ball fields, e.g.

```sage: foo = 1/4*hypergeometric((1, 1, 1, 1, 1), (3/2, 2, 2, 2), 1/8)
sage: RBF(foo)
```

### comment:1 Changed 5 years ago by Fredrik Johansson

The balls are suspiciously precise. It looks like it's going through `RealField`:

```sage: RealBallField(53)(RealField(53)(foo))
[0.2526850273732758 +/- 5.66e-18]
sage: RealBallField(100)(RealField(100)(foo))
[0.2526850273732758327317762593029 +/- 4.32e-32]
```

### comment:2 Changed 4 years ago by David Einstein

The underlying problem here is in the RBF `element_constructor` the coercion attempts are something like

1. Try to convert directly to a RealBall?
2. Try to convert to a pyobject, then to a RealBall?
3. Try to convert the operands of the object to RealBalls?, then apply the operator to them to compute the RealBall?
4. Drop back and compute the value as an element of RealIntervalField? then convert to a RealBall?

In this case step 3 goes horribly wrong because the first operand of hypergeometric((1, 1, 1, 1, 1), (3/2, 2, 2, 2), 1/8) is a tuple and any attempt to convert it to a RealBall? is doomed to failure. This coupled with the fact that the RealBall? field does not implement the hypergeometric functions (connecting arb_hypgeom_pfq to RealBall? seems straightforward, but connecting that somehow to symbolic.expression seems problematic).

Which basically means that this is all over my head.

The fact that step 4 succeeds but gives an incorrect answer suggests that there are similar problems with RIF.

### comment:3 in reply to:  description Changed 2 years ago by Marc Mezzarobba

Description: modified (diff) sage-8.2 → sage-wishlist major → minor defect → enhancement

```sage: foo = 1/4*hypergeometric((1, 1, 1, 1, 1), (3/2, 2, 2, 2), 1/8)
sage: a = RBF(foo); a
[0.2526850273732758 +/- 5.66e-18]
sage: b = RealBallField(100)(foo); b
[0.2526850273732758327317762593029 +/- 4.32e-32]
sage: a.overlaps(b)
False
```

This doesn't happen with python-flint and the last version of arb: it may either be a sage-specific issue or a bug in the version of arb that sage is using.

Now fixed by making the conversion raise an error, probably in #28517 or one of its dependencies. It may still be nice to implement the correct conversion.

Note: See TracTickets for help on using tickets.