# Ticket #11647(closed defect: duplicate)

Opened 22 months ago

## Numerical approximation to one digit

Reported by: Owned by: eviatarbach jason, jkantor major sage-duplicate/invalid/wontfix numerical N/A Karl-Dieter Crisman, Julian Rueth, Eviatar Bach

### Description

Sage behaves unexpectedly when returning a numerical approximation to one digit:

```sage: n(3.4, digits=1)
3.4
```

This should return 3.

## Change History

### comment:1 Changed 22 months ago by eviatarbach

• Summary changed from Numerical approximation one digit to Numerical approximation to one digit

### comment:2 Changed 22 months ago by kcrisman

Here is the code:

```    if prec is None:
if digits is None:
prec = 53
else:
prec = int((digits+1) * 3.32192) + 1
try:
return x._numerical_approx(prec)
```

I think the idea is to give at least one correct digit. It is a numerical approximation, after all, not a truncation. What would you expect from this?

```sage: n(3.7,digits=1)
```

My first instinct, thus, is that this is not a bug, though more details are welcome.

### comment:3 follow-up: ↓ 4 Changed 22 months ago by eviatarbach

I would expect 4. from that, similar to

```sage: n(37.7,digits=2)
38.
```

Considering that for any number other than one (except very large ones, see  http://trac.sagemath.org/sage_trac/ticket/10164), the number of digits in the returned number is equal to the digits argument, I think it is an unexpected result. It can be trivially fixed by adding a special case when the argument is one.

### comment:4 in reply to: ↑ 3 Changed 22 months ago by nbruin

Don't expect exact results for decimal arithmetic. The underlying type is base 2. The fact that n allows "digits" to be specified in terms of decimal digits is for convenience only. When you specifying digits=1 you are really asking for ln(10)/ln(2)=3.3219 binary digits. Naturally, the system can't give you exactly what you ask for. In fact the system refuses to give you less than 53 binary digits, because there is no gain in keeping track of less. This translates to almost 16 decimal digits.

If you want decimal arithmetic rather than binary arithmetic (there is a difference when you're working with floats!), use a package that gives you that. See the decimal module that comes standard with python. It allows accurately setting the precision with which to do arithmetic.

Sage's "RealNumber?" is trying to approximate the real numbers in behaviour. It is not concerned with managing low precisions very accurately.

### comment:5 Changed 22 months ago by eviatarbach

I'm not talking about precision in arithmetic, simply saying that the user would expect the digits argument in the numerical approximation function to return a number with that number of digits, which of course is converted into bits of precision. As setting the digits argument to one is the only number which returns unexpected results, I think a special case should be added.

By the way, this is also the way Mathematica acts ( http://www.wolframalpha.com/input/?i=N%5BGamma%5B3.3%5D%2C+1%5D).

### comment:6 Changed 21 months ago by kcrisman

• Status changed from new to needs_info

Since there doesn't seem to be a consensus on whether this is a bug yet, setting to 'needs info'.

### comment:7 Changed 18 months ago by saraedum

I think it's acceptable that digits=1 shows some strange behavior. I believe it should at least be documented, so I wrote a patch at #12120 to do so. Btw. should we assert that digits is not 0? Otherwise this should be added at #12120 as well.

### comment:8 Changed 10 months ago by kcrisman

At this point I'm wondering whether this is just a dup of #12120. Or should it be considered a bug of some sort?

### comment:9 Changed 10 months ago by saraedum

As I said before, I don't think this is a bug since it is documented now. So from my point of view this can be closed.

### comment:10 Changed 10 months ago by kcrisman

Ok. And the original reporter should probably also weigh in...

### comment:11 Changed 10 months ago by eviatarbach

There seems to be a consensus that this behaviour is acceptable, so feel free to close.

### comment:12 Changed 10 months ago by kcrisman

• Status changed from needs_info to needs_review
• Reviewers set to Karl-Dieter Crisman, Julian Rueth, Eviatar Bach

### comment:13 Changed 10 months ago by kcrisman

• Status changed from needs_review to positive_review