Opened 10 years ago
Closed 9 years ago
#11647 closed defect (duplicate)
Numerical approximation to one digit
Reported by: | eviatarbach | Owned by: | jason, jkantor |
---|---|---|---|
Priority: | major | Milestone: | sage-duplicate/invalid/wontfix |
Component: | numerical | Keywords: | |
Cc: | Merged in: | ||
Authors: | Reviewers: | Karl-Dieter Crisman, Julian Rueth, Eviatar Bach | |
Report Upstream: | N/A | Work issues: | |
Branch: | Commit: | ||
Dependencies: | Stopgaps: |
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 (16)
comment:1 Changed 10 years ago by
- Summary changed from Numerical approximation one digit to Numerical approximation to one digit
comment:2 Changed 10 years ago by
comment:3 follow-up: ↓ 4 Changed 10 years ago by
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
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
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
- 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
comment:8 Changed 9 years ago by
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
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
Ok. And the original reporter should probably also weigh in...
comment:11 Changed 9 years ago by
There seems to be a consensus that this behaviour is acceptable, so feel free to close.
comment:12 Changed 9 years ago by
- 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
- Status changed from needs_review to positive_review
comment:14 Changed 9 years ago by
Please fill in your real name as Author.
comment:15 Changed 9 years ago by
comment:16 Changed 9 years ago by
- Milestone changed from sage-5.3 to sage-duplicate/invalid/wontfix
- Resolution set to duplicate
- Status changed from positive_review to closed
Here is the code:
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?
My first instinct, thus, is that this is not a bug, though more details are welcome.