Few digits of precision in N().

[sagetrac-gerbicz]

For N(1+10**-400000,digits=400001) the displayed number of digits is only 400000, it is printing 1. followed by 399999 zeroes. The reason is that in functional.py: prec = int((digits+1) * 3.32192) + 1. However log(10)/log(2)~3.3219280948874>3.32192, so if digits is large the used precision will be smaller by some digits than the requested number of digits.

The suggestion is to use 3.32193 instead of 3.32192, see the trivial patch.

---

Apply: attachment: trac_10164_folder_sans_whitespace.patch to Sage library

CC: @kcrisman

Component: misc

Keywords: N, digits, numerical approximation

Author: Robert Gerbicz, Douglas McNeil

Reviewer: Karl-Dieter Crisman, Benjamin Jones

Merged: sage-5.1.beta3

Issue created by migration from https://trac.sagemath.org/ticket/10164

[kcrisman]

comment:1

Attachment: 10164.patch.gz

See also this sage-devel thread. Doug reports the following evil lines:

misc/functional.py:            prec = int((digits+1) * 3.32192) + 1 
rings/complex_interval.pyx:    bits = 
max(int(3.32192*len(s_real)),int(3.32192*len(s_imag))) 
rings/complex_number.pyx:    bits = 
max(int(3.32192*len(s_real)),int(3.32192*len(s_imag))) 
rings/real_mpfi.pyx:        bits = int(3.32192*len(s)) 
rings/real_mpfr.pyx:            bits = int(3.32192*sigfigs)+1 
symbolic/expression.pyx:                prec = int((digits+1) * 3.32192) + 1 

So a full patch would fix all of these, though we definitely want to keep the original author on. Also need doctests for these large cases, of course.

I can't believe I never saw this ticket.

[kcrisman]

Changed keywords from N, digits, numerical approximation to N, digits, numerical approximation beginner

[sagetrac-dsm]

comment:2

I'm on this one.

[sagetrac-dsm]

comment:3

Okay, I have a patch. Testing now. Turns out it's a little trickier to doctest than I thought, because some of the bugs can't be triggered yet because of other limitations. :-/

[sagetrac-dsm]

Attachment: trac_10164_round_up_log10_2.patch.gz

roud up log(10,2)

[sagetrac-dsm]

round up log(10,2)

[sagetrac-dsm]

comment:4

Attachment: trac_10164_round_up_log10_2.2.patch.gz

Okay, so I've changed all six instances of "3.32192" (which seems to be the most common approximation to log(10,2) in use). There are three other references matching 3.32* (in rings/arith.py, interfaces/gp.py, and libs/pari/gen.pyx) I left alone. Those all have at least 10 digits, so the problem would be pushed to higher levels even if it occurs, and there was in every case something I wasn't confident enough of to change. I don't know much about how pari's precision works, for example.

I think it's a step in the right direction, anyhow.

[sagetrac-dsm]

Changed author from Robert Gerbicz to Robert Gerbicz, Douglas McNeil

[kcrisman]

Reviewer: Karl-Dieter Crisman

[kcrisman]

comment:5

I think it's a step in the right direction, anyhow.

Very clever testing.

Very minor 'needs work' issues:

• I think you could also add as a doctest the example at Missing digits in numerical_approx #12163 (a dup, more or less). We do like doctesting problems people officially put on tickets. That sort of example has the added benefit of being a little easier to read :) Of course, if more than one person disagrees, it's not a big deal.
• Needs to be done - your doc lines are really long. Compare

s_real -- a string that defines a real number (or something whose

to

Make sure we've rounded up log(10,2) enough to guarantee sufficient precision (trac #10164).

Try to shorten those puppies up to the 80-character limit (if I recall correctly) for fine terminal viewing.

Because this has the potential to do weird things to doctests, I'm not going to give positive review in any case until I run long tests. But looks good other than those tiny issues.

Also, a question: I assume it's okay (and already the case, in fact) that we have MORE digits than "officially requested" by the user.