nf -> float conversion should be fast

[vdelecroix]

Given a quadratic number field, conversion to Python floating point is terribly slow compared to the more complicated MPFI interval floating point conversion

sage: %timeit float(a)
1000 loops, best of 3: 224 µs per loop
sage: %timeit RIF(a)
1000000 loops, best of 3: 919 ns per loop

With the branch applied

sage: %timeit float(a)
1000000 loops, best of 3: 245 ns per loop

(see also #26925 for MPFR floating point)

[vdelecroix]

New commits:

​390747a

26925: faster float conversion for quad nf elts

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​a599034

26927: faster float conversion for quad nf elts

[nbruin]

I agree it should be fast, but I'm not sure it should be *that* fast. It's not so strange to expect that if they transfer an algebraic number into RealField(100), they actually get something on which (close to) 100 digits are correct. That can be quite tricky, especially with high powers of fundamental units, where one conjugate will have large absolute value (easy to compute) and the other has small absolute value. If you compute these by first writing out the unit as a+b*sqrt(d) and then compute the embedding, it's quite a bit of work to get the precision right (due to a large amount of cancellation). Of course, if you have the element as a power, it's much easier: compute embedding and then take power.

If people need super-fast coversions, they should probably have a recipe to do so. I don't think the standard coercions are the place to sacrifice accuracy for speed.

[vdelecroix]

I agree with you. But this ticket is *not* about conversion to RealField(100) but to Python floats. See #29625 for the relevant ticket.

[nbruin]

Replying to vdelecroix:

I agree with you. But this ticket is *not* about conversion to RealField(100) but to Python floats. See #29625 for the relevant ticket.

Oh, sorry. The same applies to the 53 bits that float has, though. So I'd suggest to share the same code between the two.

[embray]

Retarging tickets optimistically to the next milestone. If you are responsible for this ticket (either its reporter or owner) and don't believe you are likely to complete this ticket before the next release (8.7) please retarget this ticket's milestone to sage-pending or sage-wishlist.

[embray]

Ticket retargeted after milestone closed (if you don't believe this ticket is appropriate for the Sage 8.8 release please retarget manually)

[dkrenn]

Code looks good to me, but there are some failing doctests says the patchbot. I think they are all related to the exception raised in case of complex values.

And, there should be doctests covering the else-branch of the outer if, and maybe one as well which raises the exception.

[embray]

Tickets still needing working or clarification should be moved to the next release milestone at the soonest (please feel free to revert if you think the ticket is close to being resolved).

[embray]

Ticket retargeted after milestone closed

[mkoeppe]

Batch modifying tickets that will likely not be ready for 9.1, based on a review of the ticket title, branch/review status, and last modification date.

[mkoeppe]

Setting new milestone based on a cursory review of ticket status, priority, and last modification date.

[mkoeppe]

Setting a new milestone for this ticket based on a cursory review.