Numerical approximation to one digit

[eviatarbach]

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

sage: n(3.4, digits=1)
3.4

This should return 3.

[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.

[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.

[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.

[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).

[kcrisman]

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

[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.

[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?

[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.

[kcrisman]

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

[eviatarbach]

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

[jdemeyer]

Please fill in your real name as Author.