Add %precision magic

[minrk]

As requested in #190, this adds a magic %precision, which sets floating point precision for use in pretty printing. Argument can be an integer or a raw format string. If it's an integer and numpy has been imported, numpy printing precision will also be set. If no argument is given, precision will be restored to defaults (repr for float, 8 for numpy).

Examples:

    In [1]: from math import pi

    In [2]: %precision 3

    In [3]: pi
    Out[3]: 3.142

    In [4]: %precision %i

    In [5]: pi
    Out[5]: 3

    In [6]: %precision %e

    In [7]: pi**10
    Out[7]: 9.364805e+04

    In [8]: %precision

    In [9]: pi**10
    Out[9]: 93648.047476082982

[takluyver]

Do we know which exceptions can be raised here? My informal tests suggest that, so long as we're getting a string, we can only get ValueError and TypeError, unless there's a possibility I've missed.

[minrk]

I think that's likely, I was just not sufficiently confident that I knew what all the bases were. I can put that in (and ValueError,AssertionError at L3514).

[takluyver]

I understand that it's good practice to specify something, even if it's just Exception, so that you don't catch KeyboardInterrupt and SystemExit. I don't think it makes much difference for such a trivial try block, though.

[minrk]

Changed the format check to except Exception, and check specifically for ValueError,AssertionError in the integer branch.

Also changed the exception that actually raises from TypeError to ValueError, since I think that's more accurate.

[takluyver]

OK, looks good to me.

[fperez]

Idea and code looks good, but we shouldn't commit this without any kind of tests. I realize that in this case, a good example will likely make a doctest brittle, hence the @skip_doctest is OK. But some kind of test is necessary. An easy solution would be to make a simple doctest-only test, along the lines of the doctest_foo() tests in test_magic.py (note that those must be called doctest_foo(), and should be docstring-only functions with no code).

I also have another thought worth pausing on for a second: I'm concerned about accreting more functionality in purely magics, instead of in library code that's easier to use/test on its own, aside from the magic machinery and calling syntax. In the long run, I think we should strive to make most magics be very small wrappers that process dashed command-line flags (for convenient interactive use) and do little else beyond creating a dict of flags and calling some underlying routine, be it something standalone or some method of the various ipython objects lying around.

After we flush all the work we have on 0.11, one of the big pieces of cleanup we'll need to do is the magic system, so I think the less we continue to grow it in this direction, the easier our cleanup will be.

I have to say that I'm the most guilty party on all of this: the old magics like %run and %edit are a complete nightmare. But even if it will take us a while to clean those up, we should try to write new code in a slightly more testable manner.

[minrk]

I was actually trying to use the examples for a doctest, but the test runner seems to ignore or reinitialize the DisplayFormatter for some reason, and I couldn't figure it out. Do you know why this would be?

Your comment about not putting real code in the magics makes perfect sense. Should I then place the implementation inside PlainTextFormatter (likely into a configurable Trait, like float_precision), and replace the magic with a very thin wrapper on that?

[fperez]

No, no idea what can be going on with the doctest, sorry. All the more reason to make it a more library-style piece we can test functionally, without relying on the running environment. Still, I know we need to clean and simplify all that so the test environment is as normal as possible. I've made some improvements, but there's a ton more to do.

Yes, that sounds to me as good a place as any to put the implementation in.

[minrk]

changes made.

• moved content of %precision into PlainTextFormatter_float_precision_changed configurable trait
• %precision is now 2 lines that simply sets PTF.float_precision
• added doctests for %precision
• added tests for PTF.float_precision

[fperez]

Let's keep import statements alphabetically ordered, it makes it easier later to find if something has already been imported or not.

[fperez]

Thanks! Other than the trivial ordering of the imports, merge away. Great job.

[minrk]

Okay, thanks.

I'll go a head and merge.

[minrk]

reorder stdlib imports

closed by 8e2b825

[rominf]

I try to teach my friend to make scientific computations with IPython Qt console (pylab mode). As a programmer I understand difference between float and sympy.core.numbers.Float and why printing of some numbers changes after execution:

%precision 3

and some do not, for example:

var('x')
solve(x**2-2,x)[0].n()

But it's hard to describe the difference to newbie. Calling n method with the same argument isn't pretty solution.

I think %precision function should change printing precision for Sympy's floats too.

By the way, I didn't find method for changing printing precision for sympy numbers at all. As I understood after 10-minute googling I should use sympy's printer classes, but that's very unintuitive!

PS: IMHO, problems appears because of 3 different float types exists: native Python's float, Numpy's float, Sympy's float (as I understood it uses mpmath for numbers, sigh). Are there chances for unifying floats to at most 2 different float (native and mathematical)?

[minrk]

numpy actually handles its own representations of floats, the %precision magic just calls the numpy api function to change this (numpy.set_printoptions). If sympy has a similar API function, we can do the same, but display precision is more subtle in sympy.