#6199: Integer * int is slow
-------------------------------+--------------------------------------------
Reporter: fredrik.johansson | Owner: somebody
Type: defect | Status: needs_info
Priority: major | Milestone: sage-4.3.2
Component: basic arithmetic | Resolution:
Keywords: | Author:
Upstream: N/A | Reviewer:
Merged: | Work_issues:
-------------------------------+--------------------------------------------
Comment(by fredrik.johansson):
Craig:
> That said, I guess I don't understand why GMP/MPIR don't use unboxed
immediate integers for small values, but given that I haven't played with
the guts of the code, they probably know better than I do. It would be
nice in your case, though -- you could have both counter_type and
value_type be Integer. (Well, you might run into some issues when you only
used small values, but in principle, anyway.)
This is actually on MPIR's list of "development ideas"; I think the only
reason it isn't supported is that no one has written the code yet. Still,
there are reasons to keep using Python ints: ints are a bit faster than
custom types because they are special-cased in various places in the
Python interpreter, and JITs can optimize them (psyco does a decent job
with mpmath partly because of this -- maybe in the future we'll also have
Unladen Swallow and !PyPy).
> I'm curious: is this code going to be used as part of the "core" of
mpmath, or will you just write the code so it takes advantage of Sage
whenever it's available? (My impression was that you liked mpmath being
pure Python.)
It already uses sage.Integer when it's available.
Since the core is fairly complex (and hence difficult to optimize), I've
recently split everything cleanly into "core" and "high level" code. All
the high level code can easily use different cores (or "contexts"). There
is now both the standard multiprecision context, and a fully working
machine-precision context (using float/complex) implemented in less than
300 lines of code. It should be possible to implement a light wrapper of
Sage's real and complex numbers in close to 300 lines so that Sage can use
all the high-level functions in mpmath "natively".
Still, since Sage's numbers don't provide quite the same features as
mpmath's core, it remains necessary to continue optimizing mpmath's core
as well. This will eventually have to be done by rewriting more of it in
Cython (already a few Cython helper functions are imported from Sage when
available). But for now, fixing basic inefficiencies in the present code
(such as this issue) seems worthwhile IMHO.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/6199#comment:11>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
