Merge new contexts code

[GoogleCodeExporter]

Here is a big patch merging changes from the mp4 branch to fully support
multiple contexts (both classes and instances). Also there are some
optimizations and minor bugfixes from that branch. It also adds a machine
precision context, which is still in a very rough state, but which supports
the basics.

A nifty example:

>>> mp.dps = 1000
>>> timing(lambda: mp.findroot(mp.cos, 1))
0.025849207091962804
>>> timing(lambda: mp.findroot(mp.cos, fp.findroot(fp.cos, 1)))
0.016556294165877894

All old tests pass, with the exception of some trivial printing related
issues, and pickling (there is a horrible hack in place atm to fix pickling
-- this needs to be done properly).

This needs more cleanup, and I'd like to do a bit renaming and
reorganizing. Some features that should be shared for the context
implementations is currently duplicated or hackish. A couple of
function/module names are awful and/or awfully inconsistent. There are also
barely any fp tests. We should fix the tests and doctests to import and use
mp and fp objects explicitly, and test both.

Besides the pickling issue, there are also probably issues with generating
the docs now that more things are created dynamically... I haven't looked
at it, but the problems are probably easy to fix.

Also, Vinzent, your code (optimization and matrices) perhaps needs a closer
look. The force_type stuff should be possible to remove; we should always
just convert the inputs, and the fp context will support float/complex. I
did a bit of work on this already, but it needs to be done thoroughly.

Vinzent - do you think it's ok to apply this to the trunk as it is?
Although it will introduce some minor breakage at this point, tests
basically pass, and I'd rather merge as soon as possible so I can also work
on some overdue features and bugfixes without having to worry about having
two codebases.

Original issue reported on code.google.com by fredrik....@gmail.com on 17 Dec 2009 at 5:04

Attachments:

• contexts.diff

[GoogleCodeExporter]

The force_type stuff is anyway somewhat broken, so don't worry. I'll have a 
closer 
look   later.

Basically I'm +1 for merging soon, it's a nice feature, and I assume it's no 
pleasure 
to maintain branches in svn.

> tests basically pass

So do they pass or not? If not, this should probably be fixed before merging, 
otherwise it will be seemingly hard for me to refactor code.

Original comment by Vinzent.Steinberg@gmail.com on 17 Dec 2009 at 7:57

[GoogleCodeExporter]

> So do they pass or not? If not, this should probably be fixed before merging, 
> otherwise it will be seemingly hard for me to refactor code.

The tests pass (at least for me), but the pickle tests pass only due to a 
workaround
(see __init__.py). And there are a few broken doctests (again, broken for 
trivial
reasons).

Original comment by fredrik....@gmail.com on 17 Dec 2009 at 8:10

[GoogleCodeExporter]

Ok, so let's merge your code. There are quite a lot of rough ends, but this can 
be
fixed before the next release.

Original comment by Vinzent.Steinberg@gmail.com on 17 Dec 2009 at 9:09

[GoogleCodeExporter]

Original comment by Vinzent.Steinberg@gmail.com on 19 Dec 2009 at 5:15

• Changed state: Fixed