#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:
-------------------------------+--------------------------------------------
Changes (by craigcitro):
* milestone: sage-duplicate/invalid/wontfix => sage-4.3.2
Comment:
Robert:
I think there are several places we could put the code -- if nothing else,
it might be nice to keep it in `coerce.pyx`, so that it's the one place
where all the "rules" for coercion appear. Also, if we ultimately wanted
to implement such a pathway for something that isn't a `RingElement`
(which is the `__mul__` we're going to need to put the code in), the code
would be in the same place.
Also, I'd prefer to just go ahead and implement it for arithmetic on both
sides -- we can do two type comparisons as `PY_TYPE_CHECK_EXACT`, and if
need be, tell the branch predictor that they're unlikely (because they are
in the general case, I think). I'm always suspicious of rules like "keep
the Python int on the right, because that's 10X faster." I'd also hate to
have to make a comment in a patch review saying "oh, this speeds up by a
factor of 10 if you reverse the order of operands." I know these things
exist elsewhere -- but that's no reason to add one more to the pile.
Plus, it's sure to lead to a ton of posts on the mailing list about it,
where people think they've found a new "bug." `:)`
I suspect you're going to be on campus in a few hours -- we can chat about
this then.
Fredrik:
That's a really good use-case. 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.)
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.)
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/6199#comment:9>
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.
