Opened 10 years ago

Closed 9 years ago

# Numerical approximation to one digit

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

### Description

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

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

This should return 3.

### comment:1 Changed 10 years ago by eviatarbach

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

### comment:2 Changed 10 years 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 10 years 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 10 years 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 10 years 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 10 years 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 9 years 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 9 years 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 9 years 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 9 years ago by kcrisman

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

### comment:11 Changed 9 years ago by eviatarbach

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

### comment:12 Changed 9 years ago by kcrisman

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

### comment:13 Changed 9 years ago by kcrisman

• Status changed from needs_review to positive_review